All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com>
Cc: airlied@gmail.com, daniel@ffwll.ch, lucas.demarchi@intel.com,
	thomas.hellstrom@linux.intel.com, rodrigo.vivi@intel.com,
	jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	tursulin@ursulin.net, intel-xe@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	himal.prasad.ghimiray@intel.com, francois.dugast@intel.com,
	anshuman.gupta@intel.com, bellekallu.rajkiran@intel.com,
	saikishore.konda@intel.com
Subject: Re: [PATCH v3 1/3] drm: Introduce device wedged event
Date: Tue, 3 Sep 2024 10:48:29 +0300	[thread overview]
Message-ID: <Zta_TbD9mkbacvYi@black.fi.intel.com> (raw)
In-Reply-To: <7724fc32-3dbe-41dd-ad13-e91f7e6ebd8c@linux.intel.com>

On Mon, Sep 02, 2024 at 02:44:21PM +0530, Aravind Iddamsetty wrote:
> 
> On 02/09/24 13:18, Raag Jadav wrote:
> > Introduce device wedged event, which will notify userspace of wedged
> > (hanged/unusable) state of the DRM device through a uevent. This is
> > useful especially in cases where the device is in unrecoverable state
> > and requires userspace intervention for recovery.
> >
> > Purpose of this implementation is to be vendor agnostic. Userspace
> > consumers (sysadmin) can define udev rules to parse this event and
> > take respective action to recover the device.
> >
> > Consumer expectations:
> > ----------------------
> > 1) Unbind driver
> > 2) Reset bus device
> > 3) Re-bind driver
> >
> > Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> > ---
> >  drivers/gpu/drm/drm_drv.c | 21 +++++++++++++++++++++
> >  include/drm/drm_drv.h     |  1 +
> >  2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 93543071a500..dc55cc237d89 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -499,6 +499,27 @@ void drm_dev_unplug(struct drm_device *dev)
> >  }
> >  EXPORT_SYMBOL(drm_dev_unplug);
> >  
> > +/**
> > + * drm_dev_wedged - declare DRM device as wedged
> > + * @dev: DRM device
> > + *
> > + * This declares a DRM device specified by @dev as wedged (hanged/unusable)
> this doesn't seem to set any drm state as wedged, it is just sending an
> uevent. you might need to correct the above statement.

On a second thought, perhaps this warrants any action on drm_device?

Raag

  reply	other threads:[~2024-09-03  7:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02  7:48 [PATCH v3 0/3] Introduce DRM device wedged event Raag Jadav
2024-09-02  7:34 ` ✓ CI.Patch_applied: success for " Patchwork
2024-09-02  7:34 ` ✗ CI.checkpatch: warning " Patchwork
2024-09-02  7:35 ` ✓ CI.KUnit: success " Patchwork
2024-09-02  7:47 ` ✓ CI.Build: " Patchwork
2024-09-02  7:48 ` [PATCH v3 1/3] drm: Introduce " Raag Jadav
2024-09-02  7:51   ` Jani Nikula
2024-09-02  9:14   ` Aravind Iddamsetty
2024-09-03  7:48     ` Raag Jadav [this message]
2024-09-02  7:48 ` [PATCH v3 2/3] drm/xe: Use " Raag Jadav
2024-09-02  9:09   ` Aravind Iddamsetty
2024-09-02  7:48 ` [PATCH v3 3/3] drm/i915: " Raag Jadav
2024-09-02  8:52   ` Aravind Iddamsetty
2024-09-03  7:03     ` Raag Jadav
2024-09-02  7:49 ` ✓ CI.Hooks: success for Introduce DRM " Patchwork
2024-09-02  7:51 ` ✗ CI.checksparse: warning " Patchwork
2024-09-02  8:10 ` ✓ CI.BAT: success " Patchwork
2024-09-02  8:33 ` ✗ Fi.CI.CHECKPATCH: warning " Patchwork
2024-09-02  8:33 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-09-02  8:39 ` ✓ Fi.CI.BAT: success " Patchwork
2024-09-02  9:24 ` ✗ CI.FULL: failure " Patchwork
2024-09-02 11:27 ` ✗ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zta_TbD9mkbacvYi@black.fi.intel.com \
    --to=raag.jadav@intel.com \
    --cc=airlied@gmail.com \
    --cc=anshuman.gupta@intel.com \
    --cc=aravind.iddamsetty@linux.intel.com \
    --cc=bellekallu.rajkiran@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=francois.dugast@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=saikishore.konda@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tursulin@ursulin.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.