[Intel-gfx] [PATCH v4 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

[Daniel Vetter]

On Tue, Jan 19, 2016 at 10:16:52AM +0000, Arun Siluvery wrote:
> On 19/01/2016 09:00, Daniel Vetter wrote:
> >On Thu, Jan 14, 2016 at 03:27:35PM +0000, Arun Siluvery wrote:
> >>Some of the HW registers are privileged and cannot be written to from
> >>non-privileged batch buffers coming from userspace unless they are added to
> >>the HW whitelist. This whitelist is maintained by HW and it is different from
> >>SW whitelist. Userspace need write access to them to implement preemption
> >>related WA.
> >>
> >>The reason for using this approach is, the register bits that control
> >>preemption granularity at the HW level are not context save/restored; so even
> >>if we set these bits always in kernel they are going to change once the
> >>context is switched out.  We can consider making them non-privileged by
> >>default but these registers also contain other chicken bits which should not
> >>be allowed to be modified.
> >>
> >>In the later revisions controlling bits are save/restored at context level but
> >>in the existing revisions these are exported via other debug registers and
> >>should be on the whitelist. This patch adds changes to provide HW with a list
> >>of registers to be whitelisted. HW checks this list during execution and
> >>provides access accordingly.
> >>
> >>HW imposes a limit on the number of registers on whitelist and it is
> >>per-engine.  At this point we are only enabling whitelist for RCS and we don't
> >>foresee any requirement for other engines.
> >>
> >>The registers to be whitelisted are added using generic workaround list
> >>mechanism, even these are only enablers for userspace workarounds. But by
> >>sharing this mechanism we get some test assets without additional cost (Mika).
> >>
> >>v2: rebase
> >>
> >>v3: parameterize RING_FORCE_TO_NONPRIV() as _MMIO() should be limited to
> >>i915_reg.h (Ville), drop inline for wa_ring_whitelist_reg (Mika).
> >>
> >>v4: improvements suggested by Chris Wilson.
> >>Clarify that this is HW whitelist and different from the one maintained in
> >>driver. This list is engine specific but it gets initialized along with other
> >>WA which is RCS specific thing, so make it clear that we are not doing any
> >>cross engine setup during initialization.
> >>Make HW whitelist count of each engine available in debugfs.
> >>
> >>Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>Reviewed-by: Mika Kuoppala <mika.kuoppala at intel.com>
> >>Cc: Mika Kuoppala <mika.kuoppala at intel.com>
> >>Cc: Chris Wilson <chris at chris-wilson.co.uk>
> >>Signed-off-by: Arun Siluvery <arun.siluvery at linux.intel.com>
> >
> >If you resend just single patches to a series you must --in-reply-to the
> >individual patch, not the cover letter. Otherwise patchwork won't pick it
> >up, which means we don't have CI results for this.
> 
> Hi Daniel,
> 
> Yes I did use --in-reply-to but probably not the correct message-id, will
> keep this in mind.
> 
> >
> >Since it's been a while probably best to just resend the entire pile.
> >
> >Also we seem to be missing r-b tags for the actual w/a changes.
> yes, actual w/a are yet to be reviewed, I can resend all of them once they
> are reviewed or you want me to send it now?

Either way is fine I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch