[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75985

--- Comment #104 from Lukas Wunner <lukas at wunner.de> ---
(In reply to Daniel Drake from comment #102)
> Thanks. azx_runtime_idle() is returning EBUSY because
> azx_bus(chip)->codec_powered=0xf.
> 
> codec_powered is set during initialization via snd_hdac_bus_add_device(),
> presumably to reflect that the device is definitely powered up at
> initialization time.
> 
> It's unset during hdac_hdmi_runtime_suspend() (and/or during
> hda_codec_runtime_suspend()) via the call to snd_hdac_codec_link_down().
> 
> I guess this implies that the HDA codec (hdac_hdmi.c) is expected to be
> fully runtime suspended before the controller (hda_intel.c) runtime idle
> check is executed, and that this is not happening.

Right. However codec_powered is a bitmask and the position in the bitmask is
the "addr" member of struct hdac_device. We can see from the dmesg output that
there are four devices C1D0 .. C1D3. So only bits 0 .. 3 in codec_powered
should ever be set. How can it be that bit 15 (0xf) is set?

I'll see to it that I prepare another debug patch today to instrument all the
places where codec_powered is changed with printk's. But my suspicion is that
the bit may be set differently.  E.g. codec_mask is immediately preceding
codec_powered in the struct (assuming gcc doesn't change the order of the
members). If we happen to set a bit > 64 in codec_mask, we may inadvertantly
clobber codec_powered. So I'll try to instrument changes to surrounding members
as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20191003/6e8cdebe/attachment.html>