[alsa-devel] HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Wednesday, December 11, 2013 9:37 PM
> To: Lin, Mengdong
> Cc: Alsa-devel at alsa-project.org; Wang Xingchao; David Henningsson
> Subject: Re: [alsa-devel] HD-audio runtime PM
> 
> At Wed, 11 Dec 2013 05:37:44 +0000,
> Lin, Mengdong wrote:
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai at suse.de]
> > > Sent: Tuesday, December 10, 2013 10:26 PM
> >
> > > > > > 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.
> >
> > Hi Takashi,
> >
> > I'm sure how to use a common object like vga_switcheroo. Would you
> please share more info?
> >
> > I feel a wake up process may be like this:
> > - Gfx driver detects the hot-plug at first and notify audio driver by the
> communication channel.
> > - In the notification callback, the audio driver wakes up the audio
> controller to D0, but codec can still stay in D3.
> >  (Hope we can add a time out for controller here to avoid controller
> > back to D3 at once and lose the capability to check unsol event)
> > - Then when Gfx driver enables or disables audio, and the audio
> controller can receive the unsol event in D0.
> > - Audio driver check ELD in unsol event handler, this will make codec
> resume to D0.
> 
> If we have a direct communication with the graphics driver, the audio
> driver doesn't wait for the unsol event at all.  It can retrieve ELD and
> even better port info more directly; i.e. we can skip even the wake up of
> the HDMI controller and codec chips.  The notification and ELD updates
> can be done without the audio hardware, after all (actual ELD updates will
> be done at resume).
> 
Good idea. We can try this.
The HDMI controller and codec can sleep until user space really wants to use HDMI audio.

Regards
Mengdong