On Thu, Jul 18, 2013 at 10:42:48PM -0700, Ben Widawsky wrote:
> We've recently deferred error handling with a workqueue for a number of
> reasons. However, when we're trying to pass the information to
> userspace, it's likely more interesting to know when the error was
> detected by the kernel, and not when we eventually get around to
> handling it in the workqueue.
>
> This was inspired as a result of the patch to move these events to the
> uapi.
>
> Signed-off-by: Ben Widawsky <b...@bwidawsk.net>
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 9910699..9fe430a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1435,13 +1435,10 @@ static void i915_error_work_func(struct work_struct
> *work)
> gpu_error);
> struct drm_device *dev = dev_priv->dev;
> struct intel_ring_buffer *ring;
> - char *error_event[] = { "ERROR=1", NULL };
> char *reset_event[] = { "RESET=1", NULL };
> char *reset_done_event[] = { "ERROR=0", NULL };
> int i, ret;
>
> - kobject_uevent_env(&dev->primary->kdev.kobj, KOBJ_CHANGE, error_event);
> -
> /*
> * Note that there's only one work item which does gpu resets, so we
> * need not worry about concurrent gpu resets potentially incrementing
> @@ -1594,11 +1591,14 @@ void i915_handle_error(struct drm_device *dev, bool
> wedged)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_ring_buffer *ring;
> + char *error_event[] = { "ERROR=1", NULL };
> int i;
>
> i915_capture_error_state(dev);
> i915_report_and_clear_eir(dev);
>
> + kobject_uevent_env(&dev->primary->kdev.kobj, KOBJ_CHANGE, error_event);
> +
> if (wedged) {
> atomic_set_mask(I915_RESET_IN_PROGRESS_FLAG,
> &dev_priv->gpu_error.reset_counter);
This leaves the reset counter unchanged prior to the uevent, if you move
the uevent signalling down to just before the queue_work() there would
be no userspace visible changes (other than timing, which is a moot
point).
However, kobject_uevent_env() is not suitable for calling from
irq-context.
-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
