[PATCH 1/6] drm/i915: Get runtime pm ref on i915_drop_caches_set

[PATCH 1/6] drm/i915: Get runtime pm ref on i915_drop_caches_set

[Mika Kuoppala]

When we drop caches, this debugfs entry does hardware access later in
the chain, when fences are updated, so it needs a runtime pm ref.

Dropping caches is used by some igt/bat tests, so this fixes
some unclaimed register access traces.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 24318b7..bd8ba7e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4839,6 +4839,8 @@ i915_drop_caches_set(void *data, u64 val)
 	if (ret)
 		return ret;
 
+	intel_runtime_pm_get(dev_priv);
+
 	if (val & DROP_ACTIVE) {
 		ret = i915_gpu_idle(dev);
 		if (ret)
@@ -4855,6 +4857,7 @@ i915_drop_caches_set(void *data, u64 val)
 		i915_gem_shrink(dev_priv, LONG_MAX, I915_SHRINK_UNBOUND);
 
 unlock:
+	intel_runtime_pm_put(dev_priv);
 	mutex_unlock(&dev->struct_mutex);
 
 	return ret;
-- 
2.5.0

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

[PATCH 2/6] drm/i915: Get runtime pm ref when setting min/max freqs

[Mika Kuoppala]

intel_set_rps() does hardware access later in the
chain, so it needs a runtime pm ref.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++++
 drivers/gpu/drm/i915/i915_sysfs.c   | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index bd8ba7e..d0e9f2d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4923,7 +4923,9 @@ i915_max_freq_set(void *data, u64 val)
 
 	dev_priv->rps.max_freq_softlimit = val;
 
+	intel_runtime_pm_get(dev_priv);
 	intel_set_rps(dev, val);
+	intel_runtime_pm_put(dev_priv);
 
 	mutex_unlock(&dev_priv->rps.hw_lock);
 
@@ -4990,7 +4992,9 @@ i915_min_freq_set(void *data, u64 val)
 
 	dev_priv->rps.min_freq_softlimit = val;
 
+	intel_runtime_pm_get(dev_priv);
 	intel_set_rps(dev, val);
+	intel_runtime_pm_put(dev_priv);
 
 	mutex_unlock(&dev_priv->rps.hw_lock);
 
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c b/drivers/gpu/drm/i915/i915_sysfs.c
index 37e3f0d..d43aebf 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -391,10 +391,12 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
 		      dev_priv->rps.min_freq_softlimit,
 		      dev_priv->rps.max_freq_softlimit);
 
+	intel_runtime_pm_get(dev_priv);
 	/* We still need *_set_rps to process the new max_delay and
 	 * update the interrupt limits and PMINTRMSK even though
 	 * frequency request may be unchanged. */
 	intel_set_rps(dev, val);
+	intel_runtime_pm_put(dev_priv);
 
 	mutex_unlock(&dev_priv->rps.hw_lock);
 
@@ -450,10 +452,12 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
 		      dev_priv->rps.min_freq_softlimit,
 		      dev_priv->rps.max_freq_softlimit);
 
+	intel_runtime_pm_get(dev_priv);
 	/* We still need *_set_rps to process the new min_delay and
 	 * update the interrupt limits and PMINTRMSK even though
 	 * frequency request may be unchanged. */
 	intel_set_rps(dev, val);
+	intel_runtime_pm_put(dev_priv);
 
 	mutex_unlock(&dev_priv->rps.hw_lock);
 
-- 
2.5.0

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

[PATCH 3/6] drm/i915: Get runtime pm ref on i915_fbc_fc_set

[Mika Kuoppala]

Setting the fbc does hardware access so it needs to have
pm ref.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e9f2d..0e568de 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1678,6 +1678,7 @@ static int i915_fbc_fc_set(void *data, u64 val)
 		return -ENODEV;
 
 	mutex_lock(&dev_priv->fbc.lock);
+	intel_runtime_pm_get(dev_priv);
 
 	reg = I915_READ(ILK_DPFC_CONTROL);
 	dev_priv->fbc.false_color = val;
@@ -1686,7 +1687,9 @@ static int i915_fbc_fc_set(void *data, u64 val)
 		   (reg | FBC_CTL_FALSE_COLOR) :
 		   (reg & ~FBC_CTL_FALSE_COLOR));
 
+	intel_runtime_pm_put(dev_priv);
 	mutex_unlock(&dev_priv->fbc.lock);
+
 	return 0;
 }
 
-- 
2.5.0

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

[PATCH 4/6] drm/i915: Get runtime pm ref on i915_emon_status

[Mika Kuoppala]

Getting emon status does access hw so it needs to have pm ref.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e568de..3e0e30d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1771,9 +1771,13 @@ static int i915_emon_status(struct seq_file *m, void *unused)
 	if (ret)
 		return ret;
 
+	intel_runtime_pm_get(dev_priv);
+
 	temp = i915_mch_val(dev_priv);
 	chipset = i915_chipset_val(dev_priv);
 	gfx = i915_gfx_val(dev_priv);
+
+	intel_runtime_pm_put(dev_priv);
 	mutex_unlock(&dev->struct_mutex);
 
 	seq_printf(m, "GMCH temp: %ld\n", temp);
-- 
2.5.0

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

[PATCH 5/6] drm/i915: Get runtime pm ref on i915_guc_load_status_info

[Mika Kuoppala]

Getting guc load status does hardware access so it needs
to have pm ref.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 3e0e30d..5770307 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2417,6 +2417,8 @@ static int i915_guc_load_status_info(struct seq_file *m, void *data)
 	seq_printf(m, "\tRSA: offset is %d; size = %d\n",
 		guc_fw->rsa_offset, guc_fw->rsa_size);
 
+	intel_runtime_pm_get(dev_priv);
+
 	tmp = I915_READ(GUC_STATUS);
 
 	seq_printf(m, "\nGuC status 0x%08x:\n", tmp);
@@ -2430,6 +2432,8 @@ static int i915_guc_load_status_info(struct seq_file *m, void *data)
 	for (i = 0; i < 16; i++)
 		seq_printf(m, "\t%2d: \t0x%x\n", i, I915_READ(SOFT_SCRATCH(i)));
 
+	intel_runtime_pm_put(dev_priv);
+
 	return 0;
 }
 
-- 
2.5.0

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

[PATCH 6/6] drm/i915: Get runtime pm ref on i915_sseu_status

[Mika Kuoppala]

Getting subslice status does access hw so it needs a pm ref.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 5770307..c9d11ba 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5206,6 +5206,7 @@ static int i915_sseu_status(struct seq_file *m, void *unused)
 {
 	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 sseu_dev_status stat;
 
 	if (INTEL_INFO(dev)->gen < 8)
@@ -5231,6 +5232,8 @@ static int i915_sseu_status(struct seq_file *m, void *unused)
 
 	seq_puts(m, "SSEU Device Status\n");
 	memset(&stat, 0, sizeof(stat));
+
+	intel_runtime_pm_get(dev_priv);
 	if (IS_CHERRYVIEW(dev)) {
 		cherryview_sseu_device_status(dev, &stat);
 	} else if (IS_BROADWELL(dev)) {
@@ -5238,6 +5241,8 @@ static int i915_sseu_status(struct seq_file *m, void *unused)
 	} else if (INTEL_INFO(dev)->gen >= 9) {
 		gen9_sseu_device_status(dev, &stat);
 	}
+	intel_runtime_pm_put(dev_priv);
+
 	seq_printf(m, "  Enabled Slice Total: %u\n",
 		   stat.slice_total);
 	seq_printf(m, "  Enabled Subslice Total: %u\n",
-- 
2.5.0

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

Re: [PATCH 1/6] drm/i915: Get runtime pm ref on i915_drop_caches_set

[Chris Wilson]

On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
> When we drop caches, this debugfs entry does hardware access later in
> the chain, when fences are updated, so it needs a runtime pm ref.
> 
> Dropping caches is used by some igt/bat tests, so this fixes
> some unclaimed register access traces.
> 
> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index 24318b7..bd8ba7e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4839,6 +4839,8 @@ i915_drop_caches_set(void *data, u64 val)
>  	if (ret)
>  		return ret;
>  
> +	intel_runtime_pm_get(dev_priv);

The current idea of the very coarse granularity of rpm_get() is to do it
before struct_mutex (since rpm_get resume may try to acquire the mutex
iirc).

Ok, fixing that may be bolting the stable door after the horse bolted,
but we should nevertheless. In my opinion, it would be more productive
to work with Imre on making rpm fine grained so that we don't so many
and can actually place the wakelock around the hardware access itself,
not every single path that *may* touch hardware.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/i915: Get runtime pm ref on i915_drop_caches_set

[Mika Kuoppala]

Some igt tests wants to drop caches by writing to this debugfs
entry. The call to shrinker may ensure and it wants to update
the fence registers, so hardware access happens. This access
can happen in a spot where the block containing these registers
might bepowered down.

To avoid getting unclaimed register access trace noise due
to this, take a runtime pm reference during i915_drop_caches set.

v2: pm_ref and mutex lock ordering (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 24318b7..d96709a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4833,11 +4833,13 @@ i915_drop_caches_set(void *data, u64 val)
 
 	DRM_DEBUG("Dropping caches: 0x%08llx\n", val);
 
+	intel_runtime_pm_get(dev_priv);
+
 	/* No need to check and wait for gpu resets, only libdrm auto-restarts
 	 * on ioctls on -EAGAIN. */
 	ret = mutex_lock_interruptible(&dev->struct_mutex);
 	if (ret)
-		return ret;
+		goto pm_put;
 
 	if (val & DROP_ACTIVE) {
 		ret = i915_gpu_idle(dev);
@@ -4856,7 +4858,9 @@ i915_drop_caches_set(void *data, u64 val)
 
 unlock:
 	mutex_unlock(&dev->struct_mutex);
-
+pm_put:
+	intel_runtime_pm_put(dev_priv);
+	
 	return ret;
 }
 
-- 
2.5.0

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

Re: [PATCH 1/6] drm/i915: Get runtime pm ref on i915_drop_caches_set

[Mika Kuoppala]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
>> When we drop caches, this debugfs entry does hardware access later in
>> the chain, when fences are updated, so it needs a runtime pm ref.
>> 
>> Dropping caches is used by some igt/bat tests, so this fixes
>> some unclaimed register access traces.
>> 
>> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 24318b7..bd8ba7e 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -4839,6 +4839,8 @@ i915_drop_caches_set(void *data, u64 val)
>>  	if (ret)
>>  		return ret;
>>  
>> +	intel_runtime_pm_get(dev_priv);
>
> The current idea of the very coarse granularity of rpm_get() is to do it
> before struct_mutex (since rpm_get resume may try to acquire the mutex
> iirc).
>
> Ok, fixing that may be bolting the stable door after the horse bolted,
> but we should nevertheless. In my opinion, it would be more productive
> to work with Imre on making rpm fine grained so that we don't so many
> and can actually place the wakelock around the hardware access itself,
> not every single path that *may* touch hardware.

Please consider 1/6 v2 as it is needed to avoid random unclaimed
accesses during igt/bat if the drop caches is used in wrong spot.

We can forget the rest.

-Mika



> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Get runtime pm ref on i915_drop_caches_set

[Joonas Lahtinen]

On ti, 2015-12-15 at 13:35 +0200, Mika Kuoppala wrote:
> Some igt tests wants to drop caches by writing to this debugfs
> entry. The call to shrinker may ensure and it wants to update
> the fence registers, so hardware access happens. This access
> can happen in a spot where the block containing these registers
> might bepowered down.
> 
> To avoid getting unclaimed register access trace noise due
> to this, take a runtime pm reference during i915_drop_caches set.
> 
> v2: pm_ref and mutex lock ordering (Chris)
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 24318b7..d96709a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4833,11 +4833,13 @@ i915_drop_caches_set(void *data, u64 val)
>  
>  	DRM_DEBUG("Dropping caches: 0x%08llx\n", val);
>  
> +	intel_runtime_pm_get(dev_priv);
> +
>  	/* No need to check and wait for gpu resets, only libdrm
> auto-restarts
>  	 * on ioctls on -EAGAIN. */
>  	ret = mutex_lock_interruptible(&dev->struct_mutex);
>  	if (ret)
> -		return ret;
> +		goto pm_put;
>  
>  	if (val & DROP_ACTIVE) {
>  		ret = i915_gpu_idle(dev);
> @@ -4856,7 +4858,9 @@ i915_drop_caches_set(void *data, u64 val)
>  
>  unlock:
>  	mutex_unlock(&dev->struct_mutex);
> -
> +pm_put:
> +	intel_runtime_pm_put(dev_priv);
> +	
>  	return ret;
>  }
>  
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

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

Re: [PATCH 1/6] drm/i915: Get runtime pm ref on i915_drop_caches_set

[Daniel Vetter]

On Tue, Dec 15, 2015 at 01:36:07PM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
> >> When we drop caches, this debugfs entry does hardware access later in
> >> the chain, when fences are updated, so it needs a runtime pm ref.
> >> 
> >> Dropping caches is used by some igt/bat tests, so this fixes
> >> some unclaimed register access traces.
> >> 
> >> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> >> index 24318b7..bd8ba7e 100644
> >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >> @@ -4839,6 +4839,8 @@ i915_drop_caches_set(void *data, u64 val)
> >>  	if (ret)
> >>  		return ret;
> >>  
> >> +	intel_runtime_pm_get(dev_priv);
> >
> > The current idea of the very coarse granularity of rpm_get() is to do it
> > before struct_mutex (since rpm_get resume may try to acquire the mutex
> > iirc).
> >
> > Ok, fixing that may be bolting the stable door after the horse bolted,
> > but we should nevertheless. In my opinion, it would be more productive
> > to work with Imre on making rpm fine grained so that we don't so many
> > and can actually place the wakelock around the hardware access itself,
> > not every single path that *may* touch hardware.
> 
> Please consider 1/6 v2 as it is needed to avoid random unclaimed
> accesses during igt/bat if the drop caches is used in wrong spot.

Yeah wakelocks work like locks, except lockdep doesn't check them because
they're not really locks in all aspects. But anyway, we need to obey
ordering constraints.

Hm ... maybe it would be possible to annotate get/put_rpm with a lockdep
context (and trylock for the others), and then also acquire that context
around the actual resume/suspend functions? Might be worth a shot as a
tech demo, perhaps even adding that to the pm core and pinging Rafael for
feedback. Since auditing correctness here is way too much pain.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/6] drm/i915: Get runtime pm ref on i915_drop_caches_set

[Imre Deak]

On ke, 2015-12-16 at 11:42 +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 01:36:07PM +0200, Mika Kuoppala wrote:
> > Chris Wilson <chris@chris-wilson.co.uk> writes:
> > 
> > > On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
> > > > When we drop caches, this debugfs entry does hardware access
> > > > later in
> > > > the chain, when fences are updated, so it needs a runtime pm
> > > > ref.
> > > > 
> > > > Dropping caches is used by some igt/bat tests, so this fixes
> > > > some unclaimed register access traces.
> > > > 
> > > > Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > index 24318b7..bd8ba7e 100644
> > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > @@ -4839,6 +4839,8 @@ i915_drop_caches_set(void *data, u64 val)
> > > >  	if (ret)
> > > >  		return ret;
> > > >  
> > > > +	intel_runtime_pm_get(dev_priv);
> > > 
> > > The current idea of the very coarse granularity of rpm_get() is
> > > to do it
> > > before struct_mutex (since rpm_get resume may try to acquire the
> > > mutex
> > > iirc).
> > > 
> > > Ok, fixing that may be bolting the stable door after the horse
> > > bolted,
> > > but we should nevertheless. In my opinion, it would be more
> > > productive
> > > to work with Imre on making rpm fine grained so that we don't so
> > > many
> > > and can actually place the wakelock around the hardware access
> > > itself,
> > > not every single path that *may* touch hardware.
> > 
> > Please consider 1/6 v2 as it is needed to avoid random unclaimed
> > accesses during igt/bat if the drop caches is used in wrong spot.
> 
> Yeah wakelocks work like locks, except lockdep doesn't check them
> because
> they're not really locks in all aspects. But anyway, we need to obey
> ordering constraints.
> 
> Hm ... maybe it would be possible to annotate get/put_rpm with a
> lockdep
> context (and trylock for the others), and then also acquire that
> context
> around the actual resume/suspend functions? Might be worth a shot as
> a
> tech demo, perhaps even adding that to the pm core and pinging Rafael
> for
> feedback. Since auditing correctness here is way too much pain.

Yea, this idea came up already:
http://lists.freedesktop.org/archives/intel-gfx/2015-November/079807.html

and I have a preliminary patch at:
https://github.com/ideak/linux/commit/8f63aaaef27f3c56a1996ea4ac6a8393e0af4e44

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