Comment # 104
on bug 75985
from Lukas Wunner
(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.
_______________________________________________ Nouveau mailing list Nouveau@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/nouveau
