Received: by 10.223.185.116 with SMTP id b49csp1035718wrg; Wed, 21 Feb 2018 10:58:14 -0800 (PST) X-Google-Smtp-Source: AH8x224dWgQASqOl0K7N3EQ6KrHkDrhI6DGkQeGO4lQkudkXSG0XoTmCgFlUnMyHNh7S7zVQ0YIc X-Received: by 10.101.92.138 with SMTP id a10mr3454424pgt.191.1519239494447; Wed, 21 Feb 2018 10:58:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519239494; cv=none; d=google.com; s=arc-20160816; b=lchkH1wTYpG03sNOtDGwWK/W4k6pTOn3UPtwW5X4mrbsTEznhdH+LAS1fnzv18xw1z 3rcztiFJ5OXzpi990nsDeDqs+I91V+cDbka27PRg+j1ObT8wOA8zl9fP4vzCiiyJ8lTr 4MPx9gsMa3PwQgf0mbJWISNNBdu1P60OjW2JiKnGjYjFejMp3MqtXH3cpOf2DlD2UT6l nxdE+9MeDC77sQkplPLnlbY42FUbl3A5XYSP1EXf+Zi5bsPTwtBHDuBWXQaUsweB/Ons Xg/AbnqlrrLx2DBYgO0Yfs03d9eoyz/DWcvM2PdePIJj92h4dCtPF0FnQ8D6WvVqQOo5 X6jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=GWSGaD3WK6gnLnqyyvFqZGU6LC2j/FWb4CxvykANukQ=; b=HAIWRNO25Vq8adgj6LZyF9iKPRtIeHXszfCseM8LpsjEmkvnjjPsTe4BucVUTLriid jcNOdULf0sO1X2ztoVPDOjzJjObbuNNP8V8hTBqIa9+LA1TILnnmvWt2tA+Zw0hmzkt3 AFylJQev9DtEo8towEpt+hiaEu6J8/lmPQ5A+tak/szfg6/JDsEdUajD33r6pNMw1PxA bytdFd8paiqPfrPViLMeEs/IXGg3E3webdqNj8K7h7frsb3w0/XiSaWXxeN647c596vy AqTabzLzH0uWJdCvK68jyb6QEU34H0+uCKYsWKGsUDFxq4A+wXPJ8veovTKj0vD3OYbP oR0w== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t199si1386162pgb.105.2018.02.21.10.58.00; Wed, 21 Feb 2018 10:58:14 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938424AbeBUPyP (ORCPT + 99 others); Wed, 21 Feb 2018 10:54:15 -0500 Received: from mga05.intel.com ([192.55.52.43]:64848 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937781AbeBUPyO (ORCPT ); Wed, 21 Feb 2018 10:54:14 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2018 07:54:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,543,1511856000"; d="scan'208";a="28781441" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by FMSMGA003.fm.intel.com with SMTP; 21 Feb 2018 07:54:10 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 21 Feb 2018 17:54:10 +0200 Date: Wed, 21 Feb 2018 17:54:10 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Rob Clark Cc: dri-devel , David Airlie , linux-arm-msm , Linux Kernel Mailing List Subject: Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects Message-ID: <20180221155410.GQ5453@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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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:36:06AM -0500, Rob Clark wrote: > On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrj?l? > 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? > >> 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? > >> >> 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 > >> >> >> --- > >> >> >> 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@lists.freedesktop.org > >> >> >> 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