Bug 64904

I didn't mention: As a consequence the monitor stays blank.

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

(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?

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

(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.

(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.

Created attachment 79820 [details] [review]
set NV50_PDISPLAY_DAC_CLK_CTRL1

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

(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.

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.

(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.

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

(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

(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

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)

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

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

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

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?

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/