Received: by 10.223.185.116 with SMTP id b49csp1034896wrg; Wed, 21 Feb 2018 10:57:16 -0800 (PST) X-Google-Smtp-Source: AH8x225TQ+5z+osKjjNx5FlYdfTR3Tbg40pUQuy/4J5KW5/3jdSmzwI5Req44NRwAMd1PWPPwqAB X-Received: by 2002:a17:902:42a3:: with SMTP id h32-v6mr4084825pld.231.1519239436174; Wed, 21 Feb 2018 10:57:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519239436; cv=none; d=google.com; s=arc-20160816; b=epzOWWU+3niAzzeAbctRRxYyFVmKXGsu6m0AZqUB4zQz4KZdTX47P7avacaoM3IbFq f2m9+4THE9ZLcewPXWZRoAhDzRgO1huUQYbWfk7q6jt+IsBM4s9bGUDV7fYsq5+V+6BZ TOHEB5ATiiDBQx4BkE/eifIE5lFW4pzFN1AyyLvsZJJWMW2mA/I2CovyjDnJ4wJdGSYO 2dtNMF5P/1ZR9DUVEEQuMkeusKGVvs3xA3d1wzNUrbnB0WYTv1aTzGXkZ+OuSCYHa5a0 fPFveYQq8q22raivTKg5XW2gYCN8DEB1PB+9sixB+CRQBROtjswiZP4GLW+bY24QuBJ3 5Lmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=Vsf5U1l16c2qnIcag9uDvEY5bbpPGT2KwVymK1k9pVM=; b=DHuy4aVSKpkE93pjEDoHnMKYPNC++CDvtQ3lnFd9rovkvRpIQ8f8KaRKWviU4QBJh1 RiabclEZQVGFZCK60ThcZjKast6aOr2pprfS69JK1Jze8a/JYHzHGhPzrSWelBn3ybhd 3r5lm1+hbLcV2P5WnnE2Dy+eyj9iQnQA+u9Drthla1dkLj9TBNJ7CmCEVtdF6V082pl4 8mn1U8REMHgxvvQCtZP6Ev00V2NnvqlOGiLhRfUlGFWfJtvw+BQi8e0/bW7GWGDkCGyT v2Fswce1jJ2r67Oc8lVNQGFcAgI/HUEVg3GZNWvDdcE2qQmjRR8NHJEiLFPQgv3y1nfx vSIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ekODNUK7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1-v6si7699215pld.322.2018.02.21.10.57.02; Wed, 21 Feb 2018 10:57:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ekODNUK7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938271AbeBUPgL (ORCPT + 99 others); Wed, 21 Feb 2018 10:36:11 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:41367 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935612AbeBUPgJ (ORCPT ); Wed, 21 Feb 2018 10:36:09 -0500 Received: by mail-io0-f195.google.com with SMTP id e4so2535972iob.8; Wed, 21 Feb 2018 07:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Vsf5U1l16c2qnIcag9uDvEY5bbpPGT2KwVymK1k9pVM=; b=ekODNUK7p9EcaSSjhpy6k6/SoBZTn1RrYuYSIOt9YYPTgcgMdnAxCH/Zg87JTv1W1i dyU7dCool5b7002NNPzxf3nZQ6l+DYuN4T5f4P0bHyvnY9OjUVrItZy6J10zq0xNw1I7 A3qw1136CtL5LsvCpCGpA3iHRFdBhbLzLQYK6BWDHuVRq1uowZMZl9jYpEuUWlPLJP8C nwUiK2WL/4+OaNUuk4xZ40XawOps8tmhdmANQUgYR9pX8R/EXm+9f2WPya9RwMCHYon5 2vJxRAmw9Z7A0W9aQ2g7YqxWpldTACrivdY+ctw98c+ZOXGMAmRh1VA4NKhbbjcGkZUK eNdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Vsf5U1l16c2qnIcag9uDvEY5bbpPGT2KwVymK1k9pVM=; b=OdfahmCX99uz0YxGR1/8Q4Jy0mu7A9jq5d9ToEKxp00QOtRxcv28UBtLRaYs0zLbaO ldmrwr33dZMY1TLLfbzgCGXmKapFuOPWAFDqY5doyvRE5fbmcM6nywQWN0aHSC2Rjqr5 5iSk79uETI20KeuvnIsZOQA5lujJz4+Etk26/6ldmI/DSlW/kozqDHD7SE7ZA5yTTXdy M+gLoPD8DHVeJUwC3klspEf9xeP/imU7KWH0iuDXcHe++r5CcqIHW7Oszjm2h+GL+ANZ f7R6A/jaAFiefKklG6Wg/kS06vlcep3rjuuhDw6UWqwzaX6KcEHRDnsK4XS1HYFYfRi4 +rpQ== X-Gm-Message-State: APf1xPAV8I6CVp6QML2Ds4fQYU8CyNU0jV624xavTDd1ikulalqtjffv t9eF4VbMCzl9CFS82eFH95P/U8+Rh3UmuSjT6FV44Q== X-Received: by 10.107.8.2 with SMTP id 2mr4453758ioi.167.1519227368666; Wed, 21 Feb 2018 07:36:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.92.211 with HTTP; Wed, 21 Feb 2018 07:36:06 -0800 (PST) In-Reply-To: <20180221152720.GP5453@intel.com> References: <20180221143730.30285-1-robdclark@gmail.com> <20180221143730.30285-2-robdclark@gmail.com> <20180221144919.GN5453@intel.com> <20180221150727.GO5453@intel.com> <20180221152720.GP5453@intel.com> From: Rob Clark Date: Wed, 21 Feb 2018 10:36:06 -0500 Message-ID: Subject: Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= Cc: dri-devel , David Airlie , linux-arm-msm , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrj=C3=A4l=C3=A4 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=C3=A4l=C3=A4 >> 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=C3=A4l=C3=A4 >> >> 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. T= his >> >> >> 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 a= n >> > 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, bu= t >> > 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.. BR, -R >> >> BR, >> -R >> >> > >> >> >> >> (And ofc drivers could add there own locks in addition to what is don= e >> >> 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 >> >> >> --- >> >> >> 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_at= omic.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_priva= te_obj *obj, >> >> >> { >> >> >> memset(obj, 0, sizeof(*obj)); >> >> >> >> >> >> + drm_modeset_lock_init(&obj->lock); >> >> >> + >> >> >> obj->state =3D state; >> >> >> obj->funcs =3D 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 =3D=3D state->private_objs[i].ptr) >> >> >> return state->private_objs[i].state; >> >> >> >> >> >> + ret =3D drm_modeset_lock(&obj->lock, state->acquire_ctx); >> >> >> + if (ret) >> >> >> + return ERR_PTR(ret); >> >> >> + >> >> >> num_objs =3D state->num_private_objs + 1; >> >> >> size =3D sizeof(*state->private_objs) * num_objs; >> >> >> arr =3D 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 obj= ect'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 obje= ct. >> >> >> */ >> >> >> -- >> >> >> 2.14.3 >> >> >> >> >> >> _______________________________________________ >> >> >> dri-devel mailing list >> >> >> dri-devel@lists.freedesktop.org >> >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> > >> >> > -- >> >> > Ville Syrj=C3=A4l=C3=A4 >> >> > Intel OTC >> > >> > -- >> > Ville Syrj=C3=A4l=C3=A4 >> > Intel OTC > > -- > Ville Syrj=C3=A4l=C3=A4 > Intel OTC