On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote: > On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote: > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu at amd.com> wrote: > > > > You're saying above that the HDA controller isn't runtime resumed on > > > > hotplug of a display. Is that necessary to retrieve ELD or something? > > > > I'm not sure if there's code in the HDA driver to acquire a runtime PM > > > > ref on HPD, but maybe it's necessary. Or maybe the code is there but > > > > somehow no HPD interrupt is received by the HDA driver? > > > > > > So far, I do not find any code about audio response HPD in kernel. > > > the HPD interrupt will sent to user mode via uevent, not sure whether > > > audio user mode driver can receive the event or not. > > > > On the gfx side at least, we can get a hotplug event via ACPI > > (depending on the OEM design) if displays are attached/detached while > > the dGPU is powered down. I suppose the gfx driver could call into > > the audio driver during one of those events. On the gfx side at least > > we just generate the gfx hotplug event and let userspace deal with it. > > IMO, a more proper way would be to have the direct communication > between the graphics driver and the audio driver like i915 driver > does. Then the audio driver can get plug/unplug event at more > accurate timing without races. Since v4.17, every time the GPU is powered up, the HDA controller is runtime resumed to PCI_D0. (See the call to pci_wakeup_bus() in vga_switcheroo_runtime_resume() added by dcac86b7d0.) If the HDA controller can't detect presence of an HDMI display even if it's in PCI_D0, then I suppose that needs to be adressed in the HDA driver. Thus so far I don't see the need to call from amdgpu into the HDA driver. Thanks, Lukas
