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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
