On Mon, Aug 08, 2016 at 04:28:56PM +0100, Chris Wilson wrote:
> On Mon, Aug 08, 2016 at 04:20:01PM +0300, David Weinehall wrote:
> > @@ -136,13 +140,14 @@ static void
> > describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
> > {
> > struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> > + struct drm_device *dev = &dev_priv->drm;
> > struct intel_engine_cs *engine;
> > struct i915_vma *vma;
> > unsigned int frontbuffer_bits;
> > int pin_count = 0;
> > enum intel_engine_id id;
> >
> > - lockdep_assert_held(&obj->base.dev->struct_mutex);
> > + lockdep_assert_held(&dev->struct_mutex);
>
> This is not a good tradeoff however. lockdep_assert_held() is
> conditional code that should be compiled out,
>
> >
> > seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %02x %02x [ ",
> > &obj->base,
> > @@ -157,13 +162,13 @@ describe_obj(struct seq_file *m, struct
> > drm_i915_gem_object *obj)
> > for_each_engine_id(engine, dev_priv, id)
> > seq_printf(m, "%x ",
> > i915_gem_active_get_seqno(&obj->last_read[id],
> > -
> > &obj->base.dev->struct_mutex));
> > + &dev->struct_mutex));
>
> Same again here.
>
> > seq_printf(m, "] %x %x%s%s%s",
> > i915_gem_active_get_seqno(&obj->last_write,
> > - &obj->base.dev->struct_mutex),
> > + &dev->struct_mutex),
> > i915_gem_active_get_seqno(&obj->last_fence,
> > - &obj->base.dev->struct_mutex),
> > - i915_cache_level_str(to_i915(obj->base.dev),
> > obj->cache_level),
> > + &dev->struct_mutex),
> > + i915_cache_level_str(dev_priv, obj->cache_level),
> > obj->dirty ? " dirty" : "",
> > obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
> > if (obj->base.name)
> > @@ -201,7 +206,7 @@ describe_obj(struct seq_file *m, struct
> > drm_i915_gem_object *obj)
> > }
> >
> > engine = i915_gem_active_get_engine(&obj->last_write,
> > - &obj->base.dev->struct_mutex);
> > + &dev->struct_mutex);
>
> and again.
>
> I'm quite happy with dev_priv->drm and need a strong argument to
> introduce dev = &dev_priv->drm locals. dev_priv->drm should avoid the
> need for the compiler to emit any locals should they go out of scope.
Thanks for the feedback. Will fix.
Regards: David
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
