[Intel-gfx] [PATCH] drm/i915: Suspend resume timing optimization.
shobhit.kumar at linux.intel.com
Wed Dec 9 02:55:41 PST 2015
On 12/08/2015 02:22 AM, Paulo Zanoni wrote:
> 2015-12-07 18:28 GMT-02:00 <abhay.kumar at intel.com>:
>> From: Abhay Kumar <abhay.kumar at intel.com>
>> Moving 250ms from T12 timing to suspend path so that
>> resume path will be faster.
> Can you please elaborate more on your motivation for this patch? I'm a
> little confused. You're trying to make resume faster by making suspend
> slower? What are your main arguments for this?
Actually the display resume time is currently roughly around ~700ms for
eDP. The panel power sequence as per spec needs to be minimum 510ms . So
the t11_12 time is 600ms in our code. Question is how to optimize this.
What Abhay has tried is to move the wait for panel_power_cycle_delay in
the suspend path rather then in resume path when we check if panel has
power. Since this is jiffied based we end up waiting while going down
and by the time we come back jiffies have already expired, giving us
optimization in resume path. Will this work. Is it violates the spec in
any way ? Any other suggestions ?
>> Signed-off-by: Abhay Kumar <abhay.kumar at intel.com>
>> drivers/gpu/drm/i915/intel_ddi.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
>> index 7f618cf..2679c9e 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -2389,6 +2389,12 @@ static void intel_ddi_post_disable(struct intel_encoder *intel_encoder)
> Funcion intel_ddi_post_disable() doesn't only run on suspend
> situations, yet your commit message suggests you're optimizing
> suspend. Maybe this commit makes non-suspend modesets slower because
> now we need to wait the panel power cycle earlier? Have you measured
> the possible downsides?
Yes this is a problem. I again looked at the spec and found that t7 can
be 50, but VBT was default programming 200ms which is overriding our
driver initialized value. Correcting VBT gives back 150ms here. But yes
this will impact non-suspend modeset paths. Perhaps we should figure out
a way to avoid this and do only when relevant. A flag based check would
work ? I know it sounds hackish.
>> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>> + /* Give additional delay of 250 ms so that resume time will
>> + be faster and also meets T12 delay.
>> + */
> The comment says 250ms, but the code doesn't. Also, there's a missing
> '*' char in the comment.
>> + wait_remaining_ms_from_jiffies(intel_dp->last_power_cycle,
>> + (intel_dp->panel_power_cycle_delay/2));
> Why wait half the panel power cycle? Why did you choose exactly this value?
Actually I would want to wait out full panel power cycle delay. Brings
our resume time down to ~250ms. But ultimately if this is acceptable
solution, will still depend on suspend KPIs and we might have to
balance. But as far as I know suspend path has no strict KPI, so we
might get away with this.
>> if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
More information about the Intel-gfx