Hi, On Fri, 22 May 2026 at 20:28, Nicolas Frattaroli <[email protected]> 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
