All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume
Date: Sun, 14 Jul 2013 21:56:45 +0400	[thread overview]
Message-ID: <51E2E65D.5050803@openvz.org> (raw)
In-Reply-To: <CAKMK7uEtReZxvzJj9LsSXEJEBNiK492CCONdsF5VFK2cA3u0FA@mail.gmail.com>

Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> <khlebnikov@openvz.org>  wrote:
>> This patch fixes regression in power consumtion of sandy bridge gpu, which
>> exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
>> it's extremely busy. After that it never reaches rc6 state.
>>
>> Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
>> ("drm/i915: load boot context at driver init time"). Without documentation
>> it's not clear what is happening here, probably this breaks internal state of
>> hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake
>> during whole initialization sequence in gen6_init_clock_gating() fixes this bug.
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
>> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
>
> We already hold an forcewake reference while setting up the rps stuff,
> should we maybe hold the forcewake for the entire duration, i.e. grab
> it here in clock_gating and release it only in gen6/vlv_enable_rps?
> Can you please test that version, too?

This will be racy because rps stuff is done in separate work which might be canceled
if intel_disable_gt_powersave() happens before its completion.

>
> In any case the forcewake grabbing here in the clock gating function
> needs a big comment that otherwise setting the MCTL register might
> break rc6 entry.
> -Daniel
>
>> ---
>>   drivers/gpu/drm/i915/intel_pm.c |    4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>> index aa01128..839a43f 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev)
>>          int pipe;
>>          uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
>>
>> +       gen6_gt_force_wake_get(dev_priv);
>> +
>>          I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate);
>>
>>          I915_WRITE(ILK_DISPLAY_CHICKEN2,
>> @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev)
>>          cpt_init_clock_gating(dev);
>>
>>          gen6_check_mch_setup(dev);
>> +
>> +       gen6_gt_force_wake_put(dev_priv);
>>   }
>>
>>   static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv)
>>
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume
Date: Sun, 14 Jul 2013 21:56:45 +0400	[thread overview]
Message-ID: <51E2E65D.5050803@openvz.org> (raw)
In-Reply-To: <CAKMK7uEtReZxvzJj9LsSXEJEBNiK492CCONdsF5VFK2cA3u0FA@mail.gmail.com>

Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> <khlebnikov@openvz.org>  wrote:
>> This patch fixes regression in power consumtion of sandy bridge gpu, which
>> exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
>> it's extremely busy. After that it never reaches rc6 state.
>>
>> Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
>> ("drm/i915: load boot context at driver init time"). Without documentation
>> it's not clear what is happening here, probably this breaks internal state of
>> hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake
>> during whole initialization sequence in gen6_init_clock_gating() fixes this bug.
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
>> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
>
> We already hold an forcewake reference while setting up the rps stuff,
> should we maybe hold the forcewake for the entire duration, i.e. grab
> it here in clock_gating and release it only in gen6/vlv_enable_rps?
> Can you please test that version, too?

This will be racy because rps stuff is done in separate work which might be canceled
if intel_disable_gt_powersave() happens before its completion.

>
> In any case the forcewake grabbing here in the clock gating function
> needs a big comment that otherwise setting the MCTL register might
> break rc6 entry.
> -Daniel
>
>> ---
>>   drivers/gpu/drm/i915/intel_pm.c |    4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>> index aa01128..839a43f 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev)
>>          int pipe;
>>          uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
>>
>> +       gen6_gt_force_wake_get(dev_priv);
>> +
>>          I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate);
>>
>>          I915_WRITE(ILK_DISPLAY_CHICKEN2,
>> @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev)
>>          cpt_init_clock_gating(dev);
>>
>>          gen6_check_mch_setup(dev);
>> +
>> +       gen6_gt_force_wake_put(dev_priv);
>>   }
>>
>>   static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv)
>>
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch


  reply	other threads:[~2013-07-14 17:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-14 16:30 [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume Konstantin Khlebnikov
2013-07-14 16:52 ` Daniel Vetter
2013-07-14 16:52   ` Daniel Vetter
2013-07-14 17:56   ` Konstantin Khlebnikov [this message]
2013-07-14 17:56     ` Konstantin Khlebnikov
2013-07-16  6:31     ` Daniel Vetter
2013-07-16  7:34       ` Konstantin Khlebnikov
2013-07-16  7:44         ` Daniel Vetter
2013-07-16  8:31           ` Chris Wilson
2013-07-16 11:13             ` Daniel Vetter
2013-07-16 17:06         ` Jesse Barnes
2013-07-16 17:06           ` [Intel-gfx] " Jesse Barnes
2013-07-16 20:19           ` Jesse Barnes
2013-07-16 20:43             ` Daniel Vetter
2013-07-16 20:52               ` Jesse Barnes
2013-07-14 21:48   ` Chris Wilson
2013-07-14 21:48     ` Chris Wilson
2013-07-16  6:32 ` Daniel Vetter
2013-07-16 12:06   ` Daniel Vetter
2013-07-17  6:22 ` [PATCH v2] " Konstantin Khlebnikov
2013-07-17  6:44   ` Daniel Vetter
2013-07-17 14:47   ` Jesse Barnes
2013-07-17 14:47     ` Jesse Barnes

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=51E2E65D.5050803@openvz.org \
    --to=khlebnikov@openvz.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.