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?
--
Damien
