Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


  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