Bug 32406

Created attachment 41137 [details]
mmio trace of the nvidia module while running "service gdm start"

mmio trace of the nvidia module while running "service gdm start"
That is enough to should the needed messages
[ 4326.778126] HDMI hot plug event: Pin=5 Presence_Detect=1 ELD_Valid=0
[ 4351.695743] HDMI hot plug event: Pin=5 Presence_Detect=1 ELD_Valid=0
[ 4352.597993] HDMI hot plug event: Pin=5 Presence_Detect=1 ELD_Valid=1

Created attachment 41138 [details]
mmio trace of the nvidia module loading, and then starting X

The previous trace did not seem to output anything useful.
This one is better.

I tried the following and it worked:

I modified the patch. nv50_sor.c::nv50_sor_create(), remove the "|| dev_priv->chipset == 0xac" case so that nva3_audio_init is called for your card.

I now get the hotplug event, and the ALSA audio picks up the HDMI output.
I will test actual audio tomorrow.

Update: It does not actually work from boot.
If you modprobe the nouveau module after boot, it works, if nouveau loads during boot up, it does not send the "hot plug" event.

Further investigation has found the following:
1) The nouveau driver sets the correct gpio pins and the ALSA audio driver can see them set.
2) The hotplug event only happens when the state of the gpio pins changes.
3) The ALSA driver creates the hotplug event as a result of detecting the gpio pins change.
4) nouveau modules seems to load before the alsa module, so the hotplug event never gets created by the ALSA audio driver because it is not loaded.
5) If the nouveau driver is loaded after boot, the hotplug event is sent to ALSA and it works fine.
6) If the ALSA driver is loaded after boot, it detects the gpio pins settings and acts correctly and works fine.
7) The problem is only present if the nouveau and alsa module load at boot time.
I am investingating (7) next.

I have found the problem.
nouveau tries to send the eld info in
nv50_audio_mode_set()

Unfortunately, this is sent before the audio driver is loaded.
It is then resent later.
If the ALSA audio driver is forced to try and read the eld data 3 times instead of just once, the eld data finally reaches the ALSA audio driver, and sound then works.
So, I now have a valid work around.
Some further investigation is needed to discover why the sending of eld data is so unreliable, requiring it to be sent multiple times.
Maybe some co-ordination between the nouveau driver and ALSA is required to ensure good delivery of the eld data, so that it is valid before setting the eld_valid GPIO.

(In reply to comment #6)
> I have found the problem.
> nouveau tries to send the eld info in
> nv50_audio_mode_set()
> 
> Unfortunately, this is sent before the audio driver is loaded.
> It is then resent later.
> If the ALSA audio driver is forced to try and read the eld data 3 times instead
> of just once, the eld data finally reaches the ALSA audio driver, and sound
> then works.
> So, I now have a valid work around.
> Some further investigation is needed to discover why the sending of eld data is
> so unreliable, requiring it to be sent multiple times.
> Maybe some co-ordination between the nouveau driver and ALSA is required to
> ensure good delivery of the eld data, so that it is valid before setting the
> eld_valid GPIO.

I've just been trying to get HDMI audio to work, using the Nouveau driver, and I'm running into this ELD issue. Is there any progress on this issue so as to make it work "out of the box"?

Btw, I'm using Debian Sid with:

Linux 3.0.4
Nouveau x-driver: 1:0.0.16+git20110411+8378443-1+b2
libasound 1.0.24.1-4

on an Asis X5DID computer with:

lspci -vs 02:00.0
02:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 320M] (rev a2) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 1312
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Memory at f6000000 (64-bit, prefetchable) [size=32M]
	I/O ports at dc00 [size=128]
	Expansion ROM at faf80000 [disabled] [size=512K]
	Capabilities: <access denied>
	Kernel driver in use: nouveau

and

lspci -vs 02:00.1
02:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev a1)
	Subsystem: ASUSTeK Computer Inc. Device 1312
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at faf7c000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: HDA Intel

It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one.

Thanks,

The Nouveau Team

Hey Ilia,

I can confirm that this is still an issue. In fact, I noticed it not just with the Nouveau driver (Ubuntu, amd64, 1:1.0.11+git1411032101.3fb97d~gd~u), but also with the non-free nVidia 346 driver. 

In both cases the hotplug notification was not being reported by udevadm (and presumably the kernel hotplug system either via netlink or script driven). The card in question was an nVidia GeForce GTX 960. 

This may be a hardware issue because plugging in the same HDMI sink (Onkyo TX-NR535) to my integrated Intel HDMI port emits several hotplug events no problem on both connect and disconnect.