From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 942FFCD4F21 for ; Tue, 12 May 2026 10:17:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jSoh/GaXZZ/8u/7OZ65mHX+roVMfei3a9XOPoLfNbMY=; b=EiA2m0/cJkTbin/NH8PkEpCHoO orm6V820gILfpXDXezFBcAgpiPQRTdRjabcGwfiSLB6tjVFD7TU8QyLSowk0RLOzHeQYX46zWBQnt x4LfDh8mHwlNu/KqMsZsayVRvELxxTSlopfEwnsG6ryHRswjjf8UsWNXS1cNC4EH6ZUpHRhVbMItp ohIO5AYFFCNK+E0etGvpYS0YrkqJ8mcIaDbDTjDFjsJuzH3F3ETDpLxUtHdik5cP7bi6ecVizInOE Z8EhGIbqKId3TdzhC6D0b66zUFST6S7uv9wPPzhlY0HGp/CfeEdE4RLv8tNAQd0l7qrjRjU/2lBla fx3GJFzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wMkAe-0000000GPPw-1vdP; Tue, 12 May 2026 10:17:02 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wMkAb-0000000GPPP-1lCE for linux-arm-kernel@lists.infradead.org; Tue, 12 May 2026 10:16:58 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id AC4EA43CDA; Tue, 12 May 2026 10:16:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BB70C2BCB0; Tue, 12 May 2026 10:16:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778581016; bh=w6hATkZRGSRSJowaFjN45EX2kl/oM+c7ccdVW67Eh3s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iyynMxhKI/8Jg0jAf3zt9NS9aZuPuBUsWGBl6pjep56D0BX7ArOWIvumJnsk4Hxuq mnnaRaFvBV5mkvEsDlbtbvUSCRvLWYdvCMf4sNeM7vNilIbeePN5AkWfwxvjAQev7g /0A4u2buvc8ZFh87pXWIBdFrJFLxqXQwPpvDqOdq1iuaVD2hhWsouG5CMcWCdCXTZv ifyJNn5+17bVPbWwPFuyMigi7nZbU+5QYcAqZqfLOaUQjlplaxZPW1O+AKlvC2/zNq 0oO5sua9onBYaQGmy1JTt0SnaAYmCKIZGFkBl54L+OfZD1RfSStH8Oms9Ts4XPZzEe eFQvD4RfZWaYw== Date: Tue, 12 May 2026 12:16:53 +0200 From: Maxime Ripard To: Laurent Pinchart Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Jonathan Corbet , Shuah Khan , Dmitry Baryshkov , Jyri Sarha , Tomi Valkeinen , Andrzej Hajda , Neil Armstrong , Robert Foss , Jonas Karlman , Jernej Skrabec , Simon Ser , Harry Wentland , Melissa Wen , Sebastian Wick , Alex Hung , Jani Nikula , Rodrigo Vivi , Joonas Lahtinen , Tvrtko Ursulin , Chen-Yu Tsai , Samuel Holland , Dave Stevenson , =?utf-8?B?TWHDrXJh?= Canal , Raspberry Pi Kernel Maintenance , dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Stone , intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev Subject: Re: [PATCH v3 12/20] drm/crtc: Add new atomic_create_state callback Message-ID: <20260512-unbiased-apricot-jaguar-a63eba@houat> References: <20260424-drm-mode-config-init-v3-0-8b68d9db0d8b@kernel.org> <20260424-drm-mode-config-init-v3-12-8b68d9db0d8b@kernel.org> <20260504172858.GO1344263@killaraus.ideasonboard.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="xucbq2efeno5xzls" Content-Disposition: inline In-Reply-To: <20260504172858.GO1344263@killaraus.ideasonboard.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260512_031657_503581_2872E99C X-CRM114-Status: GOOD ( 38.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --xucbq2efeno5xzls Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v3 12/20] drm/crtc: Add new atomic_create_state callback MIME-Version: 1.0 Hi, On Mon, May 04, 2026 at 08:28:58PM +0300, Laurent Pinchart wrote: > On Fri, Apr 24, 2026 at 12:18:52PM +0200, Maxime Ripard wrote: > > Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback > > to drm_private_obj") introduced a new pattern for allocating drm object > > states. > >=20 > > Instead of relying on the reset() callback, it created a new > > atomic_create_state hook. This is helpful because reset is a bit > > overloaded: it's used to create the initial software state, reset it, > > but also reset the hardware. > >=20 > > It can also be used either at probe time, to create the initial state > > and possibly reset the hardware to an expected default, but also during > > suspend/resume. > >=20 > > Both these cases come with different expectations too: during the > > initialization, we want to initialize all states, but during > > suspend/resume, drm_private_states for example are expected to be kept > > around. > >=20 > > reset() also isn't fallible, which makes it harder to handle > > initialization errors properly. This is only really relevant for some > > drivers though, since all the helpers for reset only create a new > > state, and don't touch the hardware at all. > >=20 > > It was thus decided to create a new hook that would allocate and > > initialize a pristine state without any side effect: > > atomic_create_state to untangle a bit some of it, and to separate the > > initialization with the actual reset one might need during a > > suspend/resume. > >=20 > > Continue the transition to the new pattern with CRTCs. > >=20 > > Reviewed-by: Dmitry Baryshkov > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/drm_atomic_state_helper.c | 47 +++++++++++++++++++++++= ++++++++ > > drivers/gpu/drm/drm_mode_config.c | 21 +++++++++++++- > > include/drm/drm_atomic_state_helper.h | 4 +++ > > include/drm/drm_crtc.h | 16 +++++++++++ > > 4 files changed, 87 insertions(+), 1 deletion(-) > >=20 > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/dr= m/drm_atomic_state_helper.c > > index 9cd8550cabb7..b7da134c8c50 100644 > > --- a/drivers/gpu/drm/drm_atomic_state_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c > > @@ -103,10 +103,32 @@ __drm_atomic_helper_crtc_reset(struct drm_crtc *c= rtc, > > =20 > > crtc->state =3D crtc_state; > > } > > EXPORT_SYMBOL(__drm_atomic_helper_crtc_reset); > > =20 > > +/** > > + * __drm_atomic_helper_crtc_create_state - initializes crtc state >=20 > "Initialize a CRTC state" Good catch, thanks. > The name of the function is misleading ("*_create_*" while you state it > performs initialization). > > > + * @crtc: crtc object > > + * @state: new state to initialize > > + * > > + * Initializes the newly allocated @state, usually required when > > + * initializing the drivers. > > + * > > + * @state is assumed to be zeroed. > > + * > > + * This is useful for drivers that subclass @drm_crtc_state. > > + */ > > +void __drm_atomic_helper_crtc_create_state(struct drm_crtc *crtc, > > + struct drm_crtc_state *state) > > +{ > > + __drm_atomic_helper_crtc_state_init(state, crtc); > > + > > + if (drm_dev_has_vblank(crtc->dev)) > > + drm_crtc_vblank_reset(crtc); >=20 > This is confusing to me (at least before reading the rest of the > series), and itn't mentioned in the function documentation or in the > commit message. > > Furthermore, __drm_atomic_helper_crtc_create_state() is later used in > tidss_crtc_create_state(), which is the > drm_crtc_funcs.atomic_create_state() implementation of the tidss driver. > The atomic_create_state documentation states that "This callback must > have no side effect", and drm_crtc_vblank_reset() has side effects. That's a good point. I've dropped that function entirely and moved the drm_crtc_vblank_reset() call in drm_mode_config_crtc_create_state(). Maxime --xucbq2efeno5xzls Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCagL+FQAKCRAnX84Zoj2+ dnNzAX0fzjsGevsyIM+1eS7aSdqPXqaWO2e4vKxwlm1t0+VWLC1LChDXcVfr74JX gfLRKAABgLDj6dDvAIYO++YmRFrG/pDTCiRABTfTFmqA3MNWXLLdVzFuX/WVI0ll s+ZfkvI9qg== =NbJq -----END PGP SIGNATURE----- --xucbq2efeno5xzls--