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

[Takashi Iwai]

On Wed, 11 Jul 2018 12:21:03 +0200,
jimqu wrote:
> 
> 
> 
> On 2018年07月11日 17:53, Takashi Iwai wrote:
> > On Wed, 11 Jul 2018 11:26:11 +0200,
> > jimqu wrote:
> >>
> >>
> >> On 2018年07月11日 17:04, Takashi Iwai wrote:
> >>> On Wed, 11 Jul 2018 10:41:38 +0200,
> >>> jimqu wrote:
> >>>>
> >>>> On 2018年07月11日 15:19, Takashi Iwai wrote:
> >>>>> On Tue, 10 Jul 2018 13:21:00 +0200,
> >>>>> Takashi Iwai wrote:
> >>>>>>> revert the fix of amdgpu suspend issue, audio issue also can be observed.
> >>>>>> Did you check the behavior with the single AMD GPU hardware?
> >>>>>> If confirmed, we can forget about vga_switcheroo.
> >>>>> ... and taking a look back at the recent changes, I guess it can be
> >>>>> the forced runtime PM enablement, not directly with vga_switcheroo
> >>>>> action itself.
> >>>> Yeah, the function vga_switcheroo_set_dynamic_switch() has discarded,
> >>>> so there is no way GFX driver to control audio power. However, keep in
> >>>> mind, current audio is bound to iGPU, that mean the issue should be
> >>>> nothing about
> >>>> vgaswtichreoo. since current audio pci bus is different from dGPU,
> >>>> that means the pci_bus_set_current_state() in
> >>>> vga_switcheroo_runtime_suspend() and pci_wakeup_bus() in
> >>>> vga_switcheroo_runtime_resume() could not touch the audio pci power
> >>>> state from dGPU instance.
> >>>>
> >>>> This is a feedback got from our OEM developer, it is the overview of
> >>>> audio detect process.
> >>>>
> >>>>> First, the kernel  audio driver will be triggered to read ELD, if the
> >>>>>> ELD is valid, it will report a jack event (on or available) to sound
> >>>>>> core driver; the pulseaudio subscribe all jack events, if it is told
> >>>>>> that the hdmi jack is plugged in (on), the pulseaudio will set this
> >>>>>> port to available, then the pa-card or pa-sink has available port, it
> >>>>>> can be selected (manually, some daemons or policy in
> >>>>>> /usr/share/pulseaudio/alsa-mixer/) as default output card/default sink.
> >>>> If the description is correct. I think there are maybe two problems.
> >>>>
> >>>> 1. audio will auto power off after setup device link duo to usage_count=0.
> >>>> 2. duo to audio is power down, it could not get the HDMI jack insert event.
> >>>>
> >>>> How do you think?
> >>>>
> >>>>> Jim, could you tell me which PCI devices are handled as vga_switcheroo
> >>>>> audio client?  The kernel should show all messages "xxx: Handle
> >>>>> vga_switcheroo audio client".
> >>>> [    4.311095] snd_hda_intel 0000:06:00.1: enabling device (0000 -> 0002)
> >>>> [    4.314286] snd_hda_intel 0000:06:00.1: Handle vga_switcheroo audio
> >>>> client
> >>>> [    4.314822] snd_hda_intel 0000:06:00.6: enabling device (0000 -> 0002)
> >>>>
> >>>> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> >>>> Inc. [AMD/ATI] Device [1002:699f] (rev c3)
> >>>> 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> >>>> Inc. [AMD/ATI] Device [1002:15dd] (rev d1)
> >>>> 06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
> >>>> Device [1002:15de]
> >>> OK this sheds a brighter light, finally.
> >>>
> >>> If my understanding is correct, the issue is a false vga_switcheroo
> >>> audio detection, after all.  This is the primary GPU and it shouldn't
> >>> be registered as a vga_switcheroo discrete GPU.
> >>>
> >>> Below is a very ugly workaround for this particular case.  It assumes
> >>> that the AMD+AMD combo will never have audio outputs on both but only
> >>> for the primary, and it's possibly wrong.
> >>>
> >>> Is there a handy way to identify whether the given VGA PCI entry is
> >>> a discrete GPU or not?  The amdgpu and radeon seem checking ATPX
> >>> ACPI.
> >> This is no issue about this topic, in amdgpu driver, both iGPU/dGPU
> >> will register as VGA_SWITCHEROO_UNKNOWN_ID, and the client id will be
> >> re-initialized in vgaswitchreoo_enable() via ATPX call. Then, iGPU
> >> will set as VGA_SWITCHEROO_IGD, and dGPU will set as
> >> VGA_SWITCHEROO_DIS.
> > Please check the patch.  It's not about AMDGPU driver but the vga
> > switcheroo detection in HD-audio driver.  Not the GPU side but the
> > audio side.
> >
> > The issues are two folds:
> > - We register each AMD controller associated with a GPU always as a
> >    discrete GPU vga_switcheroo audio.
> > - And when it's registered as a vga_switcheroo client, we forcibly
> >    enable runtime PM of the controller, since discrete GPU needs the
> >    runtime suspend.
> >
> > So a workaround in your case is just not to register as a vga
> > switcheroo audio client.  Then the runtime PM isn't enabled in the AMD
> > HDMI audio controller, and the HDMI detection remains active.
> >
> >
> > Takashi
> 
> OK, I got your point. Let me have a try.
> 
> BTW, what about the patch in this thread, I think it is also need for
> current code. although audio power is not controlled by vgaswitchreoo,
> we also can encounter the issue(audio which is bound to iGPU will
> suspend with dGPU) if user debugfs to control the client power.

That'd do a trick in most cases, too, but I guess one scenario is
overseen: when HD-audio driver is probed / registered before the
graphics driver, it may get a false client id, too.

And the forced runtime PM is still an issue, and this would need the
other notification mechanism than the HD-audio unsolicited event as
AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.


Takashi