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.
>
> BR,
> -R
>
>
> >>
> >> BR,
> >> -R
> >>
> >> >
> >> >>
> >> >> (And ofc drivers could add there own locks in addition to what is done
> >> >> by core, but I'd rather look at that on a case by case basis, rather
> >> >> than it being part of the boilerplate in each driver.)
> >> >>
> >> >> BR,
> >> >> -R
> >> >>
> >> >> >>
> >> >> >> Signed-off-by: Rob Clark <robdclark@xxxxxxxxx>
> >> >> >> ---
> >> >> >> drivers/gpu/drm/drm_atomic.c | 9 ++++++++-
> >> >> >> include/drm/drm_atomic.h | 5 +++++
> >> >> >> 2 files changed, 13 insertions(+), 1 deletion(-)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> >> >> index fc8c4da409ff..004e621ab307 100644
> >> >> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> >> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> >> >> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct drm_private_obj *obj,
> >> >> >> {
> >> >> >> memset(obj, 0, sizeof(*obj));
> >> >> >>
> >> >> >> + drm_modeset_lock_init(&obj->lock);
> >> >> >> +
> >> >> >> obj->state = state;
> >> >> >> obj->funcs = funcs;
> >> >> >> }
> >> >> >> @@ -1093,6 +1095,7 @@ void
> >> >> >> drm_atomic_private_obj_fini(struct drm_private_obj *obj)
> >> >> >> {
> >> >> >> obj->funcs->atomic_destroy_state(obj, obj->state);
> >> >> >> + drm_modeset_lock_fini(&obj->lock);
> >> >> >> }
> >> >> >> EXPORT_SYMBOL(drm_atomic_private_obj_fini);
> >> >> >>
> >> >> >> @@ -1113,7 +1116,7 @@ struct drm_private_state *
> >> >> >> drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> >> >> >> struct drm_private_obj *obj)
> >> >> >> {
> >> >> >> - int index, num_objs, i;
> >> >> >> + int index, num_objs, i, ret;
> >> >> >> size_t size;
> >> >> >> struct __drm_private_objs_state *arr;
> >> >> >> struct drm_private_state *obj_state;
> >> >> >> @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> >> >> >> if (obj == state->private_objs[i].ptr)
> >> >> >> return state->private_objs[i].state;
> >> >> >>
> >> >> >> + ret = drm_modeset_lock(&obj->lock, state->acquire_ctx);
> >> >> >> + if (ret)
> >> >> >> + return ERR_PTR(ret);
> >> >> >> +
> >> >> >> num_objs = state->num_private_objs + 1;
> >> >> >> size = sizeof(*state->private_objs) * num_objs;
> >> >> >> arr = krealloc(state->private_objs, size, GFP_KERNEL);
> >> >> >> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> >> >> >> index 09076a625637..9ae53b73c9d2 100644
> >> >> >> --- a/include/drm/drm_atomic.h
> >> >> >> +++ b/include/drm/drm_atomic.h
> >> >> >> @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
> >> >> >> * &drm_modeset_lock is required to duplicate and update this object's state.
> >> >> >> */
> >> >> >> struct drm_private_obj {
> >> >> >> + /**
> >> >> >> + * @lock: Modeset lock to protect the state object.
> >> >> >> + */
> >> >> >> + struct drm_modeset_lock lock;
> >> >> >> +
> >> >> >> /**
> >> >> >> * @state: Current atomic state for this driver private object.
> >> >> >> */
> >> >> >> --
> >> >> >> 2.14.3
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> dri-devel mailing list
> >> >> >> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> >> >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> >> >
> >> >> > --
> >> >> > Ville Syrjälä
> >> >> > Intel OTC
> >> >
> >> > --
> >> > Ville Syrjälä
> >> > Intel OTC
> >
> > --
> > Ville Syrjälä
> > Intel OTC
--
Ville Syrjälä
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
