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

[Takashi Iwai]

On Mon, 09 Jul 2018 17:59:00 +0200,
Alex Deucher wrote:
> 
> On Mon, Jul 9, 2018 at 11:52 AM, Takashi Iwai <tiwai at suse.de> 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 at amd.com> 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.

I guess that It's not enough to have an ACPI event but we need to read
ELD upon hotplugging (not at unplugging, of course, though).  So a GPU
wakeup would be mandatory, if I'm not mistaken.


Takashi