From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers
Date: Wed, 13 Jan 2016 12:34:45 +0200 [thread overview]
Message-ID: <20160113103445.GD23290@intel.com> (raw)
In-Reply-To: <1452679593-3922-2-git-send-email-arun.siluvery@linux.intel.com>
On Wed, Jan 13, 2016 at 10:06:26AM +0000, Arun Siluvery wrote:
> Some of the HW registers are privileged and cannot be written to from a
> non-privileged batch buffers coming from userspace unless they are on 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
>
> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 ++++++++-
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 18 ++++++++++++++++++
> 3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 104bd18..660afe1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1653,11 +1653,18 @@ struct i915_wa_reg {
> u32 mask;
> };
>
> -#define I915_MAX_WA_REGS 16
> +/*
> + * RING_MAX_NONPRIV_SLOTS is per-engine but at this point we are only
> + * allowing it for RCS as we don't foresee any requirement of having
> + * a whitelist for other engines. When it is really required for
> + * other engines then the limit need to be increased.
> + */
> +#define I915_MAX_WA_REGS (16 + RING_MAX_NONPRIV_SLOTS)
>
> struct i915_workarounds {
> struct i915_wa_reg reg[I915_MAX_WA_REGS];
> u32 count;
> + u32 hw_whitelist_index[I915_NUM_RINGS];
> };
>
> struct i915_virtual_gpu {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0a98889..6668bb0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1635,6 +1635,9 @@ enum skl_disp_power_wells {
> #define RING_WAIT (1<<11) /* gen3+, PRBx_CTL */
> #define RING_WAIT_SEMAPHORE (1<<10) /* gen6+ */
>
> +#define RING_FORCE_TO_NONPRIV(base) ((base)+0x4D0)
> +#define RING_MAX_NONPRIV_SLOTS 12
> +
> #define GEN7_TLB_RD_ADDR _MMIO(0x4700)
>
> #if 0
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 4060acf..354da81 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -787,6 +787,23 @@ static int wa_add(struct drm_i915_private *dev_priv,
>
> #define WA_WRITE(addr, val) WA_REG(addr, 0xffffffff, val)
>
> +static inline int wa_ring_whitelist_reg(struct intel_engine_cs *ring,
> + i915_reg_t reg_addr)
> +{
> + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> + struct i915_workarounds *wa = &dev_priv->workarounds;
> + const uint32_t index = wa->hw_whitelist_index[ring->id];
> +
> + if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
> + return -EINVAL;
> +
> + WA_WRITE(_MMIO(RING_FORCE_TO_NONPRIV(ring->mmio_base) + index * 4),
> + reg_addr.reg);
No _MMIO junk outside of i915_reg.h please. Just parametrize the reg define
properly.
> + wa->hw_whitelist_index[ring->id]++;
> +
> + return 0;
> +}
> +
> static int gen8_init_workarounds(struct intel_engine_cs *ring)
> {
> struct drm_device *dev = ring->dev;
> @@ -1115,6 +1132,7 @@ int init_workarounds_ring(struct intel_engine_cs *ring)
> WARN_ON(ring->id != RCS);
>
> dev_priv->workarounds.count = 0;
> + dev_priv->workarounds.hw_whitelist_index[ring->id] = 0;
>
> if (IS_BROADWELL(dev))
> return bdw_init_workarounds(ring);
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-01-13 10:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 10:06 [PATCH 0/8] Gen9 HW whitelist and Preemption WA patches Arun Siluvery
2016-01-13 10:06 ` [PATCH 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers Arun Siluvery
2016-01-13 10:34 ` Ville Syrjälä [this message]
2016-01-13 11:39 ` Mika Kuoppala
2016-01-13 10:06 ` [PATCH 2/8] drm/i915/gen9: Add GEN8_CS_CHICKEN1 to HW whitelist Arun Siluvery
2016-01-21 11:49 ` Nick Hoath
2016-01-13 10:06 ` [PATCH 3/8] drm/i915/gen9: Add HDC_CHICKEN1 " Arun Siluvery
2016-01-21 11:54 ` Nick Hoath
2016-01-13 10:06 ` [PATCH 4/8] drm/i915/bxt: Add GEN9_CS_DEBUG_MODE1 " Arun Siluvery
2016-01-21 11:56 ` Nick Hoath
2016-01-13 10:06 ` [PATCH 5/8] drm/i915/bxt: Add GEN8_L3SQCREG4 " Arun Siluvery
2016-01-21 12:14 ` Nick Hoath
2016-01-13 10:06 ` [PATCH 6/8] drm/i915/skl: " Arun Siluvery
2016-01-21 12:14 ` Nick Hoath
2016-01-13 10:06 ` [PATCH 7/8] drm/i915/skl: Enable Per context Preemption granularity control Arun Siluvery
2016-01-21 14:37 ` Nick Hoath
2016-01-13 10:06 ` [PATCH 8/8] drm/i915/gen9: Add WaOCLCoherentLineFlush Arun Siluvery
2016-01-13 10:50 ` ✓ success: Fi.CI.BAT Patchwork
2016-01-13 12:28 ` [PATCH v2 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers Arun Siluvery
2016-01-13 13:03 ` Chris Wilson
2016-01-13 13:41 ` Arun Siluvery
2016-01-13 13:52 ` Chris Wilson
2016-01-13 15:38 ` [PATCH v3 " Arun Siluvery
2016-01-13 19:01 ` Chris Wilson
2016-01-13 19:14 ` Arun Siluvery
2016-01-13 19:38 ` Chris Wilson
2016-01-14 15:27 ` [PATCH v4 " Arun Siluvery
2016-01-19 9:00 ` Daniel Vetter
2016-01-19 10:16 ` Arun Siluvery
2016-01-19 12:03 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160113103445.GD23290@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=arun.siluvery@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mika.kuoppala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).