Environment: -------------------------- Kernel: drm-intel-testing commit 95d42e7d341861132ffec806328dd7fc85516995 Merge: cf8f3ba 2a0a016 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Dec 13 17:57:43 2013 +0100 Merge remote-tracking branch 'origin/topic/core-stuff' into drm-intel-nightly Bug detailed description: ----------------------------- eDP shows black screen while testing testdisplay -f 38.25,800,832,912,1024,600,603,607,624 It's normal on last testing kernel (8ddad290a0f7f6c5769ad6d4ef2569b8ccb88b30) Steps: --------------------------- ./testdisplay -f 38.25,800,832,912,1024,600,603,607,624
Can you please bisect where this regression has been introduced?
Created attachment 90850 [details] dmesg
(In reply to comment #1) > Can you please bisect where this regression has been introduced? After bisect, We found first bad point on -next-queued branch commit dff392dbd258381a6c3164f38420593f2d291e3b Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 6 17:32:41 2013 -0200 drm/i915: don't touch the VDD when disabling the panel I don't see a reason to touch VDD when we're disabling the panel: since the panel is enabled, we don't need VDD. This saves a few sleep calls from the vdd_on and vdd_off functions at every modeset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo. Also drop the runtime_pm_put call which now has to go due to different patch ordering. Also from Paul.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reverted this commit, the bug unable to reproduce.
(In reply to comment #3) > After bisect, We found first bad point on -next-queued branch > commit dff392dbd258381a6c3164f38420593f2d291e3b > Author: Paulo Zanoni <paulo.r.zanoni@intel.com> > Date: Fri Dec 6 17:32:41 2013 -0200 > > drm/i915: don't touch the VDD when disabling the panel > > I don't see a reason to touch VDD when we're disabling the panel: > since the panel is enabled, we don't need VDD. This saves a few sleep > calls from the vdd_on and vdd_off functions at every modeset. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693 > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > [danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo. > Also drop the runtime_pm_put call which now has to go due to different > patch ordering. Also from Paul.] > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > Reverted this commit, the bug unable to reproduce. I suggest we revert that and reopen bug 69693. Assigning to Paulo.
(In reply to comment #2) > Created attachment 90850 [details] > dmesg Can you please provide a full dmesg with drm.debug=0xe Kernel boot option?
(In reply to comment #4) > (In reply to comment #3) > > After bisect, We found first bad point on -next-queued branch > > commit dff392dbd258381a6c3164f38420593f2d291e3b > > Author: Paulo Zanoni <paulo.r.zanoni@intel.com> > > Date: Fri Dec 6 17:32:41 2013 -0200 > > > > drm/i915: don't touch the VDD when disabling the panel > > > > I don't see a reason to touch VDD when we're disabling the panel: > > since the panel is enabled, we don't need VDD. This saves a few sleep > > calls from the vdd_on and vdd_off functions at every modeset. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693 > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > [danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo. > > Also drop the runtime_pm_put call which now has to go due to different > > patch ordering. Also from Paul.] > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > > > Reverted this commit, the bug unable to reproduce. > > I suggest we revert that and reopen bug 69693. Assigning to Paulo. According to the spec, we should be doing the correct thing now, so I'm in favor of spending a little bit of time on the proper fix before we decide to revert. But I don't have a BYT machine, so if someone wants to help, please :) There's also the possibility of doing a BYT-revert-only or a ILK-SNB-IVB-BYT-revert-only (leaving HSW+ untouched).
Also, is this the *only* case where you see a black screen caused by this patch? Do all the other testdisplay cases and kms_* tests still work in the same way as before with this patch? Thanks, Paulo
Created attachment 91806 [details] eDP black screen
(In reply to comment #5) > (In reply to comment #2) > > Created attachment 90850 [details] > > dmesg > > Can you please provide a full dmesg with drm.debug=0xe Kernel boot option? Please check "eDP black screen" in attachment for full dmesg with drm.debug=0xe
(In reply to comment #7) > Also, is this the *only* case where you see a black screen caused by this > patch? Do all the other testdisplay cases and kms_* tests still work in the > same way as before with this patch? > > Thanks, > Paulo ./testdisplay -d and ./testdisplay -f have this issue too.
(In reply to comment #10) > (In reply to comment #7) > > Also, is this the *only* case where you see a black screen caused by this > > patch? Do all the other testdisplay cases and kms_* tests still work in the > > same way as before with this patch? > > > > Thanks, > > Paulo > > ./testdisplay -d and ./testdisplay -f have this issue too. On all eDP modes?
Created attachment 91832 [details] dmesg
Created attachment 91833 [details] kern.log file
Don't know if this is the exact same issue, but this is happening on my Dell Venue 11 Pro. It's a Haswell i5-4210Y (Intel HD4200 graphics). This was with https://launchpad.net/ubuntu/trusty/amd64/libdrm-intel1 I believe
(In reply to comment #14) > Don't know if this is the exact same issue, but this is happening on my Dell > Venue 11 Pro. > > It's a Haswell i5-4210Y (Intel HD4200 graphics). This was with > https://launchpad.net/ubuntu/trusty/amd64/libdrm-intel1 I believe Different issue, please file a new bug.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #7) > > > Also, is this the *only* case where you see a black screen caused by this > > > patch? Do all the other testdisplay cases and kms_* tests still work in the > > > same way as before with this patch? > > > > > > Thanks, > > > Paulo > > > > ./testdisplay -d and ./testdisplay -f have this issue too. > > On all eDP modes? Guo?
(In reply to comment #16) > (In reply to comment #11) > > (In reply to comment #10) > > > (In reply to comment #7) > > > > Also, is this the *only* case where you see a black screen caused by this > > > > patch? Do all the other testdisplay cases and kms_* tests still work in the > > > > same way as before with this patch? > > > > > > > > Thanks, > > > > Paulo > > > > > > ./testdisplay -d and ./testdisplay -f have this issue too. > > > > On all eDP modes? > > Guo? Retest on latest -testing, ./testdisplay -d works well, ./testdisplay -f 38.25,800,832,912,1024,600,603,607,624 and ./testdisplay -f 63.50,1024,1072,1176,1328,768,771,775,798 still failed.
I checked on latest -nightly(e5ad48d0d4f08e5db537901a2d7b2f0750ddd88c), This bug unable to reproduce.
Closing old verified.
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.