From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Khlebnikov Subject: Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume Date: Tue, 16 Jul 2013 11:34:25 +0400 Message-ID: References: <20130714163009.22374.22100.stgit@zurg> <51E2E65D.5050803@openvz.org> <20130716063101.GK5784@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1607737018==" Return-path: In-Reply-To: <20130716063101.GK5784@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Konstantin Khlebnikov , David Airlie , intel-gfx , Linux Kernel Mailing List , dri-devel , Chris Wilson Cc: Daniel Vetter List-Id: dri-devel@lists.freedesktop.org --===============1607737018== Content-Type: multipart/alternative; boundary=001a11c21c96a1d38104e19c01ee --001a11c21c96a1d38104e19c01ee Content-Type: text/plain; charset=UTF-8 On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter wrote: > On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote: > > 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: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > > >>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? > > > > 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. > > Can be fixed with a flush_delayed_work. And since that has the same > requirements wrt locking to prevent deadlocks as cancel_work_sync it would > be a drop-in replacement. Can I volunteer you to look into testing that > out a bit? Otherwise I could volunteer someone from our team. > > In any case I think we should apply this trick to all platforms where > we've added the MBCTL write (i.e. snb, ivb, hsw & vlv) since rps/rc6 works > _very_ similar on all of those. > I've tested that patch and it really works for me. If you want change something for other hardware or extend range where forcewake is held prease do it in a separate patch. This will be good for bisecting new bugs in the future. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > --001a11c21c96a1d38104e19c01ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter <daniel@ff= wll.ch> wrote:
On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khle= bnikov wrote:
> Daniel Vetter wrote:
> >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> ><khlebnikov@openvz.org= > =C2=A0wrote:
> >>This patch fixes regression in power consumtion of sandy bridg= e gpu, which
> >>exists since v3.6 Sometimes after resuming from s2ram gpu star= ts thinking that
> >>it's extremely busy. After that it never reaches rc6 state= .
> >>
> >>Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c= 0bc6e0
> >>("drm/i915: load boot context at driver init time").= Without documentation
> >>it's not clear what is happening here, probably this break= s internal state of
> >>hardware ring buffers and confuses RPS engine. Fortunately kee= ping forcewake
> >>during whole initialization sequence in gen6_init_clock_gating= () fixes this bug.
> >>
> >>References: https://bugs.freedesktop.org/show_bug.cgi?= id=3D54089
> >>Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
> >
> >We already hold an forcewake reference while setting up the rps st= uff,
> >should we maybe hold the forcewake for the entire duration, i.e. g= rab
> >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 mig= ht be canceled
> if intel_disable_gt_powersave() happens before its completion.

Can be fixed with a flush_delayed_work. And since that has the same requirements wrt locking to prevent deadlocks as cancel_work_sync it would<= br> be a drop-in replacement. Can I volunteer you to look into testing that
out a bit? Otherwise I could volunteer someone from our team.

In any case I think we should apply this trick to all platforms where
we've added the MBCTL write (i.e. snb, ivb, hsw & vlv) since rps/rc= 6 works
_very_ similar on all of those.

I'v= e tested that patch and it really works for me. If you want change somethin= g for other hardware or
extend range where forcewake is held prea= se do it in a separate patch.
This will be good for bisecting new bugs in the future.
=C2= =A0

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - h= ttp://blog.ffwll.ch

--001a11c21c96a1d38104e19c01ee-- --===============1607737018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1607737018==--