| Message ID | 1366671570-11524-1-git-send-email-jbarnes@virtuousgeek.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 23 Apr 2013, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > We need to hold the rps lock around punit access. Reviewed-by: Jani Nikula <jani.nikula@intel.com> And a semi-related question while at it... we will need punit access also for non-rps stuff. Shall we just bundle them under the semantically wrong rps lock? It would also feel a bit awkward to add another level of locking for punit when we already have a "hw_lock" in rps. BR, Jani. > Reported-by: Kenneth Graunke <kenneth@whitecape.org> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > --- > drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c > index 367b534..d195d09 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -1012,6 +1012,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused) > } else if (IS_VALLEYVIEW(dev)) { > u32 freq_sts, val; > > + mutex_lock(&dev_priv->rps.hw_lock); > valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS, > &freq_sts); > seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts); > @@ -1028,6 +1029,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused) > seq_printf(m, "current GPU freq: %d MHz\n", > vlv_gpu_freq(dev_priv->mem_freq, > (freq_sts >> 8) & 0xff)); > + mutex_unlock(&dev_priv->rps.hw_lock); > } else { > seq_printf(m, "no P-state info available\n"); > } > -- > 1.7.10.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 23 Apr 2013 10:51:28 +0300 Jani Nikula <jani.nikula@linux.intel.com> wrote: > On Tue, 23 Apr 2013, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > > We need to hold the rps lock around punit access. > > Reviewed-by: Jani Nikula <jani.nikula@intel.com> > > And a semi-related question while at it... we will need punit access > also for non-rps stuff. Shall we just bundle them under the semantically > wrong rps lock? It would also feel a bit awkward to add another level of > locking for punit when we already have a "hw_lock" in rps. Unless the new users will need to take the lock in a blocking way (thus potentially impacting freq changes for a long time), I'd say we just keep abusing the rps hw_lock.
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 367b534..d195d09 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1012,6 +1012,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused) } else if (IS_VALLEYVIEW(dev)) { u32 freq_sts, val; + mutex_lock(&dev_priv->rps.hw_lock); valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS, &freq_sts); seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts); @@ -1028,6 +1029,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused) seq_printf(m, "current GPU freq: %d MHz\n", vlv_gpu_freq(dev_priv->mem_freq, (freq_sts >> 8) & 0xff)); + mutex_unlock(&dev_priv->rps.hw_lock); } else { seq_printf(m, "no P-state info available\n"); }
We need to hold the rps lock around punit access. Reported-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ 1 file changed, 2 insertions(+)