Re: WAs in init_clock_gating?

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Mon, 7 Jul 2014 22:50:08 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, Jul 01, 2014 at 04:51:07PM +0000, Mateo Lozano, Oscar wrote:
> > Is there any reason why the WAs are applied in *_init_clock_gating? We
> > are finding that some of them are lost during reset, and also the
> > default context ends up with wrong values because the render context is
> > restored & saved before we get to gen8_init_clok_gating (at least with
> > Execlists, I´m not sure this happens with MI_SET_CONTEXT because the
> > context won´t be saved until the next switch).
> 
> It's a historical accident since _very_ old hw only needed a bit of
> frobbing of the display clock gating bits.
> 
> > I believe this have been brought to the mailing list a couple of times, like:
> > 
> > 	drm/i916: Init chv workarounds at render ring init
> > 	My bsw is an unhappy camper if we delay the workaround init until init_clock_gating(). Move a bunch of it to the render ring init.
> > 
> > 	FIXME: need to do this for all platforms since some of the registers
> >        	also get clobbered at reset. Just need to figure out which
> >       	 registers those actually are. This patch is based on a
> >        	slightly educated guess, but verifying on actual hw would
> >        	be a good idea. Also should maybe move the init_clock_gating
> >        	earlier too since we set up a bunch of clock gating stuff
> >        	there that might be important for a properly working GT.
> > 
> > 	Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > And also:
> > 
> > http://lists.freedesktop.org/archives/intel-gfx/2013-November/036482.html
> 
> My concerns still apply. We need to move all work-arounds to the right
> places (a bunch of them also might need to get moved into the runtime pm
> code ...), and then we also need some test to make sure this all works.
> 
> Since maintaining the full list of all w/a bits is currently out of the
> question (our code is too unstructured for this) I think we should have a
> per-platform list of w/a relevant registers + maybe bitmasks with stuff to
> ignore (e.g. the ring registers where the ring base addr might differ).

I don't think it's unreasonable to use a macro that checks a global
list for whether to apply a given WA.  They'll be scattered all over,
but at least it'll be easy to see:
  1) whether we implement a given workaround
and
  2) which platforms & steppings it applies to based on the table.

-- 
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx