Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim Jim.Qu@amd.com wrote:
Hi Lukas,
Thanks to your explanation, and see comments in line.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
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?
Jim: 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.
Alex
Thanks JimQu
发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 17:27 收件人: Qu, Jim 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
Now, I found the audio device will auto suspend even if the gpu is active, and if I plug in a HDMI device it also do not resume back.
- Did you encounter similar issue before?
- audio will auto suspend as default at beginning of boot, is it expect
behaviour?
Yes, that's expected. Once you start streaming audio to attached displays, user space opens the codec device and this causes the HDA controller to runtime resume. If the discrete GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
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?
Thanks,
Lukas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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:
Hi Lukas,
Thanks to your explanation, and see comments in line.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
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?
Jim: 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.
(Though, it will cause another mess wrt the weak module dependency, but it's another story :)
thanks,
Takashi
Alex
Thanks JimQu
发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 17:27 收件人: Qu, Jim 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
Now, I found the audio device will auto suspend even if the gpu is active, and if I plug in a HDMI device it also do not resume back.
- Did you encounter similar issue before?
- audio will auto suspend as default at beginning of boot, is it expect
behaviour?
Yes, that's expected. Once you start streaming audio to attached displays, user space opens the codec device and this causes the HDA controller to runtime resume. If the discrete GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
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?
Thanks,
Lukas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
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 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@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).
Takashi
On Mon, Jul 9, 2018 at 11:52 AM, Takashi Iwai tiwai@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@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.
Alex
On Mon, 09 Jul 2018 17:59:00 +0200, Alex Deucher wrote:
On Mon, Jul 9, 2018 at 11:52 AM, Takashi Iwai tiwai@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@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
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?
Thanks,
Lukas
On Mon, Jul 9, 2018 at 12:06 PM, Lukas Wunner lukas@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.
Alex
On Mon, 09 Jul 2018 18:15:32 +0200, Alex Deucher wrote:
On Mon, Jul 9, 2018 at 12:06 PM, Lukas Wunner lukas@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
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:
Hi Lukas,
Thanks to your explanation, and see comments in line.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
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?
Jim: 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.
(Though, it will cause another mess wrt the weak module dependency, but it's another story :)
Just don't do what snd-hda-intel did and instead implement the component stuff properly :-) -Daniel
thanks,
Takashi
Alex
Thanks JimQu
发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 17:27 收件人: Qu, Jim 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
Now, I found the audio device will auto suspend even if the gpu is active, and if I plug in a HDMI device it also do not resume back.
- Did you encounter similar issue before?
- audio will auto suspend as default at beginning of boot, is it expect
behaviour?
Yes, that's expected. Once you start streaming audio to attached displays, user space opens the codec device and this causes the HDA controller to runtime resume. If the discrete GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
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?
Thanks,
Lukas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, 09 Jul 2018 17:56:43 +0200, Daniel Vetter 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@amd.com wrote:
Hi Lukas,
Thanks to your explanation, and see comments in line.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
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?
Jim: 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.
(Though, it will cause another mess wrt the weak module dependency, but it's another story :)
Just don't do what snd-hda-intel did and instead implement the component stuff properly :-)
A patch is welcome :)
thanks,
Takashi
-Daniel
thanks,
Takashi
Alex
Thanks JimQu
发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 17:27 收件人: Qu, Jim 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
Now, I found the audio device will auto suspend even if the gpu is active, and if I plug in a HDMI device it also do not resume back.
- Did you encounter similar issue before?
- audio will auto suspend as default at beginning of boot, is it expect
behaviour?
Yes, that's expected. Once you start streaming audio to attached displays, user space opens the codec device and this causes the HDA controller to runtime resume. If the discrete GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
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?
Thanks,
Lukas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Hi Takashi,
Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.
Thanks JimQu
-----邮件原件----- 发件人: Takashi Iwai tiwai@suse.de 发送时间: 2018年7月9日 23:58 收件人: Daniel Vetter daniel@ffwll.ch 抄送: 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, 09 Jul 2018 17:56:43 +0200, Daniel Vetter 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@amd.com wrote:
Hi Lukas,
Thanks to your explanation, and see comments in line.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
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?
Jim: 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.
(Though, it will cause another mess wrt the weak module dependency, but it's another story :)
Just don't do what snd-hda-intel did and instead implement the component stuff properly :-)
A patch is welcome :)
thanks,
Takashi
-Daniel
thanks,
Takashi
Alex
Thanks JimQu
发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 17:27 收件人: Qu, Jim 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
Now, I found the audio device will auto suspend even if the gpu is active, and if I plug in a HDMI device it also do not resume back.
- Did you encounter similar issue before?
- audio will auto suspend as default at beginning of boot, is
it expect behaviour?
Yes, that's expected. Once you start streaming audio to attached displays, user space opens the codec device and this causes the HDA controller to runtime resume. If the discrete GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
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?
Thanks,
Lukas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Mon, 09 Jul 2018 18:05:09 +0200, Qu, Jim wrote:
Hi Takashi,
Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.
OK, and it has all necessary patches including the one Lukas suggested, right?
If so, figure out what you're actually seeing as "PA could not detect HDMI audio". For example, is it the HDMI (jack) detection (giving false even if it's connected)? Or is it an error at opening the given device? Does the driver give the proper ELD bytes as well as the jack state?
Takashi
Thanks JimQu
-----邮件原件----- 发件人: Takashi Iwai tiwai@suse.de 发送时间: 2018年7月9日 23:58 收件人: Daniel Vetter daniel@ffwll.ch 抄送: 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, 09 Jul 2018 17:56:43 +0200, Daniel Vetter 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@amd.com wrote:
Hi Lukas,
Thanks to your explanation, and see comments in line.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
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?
Jim: 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.
(Though, it will cause another mess wrt the weak module dependency, but it's another story :)
Just don't do what snd-hda-intel did and instead implement the component stuff properly :-)
A patch is welcome :)
thanks,
Takashi
-Daniel
thanks,
Takashi
Alex
Thanks JimQu
发件人: Lukas Wunner lukas@wunner.de 发送时间: 2018年7月9日 17:27 收件人: Qu, Jim 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
Now, I found the audio device will auto suspend even if the gpu is active, and if I plug in a HDMI device it also do not resume back.
- Did you encounter similar issue before?
- audio will auto suspend as default at beginning of boot, is
it expect behaviour?
Yes, that's expected. Once you start streaming audio to attached displays, user space opens the codec device and this causes the HDA controller to runtime resume. If the discrete GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly?
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?
Thanks,
Lukas _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
participants (5)
-
Alex Deucher -
Daniel Vetter -
Lukas Wunner -
Qu, Jim -
Takashi Iwai