Created attachment 96206 [details] [review] RFC patch on top of 34d59508 (drm/nouveau: fix TTM_PL_TT memtype on pre-nv50) Commit 0a0afd28 (drm/nv50-/disp: move DP link training to core and train from supervisor) removed a call to 'nouveau_dp_dpms' at the bottom of nv50_display.c. Without this call, 'xset dpms force {on,off}' does not have any effect on my DP-attached monitor. The attached proof-of-concept patch re-adds the call, as well as a partial version of nouveau_dp_dpms which causes 'force off' to work again. It is not clear to me how to trigger link training in the supervisor, so nouveau_dp_dpms skips that step when handling DRM_MODE_DPMS_ON. The result is that 'force on' does not cause the monitor to wake up, and the connection is effectively dead. Could somebody familiar with the driver could comment on the next steps to undertake to restore the full {on,off} functionality?
Ah yes, I've been aware of this issue for a while, it just hasn't made it to the top of the list yet. I'll try and address it for the 3.15 cycle, and backport the fixes to earlier kernels if possible.
Created attachment 96281 [details] [review] [WIP,BROKEN] drm/nv50: Hack FORCE_DP_TRAIN method for DPMS power-on Hi Ben, Excellent! (FYI: I, for one, don't need any backports.) In the meantime, I tried to kludge my way into getting the monitor to wake up with another horrible hack (attached), but did not succeed before running out of time. Any idea? I understand that both patches suffer from the race condition you were trying to avoid in the first place, but an always on/off monitor is a bit of a handicap :) Alternatively/in addition, I would welcome hints on how to make Nouveau survive power-cycling the monitor (e.g. by running a command over SSH to reset the display). The current behaviour is: [On, displaying] ↓ Turn off [Off] ↓ Turn on [Booting] ⋮ [OSD: No input; shutting down] ⋮ [Standby] Of course, feel free to suggest proper fixes, docs to read, and/or patches to test. Cheers, -D
I think I'm seeing this too. Mac Pro (2009) with GT120 (G96/NV50) and 24 inch Apple Cinema display via MDP connection. powersave blanking used to work in 3.6.3 which was the last kernel I used (opensuse 12.3 otherwise). Now it does nothing in opensuse 13.1 which has 3.11.10, also notwork with a 3.14.1 kernel. X thinks that it's turned off the display (according to xset q) but nothing happened. I would be happy to test a fix if and when a trial is ready. I have all sorts of trouble with nouveau on this hardware so I suspect it's not a common setup. :-) Fortunately, recent versions seem pretty good other than the lack of powersave.
(In reply to comment #1) > Ah yes, I've been aware of this issue for a while, it just hasn't made it to > the top of the list yet. I'll try and address it for the 3.15 cycle, and > backport the fixes to earlier kernels if possible. Thanks for your work, Ben. A little feedback from my side. I tried this yesterday with the 3.15.0-rc6 Kernel, but this misbehaviour regarding the none working power management is still the same with my NVIDIA Corporation GT200GL [Quadro FX 4800] (rev a1) with NV50 Chipset(NVA0). So it would be great to get this functionality asap ;-) Regards, Andy.
There is a substantial DP rework bound for 3.16. Can you give http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next a shot? It should add proper support for DPMS.
(In reply to comment #5) > There is a substantial DP rework bound for 3.16. Can you give > http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next a shot? It should > add proper support for DPMS. I will. ASAP, but probably not today. Thanks! -D
(In reply to comment #5) > There is a substantial DP rework bound for 3.16. Can you give > http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next a shot? It should > add proper support for DPMS. Forget to mention, my monitor is connected via DVI and I have the same problem. Is the rework you mentioned also valid for the DVI output, so is it worth fo me to giv it a trial? Nevertheless thanks for your work and best regards, Andy.
(In reply to comment #5) Hi Ilia, Ben, I gave a shot at drm-next as of the following commit: > commit bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b > Merge: c1a6e9f 1ae5a62 > Author: Dave Airlie <airlied@redhat.com> > Date: Wed Jun 11 16:28:10 2014 +1000 > > Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau > > display rework fixes lots of displayport issues. I have been running that kernel for a large part of a work day, and, so far, it has worked pretty well. Many thanks! Below are a couple remaining issues, none of which are blocking in my case (GeForce 9400/DP/Dell U2711), but which may be worth investigating if they also happen with other hardware combinations: 1. The display does not wake up from (timed-out or forced) sleep on keypress or mouse move as it used to. Activating the OSD menu wakes up the panel; Nouveau seems to pick that up as a hint to get going; 2. The panel's backlight flickers very noticeably after a soft power cycle. It also flickers, but less noticeably, after a hard unplug/ re-plug. Force-switching to an unconnected input source and back makes it stable again. Let me know if there's any way I can assist you further. In the meantime, thanks again—it seems I'm not stuck with 3.8 anymore! Cheers, -D
I tried the same commit as Damien did on my hardware (2009 Mac Pro, GT120, 24" Apple LCD, Mini-Displayport) and it's half a loaf. DPMS kicks in and the backlight turns off as it should -- yay! Unfortunately it doesn't go back on -- boo. I tried keyboard, mouse movement, xset dpms force on; nothing turned the display back on. Power cycling the monitor restores the display but obviously that's not how it's supposed to work.
Meant to add: when the display goes off, xset q from a remote login shows the monitor in Standby. If one moves the mouse or presses keys, xset q says that the monitor is On, but it isn't.
First off, while I doubt that this has been fixed, it would be best to try the latest drm-next, which has some additional nouveau fixes. Assuming the issue still isn't resolved, could you boot with nouveau.debug=PDISP=debug,I2C=debug,VBIOS=trace,DRM=debug drm.debug=0xe And go through a DPMS cycle (and then powercycle the monitor to get it to turn it back on), taking care to note where in the log the various (external) events happen. I think you can actually just write to /dev/kmsg directly.
Ok. Not sure what the latest drm-next is, I found a recent looking drm-nouveau-next and it did the same thing. Monitor is blanked (backlight off) via: [ 225.790860] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 8: 0x00000600 1 [ 225.790894] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000002 [ 225.790897] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 225.790899] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 225.790901] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 225.791037] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 00 0x01108000 0x10000000 and the unsuccessful attempt to restore backlight is: [ 251.285375] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 8: 0x00000600 1 [ 251.285388] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000001 [ 251.285391] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 251.285393] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 251.285395] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 251.285529] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 00 0x01108000 0x10000000 Full log attached as it's rather lengthy. ***NOTE*** lines show when things happened.
Created attachment 101432 [details] kernel log from drm-next; backlight won't turn back on
Created attachment 101716 [details] [review] more debugging
(In reply to comment #12) > Ok. Not sure what the latest drm-next is, I found a recent looking > drm-nouveau-next and it did the same thing. > > Monitor is blanked (backlight off) via: > [ 225.790860] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 8: 0x00000600 1 > [ 225.790894] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000002 > [ 225.790897] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 225.790899] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 225.790901] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 225.791037] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 00 0x01108000 > 0x10000000 > > and the unsuccessful attempt to restore backlight is: > > [ 251.285375] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 8: 0x00000600 1 > [ 251.285388] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000001 > [ 251.285391] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 251.285393] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 251.285395] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 251.285529] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 00 0x01108000 > 0x10000000 > > Full log attached as it's rather lengthy. ***NOTE*** lines show when things > happened. Can you grab a new log with that patch I just attached applied?
Ok but I'm away from that machine for the week, won't be until the weekend.
With the extra output the display on -> standby (off) transition now looks like: [ 227.434722] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 8: 0x00000600 1 [ 227.434736] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000002 [ 227.434738] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 227.434741] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 227.434743] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 227.434877] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 00 0x01108000 0x10000000 [ 227.434884] nouveau [ PDISP][0000:05:00.0] nv50_sor_mthd: 0000 0184 [ 227.434886] nouveau [ PDISP][0000:05:00.0] 0200 0102 [ 227.434888] nouveau [ PDISP][0000:05:00.0] 0002 01c1 [ 227.434891] nouveau [ PDISP][0000:05:00.0] 0006 0284 [ 227.434893] nouveau [ PDISP][0000:05:00.0] 0002 0284 [ 227.434913] nouveau [ PDISP][0000:05:00.0] nv50_sor_mthd: 0006 0184 [ 227.434915] nouveau [ PDISP][0000:05:00.0] 0200 0102 [ 227.434917] nouveau [ PDISP][0000:05:00.0] 0002 01c1 [ 227.434919] nouveau [ PDISP][0000:05:00.0] 0006 0284 [ 227.434921] nouveau [ PDISP][0000:05:00.0] 0002 0284 and the (unsuccessful) off -> on transition looks like: [ 277.955374] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 8: 0x00000600 1 [ 277.955387] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000001 [ 277.955389] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 277.955392] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 277.955394] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 [ 277.955528] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 00 0x01108000 0x10000000 [ 277.957570] nouveau [ PDISP][0000:05:00.0] nv50_sor_mthd: 0000 0184 [ 277.957574] nouveau [ PDISP][0000:05:00.0] 0200 0102 [ 277.957576] nouveau [ PDISP][0000:05:00.0] 0002 01c1 [ 277.957578] nouveau [ PDISP][0000:05:00.0] 0006 0284 [ 277.957580] nouveau [ PDISP][0000:05:00.0] 0002 0284 [ 277.957600] nouveau [ PDISP][0000:05:00.0] nv50_sor_mthd: 0006 0184 [ 277.957602] nouveau [ PDISP][0000:05:00.0] 0200 0102 [ 277.957604] nouveau [ PDISP][0000:05:00.0] 0002 01c1 [ 277.957607] nouveau [ PDISP][0000:05:00.0] 0006 0284 [ 277.957609] nouveau [ PDISP][0000:05:00.0] 0002 0284 I'll attach the full log soon (pressed for time ATM).
Created attachment 101980 [details] kernel log with additional debug output
(In reply to comment #17) > With the extra output the display on -> standby (off) transition now looks > like: > > [ 227.434722] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 8: 0x00000600 1 > [ 227.434736] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000002 > [ 227.434738] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 227.434741] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 227.434743] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 227.434877] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 00 0x01108000 > 0x10000000 > [ 227.434884] nouveau [ PDISP][0000:05:00.0] nv50_sor_mthd: 0000 0184 > [ 227.434886] nouveau [ PDISP][0000:05:00.0] 0200 0102 > [ 227.434888] nouveau [ PDISP][0000:05:00.0] 0002 01c1 > [ 227.434891] nouveau [ PDISP][0000:05:00.0] 0006 0284 > [ 227.434893] nouveau [ PDISP][0000:05:00.0] 0002 0284 > [ 227.434913] nouveau [ PDISP][0000:05:00.0] nv50_sor_mthd: 0006 0184 > [ 227.434915] nouveau [ PDISP][0000:05:00.0] 0200 0102 > [ 227.434917] nouveau [ PDISP][0000:05:00.0] 0002 01c1 > [ 227.434919] nouveau [ PDISP][0000:05:00.0] 0006 0284 > [ 227.434921] nouveau [ PDISP][0000:05:00.0] 0002 0284 > > and the (unsuccessful) off -> on transition looks like: > > [ 277.955374] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 8: 0x00000600 1 > [ 277.955387] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000001 > [ 277.955389] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 277.955392] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 277.955394] nouveau D[ I2C][0000:05:00.0] AUXCH(3): wr 0x00000000 > [ 277.955528] nouveau D[ I2C][0000:05:00.0] AUXCH(3): 00 0x01108000 > 0x10000000 > [ 277.957570] nouveau [ PDISP][0000:05:00.0] nv50_sor_mthd: 0000 0184 > [ 277.957574] nouveau [ PDISP][0000:05:00.0] 0200 0102 > [ 277.957576] nouveau [ PDISP][0000:05:00.0] 0002 01c1 > [ 277.957578] nouveau [ PDISP][0000:05:00.0] 0006 0284 > [ 277.957580] nouveau [ PDISP][0000:05:00.0] 0002 0284 > [ 277.957600] nouveau [ PDISP][0000:05:00.0] nv50_sor_mthd: 0006 0184 > [ 277.957602] nouveau [ PDISP][0000:05:00.0] 0200 0102 > [ 277.957604] nouveau [ PDISP][0000:05:00.0] 0002 01c1 > [ 277.957607] nouveau [ PDISP][0000:05:00.0] 0006 0284 > [ 277.957609] nouveau [ PDISP][0000:05:00.0] 0002 0284 > > I'll attach the full log soon (pressed for time ATM). I see what's going on, I'll push a patch in the next little while. Thank you.
This commit[1] should hopefully make things work for you. Let me know how you go, Ben. [1] http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=55f5a9c64a638b1e14f39b43459d8eb581a479c3
That change alas produces a garbled display at startup. (It's wrapped in both directions and jittery, like an old TV with bad sync pulse detection.) Just for the heck of it, I tried removing the -1 (dcb->heads is 2) and the display is fine but then it's back to DPMS on not working after off.
(In reply to comment #21) > That change alas produces a garbled display at startup. (It's wrapped in > both directions and jittery, like an old TV with bad sync pulse detection.) > > Just for the heck of it, I tried removing the -1 (dcb->heads is 2) and the > display is fine but then it's back to DPMS on not working after off. Can I get a debug log of that please?
Created attachment 102016 [details] dmesg from garbled display The interesting thing here is that I waited for the dpms timeout, and the screen flashed and came back on more or less immediately, but clean. It's as if something decided that the DPMS-off transition was "activity" and turned the screen back on, properly this time. I don't think that's a driver issue though.
(In reply to comment #23) > Created attachment 102016 [details] > dmesg from garbled display Not sure if/why it's causing a garbled display, but I did spot one bug from the log that's causing link retraining when it's not needed: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=acc79e940a096657651980eb140176921a658e0c > > The interesting thing here is that I waited for the dpms timeout, and the > screen flashed and came back on more or less immediately, but clean. It's > as if something decided that the DPMS-off transition was "activity" and > turned the screen back on, properly this time. I don't think that's a > driver issue though. I hope this is just the monitor being really confused as a result of whatever went wrong before it. If it's not, your monitor is doing the wrong thing and it's going to cause it to immediately resume from a power off (we can work around the problem if it's necessary). But, in your log, your monitor is saying "help! i lost the link! retrain me!" in response to DP_SET_POWER_D3, which it is *explicitly* (according to the DP spec, and, well, common sense) not supposed to do.
That fixed the garbled display. The monitor off/on thing is weird. When I was trying to get 3.14 to work (before discovering this bug report), I tried the nvidia binary driver and got the same flash off/on thing. However, dpms-off was working in 3.6.3, which I unfortunately don't have lying around any more. It seems strange that the monitor would break in this manner, so I guess the 3.6.x driver was doing something to work around the monitor's response. (Also, the monitor-off screensaver works when I am in OS/X.) I can get a log to verify if you like, later today. If there's anything I can get from 3.6 to see if it's doing something different, let me know; I'm sure I can find and build a 3.6 sometime in the next day or two if necessary. At least it's going in the right direction - thanks!
(In reply to comment #25) > That fixed the garbled display. > > The monitor off/on thing is weird. When I was trying to get 3.14 to work > (before discovering this bug report), I tried the nvidia binary driver and > got the same flash off/on thing. However, dpms-off was working in 3.6.3, > which I unfortunately don't have lying around any more. It seems strange > that the monitor would break in this manner, so I guess the 3.6.x driver was > doing something to work around the monitor's response. (Also, the > monitor-off screensaver works when I am in OS/X.) If it's the same situation as Nouveau, then the binary driver probably ignored the HPD_IRQ pulse from the monitor. We need to care about it now (well, we were *supposed* to already, but anyway) for MST support particularly. I'm pretty sure I can work around the issue in the driver if we need to, so that's ok. > > I can get a log to verify if you like, later today. If there's anything I > can get from 3.6 to see if it's doing something different, let me know; I'm > sure I can find and build a 3.6 sometime in the next day or two if necessary. That'd be great, thanks. > > At least it's going in the right direction - thanks!
Created attachment 102151 [details] debug output from last patch, dpms works but screen flashes back on
Created attachment 102152 [details] debug output from 3.6.3 Don't know if this will help any, but 3.6.3 was the last kernel in which I was able to a) run nouveau successfully and b) have the full monitor-off timeout stuff work. I don't pretend that I tried every in-between version, but in general between 3.7 and 3.11 I was never able to find the right magic words to get any kind of operational display, or perhaps things were broken. 3.11 onwards works but then we have the DP DPMS issue which is the original point of this bug report.
Yeah, that's pretty much as expected. Your monitor is broken. I'll come up with some kind of workaround today.
Give this a try: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=31080d6499d64e0578ef55f7473ed83b7bfd72af
Yes, that one does the trick. Excellent, thanks. Who knows why Apple thought that behavior was a good idea. I think it was their first (mini-)display-port design, but still. Whatever...
Hi Ben, Karl, I'm very happy Karl could help diagnose this. (In reply to comment #30) > Give this a try: > http://cgit.freedesktop.org/~darktama/nouveau/commit/ > ?id=31080d6499d64e0578ef55f7473ed83b7bfd72af A janitorial mishap gave me an opportunity to (finally!) update the affected machine. It is now running v3.16-rc6, which includes commit 7fac4933 (matching your patch above). The remaining issues mentioned in comment #8 appear to be fixed in my configuration, too. Thanks! I think this ticket can be closed. Cheers, -D
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.