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=57cb54e53bdd.
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.
1. ubuntu audio setting use pactl to query audio card/output sink. Attachment
is pactl output with audio runtime pm.
2. cat /proc/asound/card0/eld* can get nothing.
Without audio runtime pm:
1. pactl can get available audio output/sink
2. 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 <ti...@suse.de>
发送时间: 2018年7月10日 1:09
收件人: Qu, Jim
抄送: Daniel Vetter; Alex Deucher; alsa-de...@alsa-project.org;
amd-gfx@lists.freedesktop.org; dri-de...@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 <ti...@suse.de>
发送时间: 2018年7月9日 23:58
收件人: Daniel Vetter <dan...@ffwll.ch>
抄送: Alex Deucher <alexdeuc...@gmail.com>; alsa-de...@alsa-project.org;
amd-gfx@lists.freedesktop.org; Qu, Jim <jim...@amd.com>; dri-de...@lists.freedesktop.org;
Deucher, Alexander <alexander.deuc...@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...@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 <lu...@wunner.de>
发送时间: 2018年7月9日 17:27
收件人: Qu, Jim
抄送: alsa-de...@alsa-project.org;
dri-de...@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-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
dri-devel mailing list
dri-de...@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)>]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
