On Wed, Feb 21, 2018 at 11:17:21AM -0500, Rob Clark wrote: > On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote: > >> On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä > >> <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote: > >> >> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä > >> >> <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> >> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote: > >> >> >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä > >> >> >> <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> >> >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote: > >> >> >> >> Follow the same pattern of locking as with other state objects. This > >> >> >> >> avoids boilerplate in the driver. > >> >> >> > > >> >> >> > I'm not sure we really want to do this. What if the driver wants a > >> >> >> > custom locking scheme for this state? > >> >> >> > >> >> >> That seems like something we want to discourage, ie. all the more > >> >> >> reason for this patch. > >> >> >> > >> >> >> There is no reason drivers could not split their global state into > >> >> >> multiple private objs's, each with their own lock, for more fine > >> >> >> grained locking. That is basically the only valid reason I can think > >> >> >> of for "custom locking". > >> >> > > >> >> > In i915 we have at least one case that would want something close to an > >> >> > rwlock. Any crtc lock is enough for read, need all of them for write. > >> >> > Though if we wanted to use private objs for that we might need to > >> >> > actually make the states refcounted as well, otherwise I can imagine > >> >> > we might land in some use-after-free issues once again. > >> >> > > >> >> > Maybe we could duplicate the state into per-crtc and global copies, but > >> >> > then we have to keep all of those in sync somehow which doesn't sound > >> >> > particularly pleasant. > >> >> > >> >> Or just keep your own driver lock for read, and use that plus the core > >> >> modeset lock for write? > >> > > >> > If we can't add the private obj to the state we can't really use it. > >> > > >> > >> I'm not sure why that is strictly true (that you need to add it to the > >> state if for read-only), since you'd be guarding it with your own > >> driver read-lock you can just priv->foo_state->bar. > >> > >> Since it is read-only access, there is no roll-back to worry about for > >> test-only or failed atomic_check()s.. > > > > That would be super ugly. We want to access the information the same > > way whether it has been modified or not. > > Well, I mean the whole idea of what you want to do seems a bit super-ugly ;-) > > I mean, in mdp5 the assigned global resources go in plane/crtc state, > and tracking of what is assigned to which plane/crtc is in global > state, so it fits nicely in the current locking model. For i915, I'm > not quite sure what is the global state you are concerned about, so it > is a bit hard to talk about the best solution in the abstract. Maybe > the better option is to teach modeset-lock how to be a rwlock instead? The thing I'm thinking is the core display clock (cdclk) frequency which we need to consult whenever computing plane states and whatnot. We don't want a modeset on one crtc to block a plane update on another crtc unless we actually have to bump the cdclk (which would generally require all crtcs to undergo a full modeset). Seems like a generally useful pattern to me. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
