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 :) 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 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
