Sorry, correct the typo. 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. Therefore, upper software could not get HDMI ELD info, it can not select an 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. Thanks JimQu ________________________________________ 发件人: Qu, Jim 发送时间: 2018年7月10日 15:44:42 收件人: Takashi Iwai 抄送: Daniel Vetter; Alex Deucher; alsa-devel@xxxxxxxxxxxxxxxx; amd-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; Deucher, Alexander 主题: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id 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: 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. 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. Thanks JimQu ________________________________________ 发件人: Takashi Iwai <tiwai@xxxxxxx> 发送时间: 2018年7月10日 1:09 收件人: Qu, Jim 抄送: Daniel Vetter; Alex Deucher; alsa-devel@xxxxxxxxxxxxxxxx; amd-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; 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@xxxxxxx> > 发送时间: 2018年7月9日 23:58 > 收件人: Daniel Vetter <daniel@xxxxxxxx> > 抄送: Alex Deucher <alexdeucher@xxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx; amd-gfx@xxxxxxxxxxxxxxxxxxxxx; Qu, Jim <Jim.Qu@xxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx; Deucher, Alexander <Alexander.Deucher@xxxxxxx> > 主题: 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@xxxxxxx> 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@xxxxxxxxx> > > > > > 发送时间: 2018年7月9日 17:27 > > > > > 收件人: Qu, Jim > > > > > 抄送: alsa-devel@xxxxxxxxxxxxxxxx; > > > > > dri-devel@xxxxxxxxxxxxxxxxxxxxx; Deucher, Alexander; > > > > > amd-gfx@xxxxxxxxxxxxxxxxxxxxx > > > > > 主题: 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@xxxxxxxxxxxxxxxxxxxxx > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > _______________________________________________ > > > > Alsa-devel mailing list > > > > Alsa-devel@xxxxxxxxxxxxxxxx > > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > _______________________________________________ > > > dri-devel mailing list > > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
