On Mon, Jul 9, 2018 at 12:06 PM, Lukas Wunner lukas@wunner.de wrote:
On Mon, Jul 09, 2018 at 05:52:49PM +0200, Takashi Iwai wrote:
On Mon, 09 Jul 2018 17:47:34 +0200, Lukas Wunner wrote:
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).
Okay. If amdgpu triggers the event on the HDA bus, it should call pm_runtime_get_sync() on the HDA device beforehand. Which device needs to be resumed exactly to ensure ELD reception, the PCI one or the codec?
I don't think it makes sense to power up anything until the user wants to do something with the event. On AMD hardware, the ELD is not actually used. The gpu passes the ELD info internally via shared registers. So as soon as the GPU driver parses the EDID and updates the shared registers, the audio driver will know the state just by reading back the shared registers. That said, there no reason to act on the event unless the user actually wants to do something with it. E.g., the desktop manager sees the event and decides to call down to the kernel to query the display topology (or not). At which point the hw can be powered up, etc.
Alex