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