[Intel-gfx] [RFC PATCH 04/20] drm/i915: Transform context WAs into static tables

[Joonas Lahtinen]

On Fri, 2017-11-03 at 11:09 -0700, Oscar Mateo wrote:
> This is for WAs that need to touch registers that get saved/restored
> together with the logical context. The idea is that WAs are "pretty"
> static, so a table is more declarative than a programmatic approah.
> Note however that some amount is caching is needed for those things
> that are dynamic (e.g. things that need some calculation, or have
> a criteria different than the more obvious GEN + stepping).
> 
> Also, this makes very explicit which WAs live in the context.
> 
> Suggested-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> Signed-off-by: Oscar Mateo <oscar.mateo at intel.com>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>

<SNIP>

> +struct i915_wa_reg;
> +
> +typedef bool (* wa_pre_hook_func)(struct drm_i915_private *dev_priv,
> +				  struct i915_wa_reg *wa);
> +typedef void (* wa_post_hook_func)(struct drm_i915_private *dev_priv,
> +				   struct i915_wa_reg *wa);

To avoid carrying any variables over, how about just apply() hook?
Also, you don't have to have "_hook" going there, it's tak

>  struct i915_wa_reg {
> +	const char *name;

We may want some Kconfig option for skipping these.

> +	enum wa_type {
> +		I915_WA_TYPE_CONTEXT = 0,
> +		I915_WA_TYPE_GT,
> +		I915_WA_TYPE_DISPLAY,
> +		I915_WA_TYPE_WHITELIST
> +	} type;
> +

Any specific reason not to have the gen here too? Then you can have one
big table, instead of tables of tables. Then the numeric code of a WA
(position in that table) would be equally identifying it compared to
the WA name (which is nice to have information, so config time opt-in).

> +	u8 since;
> +	u8 until;

Most seem to have ALL_REVS, so this could be after the coarse-grained
gen-check in the apply function.

> +
>  	i915_reg_t addr;
> -	u32 value;
> -	/* bitmask representing WA bits */
>  	u32 mask;
> +	u32 value;
> +	bool is_masked_reg;

I'd hide this detail into the apply function.

> +
> +	wa_pre_hook_func pre_hook;
> +	wa_post_hook_func post_hook;

	bool (*apply)(const struct i915_wa *wa,
		      struct drm_i915_private *dev_priv);

> +	u32 hook_data;
> +	bool applied;

The big point would be to make this into const, so "applied" would
defeat that.

<SNIP>

> +#define MASK(mask, value)	((mask) << 16 | (value))
> +#define MASK_ENABLE(x)		(MASK((x), (x)))
> +#define MASK_DISABLE(x)		(MASK((x), 0))
>  
> -#define WA_REG(addr, mask, val) do { \
> -		const int r = wa_add(dev_priv, (addr), (mask), (val)); \
> -		if (r) \
> -			return r; \
> -	} while (0)
> +#define SET_BIT_MASKED(m) 		\
> +	.mask = (m),			\
> +	.value = MASK_ENABLE(m),	\
> +	.is_masked_reg = true
>  
> -#define WA_SET_BIT_MASKED(addr, mask) \
> -	WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
> +#define CLEAR_BIT_MASKED( m) 		\
> +	.mask = (m),			\
> +	.value = MASK_DISABLE(m),	\
> +	.is_masked_reg = true
>  
> -#define WA_CLR_BIT_MASKED(addr, mask) \
> -	WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
> +#define SET_FIELD_MASKED(m, v) 		\
> +	.mask = (m),			\
> +	.value = MASK(m, v),		\
> +	.is_masked_reg = true

Lets try to have the struct i915_wa as small as possible, so this could
be calculated in the apply function.

So, avoiding the macros this would indeed become rather declarative;

{
	WA_NAME("WaDisableAsyncFlipPerfMode")
	.gen = ...,
	.reg = MI_MODE,
	.value = ASYNC_FLIP_PERF_DISABLE,
	.apply = set_bit_masked,
},

Or, we could also have;

static const struct i915_wa WaDisableAsyncFlipPerfMode = {
	.gen = ...,
	.reg = MI_MODE,
	.value = ASYNC_FLIP_PERF_DISABLE,
	.apply = set_bit_masked,
};

And then one array of those.

	WA(WaDisableAsyncFlipPerfMode),

Then you could at compile time decide if you stringify and store the
name. But that'd be more const data than necessary (pointers to
structs, instead of an array of structs).

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation