On Mon, Jul 9, 2018 at 11:52 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > On Mon, 09 Jul 2018 17:47:34 +0200, > Lukas Wunner wrote: >> >> 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@xxxxxxx> 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. > > It's not about the PCI power state, but the problem is that the > detection of the HDMI and its ELD read is somewhat asynchronous. > Basically it's handled via the hardware unsolicited event emitted over > HD-audio bus, which was originally generated by GPU at dealing with > the hotplug/unplug. So, this part is racy and not 100% reliable -- > although usually it shouldn't be a big problem. > > That said, it's not the exact "need" but it would make things more > reliable and accurate (even consumes less power as we don't need to > power up/down just for the HDMI detection). Well for display detection, we don't actually have to wake the GPU, we get the notification from the embedded controller via ACPI if the GPU is powered down, so in the GPU driver we just pass the event along to userspace if the GPU is asleep. I think if we wanted to pass the info along to the audio driver, we'd need to wake both the GPU and the audio to update the audio connect status. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
