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

  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