Received: by 10.223.185.116 with SMTP id b49csp1034269wrg; Wed, 21 Feb 2018 10:56:26 -0800 (PST) X-Google-Smtp-Source: AH8x225SHVqo1iJOwuSFeI8w0VQdDx2JqY3R38mWLVvtRKI9X+66koTRffUCS4oWJPYsrYCPeweK X-Received: by 10.98.22.65 with SMTP id 62mr4185779pfw.211.1519239386232; Wed, 21 Feb 2018 10:56:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519239386; cv=none; d=google.com; s=arc-20160816; b=kTU/6tV+SxCdK94VhqgbrVtPMqT4HOP6Vso8Qdvi6gkapz+WD8lJ68FDM1xRcd2yES ODQy/rp78skHFef3y51vBByZ3h7Pu6BhArXg2aSanV+MuVCUU7feSKwr1X0QONMS4MTV 93iAjjxohLbBCcgqgNBB3rt7gWbuV+aSDOuLlyZ26EJwI5w9jEvC0PyRNDih2iIUOOJE z5n9lJPaibX6bEJt1JDzqpqLZMaZ1J0m7TBJe1IIjZpYJQREG1H3B/g0N1xSH7dllZz3 FBMVNGWuTnAx+uRPldUTiramsWENkMUZp1yIrLSM+35rvUnF8yMkvGZZBPAw2LhoJJ0x U8bw== 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=lbhweqPixEwtvqG3lulq7UhUOv0ihHk87SzzQTskeN0=; b=xb7nQfQrae8zH2CkPsjZR+TAANbUk8LgiRFa7cF16+WMBhk8uwaxogDUgbcdOL9fhf 7TPd0a1SLt01pLN065lpwJ2x/Hr4d7KFd9TG3PO4vcZcMY3/gumc1SlbeYogpH7JSGWv p2NqmL1b1oU6pTQDksM/Qgtfs39iazY/ZFIDO5yuKa7H7xELJaxCljvrDLOcheBa2qcA 1XIw53FEjLRrxk4QkVCUk3GnWerZZI2Mlfb160vQri/rzzfLnXJDA6uOxkLn9P5R7TGF fwmXN30SYwk5NgO+jzUX1UTk6f/ARHRdW4/ISJsEK7mXm7HJ5cJe1t8EZ0wNmK3YlgP9 A6sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rFJBAWge; 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 c1-v6si34682plk.697.2018.02.21.10.56.11; Wed, 21 Feb 2018 10:56:26 -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=rFJBAWge; 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 S938206AbeBUPUI (ORCPT + 99 others); Wed, 21 Feb 2018 10:20:08 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:42012 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937764AbeBUPUF (ORCPT ); Wed, 21 Feb 2018 10:20:05 -0500 Received: by mail-io0-f195.google.com with SMTP id u84so2479611iod.9; Wed, 21 Feb 2018 07:20:04 -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=lbhweqPixEwtvqG3lulq7UhUOv0ihHk87SzzQTskeN0=; b=rFJBAWgeIjn0SfaD40eOVvLVffghku3Y0n6IkmwXsNNMHfVGOp29NbTHWE2aYi/Pag XJUEgdiIAnL6LgrCtT6+h9SYQwQXC5RFCzAb1lOn35g7BJVh96jzk+wUtYAXm9lMmgnw pJ1gG2TBrPy3nmpKfHXQs9henPtU8GIw9KTCGRF0gZW1DpP4MBwuMA0GN5tedav08+QN rk6iWJBqGs8Pq7hB7yV1unirHzb8cCHTF0ME353HVIGhFHybTlKFrNr1QXf8pH5JesbS +HTqVMrXzHSg7eDRbb/YzEX+ypNEeJI4Kv0bnyjV3FYuGx++p/h7IkxM0jxYCBN2//pA d3FA== 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=lbhweqPixEwtvqG3lulq7UhUOv0ihHk87SzzQTskeN0=; b=OHyqd1yGuhIUxhfcyFel6Aop4wbOjhh56pgFEaZ4+OduBzTMn6RZ4Zben0SgoOZrBQ 7vnx8nkhi575dJo0RRDO5C7Ox4dnEW8QCCbSBIuUKgaaBHNWFfPl95C5KftW4/QWWtDX F7RgFnQyZMobPIg6pXpIMFRBQ23GeDt8PkSsl+IuctPIgmHv7kQ9lKZb4/yy8e+pwGIu 8Zsg4Vkum7Etw7jfeQsbRmOl5KLHh0ga1Ujs9qKsj5jj+cIeAHf2oUCrymz2dbvBRk0B NOm0QdO+AqsYvPIyOwStOuyMDwOZCxGAl46zns/5+Q4350+Vtm1Lxn82FETTGCDBkpl3 R7BA== X-Gm-Message-State: APf1xPAQMH6Xo8ndZ2/ecwBBoV2/C1OTdUc4KQB/fjVY7V4y3I+BjFit 0qaj2ms661pKXFo+ashpKTg5WQflPxRQQN3nLJFhbw== X-Received: by 10.107.13.73 with SMTP id 70mr4429039ion.7.1519226404288; Wed, 21 Feb 2018 07:20:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.92.211 with HTTP; Wed, 21 Feb 2018 07:20:03 -0800 (PST) In-Reply-To: <20180221150727.GO5453@intel.com> References: <20180221143730.30285-1-robdclark@gmail.com> <20180221143730.30285-2-robdclark@gmail.com> <20180221144919.GN5453@intel.com> <20180221150727.GO5453@intel.com> From: Rob Clark Date: Wed, 21 Feb 2018 10:20:03 -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: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. 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? 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 >> >> --- >> >> 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_atomi= c.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 =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_at= omic_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 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@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