Bug 64904

Summary: [BISECTED] nouveau, nv50: External VGA not detected anymore
Product: xorg Reporter: Gerhard Bräunlich <wippbox>
Component: Driver/nouveauAssignee: Emil Velikov <emil.l.velikov>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: drewfrank, joshuabaergen
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=67382
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 66129    
Attachments:
Description Flags
Increase the delay during dac sense
none
set NV50_PDISPLAY_DAC_CLK_CTRL1
none
mangle with dpms mode, before/after dac sense none

Description Gerhard Bräunlich 2013-05-23 10:01:46 UTC
I have a lenove thinkpad T61p with a NVIDIA Corporation G84GLM [Quadro FX
570M].
When connecting my external VGA monitor my monitor is no more detected
properly:
> cat /sys/class/drm/card0-VGA-1/status
gives now "disconnected"

I bisected the kernel sources from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
and filed a bug report at https://bugzilla.kernel.org (https://bugzilla.kernel.org/show_bug.cgi?id=58021).

Last good commit is
ef22c8bb7b3fac45919b7fde412d36d1a8367d51
drm/nv50/disp: call into core to handle dac/sor power state changes

First bad commit is
7ebb38b556485449bfaa506a196439f6a6fd6ebd
drm/nv50/disp: call into core for dac load detection

The responsible function is
nv50_dac_detect in drivers/gpu/drm/nouveau/nv50_dac.c (moved to
drivers/gpu/drm/nouveau/nv50_display.c in more recent kernels).

Also tried a 3.9.1 kernel. The problem still remains.

However, replacing nv50_dac_detect with the corresponding version from the last
good commit fixed the problem (tried with a 3.8.10 and a 3.8.13 kernel).
Comment 1 Gerhard Bräunlich 2013-05-23 12:05:06 UTC
I didn't mention: As a consequence the monitor stays blank.
Comment 2 Emil Velikov 2013-05-24 20:34:53 UTC
Hi Gerhard

There are three distinct changes introduced with the bad commit

* the timeout has been decreased - 45 > 9.5 ms
* the DPMS_MODE was explicitly set before + after the DAC detection, but not any more
* the NV50_PDISPLAY_DAC_CLK_CTRL1 was set at the beginning, whereas the new version is not touching the register

So one at a time, can you increase the delay back to 45ms
Comment 3 Gerhard Bräunlich 2013-05-24 21:32:47 UTC
(In reply to comment #2)
> So one at a time, can you increase the delay back to 45ms

Hi Emil
If you get you right, that means that I should put

mdelay(45);

back into the function nv50_dac_detect.
Is that correct?
Comment 4 Emil Velikov 2013-05-24 22:18:03 UTC
Created attachment 79775 [details] [review]
Increase the delay during dac sense

Take a look at the patch to clear any confusion. It should apply cleanly on top of the 3.9 branch
Comment 5 Gerhard Bräunlich 2013-05-25 08:12:38 UTC
(In reply to comment #4)
> Created attachment 79775 [details] [review] [review]
> Increase the delay during dac sense
> 
> Take a look at the patch to clear any confusion. It should apply cleanly on
> top of the 3.9 branch

OK thank you! I don't have my thinkpad with me at the moment. But I will test the patch tomorrow.
Comment 6 Gerhard Bräunlich 2013-05-26 21:42:48 UTC
(In reply to comment #2)
> So one at a time, can you increase the delay back to 45ms
OK, done: this doesn't fix the problem!

Also tried to set NV50_PDISPLAY_DAC_CLK_CTRL1 (see patch). Didn't fix it too.
Comment 7 Gerhard Bräunlich 2013-05-26 21:43:36 UTC
Created attachment 79820 [details] [review]
set NV50_PDISPLAY_DAC_CLK_CTRL1
Comment 8 Emil Velikov 2013-05-27 14:41:35 UTC
Created attachment 79852 [details] [review]
mangle with dpms mode, before/after dac sense

This is the final piece.

If it does not help, then the three changes could be more closely related than I expected. Either way give it a try, it should apply cleanly on top of linus 3.9
Comment 9 Gerhard Bräunlich 2013-05-27 21:11:23 UTC
(In reply to comment #8)

> Created attachment 79852 [details] [review] [review]
> mangle with dpms mode, before/after dac sense
> 
> This is the final piece.
> 
> If it does not help, then the three changes could be more closely related
> than I expected. Either way give it a try, it should apply cleanly on top of
> linus 3.9

Didn't fix it.
Don't know if the following is useful:
In the statement (nv50_dac_detect)
	if (ret || load != 7)
		return connector_status_disconnected;
I get ret=0 and load!=7 (but don't know the value of load). So load!=7 is responsible that connector_status_disconnected is returned.
Comment 10 Maarten Lankhorst 2013-05-27 22:23:58 UTC
Strictly speaking it should probably be (load & 7) == 7, but I don't think it'll fix it on its own, you might want to dump the value of load to be sure, with all those patches.
Comment 11 Gerhard Bräunlich 2013-05-28 08:27:04 UTC
(In reply to comment #10)
> Strictly speaking it should probably be (load & 7) == 7, but I don't think
> it'll fix it on its own, you might want to dump the value of load to be
> sure, with all those patches.

OK, I get load=0.
Comment 12 Joshua Baergen 2013-05-30 16:00:36 UTC
I can confirm this issue on a ThinkPad W530, NVIDIA Corporation GK107GLM [Quadro K1000M] (rev a1).  I noticed the issue at work when I tried to connect to VGA extender which in turn was hooked up to a projector.  However, connecting directly to a VGA monitor worked fine.

I took Gerhard's suggestion and patched my 2.8.13 Gentoo kernel with the nv50_dac_detect from ef22c8bb7b3fac45919b7fde412d36d1a8367d51 and I was then able to connect to the projector.

FWIW, at least one other thing I noticed in the patch is that in the working code, there's the following sequence:

1) Write (NV50_PDISPLAY_DAC_LOAD_CTRL_ACTIVE | load_pattern) to DAC_LOAD_CTRL(i).
2) Read DAC_LOAD_CTRL(i).
3) Write 0 to DAC_LOAD_CTRL(i).

In the new code, it's:

1) Write (NV50_PDISPLAY_DAC_LOAD_CTRL_ACTIVE | load_pattern) to DAC_LOAD_CTRL(i).
2) Write NV50_PDISPLAY_DAC_LOAD_CTRL_DONE to DAC_LOAD_CTRL(i).
3) Read DAC_LOAD_CTRL(i).

Being completely unfamiliar with the hardware, I'm not sure if this is significant, and unfortunately, I don't have much (if any) opportunity to experiment.

Josh
Comment 13 Emil Velikov 2013-06-02 00:05:39 UTC
(In reply to comment #12)
> ...
> 2) Write NV50_PDISPLAY_DAC_LOAD_CTRL_DONE to DAC_LOAD_CTRL(i).

Nice catch Josh, although this write is not the one causing the issue.


Just got a VGA cable and I can reproduce the issue.

Would need to do some testing if the fix does not break the behaviour on any other cards
Comment 14 Joshua Baergen 2013-06-02 02:15:17 UTC
(In reply to comment #13) 
> Nice catch Josh, although this write is not the one causing the issue.

It sounds like you've figured it out.  Out of curiosity, what is the issue?

Josh
Comment 15 Emil Velikov 2013-06-02 09:31:42 UTC
Alot of unification and overhaul during the 3.9 cycle

* nv50 and nvd0 code has been unified -> some of the code that was explicitly needed for nv50 was removed, while other altered

List wrt nv50:
[removed]
DAC_CLK1 - (optional) no significance found yet
DAC_DPMS_CTRL << 0x00150000 - (must) otherwise DAC_LOAD_CTRL does not work
DAC_DPMS_CTRL << _OLD_MODE - (must) preserve the current DPMS mode

[changed]
loadval(load_pattern) - use either bios data or default. Using 0 will cause either "always connected" or the opposite, depending on the hardware

[added]
DAC_LOAD_CTRL << DONE - (optional) stabilises the reading

Would need to check if any of this can be left unified (i.e. does the extra code adds any issues for nvd0), and based on that workout a patch



Todo
* confirm the delays
* Check if any of those have any relevance on functionality or power consumption
[removed during the ufinication]
  DAC_CTRL_BLANKED (DAC_PWR_DATA)
  DAC_CTRL_OFF (DAC_PWR_STATE)
Comment 16 Ben Skeggs 2013-06-03 06:47:45 UTC
I've reproduced the issue, and pushed two commits[1][2] based on the findings that have been mentioned in this bug.

Thanks for the reports, and investigation!

Ben.

[1] http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=34fbb7eb3ce00a10e99dc4768a651f1fcb47aade
[2] http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=b911b6c0ba6daa58a736ef6fb58a873a5a271d81
Comment 17 Emil Velikov 2013-06-19 23:10:10 UTC
Thank you Ben.
Honestly hope the patches do not have any side effects on nvd9+ systems

Gerhard
AFAIK both patches are in the 3.10 as well as queued for the 3.9 stable branch[1]
Feel free to give them a try

[1] http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git
Comment 18 Gerhard Bräunlich 2013-06-20 07:37:54 UTC
OK, works for me. No obvious side effects.

(In reply to comment #17)
> Thank you Ben.
> Honestly hope the patches do not have any side effects on nvd9+ systems
> 
> Gerhard
> AFAIK both patches are in the 3.10 as well as queued for the 3.9 stable
> branch[1]
> Feel free to give them a try
> 
> [1] http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git
Comment 19 Per Arnold Blaasmo 2013-06-21 07:04:20 UTC
I seem to have much of the same problem.as this, but this fix does not seem to work for me.

I just installed kernel 3.9.7 which have these fixes included. And I still have the same problem.

I am running a Dell desktop with  NVIDA Quadro NVS 295 graphic card and two
identical Dell monitors attached via DisplayPort.

I run Fedora 18 with all latest updates and using Nouveau drivers.

Starting with Kernel 3.8.11 it boots OK and both monitors works as expected.
Starting with Kernel 3.9.2-3.9.7 it boots, but when trying to display
anything on monitor two it gets into problems.

It boots until its tries to start the Xorg server and then monitor 2 starts
flickering on and off. Monitor 1 stays with the boot logo of fedora.

Also during boot when booting I only have the boot logo of fedora on monitor 1
when running kernel 3.9.x while I have it on both screens when running kernel
3.8.11

I am able to hit CTRL+f2 to get a text login.

Is having two monitor different from having an external VGA?
Comment 20 Emil Velikov 2013-06-21 22:17:22 UTC
Per Arnold Blaasmo

As mentioned in the bugzilla.kernel.org your issue is different from this one.
Please open a separate bug report attaching relevant logs[1]. Bisection would be extremely useful :)

Emil

[1] http://nouveau.freedesktop.org/wiki/Bugs/

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.