Created attachment 94600 [details] dmesg output when my laptop monitor is switched off I have Lenovo W540 with Arch Linux. My laptop monitor slightly flashes every three seconds when it's turned off. This happens every time either when I connect an external display and turn off my laptop monitor or when I don't have any external monitor connected and my laptop monitor turns off (e.g. when I lock the screen). However, this doesn't happen in the opposite case when the external monitor is turned off and my laptop monitor is turned on. From dmesg output I can see that a call to drm:ironlake_panel_vdd_off_sync is initiated every three seconds and thus most probably this bug is related to that call.
The panel seems to have a couple of bugs. 1) It sends a hotplug event every 3 seconds. 2) It flashes when the power to the panel is switched on (at that point the panel itself is still disabled and the backlight is still supposed to be off). The trigger for the hotplug event appears to be us turning off the panel power supply. Based on that hypothesis, this should prevent the flash but at a moderate increase in power consumption when the screen is off: index 46d065b..960bcd6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1270,8 +1270,10 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync) * time from now (relative to the power down delay) * to keep the panel power up across a sequence of operations */ +#if 0 schedule_delayed_work(&intel_dp->panel_vdd_work, msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5)); +#endif } }
Created attachment 94691 [details] dmesg output with chris's patch
Yes, you are right. As you can see from dmesg output, your patch completely prevents the flash and hotplug event. However, I don't understand why it increases the power consumption when the screen is off. Thanks a lot Chris. Now I don't have to worry that these flashes will burn my screen. :)
(In reply to comment #3) > Yes, you are right. As you can see from dmesg output, your patch completely > prevents the flash and hotplug event. However, I don't understand why it > increases the power consumption when the screen is off. With the patch, we don't fully turn off all power to the screen instead the communication channel is kept alive. The remaining question is who is at fault, our code or the panel? If the panel, we may just quirk your machine to never disable the VDD line as above - otherwise we may have an incorrect sequence somewhere for controlling the panel power.
(In reply to comment #4) > With the patch, we don't fully turn off all power to the screen instead the > communication channel is kept alive. The remaining question is who is at > fault, our code or the panel? If the panel, we may just quirk your machine > to never disable the VDD line as above - otherwise we may have an incorrect > sequence somewhere for controlling the panel power. OK. Thank you for you explanation. What should I do next to locate the cause of this bug?
In bug 74628, there seems to be another VDD related issue - in that case with the sequence in which VDD is switched off. Maybe https://bugs.freedesktop.org/attachment.cgi?id=95007 helps here as well?
Some VDD related patches have recently been merged. Please try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel and report back.
Created attachment 96247 [details] dmesg output with jani's VDD patches
(In reply to comment #7) > Some VDD related patches have recently been merged. Please try > drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel and report > back. I tried with today's drm-intel-nightly (http://cgit.freedesktop.org/drm-intel/snapshot/drm-intel-ef4aa46592f81cde427e3c902fc2f77682870f82.tar.gz), but the bug still exists as you can see in the attached dmesg output.
(In reply to comment #9) > (In reply to comment #7) > > Some VDD related patches have recently been merged. Please try > > drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel and report > > back. > > I tried with today's drm-intel-nightly > (http://cgit.freedesktop.org/drm-intel/snapshot/drm-intel- > ef4aa46592f81cde427e3c902fc2f77682870f82.tar.gz), but the bug still exists > as you can see in the attached dmesg output. Please try again with current drm-intel-nightly; we've merged some power sequencing patches that would be worth trying. Thanks.
Ping for the re-test.
(In reply to comment #11) > Ping for the re-test. The bug still exists.
(In reply to comment #12) > (In reply to comment #11) > > Ping for the re-test. > > The bug still exists. Just to double check, this is on current drm-intel-nightly?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Ping for the re-test. > > > > The bug still exists. > > Just to double check, this is on current drm-intel-nightly? No it is on drm-intel-nightly from August 14th, but I forgot to respond earlier. I will try it also on the current drm-intel-51c49eafab38a20bdd12344d31d09810c9b0c3f6 and then post an update in a few hours.
Created attachment 105835 [details] dmesg output with the current drm-intel-nightly
The monitor still flashes every few seconds (when turned off) on drm-intel-nightly from yesterday (http://cgit.freedesktop.org/drm-intel/snapshot/drm-intel-51c49eafab38a20bdd12344d31d09810c9b0c3f6.tar.gz).
Ugly, so it sounds like we need something like Chris's fix then. Though I still wonder about our panel power sequencing compliance; if we're still getting the order or timing wrong somewhere we might be confusing the panel. But we've also merged changes to the DP hotplug handling, which could have been causing problems if we were trying to do panel poking at hotplug time. That should be unnecessary since eDP configs won't change. Anyway, can you try current drm-intel-nightly? If our hotplug handling still isn't correct there we should just fix it instead of trying to change our panel power handling.
This sounds like the long hpd we get on vdd off. Which we now ignore since commit 7a7f84ccb82e542c845c43f604665ccea1247866 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> AuthorDate: Thu Oct 16 20:46:10 2014 +0300 drm/i915: Ignore long hpds on eDP ports And it looks like eDP is on port D here, which explains why we even have the HPD interrupt enabled (it wouldn't be on port A). So yeah, please re-test with latest nightly or with something that has my fix included.
Created attachment 110495 [details] dmesg output with the current drm-intel-nightly which includes Ville's fix
(In reply to Ville Syrjala from comment #18) > This sounds like the long hpd we get on vdd off. Which we now ignore since > > commit 7a7f84ccb82e542c845c43f604665ccea1247866 > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > AuthorDate: Thu Oct 16 20:46:10 2014 +0300 > > drm/i915: Ignore long hpds on eDP ports > > And it looks like eDP is on port D here, which explains why we even have the > HPD interrupt enabled (it wouldn't be on port A). > > So yeah, please re-test with latest nightly or with something that has my > fix included. You are right Ville. I have tested my laptop with the current nightly (http://cgit.freedesktop.org/drm-intel/snapshot/drm-intel-74e0fec574539a1466ddc9d53f5bc9eb1de9f299.tar.gz) and the screen doesn't flash anymore. :) You can find new dmesg output in the attachments. Thanks a lot. The problem is finally solved.
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.