[alsa-devel] HD-audio runtime PM

[Lin, Mengdong]

> -----Original Message-----
> From: Lin, Mengdong
> Sent: Wednesday, December 11, 2013 1:38 PM
> To: 'Takashi Iwai'
> Cc: Alsa-devel at alsa-project.org; Wang Xingchao; David Henningsson
> Subject: RE: [alsa-devel] HD-audio runtime PM
> 
> > -----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?

A typo here. I'm NOT sure how to use it.

> 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.
> 
> Regards
> Mengdong