Summary: | [eDP regression] blank screen on boot | ||
---|---|---|---|
Product: | DRI | Reporter: | Chris Wilson <chris> |
Component: | DRM/Intel | Assignee: | Paulo Zanoni <przanoni> |
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | blocker | ||
Priority: | highest | CC: | intel-gfx-bugs, patrik.r.jakobsson, przanoni |
Version: | XOrg git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Description
Chris Wilson
2014-02-06 17:22:02 UTC
Hi Can you please boot with drm.debug=0xe and attach the output of "dmesg"? Thanks, Paulo Created attachment 93565 [details]
dmesg dump with drm.debug=0xe
Created attachment 93568 [details] [review] Patch with debugging option Hi This patch adds a Kernel command line option that will help us debug the problem. Please apply the patch, then try booting with: - i915.edp_delays=0 - i915.edp_delays=1 - i915.edp_delays=2 - i915.edp_delays=3 - i915.edp_delays=4 And please tell us which ones solve the bug for you. If you discover that i915.edp_delays=4 solves the problem for you, you could also try removing chunks of code that look for "i915.edp_delays == EDP_DELAYS_I915_OLD" until you get a minimal set of checks that are essential to get your Kernel working. But this could easily take you a few hours of debugging :) Thanks, Paulo I applied the patch to drm-intel-next (from Daniels repo). Unfortunately none of the edp_delays solved the problem. Maybe I should have pointed out that I do get console output while booting but when X starts everything goes black. Backlight is on and can be changed while the screen is black. Any other ideas? Hi I made some slight mistakes on yesterday's patch, and I also forgot to revert one commit. Can you please test http://cgit.freedesktop.org/~pzanoni/linux/?h=edp-reverts ? Please _make sure_ you're on the edp-reverts branch, and also please make sure you're using i915.edp_delays=4 and drm.debug=0xe as the Kernel command line parameter. After you boot, please also run dmesg | grep "eDP delays" just to make sure you're using the right option :) If this works for you, you can try reverting the top commits until it stops working. Thanks, Paulo Hi Paulo, thanks for looking into this. I still get a blank screen when trying HEAD at this branch with i915.edp_delays=4 and drm.debug=0xe. dmesg tells me it's active so I got the correct kernel running. I assume you've reverted the whole series at this stage so there must be something else that changed around eDP. I did a bisect twice on 3.14-rc1 and both pointed to the reported commit. /me is scratching my head Created attachment 93769 [details]
dmesg dump with i915.edp_delays=4 and drm.debug=0xe on HEAD of branch edp_reverts
Patrik, make sure you have commit ec5e0cfb19e79ce3a87b281ce4c2682eb659fa6e Author: Imre Deak <imre.deak@intel.com> Date: Wed Jan 29 13:25:40 2014 +0200 drm/i915: fix wait_remaining_ms_from_jiffies from drm-intel-nightly. Note the branches have moved to a new repo at fdo: http://cgit.freedesktop.org/drm-intel Yes I have ec5e0cfb19e79ce3a87b281ce4c2682eb659fa6e By looking at my dmesg it seems the last VDD change is: [ 12.131461] [drm:edp_panel_vdd_off_sync], Turning eDP VDD off [ 12.131474] [drm:edp_panel_vdd_off_sync], PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd0007 Why off and not on? (In reply to comment #9) > Why off and not on? It's a force VDD bypassing regular panel power sequencing. Finally had some time to look at this again so I did a new bisect but on the -nightly branch and for some reason I got a new first-bad-commit. Not sure why I saw that other patch on the previous 3-4 bisects. Did the patch order change? Turned out to be the EDP_FORCE_VDD bit missing in ironlake_edp_panel_off(). I've submitted a patch to intel-gfx that solves this problem. Thanks Patrik Created attachment 94966 [details]
Set EDP_FORCE_VDD bit in
Moving the conversation back here (my bad)... Chris Wilson wrote: I'd feel more comfortable with; diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 46d065b..876184f 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1872,9 +1872,11 @@ static void intel_disable_dp(struct intel_encoder *encoder) /* Make sure the panel is off before trying to change the mode. But also * ensure that we have vdd while we switch off the panel. */ + edp_panel_vdd_on(intel_dp); intel_edp_backlight_off(intel_dp); intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF); intel_edp_panel_off(intel_dp); + edp_panel_vdd_off(intel_dp, true); /* cpu edp my only be disable _after_ the cpu pipe/plane is disabled. */ if (!(port == PORT_A || IS_VALLEYVIEW(dev))) Or that vdd_off may have to be post-disable. Calling vdd_on / vdd_off in intel_disble_dp doesn't fix the problem. I'm attaching the broken and working dmesg (applied on top of drm-intel-nightly). Seems I get an extra call to ironlake_edp_panel_vdd_on() with my patch applied. Created attachment 94967 [details]
dmesg from broken setup (_vdd_on / _vdd_off in intel_disable_dp)
Created attachment 94968 [details]
dmesg from working setup (EDP_FORCE_VDD in _edp_panel_off)
Correction... I'm obviously doing this on drm-intel-fixes (hence the ironlake_ prefixes). Patrik, can you try moving the edp_panel_vdd_off() that I added down into intel_post_disable_dp()? The problem as I see it is the hack is to leave the vdd on virtually forever, which may or may not consume a lot of extra power. I moved it to the bottom of intel_post_disable_dp() (outside the if-stmt) but that didn't do it either. Not sure at what stage the EDP_FORCE_VDD bit is needed (link training?). Not a VESA member so no docs here. Thinking about it, I think both patches are required. Definitely we need to or in the bit there as in your patch to preserve the VDD setting during the disable. And I think we also need the explicit VDD frobbing during disable. Created attachment 95007 [details] [review] Patch with _vdd_on/_vdd_off wrapped intel_disable_dp and EDP_FORCE_VDD bit cleared So something like this? Paulo, anything you would like to add? If this is ok I'll resend it to the list. Patrik: Please reword the commit message to make it clear it's a regression. Usually we go with "This regression has been introduced in <commit citation" in a separate paragraph to really make it stand out. Just process nit from me, thanks for taking care of this issue ;-) Patch sent with better description of the regression. I forgot to tag it v2 in the patch subject so make sure you pick the right one for -fixes. Thanks Hmm, I worry about the interaction of this patch with bug 75401. Thanks for the report, fixed by commit 825938307f812c7cbfe064c7884bd8bdb27c2144 Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Mar 17 15:20:59 2014 +0200 Revert "drm/i915: don't touch the VDD when disabling the panel" Closing resolved+fixed. 2.5 years with no comments. |
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.