linux-kernel - Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51E2E65D.5050803@openvz.org>
Date:	Sun, 14 Jul 2013 21:56:45 +0400
From:	Konstantin Khlebnikov <khlebnikov@...nvz.org>
To:	Daniel Vetter <daniel.vetter@...ll.ch>
CC:	David Airlie <airlied@...ux.ie>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption
 after resume

Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> <khlebnikov@...nvz.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@...nvz.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/