From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: "Yang, Libin" <libin.yang@intel.com>,
"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>,
Takashi Iwai <tiwai@suse.de>,
"Kaskinen, Tanu" <tanu.kaskinen@intel.com>,
Liam Girdwood <liam.r.girdwood@intel.com>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm/i915: Enable runtime pm
Date: Tue, 12 May 2015 10:40:24 -0700 [thread overview]
Message-ID: <55523B08.8040702@virtuousgeek.org> (raw)
In-Reply-To: <1431111069-11847-1-git-send-email-daniel.vetter@ffwll.ch>
On 05/08/2015 11:51 AM, Daniel Vetter wrote:
> Like with every other feature that's not enabled by default we break
> runtime pm support way too often by accident because the overall test
> coverage isn't great. And it's been almost 2 years since we enabled
> the power well code by default
>
> commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
> Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Date: Wed Jul 3 17:12:13 2013 -0300
>
> drm/i915: switch disable_power_well default value to 1
>
> It's really more than overdue for runtime pm itself to follow!
>
> Note that in practice this wont do a hole lot yet, since we're still
> gated on snd-hda-intel doing proper runtime pm. But I've discussed
> this with Liam and we agreed that this needs to be done. And the audio
> team is working to hold up their end of this bargain.
>
> And the justification for updating the autosuspend delay to 100ms:
> Quick measurment shows that we can do a full rpm cycle in about 5ms,
> which means the delay should still be really conservative from a power
> conservation pov. The only workload that would suffer from ping-pong
> is also only gpu/compute with all screens off. 100ms should cover any
> kind of latency with submitting follow-up batches.
>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: Liam Girdwood <liam.r.girdwood@intel.com>
> Cc: Yang, Libin <libin.yang@intel.com>
> Cc: Lin, Mengdong <mengdong.lin@intel.com>
> Cc: Li, Jocelyn <jocelyn.li@intel.com>
> Cc: Kaskinen, Tanu <tanu.kaskinen@intel.com>
> Cc: Zanoni, Paulo R <paulo.r.zanoni@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 317b9b43d1c1..36ecbe275dd9 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1919,9 +1919,10 @@ void intel_runtime_pm_enable(struct drm_i915_private *dev_priv)
> return;
> }
>
> - pm_runtime_set_autosuspend_delay(device, 10000); /* 10s */
> + pm_runtime_set_autosuspend_delay(device, 100);
> pm_runtime_mark_last_busy(device);
> pm_runtime_use_autosuspend(device);
> + pm_runtime_allow(device);
>
> pm_runtime_put_autosuspend(device);
> }
>
This also changes the timeout... it shouldn't break anything, but it
would be good to get some numbers from Eero's team on this. It might be
better to use a lower or higher number based on a typical desktop
workload by default (though I guess the user or distro can do their own
tuning and override the value too).
Jesse
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-05-12 17:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 18:51 [PATCH] drm/i915: Enable runtime pm Daniel Vetter
2015-05-09 14:59 ` shuang.he
2015-05-12 17:40 ` Jesse Barnes [this message]
2015-06-16 8:34 ` Daniel Vetter
2015-06-16 10:42 ` Liam Girdwood
2015-06-18 7:46 ` Yang, Libin
2015-06-16 12:23 ` Paulo Zanoni
2015-06-16 12:26 ` Paulo Zanoni
2015-06-16 18:40 ` Jesse Barnes
-- strict thread matches above, loose matches on Subject: below --
2017-11-07 16:18 Daniel Vetter
2017-11-07 16:45 ` Jani Nikula
2017-11-07 16:53 ` Daniel Vetter
2017-11-08 14:25 ` David Weinehall
2017-11-16 18:24 ` David Weinehall
2017-11-16 20:45 ` Paulo Zanoni
2017-11-16 21:11 ` Chris Wilson
2017-11-17 8:39 ` David Weinehall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55523B08.8040702@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=liam.r.girdwood@intel.com \
--cc=libin.yang@intel.com \
--cc=paulo.r.zanoni@intel.com \
--cc=tanu.kaskinen@intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.