Bug 91401

Created attachment 117255 [details]
dmesg output

The driver seems to be detecting the panel correctly:
[   42.682109] [drm] Panel ID String: Samsung LTN150P1-L02    
[   42.682117] [drm] Panel Size 1400x1050
Do you have an xorg config that might be limiting the modes?

Created attachment 117272 [details]
xorg.conf

Does it work correctly if you remove your xorg config?

If I remove the xorg.conf, then the Xorg.0.log says:

.
.
.
[    80.495] (II) RADEON(0): EDID for output VGA-0
[    80.497] (II) RADEON(0): EDID for output DVI-0
[    80.497] (II) RADEON(0): EDID for output LVDS
[    80.497] (II) RADEON(0): Printing probed modes for output LVDS
[    80.497] (II) RADEON(0): Modeline "1280x1024"x59.9  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync (63.7 kHz)
[    80.497] (II) RADEON(0): Modeline "1280x960"x59.9  101.25  1280 1360 1488 1696  960 963 967 996 -hsync +vsync (59.7 kHz)
[    80.497] (II) RADEON(0): Modeline "1280x854"x59.9   89.25  1280 1352 1480 1680  854 857 867 887 -hsync +vsync (53.1 kHz)
[    80.497] (II) RADEON(0): Modeline "1280x800"x59.8   83.50  1280 1352 1480 1680  800 803 809 831 -hsync +vsync (49.7 kHz)
[    80.497] (II) RADEON(0): Modeline "1280x720"x59.9   74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync (44.8 kHz)
[    80.497] (II) RADEON(0): Modeline "1152x768"x59.8   71.75  1152 1216 1328 1504  768 771 781 798 -hsync +vsync (47.7 kHz)
[    80.497] (II) RADEON(0): Modeline "1024x768"x59.9   63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync (47.8 kHz)
[    80.497] (II) RADEON(0): Modeline "800x600"x59.9   38.25  800 832 912 1024  600 603 607 624 -hsync +vsync (37.4 kHz)
[    80.497] (II) RADEON(0): Modeline "848x480"x59.7   31.50  848 872 952 1056  480 483 493 500 -hsync +vsync (29.8 kHz)
[    80.497] (II) RADEON(0): Modeline "720x480"x59.7   26.75  720 744 808 896  480 483 493 500 -hsync +vsync (29.9 kHz)
[    80.497] (II) RADEON(0): Modeline "640x480"x59.4   23.75  640 664 720 800  480 483 487 500 -hsync +vsync (29.7 kHz)
[    80.507] (II) RADEON(0): EDID for output S-video
[    80.507] (II) RADEON(0): Output VGA-0 disconnected
[    80.507] (II) RADEON(0): Output DVI-0 disconnected
[    80.507] (II) RADEON(0): Output LVDS connected
[    80.507] (II) RADEON(0): Output S-video disconnected
[    80.507] (II) RADEON(0): Using exact sizes for initial modes
[    80.507] (II) RADEON(0): Output LVDS using initial mode 1280x960
.
.
.

Any chance you could bisect?

(In reply to Alex Deucher from comment #6)
> Any chance you could bisect?

I'm not sure how. The problem begun with the upgrade from kernel 3.19.8 to kernel 4.0.0.

(In reply to Alex Deucher from comment #6)
> Any chance you could bisect?

After bisect I've found this:

Bisecting: 5 revisions left to test after this (roughly 3 steps)
[dafffda023b04f87e695dfcf5448e4da964d2e95] drm/info: Remove unused code
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[abc0b1447d4974963548777a5ba4a4457c82c426] drm: Perform basic sanity checks on probed modes
Bisecting: 0 revisions left to test after this (roughly 1 step)
[05acaec334fcc1132d1e48c5042e044651e0b75b] drm: Reorganize probed mode validation
abc0b1447d4974963548777a5ba4a4457c82c426 is the first bad commit
commit abc0b1447d4974963548777a5ba4a4457c82c426
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Dec 17 13:56:23 2014 +0200

    drm: Perform basic sanity checks on probed modes
    
    Make sure the timings of probed modes at least pass some very basic
    sanity checks.
    
    The checks include:
     - clock,hdisplay,vdisplay are non zero
     - sync pulse fits within the blanking period
     - htotal,vtotal are big enough
    
    I have not checked all the drivers to see if the modes the generate
    might violate these constraints. I'm hoping not, because that would mean
    either abandoning the idea of doing this from the core code, or fixing
    the drivers.
    
    I'm not entirely sure about limiting the sync pulse to the blanking
    period. Intel hardware doesn't support such things, but some other
    hardware might. However at least HDMI doesn't allow having sync pulse
    edges within the active period, so I'm thinking the check is probably
    OK to have in the common code.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 ff2bab0e9a547755015e7b01560baf3605acd877 46c30fe9db7cb878d967cfaafc98cc2af9a152c9 Mdrivers
:040000 040000 af6a775d10e6af6e31efd465f9eb15e61532b0c9 fadb2a79569c8ceb25af9ea4d0944630d444cf19 Minclude

Created attachment 117398 [details] [review]
more debugging

Can you attach the dmesg output with this kernel patch applied?

Created attachment 117400 [details]
Here is the dmesg output from bad patch.

(In reply to Alex Deucher from comment #9)
> Created attachment 117398 [details] [review] [review]
> more debugging
> 
> Can you attach the dmesg output with this kernel patch applied?

Oh Sorry the last attachment is without the patch. One moment Please. The Attachment with the patch follows.

Created attachment 117404 [details]
dmesg from first bad commit with patch

Created attachment 117405 [details]
dmesg from last good commit with patch

Please attach a copy of your vbios.

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

Created attachment 117410 [details]
The Video BIOS ROM

Created attachment 117411 [details] [review]
possible fix

Does this fix the issue?

(In reply to Alex Deucher from comment #16)
> Created attachment 117411 [details] [review] [review]
> possible fix
> 
> Does this fix the issue?

Yes, it works with this patch. 

Thank you very very much.

I see that the patch was applied to the latest kernel.

I think I can change the status of this bug to resolved.