Created attachment 122709 [details] Boot log #1 [This is extracted the from the mailing list thead here: https://lists.freedesktop.org/archives/dri-devel/2016-April/104142.html] My setup is an embedded GM45 based board with a screen connected via 24 bit LVDS. After boot to console (no X), the screen is blank. Initially tested on kernel 3.14.57, but the same happens on 4.5. This report uses kernel 4.5.0. Older, pre-KMS versions of the kernel worked fine. In the BIOS, the panel type is configured as "1920x1080@148.5M". Attached boot log #1 includes Ville's patch "drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()" but this code is not touched here because the driver chooses to use the VBT mode.
Created attachment 122711 [details] Boot log #2, VBT disabled Boot log #2 is with logging changed to drm.debug=0x1e log_buf_len=1M as per Intel bug report page. Here, the VBT selection in intel-lvds.c is commented out: DRM_DEBUG_KMS("NOT using mode from VBT: "); /* Failed to get EDID, what about VBT? */ /* if (dev_priv->vbt.lfp_lvds_vbt_mode) { DRM_DEBUG_KMS("using mode from VBT: "); drm_mode_debug_printmodeline(dev_priv->vbt.lfp_lvds_vbt_mode); fixed_mode = drm_mode_duplicate(dev, dev_priv->vbt.lfp_lvds_vbt_mode); if (fixed_mode) { fixed_mode->type |= DRM_MODE_TYPE_PREFERRED; goto out; } } */ The result is that the screen seems to work properly, including X. There are several errors in the log though.
Created attachment 122712 [details] /sys/kernel/debug/dri/0/i915_opregion
Created attachment 122713 [details] BIOS panel modes
OK. That's interesting. The BIOS panel list clearly matches the VBT timings list 1:1 (except the 1400x1050 being shown as reserved in the BIOS). However the VBT panel_type is still 2. For some reason it always seems to be 2 on all the machines I see, and I'm really starting to wonder if we're parsing it correctly. Could you change the panel type in the BIOS to something else, and then grab another copy of i915_opregion so that we can check what (if anything) changes in the VBT? Also another thing I'd like to see is what the VBIOS puts into the scratch registers. So can you also run the following commands with two different panel types selected in the BIOS so that we can see if the scratch registers change: intel_reg read --count 16 0x70410 intel_reg read --count 16 0x71410 intel_reg read --count 3 0x72414
Created attachment 122743 [details] register dumps for three modes I hope the "register spec not found" is not an issue with my gpu-tools.
Created attachment 122744 [details] opregion 1366x768@73.8M
Created attachment 122745 [details] opregion 1280x1024
Created attachment 122746 [details] boot log at 1280x1024
I tested three modes and attached opregions, register dumps, and a boot log at 1280x1024, if that is useful. Note that this log still has the VBT disable hack. You're right, the panel type is 2 in all cases. How do you decode the opregion bios blobs? Is there a intel-gpu-tool for that?
(In reply to Rob Kramer from comment #9) > I tested three modes and attached opregions, register dumps, and a boot log > at 1280x1024, if that is useful. Note that this log still has the VBT > disable hack. You're right, the panel type is 2 in all cases. > > How do you decode the opregion bios blobs? Is there a intel-gpu-tool for > that? intel_opregion_decode and intel_bios_reader for the VBT parts within opregion.
I see no change in the VBT when you change the panel mode. And in the entire opregion there seems to be just one byte that has changed, and that on is marked as reserved in the spec :( Scratch registers didn't seem helpful either. The only difference there was that it claimed you had a VGA monitor attached in the 1280x1024 and 1366x768 cases.
Created attachment 122765 [details] [review] [PATCH] drm/i915: Try to get EDID via ACPI _DDC if i2c fails for LVDS/eDP Since the VBT route seems a dead end I'm starting to wonder if we shouldn't be trying to get an EDID via ACPI. Can't be sure there is one of course, but supposedly we should have some way to figure out the panel timings and I can't think of another method we're missing. If this fails, I suppse the final option is to just ignore the VBT in case the LVDS is already on when the driver loads and just use the current timings. Totally untested so might blow up or something.
Some things I could try: 1) Override broken panel type via module parameter. 2) Disable VBT via module parameter, force use of existing mode. 3) Use video=.. parameter to lookup matching VBT panel. I've tried option 1, hack panel_type to 15 in intel_bios.c, and that works: [ 4.770027] [drm:intel_lvds_init] using mode from VBT: [ 4.770030] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 148500 1920 2040 2080 2200 1080 1081 1092 1125 0x8 0xa [ 4.770033] [drm:intel_lvds_init] detected dual-link lvds configuration Option 2 also works (hack out VBT setting), but results in messy kernel warnings/backtraces about pipe state mismatches, see previously attached logs. I don't know if option 3 is too horrible to consider. I've applied your patch to 4.5 (with minor port), but it returns too early at: ret = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, &edid); if (ret < 0) return ret; Could my kernel be missing some ACPI stuff? There is CONFIG_ACPI_VIDEO=m, and the module is loaded. I didn't add a new boot log since there wasn't anything new. If you have some ideas on how to debug this, please let me know (I know very little about ACPI)..
(In reply to Rob Kramer from comment #13) > Some things I could try: > > 1) Override broken panel type via module parameter. > 2) Disable VBT via module parameter, force use of existing mode. > 3) Use video=.. parameter to lookup matching VBT panel. The driver is supposed to work without user having to pass parameters. So if we can avoid we'll not be adding any. > > I've tried option 1, hack panel_type to 15 in intel_bios.c, and that works: > > [ 4.770027] [drm:intel_lvds_init] using mode from VBT: > [ 4.770030] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 > 148500 1920 2040 2080 2200 1080 1081 1092 1125 0x8 0xa > [ 4.770033] [drm:intel_lvds_init] detected dual-link lvds configuration > > Option 2 also works (hack out VBT setting), but results in messy kernel > warnings/backtraces about pipe state mismatches, see previously attached > logs. Those warns shouldn't happen with https://lists.freedesktop.org/archives/intel-gfx/2016-April/091392.html There was also a more troubling error in the log [drm:intel_enable_lvds [i915]] *ERROR* timed out waiting for panel to power on but I don't have a decent idea for that now. > > I don't know if option 3 is too horrible to consider. > > I've applied your patch to 4.5 (with minor port), but it returns too early > at: > > ret = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, > &edid); > if (ret < 0) > return ret; > > Could my kernel be missing some ACPI stuff? There is CONFIG_ACPI_VIDEO=m, > and the module is loaded. I didn't add a new boot log since there wasn't > anything new. If you have some ideas on how to debug this, please let me > know (I know very little about ACPI).. It's possible ACPI doesn't implement the _DDC method on your board. We could check that from the ACPI tables. Can you take an 'acpidump -b', stuff the results into a tarball and attach here? The question I keep asking myself is "if the panel type is genuinely wrong in the VBT, how could Windows work on this board?" Any idea if it does?
(In reply to Ville Syrjala from comment #14) > > Option 2 also works (hack out VBT setting), but results in messy kernel > > warnings/backtraces about pipe state mismatches, see previously attached > > logs. > > Those warns shouldn't happen with > https://lists.freedesktop.org/archives/intel-gfx/2016-April/091392.html Oh, I have not applied that patch, since I thought it was just some refactoring. I'll add it tomorrow. > > Could my kernel be missing some ACPI stuff? There is CONFIG_ACPI_VIDEO=m, > > and the module is loaded. I didn't add a new boot log since there wasn't > > anything new. If you have some ideas on how to debug this, please let me > > know (I know very little about ACPI).. > > It's possible ACPI doesn't implement the _DDC method on your board. We could > check that from the ACPI tables. Can you take an 'acpidump -b', stuff the > results into a tarball and attach here? Ok, I'll do that tomorrow. > The question I keep asking myself is "if the panel type is genuinely wrong > in the VBT, how could Windows work on this board?" Any idea if it does? Yes, the vendor-provided hdd has windows on it (we use a CF card). That windows works fine - by which I mean that it shows the windows desktop at the right resolution.
(In reply to Rob Kramer from comment #15) > (In reply to Ville Syrjala from comment #14) > > The question I keep asking myself is "if the panel type is genuinely wrong > > in the VBT, how could Windows work on this board?" Any idea if it does? > > Yes, the vendor-provided hdd has windows on it (we use a CF card). That > windows works fine - by which I mean that it shows the windows desktop at > the right resolution. One extra question that comes to mind is whether Windows works if you boot with and external monitor attached and LVDS disabled. Is that possible? I did see some "boot display" knob at least in your BIOS screenshot.
(In reply to Ville Syrjala from comment #16) > > Yes, the vendor-provided hdd has windows on it (we use a CF card). That > > windows works fine - by which I mean that it shows the windows desktop at > > the right resolution. > > One extra question that comes to mind is whether Windows works if you boot > with > and external monitor attached and LVDS disabled. Is that possible? I did see > some "boot display" knob at least in your BIOS screenshot. Ok, I tried that; set 'boot display device' to 'crt' instead of 'lvds + crt'. After booting, windows logo shows on crt (at lower mode), then the LVDS panel switches on an shows the windows desktop as per normal. Not sure what that tells you.. :)
Created attachment 122803 [details] acpidump -b There were several checksum errors when running this command; not sure if that is bad: ACPI BIOS Warning (bug): Incorrect checksum in table [OEMB] - 0x34, should be 0x31 (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [GSCI] - 0x9B, should be 0x0D (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [OEMB] - 0x34, should be 0x31 (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [OEMB] - 0x34, should be 0x31 (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [OEMB] - 0x34, should be 0x31 (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [GSCI] - 0x9B, should be 0x0D (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [OEMB] - 0x34, should be 0x31 (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [GSCI] - 0x9B, should be 0x0D (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [OEMB] - 0x34, should be 0x31 (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [GSCI] - 0x9B, should be 0x0D (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [OEMB] - 0x34, should be 0x31 (20150515/tbprint-232) ACPI BIOS Warning (bug): Incorrect checksum in table [GSCI] - 0x9B, should be 0x0D (20150515/tbprint-232)
(In reply to Rob Kramer from comment #17) > (In reply to Ville Syrjala from comment #16) > > > Yes, the vendor-provided hdd has windows on it (we use a CF card). That > > > windows works fine - by which I mean that it shows the windows desktop at > > > the right resolution. > > > > One extra question that comes to mind is whether Windows works if you boot > > with > > and external monitor attached and LVDS disabled. Is that possible? I did see > > some "boot display" knob at least in your BIOS screenshot. > > Ok, I tried that; set 'boot display device' to 'crt' instead of 'lvds + > crt'. After booting, windows logo shows on crt (at lower mode), then the > LVDS panel switches on an shows the windows desktop as per normal. > > Not sure what that tells you.. :) It tells me Windows *somehow* figures out the correct panel timings.
(In reply to Rob Kramer from comment #18) > Created attachment 122803 [details] > acpidump -b > > There were several checksum errors when running this command; not sure if > that is bad: I wouldn't worry about them if things work. Anyways I don't see a _DDC method anywhere, so I guess the ACPI route is out.
I found something interesting in the opregion spec. Based on that I posted a few patches that could help here: https://lists.freedesktop.org/archives/intel-gfx/2016-April/091988.html Please test and report back.
(In reply to Ville Syrjala from comment #21) > I found something interesting in the opregion spec. Based on that I posted a > few patches that could help here: > https://lists.freedesktop.org/archives/intel-gfx/2016-April/091988.html > > Please test and report back. OK, reverted your previous _DDC patch, applied these three. The result is a blank screen. I added some debug statements in your opregion.c patch: ret = swsci(dev, SWSCI_GBDA_PANEL_DETAILS, 0x0, &panel_details); if (ret) { DRM_DEBUG_KMS ("Rob: return %d\n", ret); return ret; } DRM_DEBUG_KMS ("Rob: panel details 0x%x\n", panel_details); And in the log: [drm:intel_opregion_get_panel_type] Rob: panel details 0x21000 Which would mean panel 0x10 according to the spec in your mail, which would be good if you'd started counting at 1 :) Next, I tried setting the mode to 1366x768@73.8M in the bios, and the output changes to: [drm:intel_opregion_get_panel_type] Rob: panel details 0x20d00 That is off by one too, but is still good news since it follows the BIOS setting.. Trying the obvious fix works: return ((panel_details >> 8) & 0xff) - 1; > "Bits [15:8] - Panel Type > Bits contain the panel type user setting from CMOS > 00h = Not Valid, use default Panel Type & Timings from VBT > 01h - 0Fh = Panel Number" That would mean only 15 possible valid modes, right? But my BIOS has 16 in its list already, and the correct mode happens to be the last one. [No log attached, because nothing further of interest]
(In reply to Rob Kramer from comment #22) > (In reply to Ville Syrjala from comment #21) > > I found something interesting in the opregion spec. Based on that I posted a > > few patches that could help here: > > https://lists.freedesktop.org/archives/intel-gfx/2016-April/091988.html > > > > Please test and report back. > > OK, reverted your previous _DDC patch, applied these three. The result is a > blank screen. I added some debug statements in your opregion.c patch: > > ret = swsci(dev, SWSCI_GBDA_PANEL_DETAILS, 0x0, &panel_details); > if (ret) > { > DRM_DEBUG_KMS ("Rob: return %d\n", ret); > return ret; > } > > DRM_DEBUG_KMS ("Rob: panel details 0x%x\n", panel_details); > > And in the log: > > [drm:intel_opregion_get_panel_type] Rob: panel details 0x21000 > > Which would mean panel 0x10 according to the spec in your mail, which would > be good if you'd started counting at 1 :) > > Next, I tried setting the mode to 1366x768@73.8M in the bios, and the output > changes to: > > [drm:intel_opregion_get_panel_type] Rob: panel details 0x20d00 > > That is off by one too, but is still good news since it follows the BIOS > setting.. Trying the obvious fix works: > > return ((panel_details >> 8) & 0xff) - 1; > > > "Bits [15:8] - Panel Type > > Bits contain the panel type user setting from CMOS > > 00h = Not Valid, use default Panel Type & Timings from VBT > > 01h - 0Fh = Panel Number" > > That would mean only 15 possible valid modes, right? But my BIOS has 16 in > its list already, and the correct mode happens to be the last one. > > [No log attached, because nothing further of interest] Thanks for testing. I found another version of the spec that says panel type 16 is still valid. I posted new versions of patches 1 and 3. Please double check that they work correctly.
Created attachment 122859 [details] boot log, panel 15 Latest patch #1 and #3 applied, works well. Thanks for all your effort!
Ah, I just noticed there is still this issue: [drm:intel_enable_lvds [i915]] *ERROR* timed out waiting for panel to power on This occurs every time I restart X, which perhaps does a mode switch to the same mode? The panel seems to work fine though.. When there is a mode switch (or X is started), a relay clicks in this display setup. I'm not sure why or what that's for, or if that could introduce an external delay that the driver doesn't expect. if (wait_for((I915_READ(stat_reg) & PP_ON) != 0, 1000)) DRM_ERROR("timed out waiting for panel to power on\n"); Is there a way to see if the panel is detected as switched on after a longer period of time (some seconds)? In /sys, debugfs, or with intel-gpu-tools?
(In reply to Rob Kramer from comment #25) > Ah, I just noticed there is still this issue: > > [drm:intel_enable_lvds [i915]] *ERROR* timed out waiting for panel to > power on > > This occurs every time I restart X, which perhaps does a mode switch to the > same mode? The panel seems to work fine though.. > > When there is a mode switch (or X is started), a relay clicks in this > display setup. I'm not sure why or what that's for, or if that could > introduce an external delay that the driver doesn't expect. > > if (wait_for((I915_READ(stat_reg) & PP_ON) != 0, 1000)) > DRM_ERROR("timed out waiting for panel to power on\n"); > > Is there a way to see if the panel is detected as switched on after a longer > period of time (some seconds)? In /sys, debugfs, or with intel-gpu-tools? Please open a new bug for that, and attach the dmesg, opregion, and 'intel_reg dump' there. Make sure you grab intel-gpu-tools fresh from git since we had a bug there which make 'intel_reg dump' fail on gen4. I pushed the fix for that a few days ago.
Opregionb panel type stuff is now merged so marking as fixed. commit a05628195a0d9f3173dd9aa76f482aef692e46ee Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Apr 11 10:23:51 2016 +0300 drm/i915: Get panel_type from OpRegion panel details
Unfortunaltey the fix has regressed a lot of other machines, so we either need to refine the fix or revert it entirely :( Rob, if you still have the machine around I'd appreciate if you could test this branch to see if it still works for you: git://github.com/vsyrjala/linux.git opregion_panel_type_stuff And whether it works or not, I'd like to see the resulting dmesg with drm.debug=0xe.
Yes, I still have the hardware in my office. I can test your branch, but that may take a few days..
Created attachment 126271 [details] dmesg with override bit patch I've added a dmesg dump of kernel 4.7.2 with two of your patches (backported): drm/i915: Debug GBDA get panel details drm/i915: Ignore OpRegion panel type unless the "override" bit is set The result is that my screen doesn't switch on anymore. I've tested with vanilla 4.7.2 as well, and that works OK. Is the output OK for you? If you want me to test further patches, no problem.
(In reply to Rob Kramer from comment #30) > Created attachment 126271 [details] > dmesg with override bit patch > > I've added a dmesg dump of kernel 4.7.2 with two of your patches > (backported): > > drm/i915: Debug GBDA get panel details > drm/i915: Ignore OpRegion panel type unless the "override" bit is set > > The result is that my screen doesn't switch on anymore. I've tested with > vanilla 4.7.2 as well, and that works OK. > > Is the output OK for you? If you want me to test further patches, no problem. [ 4.988023] [drm:swsci] GBDA get panel details 0x00000020 0x00021000 [ 4.988026] [drm:intel_opregion_get_panel_type] No OpRegion panel type override Argh. So the override bit won't help us :( I have no good ideas how to make this truly automagic, so I think we need a quirk of some sort for your machine. Can you provide the output of 'lspci -vnn -s 0:2.0' and 'dmidecode' ?
Created attachment 126291 [details] dmidecode
Created attachment 126292 [details] lspci Added dmidecode and lspci for my board.
(In reply to Rob Kramer from comment #33) > Created attachment 126292 [details] > lspci > > Added dmidecode and lspci for my board. Thanks. New branch with the quirk in place. Please test: git://github.com/vsyrjala/linux.git opregion_panel_type_quirk
Created attachment 126361 [details] dmesg with quirk patch OK, I added drm/i915: Ignore OpRegion panel type except on select machines on top of 4.7.2 vanilla (minor hack required). I didn't apply the other two patches in your branch, since they looked irrelevant. Result is no screen.. In the new dmesg I added, it looks like the quirk is detected too late in the process, so it is as if no quirk is present when it is needed, and the wrong panel type is picked. At least the quirk itself works well! :)
(In reply to Rob Kramer from comment #35) > Created attachment 126361 [details] > dmesg with quirk patch > > OK, I added > > drm/i915: Ignore OpRegion panel type except on select machines > > on top of 4.7.2 vanilla (minor hack required). I didn't apply the other two > patches in your branch, since they looked irrelevant. > > Result is no screen.. In the new dmesg I added, it looks like the quirk is > detected too late in the process, so it is as if no quirk is present when it > is needed, and the wrong panel type is picked. > > At least the quirk itself works well! :) Doh. Let's try that again. Assuming I didn't fumble anything else this should do the trick: git://github.com/vsyrjala/linux.git opregion_panel_type_quirk_2
Patch submitted and under review: https://patchwork.freedesktop.org/series/12380/
Tested V2, and that works well: [ 4.990018] [drm] Using panel type from OpRegion on Conrac GmbH IX45GM2 [ 4.990022] [drm:parse_lfp_panel_data] Panel type: 15 (OpRegion)
Fixed by commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Sep 13 12:22:19 2016 +0300 drm/i915: Ignore OpRegion panel type except on select machines in drm-intel-fixes.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.