On 11/03/2017 11:09 AM, Oscar Mateo wrote:
New approach using static tables instead of a programmatic one. This is RFC for
two reasons: firstly because I still need to re-review everything myself (I
wanted to get it out ther asap), and secondly because I'm not 100% convinced
by this approach.

While writing the patches, the approach seemed forceful: I couldn't use const
structs

Or, in other words, this whole thing I just sent is broken and not better that using global variables. I'll try to cache things somewhere else and resend, sorry for even sending this stupid respin.

because there are a good deal of things that need calculations (e.g.
skl_tune_iz_hashing), or need to pass data between the pre- and the post- hooks
(e.g. disable/enable_dop_clock_gating), or cannot be done in tables (e.g. assert
the values make sense for those registers that are masked), or need to extract
fields from structs (whitelist registers). I also cannot predict how 
future-proof
this thing is.

Furthermote, this is going to be much more difficult to review than the previous
approach, if only because the delta is much bigger. If this approach is 
preferred,
I stronly suggest we do it in top of the previous one (that way we have the 
debugfs
output much earlier in the game to make sure we are missing anything).

 From previous cover letters:

Currently, deciding how/where to apply new workarounds is challenging. Often,
workarounds end up applied incorrectly and get lost under certain circumstances
(e.g. a context switch or a GPU reset). This is a proposal to attempt to
eliminate some of this pain, by clarifying the current classification of
workarounds (context saved/restored, global registers, whitelisting, BB),
putting them together on the same file, and improving the existing validation
infrastructure (debugfs/i-g-t).

Oscar Mateo (20):
   drm/i915: Remove Gen9 WAs with no effect
   drm/i915: Move a bunch of workaround-related code to its own file
   drm/i915: Split out functions for different kinds of workarounds
   drm/i915: Transform context WAs into static tables
   drm/i915: Transform GT WAs into static tables
   drm/i915: Transform Whitelist WAs into static tables
   drm/i915: Create a new category of display WAs
   drm/i915: Print all workaround types correctly in debugfs
   drm/i915: Do not store the total counts of WAs
   drm/i915: Move WA BB stuff to the workarounds file as well
   drm/i915/cnl: Move GT and Display workarounds from init_clock_gating
   drm/i915/gen9: Move GT and Display workarounds from init_clock_gating
   drm/i915/cfl: Move GT and Display workarounds from init_clock_gating
   drm/i915/glk: Move GT and Display workarounds from init_clock_gating
   drm/i915/kbl: Move GT and Display workarounds from init_clock_gating
   drm/i915/bxt: Move GT and Display workarounds from init_clock_gating
   drm/i915/skl: Move GT and Display workarounds from init_clock_gating
   drm/i915/chv: Move GT and Display workarounds from init_clock_gating
   drm/i915/bdw: Move GT and Display workarounds from init_clock_gating
   drm/i915: Document the i915_workarounds file

  drivers/gpu/drm/i915/Makefile            |    3 +-
  drivers/gpu/drm/i915/i915_debugfs.c      |  117 ++-
  drivers/gpu/drm/i915/i915_drv.h          |   40 +-
  drivers/gpu/drm/i915/i915_gem.c          |    3 +
  drivers/gpu/drm/i915/i915_gem_context.c  |    1 +
  drivers/gpu/drm/i915/i915_reg.h          |    3 -
  drivers/gpu/drm/i915/intel_engine_cs.c   |  682 ------------
  drivers/gpu/drm/i915/intel_lrc.c         |  264 +----
  drivers/gpu/drm/i915/intel_pm.c          |  312 +-----
  drivers/gpu/drm/i915/intel_ringbuffer.c  |    5 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h  |    3 -
  drivers/gpu/drm/i915/intel_workarounds.c | 1663 ++++++++++++++++++++++++++++++
  drivers/gpu/drm/i915/intel_workarounds.h |   51 +
  13 files changed, 1867 insertions(+), 1280 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_workarounds.c
  create mode 100644 drivers/gpu/drm/i915/intel_workarounds.h


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

Reply via email to