[alsa-devel] HD-audio runtime PM

[Takashi Iwai]

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).


Takashi