[Intel-gfx] [PATCH 10/12] drm/i915/gt: Refactor l3cc/mocs availability

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2020-02-18 21:24:47)
> 
> 
> On 2/18/20 8:21 AM, Chris Wilson wrote:
> > On dgfx, we only use l3cc and not mocs, but we share the table of
> > register definitions with Tigerlake (which includes the mocs). This

-share the table of register definitions
+share the table containing both register definitions
 
> Just a small correction here: the problem is not that the Tigerlake 
> definitions will be shared (which is not necessarily going to happen), 
> but that our table entry definition contains both l3cc and mocs and 
> there is currently no way to know if only one of the 2 is valid. We 
> could split the table, but IMO that'd be overkill and it'll make things 
> messier for integrated platforms that have both, so I prefer the 
> approach in this patch.
> 
> > confuses our selftest that verifies that the registers do contain the
> > values in our tables after various events (idling, reset, activity etc).
> > 
> > When constructing the table of register definitions, also include the
> > flags for which registers are valid so that information is computed
> > centrally and available to all callers.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Brian Welty <brian.welty at intel.com>
> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> 
> Was confused for a moment by the uninitialized table passed to 
> read_mocs_table(), but we're ok because we memset it to 0 and therefore 

I did put the memset there to try and reassure :)

> table->n_entries is zero. Maybe worth adding a check to avoid calling 
> ring_begin() and ring_advance() in read_regs() that scenario?

ring_advance is just a debug aide; ring_begin becomes a no-op, after a
few twists and turns. (At worst it is a intel_ring_wrap.)

I liked the simple look of not having to special case 0.
-Chris