On Thu, Sep 28, 2023 at 03:33:46PM -0400, Ray Strode wrote: > hI, > > On Thu, Sep 28, 2023 at 11:05 AM Ville Syrjälä > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > Here's my earlier take on this: https://patchwork.freedesktop.org/series/108668/ > > Nice. Was there push back? Why didn't it go in? No one really seemed all that interested in it. I'd still like to get it in, if for no other reason than to make things operate more uniformly. Though there are lots of legacy codepaths left that still hold the locks over the whole commit, but those could be fixed up as a followup. > > > execpt I went further and moved the flush past the unlock in the end. > > Is that necessary? I was wondering about that but there's this comment > in the code: I'm not really sure there is any point in doing this otherwise. It would just change which thread executes the code but everything else would still get blocked on the locks the same as before. > > * ... Locks, especially struct > * &drm_modeset_lock, should not be held in worker threads or any other > * asynchronous context used to commit the hardware state. > > So it made me think there would be no locks held, and then I threw a > scratch build > at someone who reported it didn't deadlock and solved their issue. > > --Ray -- Ville Syrjälä Intel
