From: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
Raag Jadav <raag.jadav@intel.com>,
thomas.hellstrom@linux.intel.com,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
himal.prasad.ghimiray@intel.com, francois.dugast@intel.com,
anshuman.gupta@intel.com
Subject: Re: [PATCH v2] drm/xe/uapi: Bring back reset uevent
Date: Fri, 16 Aug 2024 09:59:31 +0530 [thread overview]
Message-ID: <bc514b83-69b4-43ea-bda6-2e498ae1e2ee@linux.intel.com> (raw)
In-Reply-To: <xcfgszlk4fqraxpzpxhqsaz6zyyi27eojapl6wx4qtbgj2hk4m@6jppy3zg5ea3>
On 14/08/24 19:54, Lucas De Marchi wrote:
> On Wed, Aug 14, 2024 at 12:16:41PM GMT, Aravind Iddamsetty wrote:
>>>>> i see that this is even called from xe_guc_exec_queue_lr_cleanup which is for long running queue
>>>>> from various call paths need to check in what scenarios those happen.
>>>> Should we add a reason for long running queue?
>>> Both of your questions would probably be answered if this was getting developed
>>> at the same time of the user space usage of these uevents.
>>
>> Can't we consider the generic Linux user as a consumer, via udevadm.
>
> No, udevadm just confirms that there is an event being sent. Main thing
> to understand here is "what is this event useful for? what can be done
> as outcome of receiving this event?". From your other reply it seems
> this is about "device is wedged/toast, and driver can't recover without
> userspace intervention since userspace may have different policies"
>
> What would be some examples of actions for userspace to take?
>
> - Unbind driver, kill clients, rebind?
> - FLR?
> - Something else?
The expectation from userspace on receiving this event is to do a reset
most probably SBR(unbind->sbr->rebind).
The other requirement of this event is for L0 Sysman
https://spec.oneapi.io/level-zero/latest/sysman/api.html#_CPPv4N21zes_event_type_flag_t41ZES_EVENT_TYPE_FLAG_DEVICE_RESET_REQUIREDE
https://spec.oneapi.io/level-zero/latest/sysman/api.html#_CPPv4N18zes_device_state_t5resetE
So we expect the admin do the above actions
>
> Is this currently implemented somewhere?
Do you mean by some other driver or subsystem?
>
> Also, is it possible to make is a generic drm event handling so distros
> don't have to setup udev rules for each vendor?
I think doing via drm event mandates the observability applications(L0)
to have open connection to the device to process these which is not desired.
Thanks,
Aravind.
>
>
>
> Lucas De Marchi
>
>>
>> Thanks,
>> Aravind.
>>>
>>>> Raag
next prev parent reply other threads:[~2024-08-16 4:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 7:48 [PATCH v2] drm/xe/uapi: Bring back reset uevent Raag Jadav
2024-08-12 7:47 ` ✓ CI.Patch_applied: success for drm/xe/uapi: Bring back reset uevent (rev2) Patchwork
2024-08-12 7:47 ` ✗ CI.checkpatch: warning " Patchwork
2024-08-12 7:48 ` ✓ CI.KUnit: success " Patchwork
2024-08-12 8:00 ` ✓ CI.Build: " Patchwork
2024-08-12 8:02 ` ✓ CI.Hooks: " Patchwork
2024-08-12 8:04 ` ✓ CI.checksparse: " Patchwork
2024-08-12 8:06 ` [PATCH v2] drm/xe/uapi: Bring back reset uevent Ghimiray, Himal Prasad
2024-08-12 8:27 ` ✗ CI.BAT: failure for drm/xe/uapi: Bring back reset uevent (rev2) Patchwork
2024-08-12 9:38 ` [PATCH v2] drm/xe/uapi: Bring back reset uevent Aravind Iddamsetty
2024-08-13 13:28 ` Raag Jadav
2024-08-13 16:54 ` Rodrigo Vivi
2024-08-14 6:46 ` Aravind Iddamsetty
2024-08-14 9:12 ` Raag Jadav
2024-08-14 12:49 ` Aravind Iddamsetty
2024-08-14 14:24 ` Lucas De Marchi
2024-08-16 4:29 ` Aravind Iddamsetty [this message]
2024-08-16 5:41 ` Lucas De Marchi
2024-08-12 9:55 ` ✗ CI.FULL: failure for drm/xe/uapi: Bring back reset uevent (rev2) Patchwork
2024-08-13 14:13 ` [PATCH v2] drm/xe/uapi: Bring back reset uevent Lucas De Marchi
2024-08-14 6:31 ` Aravind Iddamsetty
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=bc514b83-69b4-43ea-bda6-2e498ae1e2ee@linux.intel.com \
--to=aravind.iddamsetty@linux.intel.com \
--cc=anshuman.gupta@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=francois.dugast@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 \
--cc=thomas.hellstrom@linux.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