[Intel-gfx] [RFC PATCH v5 00/20] Refactor HW workaround code
Oscar Mateo
oscar.mateo at intel.com
Fri Nov 3 21:51:33 UTC 2017
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
>
More information about the Intel-gfx
mailing list