Re: [PATCH v9 2/2] drm: Send per-connector hotplug events

[Daniel Stone]

Hi,

On Fri, 22 May 2026 at 20:28, Nicolas Frattaroli
<nicolas.frattaroli@xxxxxxxxxxxxx> wrote:
> On Friday, 22 May 2026 19:58:26 Central European Summer Time Daniel Stone wrote:
> > I wonder if the safest path which guarantees eventual consistency is
> > to change the !trylock(mode_config) { goto out } path in
> > output_poll_execute() to jump directly to the schedule_delayed_work()?
> > That way we could read and modify delayed_event under the mode_config
> > mutex; the if (changed) path will not be taken if it wasn't possible
> > to take the mode_config mutex.
>
> If the drm_kms_helper_poll module parameter is set to false (i.e. the
> non-default setting), with my patch we'd then also need to think about
> the behavior if delayed_event == true in that case, since it also goes
> to `out` without taking the lock.
>
> I think I need to ponder this particular orb some more. I suspect it'd
> be fine to move the delayed_event clearing + sending to before the
> mutex unlock, since failing to lock the mutex will just make it repoll
> and try again in 0.1 seconds. The event would only be lost if the
> another delayed_event arrives before it's processed.
>
> I think Ville's on the money here in that the users of delayed_event
> might want to call a drm_client_dev_hotplug that does the work
> scheduling instead, but that might be a bigger thing to work towards.

Yeah. That would certainly be a series (ok, multiple series - the sun
has made me optimistic I suppose) in itself, and I don't think it
makes sense to entangle the two.

Cheers,
Daniel