[alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Mon, Jul 9, 2018 at 12:06 PM, Lukas Wunner <lukas at 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