This series looks good to me.
Just to let people know; I have some related changes on my
wip/rib/oa-next branch where I'm defining the subslice mask
differently to this (to reflect the slice mask too)...
In my case for exposing OA unit counters we have a number of metric
sets which have multiple associated MUX configurations and the
appropriate config sometimes depends on which specific subslices are
enabled.
The way this is managed a.t.m is that the XML files maintained by VPG,
that describe the configs, have an RPN 'Availability' expression
associated with each MUX config which is parsed to auto generate
corresponding if() statements to test when trying to select a
particular metric set requested by userspace. These expressions can
refer to a $SubsliceMask variable and in this case the mask is
expected to reflect the slice and subslice mask in one mask, e.g. a
3bit mask per slice packed together on BDW.
Given this, the simplest way for me to work with these availability
checks has been to make the subslice_mask follow the same definition,
something like:
> ss_mask = ss_disable ^ ((1 << ss_max) - 1);
> for (s = 0; s < s_max; s++) {
> if (s_enable & (0x1 << s))
> info->subslice_mask |= ss_mask << (ss_max * s);
> }
Ref: https://github.com/rib/linux/blob/wip/rib/oa-next/drivers/gpu/drm/i915/i915_dma.c#L622
(sorry the patches on my wip/rib/oa-next branch related to this
aren't currently well contained)
For reference my wip/rib/oa-next branch is also exposing the subslice
mask to userspace via GETPARM, as described above, mainly because the
same kinds of RPN expressions are also tested in userspace to
determine how to interpret some metric sets.
Not that the above should affect landing this series; it just seems
relevant to mention.
Reviewed-by: Robert Bragg <robert@xxxxxxxxxxxxx>
Regards,
- Robert
On Wed, Oct 21, 2015 at 4:40 PM, Imre Deak <imre.deak@xxxxxxxxx> wrote:
> The per-slice/subslice INSTDONE patchset from Ben [1] will need the
> subslice/slice masks in addition to the corresponding counts that we
> maintain atm. So I added support to store the masks instead of the
> counts and calculate the counts whenever we need them based on the
> masks. While at it I also noticed that the SSEU readout code could be
> simplified by reusing the data structure storing the SSEU properties.
>
> Tested on BXT/SKL.
>
> [1]
> http://lists.freedesktop.org/archives/intel-gfx/2015-September/077050.html
>
> Imre Deak (7):
> drm/i915: sseu: move sseu_dev_status to i915_drv.h
> drm/i915: sseu: use sseu_dev_info in device info
> drm/i915: sseu: simplify debugfs status/info printing
> drm/i915: sseu: convert slice count field to mask
> drm/i915: sseu: convert subslice count fields to subslice mask
> drm/i915: sseu: add debug printf for slice/subslice masks
> drm/i915/bdw: sseu: fix sseu status parsing
>
> drivers/gpu/drm/i915/i915_debugfs.c | 134 +++++++++++++++-----------------
> drivers/gpu/drm/i915/i915_dma.c | 115 +++++++++++++--------------
> drivers/gpu/drm/i915/i915_drv.h | 28 ++++---
> drivers/gpu/drm/i915/intel_lrc.c | 14 ++--
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +-
> 6 files changed, 150 insertions(+), 147 deletions(-)
>
> --
> 2.1.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
