All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arun Siluvery <arun.siluvery@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org, Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH v4 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers
Date: Tue, 19 Jan 2016 10:16:52 +0000	[thread overview]
Message-ID: <569E0D14.4090807@linux.intel.com> (raw)
In-Reply-To: <20160119090023.GT19130@phenom.ffwll.local>

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@chris-wilson.co.uk>
>> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
>> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Signed-off-by: Arun Siluvery <arun.siluvery@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?

regards
Arun

> -Daniel
>
>> ---
>>   drivers/gpu/drm/i915/i915_debugfs.c     | 15 ++++++++++-----
>>   drivers/gpu/drm/i915/i915_drv.h         |  9 ++++++++-
>>   drivers/gpu/drm/i915/i915_reg.h         |  3 +++
>>   drivers/gpu/drm/i915/intel_ringbuffer.c | 17 +++++++++++++++++
>>   4 files changed, 38 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
>> index e3377ab..7eb002c 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -3229,9 +3229,11 @@ static int i915_wa_registers(struct seq_file *m, void *unused)
>>   {
>>   	int i;
>>   	int ret;
>> +	struct intel_engine_cs *ring;
>>   	struct drm_info_node *node = (struct drm_info_node *) m->private;
>>   	struct drm_device *dev = node->minor->dev;
>>   	struct drm_i915_private *dev_priv = dev->dev_private;
>> +	struct i915_workarounds *workarounds = &dev_priv->workarounds;
>>
>>   	ret = mutex_lock_interruptible(&dev->struct_mutex);
>>   	if (ret)
>> @@ -3239,15 +3241,18 @@ static int i915_wa_registers(struct seq_file *m, void *unused)
>>
>>   	intel_runtime_pm_get(dev_priv);
>>
>> -	seq_printf(m, "Workarounds applied: %d\n", dev_priv->workarounds.count);
>> -	for (i = 0; i < dev_priv->workarounds.count; ++i) {
>> +	seq_printf(m, "Workarounds applied: %d\n", workarounds->count);
>> +	for_each_ring(ring, dev_priv, i)
>> +		seq_printf(m, "HW whitelist count for %s: %d\n",
>> +			   ring->name, workarounds->hw_whitelist_count[i]);
>> +	for (i = 0; i < workarounds->count; ++i) {
>>   		i915_reg_t addr;
>>   		u32 mask, value, read;
>>   		bool ok;
>>
>> -		addr = dev_priv->workarounds.reg[i].addr;
>> -		mask = dev_priv->workarounds.reg[i].mask;
>> -		value = dev_priv->workarounds.reg[i].value;
>> +		addr = workarounds->reg[i].addr;
>> +		mask = workarounds->reg[i].mask;
>> +		value = workarounds->reg[i].value;
>>   		read = I915_READ(addr);
>>   		ok = (value & mask) == (read & mask);
>>   		seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X, read: 0x%08x, status: %s\n",
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> index 104bd18..83fccc0 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_count[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..7938814 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, i) _MMIO(((base)+0x4D0) + (i)*4)
>> +#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..56af736 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -787,6 +787,22 @@ static int wa_add(struct drm_i915_private *dev_priv,
>>
>>   #define WA_WRITE(addr, val) WA_REG(addr, 0xffffffff, val)
>>
>> +static int wa_ring_whitelist_reg(struct intel_engine_cs *ring, i915_reg_t reg)
>> +{
>> +	struct drm_i915_private *dev_priv = ring->dev->dev_private;
>> +	struct i915_workarounds *wa = &dev_priv->workarounds;
>> +	const uint32_t index = wa->hw_whitelist_count[ring->id];
>> +
>> +	if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
>> +		return -EINVAL;
>> +
>> +	WA_WRITE(RING_FORCE_TO_NONPRIV(ring->mmio_base, index),
>> +		 i915_mmio_reg_offset(reg));
>> +	wa->hw_whitelist_count[ring->id]++;
>> +
>> +	return 0;
>> +}
>> +
>>   static int gen8_init_workarounds(struct intel_engine_cs *ring)
>>   {
>>   	struct drm_device *dev = ring->dev;
>> @@ -1115,6 +1131,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_count[RCS] = 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
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-01-19 10:17 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ä
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 [this message]
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=569E0D14.4090807@linux.intel.com \
    --to=arun.siluvery@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.