Re: [alsa-devel] 答复: 答复: 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
On Tue, 10 Jul 2018 09:44:42 +0200, Qu, Jim wrote:
Hi Takashi,
I am not expert in audio driver, so I just update some test result, please help triage the issue.
With audio runtime pm:
What does this mean? Is it the stock 4.17.x (or 4.18-rc)? Please clarify your test environment at first: which kernel, which hardware setup.
- ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
- cat /proc/asound/card0/eld* can get nothing.
Without audio runtime pm:
- pactl can get available audio output/sink
- can get eld info from eld#0.1
IMO, the issue should be:
Current operations like HDMI hotplug in/out, pactl command, they do not access audio HW, so the audio could not resume back at this period.
Sorry, not understood. Why they don't access the audio hardware?
Therefore, upper software could not get HDMI ELD info, can select a available card/output sink. I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
As long as it's i915 and HD-audio, the hotplug and ELD info transfer doesn't trigger the runtime PM since it's done via the direct callback. And ELD value is cached in HD-audio side.
The exception is that if the notification is done during the PM operation. But, the connection and ELD query is performed at the end of codec resume, hence it'll be covered there.
So in theory, ELD information should be passed from the GPU to HD-audio no matter whether runtime PM is enabled or not.
BTW, please stop top-posting. It makes the thread readability awfully worse.
thanks,
Takashi
Thanks JimQu
发件人: Takashi Iwai tiwai@suse.de 发送时间: 2018年7月10日 1:09 收件人: Qu, Jim 抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander 主题: Re: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
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. > > 1. Did you encounter similar issue before? > 2. 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
[2 pactl_with_runtimepm <application/octet-stream (base64)>]
On 2018年07月10日 16:01, Takashi Iwai wrote:
On Tue, 10 Jul 2018 09:44:42 +0200, Qu, Jim wrote:
Hi Takashi,
I am not expert in audio driver, so I just update some test result, please help triage the issue.
With audio runtime pm:
What does this mean? Is it the stock 4.17.x (or 4.18-rc)? Please clarify your test environment at first: which kernel, which hardware setup.
This is v4.15 which backport Lukas' patches and also one bug fix https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=5.... The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX platform. In generic, dGPU will always be suspended.
- ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
- cat /proc/asound/card0/eld* can get nothing.
Without audio runtime pm:
- pactl can get available audio output/sink
- can get eld info from eld#0.1
IMO, the issue should be:
Current operations like HDMI hotplug in/out, pactl command, they do not access audio HW, so the audio could not resume back at this period.
Sorry, not understood. Why they don't access the audio hardware?
This is my guess, since I do not get azx_runtime_resume() print info which I added. it maybe access HW during this period, but do not trigger audio resume progress. https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume
Therefore, upper software could not get HDMI ELD info, can select a available card/output sink. I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
As long as it's i915 and HD-audio, the hotplug and ELD info transfer doesn't trigger the runtime PM since it's done via the direct callback. And ELD value is cached in HD-audio side.
Yeah, I have reviewed these code, it constructs ELD after reading EDID, and write them into HW buffer when set display mode.
The exception is that if the notification is done during the PM operation. But, the connection and ELD query is performed at the end of codec resume, hence it'll be covered there.
So in theory, ELD information should be passed from the GPU to HD-audio no matter whether runtime PM is enabled or not.
BTW, please stop top-posting. It makes the thread readability awfully worse.
Sorry, I justed used outlook client.
thanks,
Takashi
Thanks JimQu
发件人: Takashi Iwai tiwai@suse.de 发送时间: 2018年7月10日 1:09 收件人: Qu, Jim 抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander 主题: Re: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
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. >> >> 1. Did you encounter similar issue before? >> 2. 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
[2 pactl_with_runtimepm <application/octet-stream (base64)>]
On Tue, 10 Jul 2018 11:13:27 +0200, jimqu wrote:
On 2018年07月10日 16:01, Takashi Iwai wrote:
On Tue, 10 Jul 2018 09:44:42 +0200, Qu, Jim wrote:
Hi Takashi,
I am not expert in audio driver, so I just update some test result, please help triage the issue.
With audio runtime pm:
What does this mean? Is it the stock 4.17.x (or 4.18-rc)? Please clarify your test environment at first: which kernel, which hardware setup.
This is v4.15 which backport Lukas' patches and also one bug fix https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=5.... The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX platform. In generic, dGPU will always be suspended.
Ah, so it's AMD+AMD, not Intel+AMD combo. Now I understand the situation better, thanks.
- ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
- cat /proc/asound/card0/eld* can get nothing.
Without audio runtime pm:
- pactl can get available audio output/sink
- can get eld info from eld#0.1
IMO, the issue should be:
Current operations like HDMI hotplug in/out, pactl command, they do not access audio HW, so the audio could not resume back at this period.
Sorry, not understood. Why they don't access the audio hardware?
This is my guess, since I do not get azx_runtime_resume() print info which I added. it maybe access HW during this period, but do not trigger audio resume progress. https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume
Therefore, upper software could not get HDMI ELD info, can select a available card/output sink. I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
As long as it's i915 and HD-audio, the hotplug and ELD info transfer doesn't trigger the runtime PM since it's done via the direct callback. And ELD value is cached in HD-audio side.
Yeah, I have reviewed these code, it constructs ELD after reading EDID, and write them into HW buffer when set display mode.
If the controller chip supports "wake-enable" feature (HD-audio WAKEEN register), it could be woken up at unsolicited event even during the link power down. But, your report implies that AMD controller doesn't do this, or something missing there. That's the likely cause of the missing hotplug event.
So, if my understanding is right, the situation won't be different even if you have a single AMD GPU. And possibly a side-effect of the latest fix to force link-down for AMD GPU. Need to check it...
Takashi
The exception is that if the notification is done during the PM operation. But, the connection and ELD query is performed at the end of codec resume, hence it'll be covered there.
So in theory, ELD information should be passed from the GPU to HD-audio no matter whether runtime PM is enabled or not.
BTW, please stop top-posting. It makes the thread readability awfully worse.
Sorry, I justed used outlook client.
thanks,
Takashi
Thanks JimQu
发件人: Takashi Iwai tiwai@suse.de 发送时间: 2018年7月10日 1:09 收件人: Qu, Jim 抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander 主题: Re: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
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. >>> >>> 1. Did you encounter similar issue before? >>> 2. 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
[2 pactl_with_runtimepm <application/octet-stream (base64)>]
[2 <text/html; utf-8 (8bit)>]
On 2018年07月10日 17:50, Takashi Iwai wrote:
On Tue, 10 Jul 2018 11:13:27 +0200, jimqu wrote:
On 2018年07月10日 16:01, Takashi Iwai wrote:
On Tue, 10 Jul 2018 09:44:42 +0200, Qu, Jim wrote:
Hi Takashi,
I am not expert in audio driver, so I just update some test result, please help triage the issue.
With audio runtime pm:
What does this mean? Is it the stock 4.17.x (or 4.18-rc)? Please clarify your test environment at first: which kernel, which hardware setup.
This is v4.15 which backport Lukas' patches and also one bug fix https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=5.... The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX platform. In generic, dGPU will always be suspended.
Ah, so it's AMD+AMD, not Intel+AMD combo. Now I understand the situation better, thanks.
- ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
- cat /proc/asound/card0/eld* can get nothing.
Without audio runtime pm:
- pactl can get available audio output/sink
- can get eld info from eld#0.1
IMO, the issue should be:
Current operations like HDMI hotplug in/out, pactl command, they do not access audio HW, so the audio could not resume back at this period.
Sorry, not understood. Why they don't access the audio hardware?
This is my guess, since I do not get azx_runtime_resume() print info which I added. it maybe access HW during this period, but do not trigger audio resume progress. https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume
Therefore, upper software could not get HDMI ELD info, can select a available card/output sink. I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
As long as it's i915 and HD-audio, the hotplug and ELD info transfer doesn't trigger the runtime PM since it's done via the direct callback. And ELD value is cached in HD-audio side.
Yeah, I have reviewed these code, it constructs ELD after reading EDID, and write them into HW buffer when set display mode.
If the controller chip supports "wake-enable" feature (HD-audio WAKEEN register), it could be woken up at unsolicited event even during the link power down. But, your report implies that AMD controller doesn't do this, or something missing there. That's the likely cause of the missing hotplug event.
Is there any method to confirm it?
So, if my understanding is right, the situation won't be different even if you have a single AMD GPU. And possibly a side-effect of the latest fix to force link-down for AMD GPU. Need to check it...
Before Lukas' patches, it is relative with dGPU, because audio power is controlled by vgaswitchreroo and GFX driver, but now it won't. revert the fix of amdgpu suspend issue, audio issue also can be observed.
Takashi
The exception is that if the notification is done during the PM operation. But, the connection and ELD query is performed at the end of codec resume, hence it'll be covered there.
So in theory, ELD information should be passed from the GPU to HD-audio no matter whether runtime PM is enabled or not.
BTW, please stop top-posting. It makes the thread readability awfully worse.
Sorry, I justed used outlook client.
thanks,
Takashi
Thanks JimQu
发件人: Takashi Iwai tiwai@suse.de 发送时间: 2018年7月10日 1:09 收件人: Qu, Jim 抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander 主题: Re: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
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. >>>> >>>> 1. Did you encounter similar issue before? >>>> 2. 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
[2 pactl_with_runtimepm <application/octet-stream (base64)>]
[2 <text/html; utf-8 (8bit)>]
On Tue, 10 Jul 2018 13:11:20 +0200, jimqu wrote:
On 2018年07月10日 17:50, Takashi Iwai wrote:
On Tue, 10 Jul 2018 11:13:27 +0200, jimqu wrote:
On 2018年07月10日 16:01, Takashi Iwai wrote:
On Tue, 10 Jul 2018 09:44:42 +0200, Qu, Jim wrote:
Hi Takashi,
I am not expert in audio driver, so I just update some test result, please help triage the issue.
With audio runtime pm:
What does this mean? Is it the stock 4.17.x (or 4.18-rc)? Please clarify your test environment at first: which kernel, which hardware setup.
This is v4.15 which backport Lukas' patches and also one bug fix https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=5.... The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX platform. In generic, dGPU will always be suspended.
Ah, so it's AMD+AMD, not Intel+AMD combo. Now I understand the situation better, thanks.
- ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
- cat /proc/asound/card0/eld* can get nothing.
Without audio runtime pm:
- pactl can get available audio output/sink
- can get eld info from eld#0.1
IMO, the issue should be:
Current operations like HDMI hotplug in/out, pactl command, they do not access audio HW, so the audio could not resume back at this period.
Sorry, not understood. Why they don't access the audio hardware?
This is my guess, since I do not get azx_runtime_resume() print info which I added. it maybe access HW during this period, but do not trigger audio resume progress. https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume
Therefore, upper software could not get HDMI ELD info, can select a available card/output sink. I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
As long as it's i915 and HD-audio, the hotplug and ELD info transfer doesn't trigger the runtime PM since it's done via the direct callback. And ELD value is cached in HD-audio side.
Yeah, I have reviewed these code, it constructs ELD after reading EDID, and write them into HW buffer when set display mode.
If the controller chip supports "wake-enable" feature (HD-audio WAKEEN register), it could be woken up at unsolicited event even during the link power down. But, your report implies that AMD controller doesn't do this, or something missing there. That's the likely cause of the missing hotplug event.
Is there any method to confirm it?
The driver always sets WAKEEN bit, see azx_runtime_suspend() in hda_intel.c. If it still doesn't behave as expected, it means that the feature isn't supported on that chip :)
So, if my understanding is right, the situation won't be different even if you have a single AMD GPU. And possibly a side-effect of the latest fix to force link-down for AMD GPU. Need to check it...
Before Lukas' patches, it is relative with dGPU, because audio power is controlled by vgaswitchreroo and GFX driver, but now it won't.
Right, and this is the correct behavior.
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.
Takashi
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.
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".
At best, give the full dmesg output and the lspci -nv output.
thanks,
Takashi
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]
Thanks JimQu
At best, give the full dmesg output and the lspci -nv output.
thanks,
Takashi
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.
- audio will auto power off after setup device link duo to usage_count=0.
- 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.
Takashi
--- --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1418,8 +1418,18 @@ static int azx_dev_free(struct snd_device *device) */ static struct pci_dev *get_bound_vga(struct pci_dev *pci) { + static const struct pci_device_id ids[] = { + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID), + .class = PCI_BASE_CLASS_DISPLAY << 16, + .class_mask = 0xff << 16 }, + {} + }; struct pci_dev *p;
+ /* check whether Intel graphics is present as primary GPU */ + if (!pci_dev_present(ids)) + return NULL; + /* check only discrete GPU */ switch (pci->vendor) { case PCI_VENDOR_ID_ATI:
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.
- audio will auto power off after setup device link duo to usage_count=0.
- 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.
I think current focus should be how to detect HDMI audio device under audio suspend state.
Thanks JimQu
Takashi
--- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1418,8 +1418,18 @@ static int azx_dev_free(struct snd_device *device) */ static struct pci_dev *get_bound_vga(struct pci_dev *pci) {
static const struct pci_device_id ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID),.class = PCI_BASE_CLASS_DISPLAY << 16,.class_mask = 0xff << 16 },{}}; struct pci_dev *p;
/* check whether Intel graphics is present as primary GPU */
if (!pci_dev_present(ids))
return NULL;/* check only discrete GPU */ switch (pci->vendor) { case PCI_VENDOR_ID_ATI:
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.
- audio will auto power off after setup device link duo to usage_count=0.
- 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
Thanks JimQu
Takashi
--- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1418,8 +1418,18 @@ static int azx_dev_free(struct snd_device *device) */ static struct pci_dev *get_bound_vga(struct pci_dev *pci) {
- static const struct pci_device_id ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID),.class = PCI_BASE_CLASS_DISPLAY << 16,.class_mask = 0xff << 16 },{}- }; struct pci_dev *p;
- /* check whether Intel graphics is present as primary GPU */
- if (!pci_dev_present(ids))
return NULL;- /* check only discrete GPU */ switch (pci->vendor) { case PCI_VENDOR_ID_ATI:
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.
- audio will auto power off after setup device link duo to usage_count=0.
- 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.
Thanks JimQu
Thanks JimQu
Takashi
--- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1418,8 +1418,18 @@ static int azx_dev_free(struct snd_device *device) */ static struct pci_dev *get_bound_vga(struct pci_dev *pci) {
- static const struct pci_device_id ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID),.class = PCI_BASE_CLASS_DISPLAY << 16,.class_mask = 0xff << 16 },{}- }; struct pci_dev *p;
- /* check whether Intel graphics is present as primary GPU */
- if (!pci_dev_present(ids))
return NULL;- /* check only discrete GPU */ switch (pci->vendor) { case PCI_VENDOR_ID_ATI:
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.
- audio will auto power off after setup device link duo to usage_count=0.
- 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
On Wed, 11 Jul 2018 13:12:01 +0200, Takashi Iwai wrote:
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.
Since we had a nice "hack week" in this week at SUSE, I spent some time to write some patches for the support of the direct hotplug notification / ELD query between HD-audio and radeon/amdgpu. It re-utilizes the audio component framework for i915 but in a slightly more flexible way.
The patches are found in topic/hda-acomp branch of my sound.git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The following commits are relevant: drm/i915: Split audio component to a generic type ALSA: hda/i915: Allow delayed i915 audio component binding ALSA: hda/i915: Associate audio component with devres ALSA: hda: Make audio component support more generic ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI ALSA: hda/hdmi: Use single mutex unlock in error paths drm/radeon: Add audio component support drm/amdgpu: Add audio component support
The branch should be cleanly pullable onto the latest 4.18-rc.
I couldn't test amdgpu but the test with a radeon driver on an old laptop seemed working through a very quick test.
Please give it a try.
thanks,
Takashi
在 2018/7/13 23:07, Takashi Iwai 写道:
On Wed, 11 Jul 2018 13:12:01 +0200, Takashi Iwai wrote:
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.
Since we had a nice "hack week" in this week at SUSE, I spent some time to write some patches for the support of the direct hotplug notification / ELD query between HD-audio and radeon/amdgpu. It re-utilizes the audio component framework for i915 but in a slightly more flexible way.
The patches are found in topic/hda-acomp branch of my sound.git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The following commits are relevant: drm/i915: Split audio component to a generic type ALSA: hda/i915: Allow delayed i915 audio component binding ALSA: hda/i915: Associate audio component with devres ALSA: hda: Make audio component support more generic ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI ALSA: hda/hdmi: Use single mutex unlock in error paths drm/radeon: Add audio component support drm/amdgpu: Add audio component support
The branch should be cleanly pullable onto the latest 4.18-rc.
I couldn't test amdgpu but the test with a radeon driver on an old laptop seemed working through a very quick test.
Please give it a try.
That is really wonderful work. I will check it on our AMD platform. BTW, For display, AMD has moved to use DC to support new asics. so there also need a patch for amdgpu in DC code.
Thanks JimQu
thanks,
Takashi
On Sat, 14 Jul 2018 14:03:26 +0200, jimqu wrote:
在 2018/7/13 23:07, Takashi Iwai 写道:
On Wed, 11 Jul 2018 13:12:01 +0200, Takashi Iwai wrote:
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.
Since we had a nice "hack week" in this week at SUSE, I spent some time to write some patches for the support of the direct hotplug notification / ELD query between HD-audio and radeon/amdgpu. It re-utilizes the audio component framework for i915 but in a slightly more flexible way.
The patches are found in topic/hda-acomp branch of my sound.git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The following commits are relevant: drm/i915: Split audio component to a generic type ALSA: hda/i915: Allow delayed i915 audio component binding ALSA: hda/i915: Associate audio component with devres ALSA: hda: Make audio component support more generic ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI ALSA: hda/hdmi: Use single mutex unlock in error paths drm/radeon: Add audio component support drm/amdgpu: Add audio component support
The branch should be cleanly pullable onto the latest 4.18-rc.
I couldn't test amdgpu but the test with a radeon driver on an old laptop seemed working through a very quick test.
Please give it a try.
That is really wonderful work. I will check it on our AMD platform.
Thanks, it'll be great if you can check whether the current code works or not. I'd love to push the stuff for 4.19. Hopefully I'll start submitting the preparation patches in the next week.
Basically this also opens the door of the similar capability for nouveau, and I guess it's also trivial enough.
BTW, For display, AMD has moved to use DC to support new asics. so there also need a patch for amdgpu in DC code.
Could you give a more hint? I'll try adapt the code if such a change is already in upstream tree.
Takashi
On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai tiwai@suse.de wrote:
On Sat, 14 Jul 2018 14:03:26 +0200, jimqu wrote:
在 2018/7/13 23:07, Takashi Iwai 写道:
On Wed, 11 Jul 2018 13:12:01 +0200, Takashi Iwai wrote:
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.
Since we had a nice "hack week" in this week at SUSE, I spent some time to write some patches for the support of the direct hotplug notification / ELD query between HD-audio and radeon/amdgpu. It re-utilizes the audio component framework for i915 but in a slightly more flexible way.
The patches are found in topic/hda-acomp branch of my sound.git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The following commits are relevant: drm/i915: Split audio component to a generic type ALSA: hda/i915: Allow delayed i915 audio component binding ALSA: hda/i915: Associate audio component with devres ALSA: hda: Make audio component support more generic ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI ALSA: hda/hdmi: Use single mutex unlock in error paths drm/radeon: Add audio component support drm/amdgpu: Add audio component support
The branch should be cleanly pullable onto the latest 4.18-rc.
I couldn't test amdgpu but the test with a radeon driver on an old laptop seemed working through a very quick test.
Please give it a try.
That is really wonderful work. I will check it on our AMD platform.
Thanks, it'll be great if you can check whether the current code works or not. I'd love to push the stuff for 4.19. Hopefully I'll start submitting the preparation patches in the next week.
Basically this also opens the door of the similar capability for nouveau, and I guess it's also trivial enough.
BTW, For display, AMD has moved to use DC to support new asics. so there also need a patch for amdgpu in DC code.
Could you give a more hint? I'll try adapt the code if such a change is already in upstream tree.
The new code is in drivers/gpu/drm/amd/display.
Alex
On 2018-07-15 10:36 AM, Alex Deucher wrote:
On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai tiwai@suse.de wrote:
On Sat, 14 Jul 2018 14:03:26 +0200, jimqu wrote:
在 2018/7/13 23:07, Takashi Iwai 写道:
On Wed, 11 Jul 2018 13:12:01 +0200, Takashi Iwai wrote:
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.
Since we had a nice "hack week" in this week at SUSE, I spent some time to write some patches for the support of the direct hotplug notification / ELD query between HD-audio and radeon/amdgpu. It re-utilizes the audio component framework for i915 but in a slightly more flexible way.
The patches are found in topic/hda-acomp branch of my sound.git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The following commits are relevant: drm/i915: Split audio component to a generic type ALSA: hda/i915: Allow delayed i915 audio component binding ALSA: hda/i915: Associate audio component with devres ALSA: hda: Make audio component support more generic ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI ALSA: hda/hdmi: Use single mutex unlock in error paths drm/radeon: Add audio component support drm/amdgpu: Add audio component support
The branch should be cleanly pullable onto the latest 4.18-rc.
I couldn't test amdgpu but the test with a radeon driver on an old laptop seemed working through a very quick test.
Please give it a try.
That is really wonderful work. I will check it on our AMD platform.
Thanks, it'll be great if you can check whether the current code works or not. I'd love to push the stuff for 4.19. Hopefully I'll start submitting the preparation patches in the next week.
Basically this also opens the door of the similar capability for nouveau, and I guess it's also trivial enough.
BTW, For display, AMD has moved to use DC to support new asics. so there also need a patch for amdgpu in DC code.
Could you give a more hint? I'll try adapt the code if such a change is already in upstream tree.
The new code is in drivers/gpu/drm/amd/display.
In particular, I imagine all you need should be in display/amdgpu_dm, although there's chance you might have to touch display/dc/dce/dce_audio.c if you have to do anything with the unsolicited event.
I see you're using the GPL license, rather than MIT in amdgpu_audio.c. Since the code in display/dc is shared with other OSes and internal test frameworks it has to be MIT. Not entirely sure about display/amdgpu_dm, but if GPL is fine in amd/amdgpu it's probably fine there as well.
Harry
Alex _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, 16 Jul 2018 17:10:43 +0200, Harry Wentland wrote:
On 2018-07-15 10:36 AM, Alex Deucher wrote:
On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai tiwai@suse.de wrote:
On Sat, 14 Jul 2018 14:03:26 +0200, jimqu wrote:
在 2018/7/13 23:07, Takashi Iwai 写道:
On Wed, 11 Jul 2018 13:12:01 +0200, Takashi Iwai wrote:
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.
Since we had a nice "hack week" in this week at SUSE, I spent some time to write some patches for the support of the direct hotplug notification / ELD query between HD-audio and radeon/amdgpu. It re-utilizes the audio component framework for i915 but in a slightly more flexible way.
The patches are found in topic/hda-acomp branch of my sound.git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The following commits are relevant: drm/i915: Split audio component to a generic type ALSA: hda/i915: Allow delayed i915 audio component binding ALSA: hda/i915: Associate audio component with devres ALSA: hda: Make audio component support more generic ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI ALSA: hda/hdmi: Use single mutex unlock in error paths drm/radeon: Add audio component support drm/amdgpu: Add audio component support
The branch should be cleanly pullable onto the latest 4.18-rc.
I couldn't test amdgpu but the test with a radeon driver on an old laptop seemed working through a very quick test.
Please give it a try.
That is really wonderful work. I will check it on our AMD platform.
Thanks, it'll be great if you can check whether the current code works or not. I'd love to push the stuff for 4.19. Hopefully I'll start submitting the preparation patches in the next week.
Basically this also opens the door of the similar capability for nouveau, and I guess it's also trivial enough.
BTW, For display, AMD has moved to use DC to support new asics. so there also need a patch for amdgpu in DC code.
Could you give a more hint? I'll try adapt the code if such a change is already in upstream tree.
The new code is in drivers/gpu/drm/amd/display.
In particular, I imagine all you need should be in display/amdgpu_dm, although there's chance you might have to touch display/dc/dce/dce_audio.c if you have to do anything with the unsolicited event.
Thanks, I'm currently struggling to read down the whole complex DC code tree, and it's a very helpful hint.
How is the audio enable/disable call associated with the pipe index? IOW, if I add a hook to call a notifier callback to pass the pipe index that is enabled/disabled, how can it be deduced?
Similarly, when DC driver gets the query about the ELD on the given pipe, where can I convert it to which object?
DC is quite another beast, so I still haven't figured out the structures yet...
I see you're using the GPL license, rather than MIT in amdgpu_audio.c. Since the code in display/dc is shared with other OSes and internal test frameworks it has to be MIT. Not entirely sure about display/amdgpu_dm, but if GPL is fine in amd/amdgpu it's probably fine there as well.
Oh I just didn't know that amdgpu code was with MIT. Indeed the driver module is provided via "GPL and additional rights".
I'm fine to change the license to follow other code bits there. What exactly SPDX tag should be put there?
thanks,
Takashi
On Mon, Jul 16, 2018 at 11:25 AM, Takashi Iwai tiwai@suse.de wrote:
On Mon, 16 Jul 2018 17:10:43 +0200, Harry Wentland wrote:
On 2018-07-15 10:36 AM, Alex Deucher wrote:
On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai tiwai@suse.de wrote:
On Sat, 14 Jul 2018 14:03:26 +0200, jimqu wrote:
在 2018/7/13 23:07, Takashi Iwai 写道:
On Wed, 11 Jul 2018 13:12:01 +0200, Takashi Iwai wrote: > 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. Since we had a nice "hack week" in this week at SUSE, I spent some time to write some patches for the support of the direct hotplug notification / ELD query between HD-audio and radeon/amdgpu. It re-utilizes the audio component framework for i915 but in a slightly more flexible way.
The patches are found in topic/hda-acomp branch of my sound.git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The following commits are relevant: drm/i915: Split audio component to a generic type ALSA: hda/i915: Allow delayed i915 audio component binding ALSA: hda/i915: Associate audio component with devres ALSA: hda: Make audio component support more generic ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI ALSA: hda/hdmi: Use single mutex unlock in error paths drm/radeon: Add audio component support drm/amdgpu: Add audio component support
The branch should be cleanly pullable onto the latest 4.18-rc.
I couldn't test amdgpu but the test with a radeon driver on an old laptop seemed working through a very quick test.
Please give it a try.
That is really wonderful work. I will check it on our AMD platform.
Thanks, it'll be great if you can check whether the current code works or not. I'd love to push the stuff for 4.19. Hopefully I'll start submitting the preparation patches in the next week.
Basically this also opens the door of the similar capability for nouveau, and I guess it's also trivial enough.
BTW, For display, AMD has moved to use DC to support new asics. so there also need a patch for amdgpu in DC code.
Could you give a more hint? I'll try adapt the code if such a change is already in upstream tree.
The new code is in drivers/gpu/drm/amd/display.
In particular, I imagine all you need should be in display/amdgpu_dm, although there's chance you might have to touch display/dc/dce/dce_audio.c if you have to do anything with the unsolicited event.
Thanks, I'm currently struggling to read down the whole complex DC code tree, and it's a very helpful hint.
How is the audio enable/disable call associated with the pipe index? IOW, if I add a hook to call a notifier callback to pass the pipe index that is enabled/disabled, how can it be deduced?
Similarly, when DC driver gets the query about the ELD on the given pipe, where can I convert it to which object?
DC is quite another beast, so I still haven't figured out the structures yet...
I see you're using the GPL license, rather than MIT in amdgpu_audio.c. Since the code in display/dc is shared with other OSes and internal test frameworks it has to be MIT. Not entirely sure about display/amdgpu_dm, but if GPL is fine in amd/amdgpu it's probably fine there as well.
Oh I just didn't know that amdgpu code was with MIT. Indeed the driver module is provided via "GPL and additional rights".
I'm fine to change the license to follow other code bits there. What exactly SPDX tag should be put there?
Preferably: SPDX-License-Identifier: MIT or I suppose dual licensing (MIT or GPL 2.0) is ok too.
Alex
thanks,
Takashi
participants (4)
-
Alex Deucher -
Harry Wentland -
jimqu -
Takashi Iwai