[alsa-devel] Enable display power well management in HD-A driver on Baytrail platform (Valleyview SOC)
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.
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
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.
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:
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.
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
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:
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.
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
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, October 25, 2013 7:42 PM
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.
Yes, the i915 power up/down is just for the HDMI codec. The audio controller and on-board codec are not affected. So we'll try the 1st option and see if it can work as we expected.
Thanks for your advice! Mengdong
participants (2)
-
Lin, Mengdong
-
Takashi Iwai