On Wed, Sep 25, 2024 at 06:04:43AM +0300, Raag Jadav wrote: > On Tue, Sep 24, 2024 at 01:23:13PM +0200, Simona Vetter wrote: > > On Mon, Sep 23, 2024 at 09:28:23AM +0530, 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 no longer operating as > > > expected and has become unrecoverable from driver context. > > > > > > Purpose of this implementation is to provide drivers a way to recover > > > through userspace intervention. Different drivers may have different > > > ideas of a "wedged device" depending on their hardware implementation, > > > and hence the vendor agnostic nature of the event. It is up to the drivers > > > to decide when they see the need for recovery and how they want to recover > > > from the available methods. > > > > > > Current implementation defines three recovery methods, out of which, > > > drivers can choose to support any one or multiple of them. Preferred > > > recovery method will be sent in the uevent environment as WEDGED=<method>. > > > Userspace consumers (sysadmin) can define udev rules to parse this event > > > and take respective action to recover the device. > > > > > > Method | Consumer expectations > > > -----------|----------------------------------- > > > rebind | unbind + rebind driver > > > bus-reset | unbind + reset bus device + rebind > > > reboot | reboot system > > > > > > v4: s/drm_dev_wedged/drm_dev_wedged_event > > > Use drm_info() (Jani) > > > Kernel doc adjustment (Aravind) > > > v5: Send recovery method with uevent (Lina) > > > v6: Access wedge_recovery_opts[] using helper function (Jani) > > > Use snprintf() (Jani) > > > > > > Signed-off-by: Raag Jadav <raag.jadav@xxxxxxxxx> > > > > Finally caught up on mail, so dropping this here again: Please also add a > > small section to drm-uapi.rst, pointing at these functions. Just the > > kerneldoc for developers is kinda not enough I think. > > Would you prefer a new section or have the existing one (Device reset which > looks somewhat similar but not entirely) modified? Great point, I think just adding a paragraph and maybe the table/list you have to the device reset section is perfect. -Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
