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.
Sounds like a bug in the HDA driver. The HDA driver should cache what it needs or power it back up when there is an ioctl/etc. that requires something that can't be cached.
Alex
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.
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 16:02:48 +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.
Sounds like a bug in the HDA driver. The HDA driver should cache what it needs or power it back up when there is an ioctl/etc. that requires something that can't be cached.
Actually I'm not sure whether the analysis above is correct. If PA shows it's unavailable, it implies rather that the HDMI is seen as unconnected. PA doesn't matter about the runtime PM state. If a runtime PM fails, it'd result in a "failure", not "unavailable".
Takashi
Alex
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.
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
participants (2)
-
Alex Deucher -
Takashi Iwai