Summary: | [regression arrandale] X blanks when external HDMI/DVI connected since 3.2.7 and 3.3 | ||
---|---|---|---|
Product: | DRI | Reporter: | Brice Goglin <brice.goglin> |
Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | ben, chris, daniel, jbarnes, jrnieder |
Version: | XOrg git | Keywords: | regression |
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 42991 | ||
Attachments: |
Description
Brice Goglin
2012-04-02 00:08:11 UTC
Please boot with drm.debug=0xe attached on your kernel commandline and attach the entire dmesg. Created attachment 59363 [details]
dmesg with drm.debug=0xe
Here's what you requested.
Created attachment 59365 [details] [review] sprinkle a few printks Please grab dmesg with drm.debug=0xe and this patch again - I need to double-check whether what's exactly going wrong. Created attachment 59367 [details]
dmesg with more printk
Added your debug printk
Created attachment 59428 [details] [review] Print out the bw required and bw products Created attachment 59481 [details]
dmesg with more printk + bw
Here's the new dmesg. In short, your new printk say:
[ 4.571661] [drm:intel_dp_mode_fixup], dp link requires bw=173160 for clock=96200 and bpp=18
[ 4.571663] [drm:intel_dp_mode_fixup], max-data-rate for clock 6 nad 1 lanes: 18
[ 4.571664] [drm:intel_dp_mode_fixup], max-data-rate for clock 10 nad 1 lanes: 18
[ 57.862489] [drm:intel_dp_mode_fixup], dp link requires bw=230880 for clock=96200 and bpp=24
[ 57.862494] [drm:intel_dp_mode_fixup], max-data-rate for clock 6 nad 1 lanes: 24
[ 57.862499] [drm:intel_dp_mode_fixup], max-data-rate for clock 10 nad 1 lanes: 24
[ 57.862524] [drm:intel_dp_mode_fixup], dp link requires bw=173160 for clock=96200 and bpp=18
[ 57.862529] [drm:intel_dp_mode_fixup], max-data-rate for clock 6 nad 1 lanes: 18
[ 57.862534] [drm:intel_dp_mode_fixup], max-data-rate for clock 10 nad 1 lanes: 18
So the issue is that we want to turn it on with 24bpp instead of 18bpp. And there's not enough bw for that. Created attachment 59486 [details] [review] properly compute dp dithering A quick patch for you to try. This will likely conflict with the debug patches, so please drop them. Created attachment 59504 [details]
dmesg after applying "59486: properly compute dp dithering"
No, still fails the same. dmesg attached.
Created attachment 59505 [details] [review] properly compute dp dithering v2 Oops, broken logic in the patch. And I've added a printk to check it, too. Please retest. Still broken: [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3] dp mode_fixup, bpp: 24 [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3] detected fb_set_par error, error code: -22 dp mode_fixup, bpp: 24 [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3] and so on. And eDP seems broken now too: it just blanks when KMS starts, even when the DVI monitor isn't plugged. By the way, I screwed up my testing earlier with your first patch. It's basically broken as the last one: same CRTC:3 messages in dmesg, and eDP blanks. Created attachment 59683 [details] [review] properly compute dp dithering v3 As long as we have "dp mode_fixup, bpp: 24" in the dmesg, I've failed to write the correct patch and massive breakage is expected. The right thing is 18 bpp. So it looks like my brain has already been on leave for the easter w/e and v2 contained yet another goof-up. New patch (this time hopefully correct) for you to test attached. Created attachment 59708 [details] dmesg after applying "59683: properly compute dp dithering v3" Yeah this one seems to work. eDP doesn't blank anymore. X starts fine with and without HDMI/DVI plugged, and I get my usual modes. Thanks! Reported-and-tested-by: Brice Goglin <Brice.Goglin@ens-lyon.org> commit c4867936474183332db4c19791a65fdad6474fd5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 10 10:42:36 2012 +0200 drm/i915: properly compute dp dithering for user-created modes We've only computed whether we need to fall back to 6bpc due to dp link bandwidth constrains in mode_valid, but not mode_fixup. Under various circumstances X likes to create new modes which then lack proper 6bpc flags (if required), resulting in mode_fixup failures and ultimately black screens. Chris Wilson pointed out that we still get things wrong for bpp > 24, but that should be fixed in another patch (and it'll be easier because this patch consolidates the logic). The likely culprit for this regression is commit 3d794f87238f74d80e78a7611c7fbde8a54c85c2 Author: Keith Packard <keithp@keithp.com> Date: Wed Jan 25 08:16:25 2012 -0800 drm/i915: Force explicit bpp selection for intel_dp_link_required v2: Fix indentation and tune down the too bold claim that this should fix the world. Both noticed by Chris Wilson. v3: Try to really git add things. Reported-and-tested-by: Brice Goglin <Brice.Goglin@ens-lyon.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170 Cc: stable@kernel.org Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Closing resolved+fixed. Verified by Reporter. Code CommitDate: Thu Apr 12 2012. |
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.