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

[Takashi Iwai]

On Mon, 09 Jul 2018 18:15:32 +0200,
Alex Deucher wrote:
> 
> 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.

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