Re: [PATCH v3 1/2] drm: introduce KMS recovery mechanism

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Apr 17, 2026 at 06:08:05PM +0200, Michel Dänzer wrote:
> On 2/20/26 10:09, Michel Dänzer wrote:
> > On 2/20/26 09:42, Michel Dänzer wrote:
> >> On 2/18/26 10:22, Michel Dänzer wrote:
> >>> On 2/18/26 01:45, Hamza Mahfooz wrote:
> >>>> On Mon, Feb 16, 2026 at 10:28:13AM +0100, Michel Dänzer wrote:
> >>>>> On 2/14/26 23:16, Hamza Mahfooz wrote:
> >>>>>> On Sat, Feb 14, 2026 at 03:02:49PM +0100, Michel Dänzer wrote:
> >>>>>>
> >>>>>>> In principle it's possible to do (the equivalent of) a modeset with the current state for all CRTCs, no need to do it separately per CRTC.
> >>>>>>
> >>>>>> AFAIK that is what the uevent is already doing (unless I'm mistaken).
> >>>>>
> >>>>> This is about just doing a full modeset, which isn't something user space can do in response to a wedged event.
> >>>>
> >>>> I was referring to what compositors are doing in response to
> >>>> `drm_kms_helper_hotplug_event()`. Perhaps, the enum constants should be
> >>>> renamed, since the forced modeset is actually sent when the current
> >>>> reset phase is DRM_KMS_RESET_NONE (the phase is updated before sending
> >>>> out the event though).
> >>>
> >>> Ah, you're talking about the drm_kms_helper_hotplug_event call in drm_atomic_helper_wait_for_flip_done (I thought "uevent" referred to drm_dev_wedged_event in patch 2).
> >>>
> >>> I don't know about other compositors, but I don't think mutter will do a modeset in response to a hotplug event if no KMS state changed (because some monitors can generate spurious hotplug events).
> >>
> >> [...]
> > 
> > [...], a reason why the kernel can't just do a modeset itself occurred to me: A modeset might affect other CRTCs than the ones affected by the timed-out commit, which could interact badly with other pending commits affecting those other CRTCs.
> 
> In a different thread, Ville (added to Cc) said this shouldn't be an issue.
> 
> In which case this would seem like the simplest solution.

Yeah, so extra blocking commits will just make everything (including
subsequent non-blocking commits) block on the modeset mutexes before
the -EBUSY check even happens.

On a somewhat relatd note, some time ago I proposed making blocking
commits also do the commit_tail part locklessly. But realizing that
something might depend on the current not-actually-nonblocking commit
semantics I was careful to preserve that even while dropping the locks:
https://lore.kernel.org/dri-devel/20220916163331.6849-1-ville.syrjala@linux.intel.com/

-- 
Ville Syrjälä
Intel