WAs in init_clock_gating?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

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@xxxxxxxxxxxxxxx>

And also:

http://lists.freedesktop.org/archives/intel-gfx/2013-November/036482.html

-- Oscar
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux