From: Riana Tauro <riana.tauro@intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>, <anshuman.gupta@intel.com>,
<rodrigo.vivi@intel.com>, <lucas.demarchi@intel.com>,
<aravind.iddamsetty@linux.intel.com>,
<himal.prasad.ghimiray@intel.com>, <frank.scarbrough@intel.com>,
<andrealmeid@igalia.com>, <christian.koenig@amd.com>
Subject: Re: [PATCH 1/4] drm: Add a firmware flash method to device wedged uevent
Date: Thu, 5 Jun 2025 16:54:24 +0530 [thread overview]
Message-ID: <062a11d5-ada1-47e7-ad33-46c4b48da439@intel.com> (raw)
In-Reply-To: <aEAjaGK9BYK89U3Z@black.fi.intel.com>
Hi Raag
On 6/4/2025 4:13 PM, Raag Jadav wrote:
> On Tue, Jun 03, 2025 at 01:43:57PM +0530, Riana Tauro wrote:
>> A device is declared wedged when it is non-recoverable from
>> the driver context. Some firmware errors can also cause
>> the device to enter this state and the only method to recover
>> from this would be to do a firmware flash
>>
>> Signed-off-by: Riana Tauro <riana.tauro@intel.com>
>> ---
>> Documentation/gpu/drm-uapi.rst | 6 +++---
>> drivers/gpu/drm/drm_drv.c | 2 ++
>> include/drm/drm_device.h | 1 +
>> 3 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
>> index 4863a4deb0ee..524224afb09f 100644
>> --- a/Documentation/gpu/drm-uapi.rst
>> +++ b/Documentation/gpu/drm-uapi.rst
>> @@ -422,9 +422,8 @@ Current implementation defines three recovery methods, out of which, drivers
>> can use any one, multiple or none. Method(s) of choice will be sent in the
>> uevent environment as ``WEDGED=<method1>[,..,<methodN>]`` in order of less to
>> more side-effects. If driver is unsure about recovery or method is unknown
>> -(like soft/hard system reboot, firmware flashing, physical device replacement
>> -or any other procedure which can't be attempted on the fly), ``WEDGED=unknown``
>> -will be sent instead.
>> +(like soft/hard system reboot, physical device replacement or any other procedure
>> +which can't be attempted on the fly), ``WEDGED=unknown`` will be sent instead.
>>
>> Userspace consumers can parse this event and attempt recovery as per the
>> following expectations.
>> @@ -435,6 +434,7 @@ following expectations.
>> none optional telemetry collection
>> rebind unbind + bind driver
>> bus-reset unbind + bus reset/re-enumeration + bind
>> + firmware-flash unbind + firmware flash + bind
>
> Can you guarantee this to be generic for all drivers?
Firmware flash as a method was mentioned as unknown in the document. So
if there is an error that requires firmware flash to recover, mentioning
this as recovery method should be okay
Wanted to get some comments on unbind/bind. If this is not required will
remove it.
Adding reviewers for inputs
Thanks
Riana
>
> Raag
next prev parent reply other threads:[~2025-06-05 11:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 8:13 [PATCH 0/4] Handle Firmware reported Hardware Errors Riana Tauro
2025-06-03 7:55 ` ✓ CI.Patch_applied: success for " Patchwork
2025-06-03 7:56 ` ✗ CI.checkpatch: warning " Patchwork
2025-06-03 7:57 ` ✓ CI.KUnit: success " Patchwork
2025-06-03 8:07 ` ✓ CI.Build: " Patchwork
2025-06-03 8:10 ` ✗ CI.Hooks: failure " Patchwork
2025-06-03 8:12 ` ✗ CI.checksparse: warning " Patchwork
2025-06-03 8:13 ` [PATCH 1/4] drm: Add a firmware flash method to device wedged uevent Riana Tauro
2025-06-04 10:43 ` Raag Jadav
2025-06-05 11:24 ` Riana Tauro [this message]
2025-06-16 20:39 ` Rodrigo Vivi
2025-06-03 8:13 ` [PATCH 2/4] drm/xe: Add a helper function to set recovery method Riana Tauro
2025-06-06 15:12 ` Raag Jadav
2025-06-19 7:26 ` Riana Tauro
2025-06-03 8:13 ` [PATCH 3/4] drm/xe: Add support to handle hardware errors Riana Tauro
2025-06-03 8:14 ` [PATCH 4/4] drm/xe/xe_hw_error: Handle CSC Firmware reported Hardware errors Riana Tauro
2025-06-03 9:31 ` Ghimiray, Himal Prasad
2025-06-03 9:53 ` Riana Tauro
2025-06-03 8:57 ` ✓ Xe.CI.BAT: success for Handle Firmware reported Hardware Errors Patchwork
2025-06-04 8:55 ` ✓ Xe.CI.Full: " 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=062a11d5-ada1-47e7-ad33-46c4b48da439@intel.com \
--to=riana.tauro@intel.com \
--cc=andrealmeid@igalia.com \
--cc=anshuman.gupta@intel.com \
--cc=aravind.iddamsetty@linux.intel.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=frank.scarbrough@intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=raag.jadav@intel.com \
--cc=rodrigo.vivi@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox