From: Liam Girdwood <liam.r.girdwood@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
"Lin, Mengdong" <mengdong.lin@intel.com>
Cc: "Yang, Libin" <libin.yang@intel.com>,
"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>,
Takashi Iwai <tiwai@suse.de>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
"Kaskinen, Tanu" <tanu.kaskinen@intel.com>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm/i915: Enable runtime pm
Date: Tue, 16 Jun 2015 11:42:12 +0100 [thread overview]
Message-ID: <1434451332.2489.21.camel@loki> (raw)
In-Reply-To: <CAKMK7uGb0GFz6SDJv5ErX_=xXNLw1UnZCr6SF4FB2HPecC-wHQ@mail.gmail.com>
On Tue, 2015-06-16 at 10:34 +0200, Daniel Vetter wrote:
> Can I get an ack on this please? The audio folks already move ahead
>
> http://permalink.gmane.org/gmane.linux.alsa.devel/139831
>
> Would be embarassing if we are late to the party we organized ourselves ...
> -Daniel
>
>
Mengdong, Libin - I assume someone has tested this ? could someone Ack.
Thanks
Liam
> On Fri, May 8, 2015 at 8:51 PM, Daniel Vetter <daniel.vetter@ffwll.ch> 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);
> > }
> > --
> > 2.1.0
> >
>
>
>
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-06-16 10:42 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
2015-06-16 8:34 ` Daniel Vetter
2015-06-16 10:42 ` Liam Girdwood [this message]
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=1434451332.2489.21.camel@loki \
--to=liam.r.girdwood@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=libin.yang@intel.com \
--cc=mengdong.lin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox