[alsa-devel] Enable display power well management in HD-A driver on Baytrail platform (Valleyview SOC)

[Takashi Iwai]

At Fri, 25 Oct 2013 13:03:50 +0200,
Takashi Iwai wrote:
> 
> At Fri, 25 Oct 2013 09:20:02 +0000,
> Lin, Mengdong wrote:
> > 
> > Hi Takashi,
> > 
> > We want to enable display power well management on Batrail platform (Valleyview SOC), similar to what we did on Haswell.
> > Would you please check if our ideas are ok and give some advice?
> > 
> > For Valleyview/VLV the display controller has a power well island. When display is off, the display island can be power gated.
> > Unlike Haswell, the VLV HD-A controller is not in the display power well. The controller is in south bridge and shared by multiple codecs, same as the predecessors of Haswell.
> 
> But the power is still controlled based on the usage of HD-audio
> controller, not per codec, isn't it?  If so, we can keep using the
> runtime PM implementation.

Reading again your mail, it sounds like we need the i915 power up/down
*just for HDMI codec*, not for onboard audio, while both of them are
connected over the same HD-audio bus (i.e. controller).  If it's the
case, an easiest way is to put i915_request_power_well*() at
set_power_state callback as you pointed.

I don't like an idea to add pre_resume and post_suspend opts again.


Takashi

> 
> Or what am I missing?
> 
> 
> Takashi
> 
> > To assure audio is not disturbed by power well off, the Gfx i915 driver will provide the same API as Haswell: i915_request_power_well & i915_release_power_well
> > So audio driver can indicate whether audio codec needs the power well.
> > 
> > In HD-A driver, the display codec can suspend to D3 when there this no active streaming or ioctls which will actually trigger transactions to the display codec on HD-A bus.
> > So our basic idea is to request power before codec resumes to D0 and release power after codec suspends to D3.
> > And there can be two options for this:
> > 
> > 1.       Overwrite the 'set_power_state' ops for the VLV display codec, and request/release Gfx power well there via the i915 API in this ops.
> > 
> > And future VLV specific fixes may also go to this ops.
> > 
> > 2.       Add two new codec ops like 'pre_resume/post_suspend', and request/release Gfx power well here.
> > Which way do you think is better? Personally I don't want to add new ops and prefer 1st option, and VLV-like processors can use the same ops.
> > And there is an open question:
> > Can we assume that middleware (e.g. pulseaudio or audio flinger) will close the PCM device if there is no need to play audio for power saving?
> > Is this a usual way for middleware to work with ALSA?
> > Now in HD-A driver, once the PCM device is open, the codec will resume to D0. And so the codec will request display power well.
> > If middleware opens PCM device but doesn't play, there will be power waste. We want to avoid this.
> > 
> > Thanks
> > Mengdong
> >