Re: [alsa-devel] 答复: ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Mon, 09 Jul 2018 17:53:19 +0200, Qu, Jim wrote:
Hi All,
Here, I want to clarify the audio device is bound to iGPU. There is no audio codec for dGPU.
I'm confused. So you mean that the HDMI detection on Intel GPU doesn't work with the hybrid GPUs? And no audio codec on discrete GPU...? Why do we need vga_switcheroo at all, then?
Takashi
Thanks JimQu
-----邮件原件----- 发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 23:48 收件人: Takashi Iwai tiwai@suse.de 抄送: Alex Deucher alexdeucher@gmail.com; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim Jim.Qu@amd.com; dri-devel@lists.freedesktop.org; Deucher, Alexander Alexander.Deucher@amd.com 主题: Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
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@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.
Thanks,
Lukas
On Mon, Jul 9, 2018 at 11:57 AM, Takashi Iwai tiwai@suse.de wrote:
On Mon, 09 Jul 2018 17:53:19 +0200, Qu, Jim wrote:
Hi All,
Here, I want to clarify the audio device is bound to iGPU. There is no audio codec for dGPU.
I'm confused. So you mean that the HDMI detection on Intel GPU doesn't work with the hybrid GPUs? And no audio codec on discrete GPU...? Why do we need vga_switcheroo at all, then?
The original problem is the audio codec is getting associated with dGPU rather than the iGPU so switcheroo tries to power down the audio codec when it powers down the dGPU. We got a bit sidetracked in the discussion however.
Alex
Takashi
Thanks JimQu
-----邮件原件----- 发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 23:48 收件人: Takashi Iwai tiwai@suse.de 抄送: Alex Deucher alexdeucher@gmail.com; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim Jim.Qu@amd.com; dri-devel@lists.freedesktop.org; Deucher, Alexander Alexander.Deucher@amd.com 主题: Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
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@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.
Thanks,
Lukas
On Mon, 09 Jul 2018 18:03:48 +0200, Alex Deucher wrote:
On Mon, Jul 9, 2018 at 11:57 AM, Takashi Iwai tiwai@suse.de wrote:
On Mon, 09 Jul 2018 17:53:19 +0200, Qu, Jim wrote:
Hi All,
Here, I want to clarify the audio device is bound to iGPU. There is no audio codec for dGPU.
I'm confused. So you mean that the HDMI detection on Intel GPU doesn't work with the hybrid GPUs? And no audio codec on discrete GPU...? Why do we need vga_switcheroo at all, then?
The original problem is the audio codec is getting associated with dGPU rather than the iGPU so switcheroo tries to power down the audio codec when it powers down the dGPU. We got a bit sidetracked in the discussion however.
Ah, thanks, that clarifies better, but still I'm lost about what's going on...
Can anyone summarize the problem and the results with the recent (>= 4.17) Linux kernel...?
thanks,
Takashi
Alex
Takashi
Thanks JimQu
-----邮件原件----- 发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 23:48 收件人: Takashi Iwai tiwai@suse.de 抄送: Alex Deucher alexdeucher@gmail.com; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim Jim.Qu@amd.com; dri-devel@lists.freedesktop.org; Deucher, Alexander Alexander.Deucher@amd.com 主题: Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
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@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.
Thanks,
Lukas
participants (2)
-
Alex Deucher -
Takashi Iwai