(In reply to Daniel Drake from comment #102)
> Thanks. azx_runtime_idle() is returning EBUSY be=
cause
> azx_bus(chip)->codec_powered=3D0xf.
>=20
> 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.
>=20
> It's unset during hdac_hdmi_runtime_suspend() (and/or during
> hda_codec_runtime_suspend()) via the call to snd_hdac_codec_link_down(=
).
>=20
> 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 id=
le
> 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 dmes=
g 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 t=
he
places where codec_powered is changed with printk's. But my suspicion is th=
at
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 inadverta=
ntly
clobber codec_powered. So I'll try to instrument changes to surrounding mem=
bers
as well.