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  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]
Date:	Sun, 14 Jul 2013 22:48:24 +0100
From:	Chris Wilson <>
To:	Daniel Vetter <>
Cc:	Konstantin Khlebnikov <>,
	David Airlie <>,
	intel-gfx <>,
	Linux Kernel Mailing List <>,
	dri-devel <>
Subject: Re: [PATCH] drm/i915: fix long-standing SNB regression in power
 consumption after resume

On Sun, Jul 14, 2013 at 06:52:39PM +0200, Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> <> 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:
> > Signed-off-by: Konstantin Khlebnikov <>
> 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?
> 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.

It is not clear why the forcewake works, but is easy to imagine one of
the operations in that sequence requires the GPU to be awake at the time
of programming for it to succeed. MBCTL:EnableBootFetch does seem the most
suspicious from its wording in the bspec. I guess all instances of
poking this bit should be protected similary (snb, ivb, vlv, hsw).

Based on that reasoning and that waking the GPU up here has no negative
consequences, and so long as all paths are fixed, I am happy to give this
an Acked-by: Chris Wilson <>

Also, we need to reapply the w/a after a Function Level Reset, in other
words we do need to repeat the init_clock_gating after

Chris Wilson, Intel Open Source Technology Centre
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists