[alsa-devel] HD-audio runtime PM

Takashi Iwai tiwai at suse.de
Tue Dec 10 15:25:54 CET 2013


At Tue, 10 Dec 2013 12:34:51 +0000,
Lin, Mengdong wrote:
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai at suse.de]
> > Sent: Tuesday, December 10, 2013 8:25 PM
> > To: Lin, Mengdong
> > Cc: Alsa-devel at alsa-project.org; Wang Xingchao; David Henningsson
> > Subject: Re: [alsa-devel] HD-audio runtime PM
> > 
> > At Tue, 10 Dec 2013 12:17:16 +0000,
> > Lin, Mengdong wrote:
> > >
> > > Hi Takashi,
> > >
> > > > -----Original Message-----
> > > > From: Lin, Mengdong
> > > > Sent: Monday, December 09, 2013 3:03 PM
> > >
> > > > > > > I've checked two Haswell-ULT platforms with sound git tree
> > > > > > > for-linus
> > > > > > branch, under Ubuntu:
> > > > > > > - ELD cannot refresh properly.
> > > > > > > - HDMI hot-plug cannot wake up the audio controller.
> > > >
> > > > I've tested the latest 3.13-rc2 based sound git tree, master branch:
> > > > - ELD can refresh properly on hot-plug event.
> > > >  I need to bisect to see where the ELD regression happened and how
> > > > it was fixed.
> > >
> > > ELD info cannot refresh on hot-plug event after the controller enters D3
> > on Haswell.
> > > Sorry, I forgot to enable runtime PM yesterday when checking ELD
> > refreshing.
> > >
> > > > - Headset insertion can wake up the legacy audio controller (PCI
> > > > device
> > > > 00:1b)
> > > >
> > > > - HDMI insertion still cannot wake up the display audio controller
> > > > (PCI device 00:03)  We'll double check with HW owner whether the
> > > > display audio controller really supports wake up on HDMI/DP
> > insertion.
> > > >  I remember when Xingchao enabled runtime PM on Haswell display
> > > > audio controller for display power well release,  there was an issue
> > > > that this controller does not support "wake up", but we finally
> > > > enable runtime PM on it and remove the request for "wake up".
> > >
> > > HW team clarified that HDMI/DP jack insertion cannot wake up the
> > controller from D3. So this is a HW restriction for Haswell, not a driver
> > regression.
> > >
> > > Now the problem on Haswell/Broadwell is:
> > > After the controller enters D3, Gfx driver can still detect HDMI/DP hot
> > plug event even if the display power well is disabled.
> > > Although Gfx driver set Presence Detect and ELD Valid , the audio
> > controller does not wake up and so audio driver has no idea about the
> > HDMI/DP hot-plug.
> > >
> > > Is it audio driver itself or the user space that need this ELD info?
> > > Maybe Gfx driver can directly report ELD info to user space.
> > 
> > If so, the graphics driver can wake up the audio driver as well -- this is yet
> > one more reason to create a direct communication channel between the
> > graphics and audio drivers :)
> 
> Need the audio driver provide an API for gfx driver?
> Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec),
> thus the controller and codec will wake up and audio driver can check ELD info.

Well, we can create a common object containing the ops registered by
both graphics and audio drivers, then communicate through it,
something like vga_switcheroo.


Takashi


More information about the Alsa-devel mailing list