On Mon, 09 Jul 2018 18:15:32 +0200, Alex Deucher wrote: > > On Mon, Jul 9, 2018 at 12:06 PM, Lukas Wunner <lukas@xxxxxxxxx> 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. It needs to power up to read even the shared registers; they are accessed via HD-audio verbs, so we need the whole runtime resume of the bus & codec just for reading ELD information that are stored by GPU. And, ELD info is mandatory for informing the hotplug information to user-space, not only the connection/disconnection state. If ELD and hoptlug info are passed directly from GPU by other means, we can avoid the power up/down in the audio side, indeed. That's what Intel driver serves, after all. Takashi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
