On Wed, Dec 05, 2012 at 04:35:59PM +0000, Damien Lespiau wrote:
> On Thu, Nov 15, 2012 at 4:17 PM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> > + * Note: It is of utmost importance that the passed in seqno and reset_counter
> > + * values have been read by the caller in an smb safe manner. Where read-side
>
> smp?
>
> > + * locks are involved, it is sufficient to read the reset_counter before
> > + * unlocking the lock that protects the seqno. For lockless tricks, the
> > + * reset_counter _must_ be read before, and an appropriate smb_rmb must be
>
> smp_rmb()?
>
> > if (!i915_reset(dev)) {
> > - atomic_set(&error->reset_counter, 0);
> > kobject_uevent_env(&dev->primary->kdev.kobj, KOBJ_CHANGE, reset_done_event);
> > } else {
> > atomic_set(&error->reset_counter, I915_WEDGED);
> > }
> >
> > + /*
> > + * After all the gem state is reset, increment the reset counter
> > + * and wake up everyone waiting for the reset to complete.
> > + *
> > + * Since unlock operations are a one-sided barrier only, we need
> > + * to insert a barrier here to order any seqno updates before
> > + * the counter increment.
> > + */
> > + smp_mb__before_atomic_inc();
> > + atomic_inc(&dev_priv->gpu_error.reset_counter);
>
> It seems that if the GPU can't reset, reset_counter is set to
> I915_WEDGED ie 0xffffffff and we increment that to 0?
I've somehow totally lost track of this series here. I've now slurped in
the first four patches up to "drm/i915: clear up wedged transitions". Can
you please take a look at the two follow-up patches I've posted in reply
to your mail and smash and r-b onto them if you approve?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
