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@xxxxxxxxxxxxxxxxxx> > > Cc: Brian Welty <brian.welty@xxxxxxxxx> > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
