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 :-) -Daniel > > > thanks, > > Takashi > > > > > > Alex > > > > > > > > Thanks > > > JimQu > > > > > > ________________________________________ > > > 发件人: Lukas Wunner <lu...@wunner.de> > > > 发送时间: 2018年7月9日 17:27 > > > 收件人: Qu, Jim > > > 抄送: alsa-de...@alsa-project.org; dri-devel@lists.freedesktop.org; > > > Deucher, Alexander; amd-...@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-de...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
