From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=185.246.85.4 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793381493; b=r/Ln/iL5XBdvSsseCSA8pcGd0USM0JRZrC1vSyKWwHt9grcEwHKUfuiZjWTO2lhONNwh sJZOawMbX1EqUrU1G52qceZRSPIAsm5wuOPcFYyz/qx9Mv1sapko0frMB/32tz6Lao4si Gq2YJ8y82aqEvo57OKLo2TmuIGndyrcp3PwgWviHR9I7Ev7irQTyfu1L/lq4eoLvpAfxa oAFcR6uHBSC7AP+RrH5DJjdCwchon1hFtdWw8++HSQaqT660KCdjJeYiasDCW4U0WLFgR IS3VsOl8Cdf1HqCU3NwKa2B+z8j+L6fbbIsr97c6ZLDPNavwiJlc5KZXU11n+ILXCfg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793381493; h=DMARC-Filter:Received:Received:Received:DKIM-Signature:Mime-Version: Content-Transfer-Encoding:Content-Type:Date:Message-Id:Cc:To:From: Subject:X-Mailer:References:In-Reply-To:X-Last-TLS-Session-Version; bh=lg0kgxHUKFzjiXY6CFOjM8mcZ+WYoVq2CQlrIXQSExI=; b=zgFP99BUi3jsW/OBrNSRmzOL8J8bkjq/rG75X2nr+S2w4B0D/tzkn4eZaowkC9x4rpT9 CLrprcTB5hHVei++wKKR6MlycO2x9AAcPa+JKP4MG/Q3WwGITjxYbGiyTF9AMX6VmP0sh aK0I8y2NptZxTGD5RKrnNLj9Kh11x0GsiGDBrNeN81yqWtEba0NlGsiqn6Ji2fTkDHrRk tNRR6hN9hg2U6O2MLzsiez8ECJctxDASBulkNYgjcFg9DBWLV7tJ/FC8BK2ryfRdydazH U2QBUQXpqCE99lU2BVrgVYJtK4hqbDTfvpm7jXap+dwupS5KE77pcZL/j0PTQ93mFpA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=dkim header.b=Sd14mJMc; arc=none smtp.remote-ip=185.246.85.4 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABA37606A31C; Fri, 30 Oct 2026 17:31:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org ABA37606A31C Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=dkim header.b=Sd14mJMc Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 5356A4E413A4; Fri, 30 Oct 2026 17:31:31 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 1AACC603C2; Fri, 30 Oct 2026 17:31:31 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id C43DF10329127; Fri, 30 Oct 2026 18:31:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1793381485; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=lg0kgxHUKFzjiXY6CFOjM8mcZ+WYoVq2CQlrIXQSExI=; b=Sd14mJMcVMS3sOmQ2BRP/Yu27JyNaplvycxZT/sUbjYugorR3C5K7ebD0EIYqmrAIAN91+ FRNv2vEt72dF438Dcgvt+/81ygxJN+sBh1LbP2ri3aRyIt+vnasNOrhK09Ec5zoI/msld6 2J8HnJxSrBm74asVssFdeUzcikjyEmZkRY48/ikGuxsB9r8bqxUQjZNu2ROt2rQWE9la0o wjL8CWYXEBOHplUPlRUhEnbfGB+nsQR2542d2e/8X6vnD9ZRfuPojJvtYZwBfktqkS3o+e fgNUZTQ4Eww+aJUgZifIz687VPiGnsT3xVSNvC5qUf7felDCsf5sWg7oRh9q1g== X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 30 Oct 2026 18:31:02 +0100 Message-Id: Cc: , , , , , , , , , , , , To: "Dmitry Baryshkov" , "Douglas Anderson" , "Neil Armstrong" , "Jessica Zhang" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Jyri Sarha" , "Tomi Valkeinen" , "Andrzej Hajda" , "Robert Foss" , "Laurent Pinchart" , "Jonas Karlman" , "Jernej Skrabec" , "Luca Ceresoli" , "Paul Cercueil" , "Marek Vasut" , "Stefan Agner" , "Frank Li" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "Laurent Pinchart" , "Tomi Valkeinen" , "Kieran Bingham" , "Geert Uytterhoeven" , "Magnus Damm" , "Biju Das" , "Linus Walleij" , "Sandy Huang" , =?utf-8?q?Heiko_St=C3=BCbner?= , "Andy Yan" , "Jonathan Corbet" , "Shuah Khan" , "Randy Dunlap" , "Inki Dae" , "Seung-Woo Kim" , "Kyungmin Park" , "Krzysztof Kozlowski" , "Peter Griffin" , "Alim Akhtar" , "Alison Wang" , "Paul Kocialkowski" , "Yannick Fertre" , "Raphael Gallais-Pou" , "Philippe Cornu" , "Maxime Coquelin" , "Alexandre Torgue" , "Chen-Yu Tsai" , "Samuel Holland" , "Thierry Reding" , "Mikko Perttunen" , "Jonathan Hunter" , "Jagan Teki" , "Ondrej Jirman" , "Javier Martinez Canillas" , "Igor Reznichenko" , "Michael Walle" , "Dario Binacchi" , "Jagan Teki" , "Jianhua Lu" , =?utf-8?q?Guido_G=C3=BCnther?= , "Purism Kernel Team" , "Jerry Han" , "Joel Selvaraj" , "Icenowy Zheng" , "Michael Trimarchi" , "Sumit Semwal" , "Casey Connolly" , "Michael Tretter" , "Cristian Cozzolino" , "Junjie Cao" , "Ryan Brue" , "Nickolay Goppen" , "Stefan Mavrodiev" , "Florian Fainelli" , "Broadcom internal kernel review list" , "Robert Chiras" , "Alexander Koskovich" , "Markuss Broks" , "Artur Weber" , "David Heidelberg" , "Dzmitry Sankouski" , "Yedaya Katsman" From: "Luca Ceresoli" Subject: Re: [PATCH 00/35] drm/panel: let the panels use the atomic state X-Mailer: aerc 0.22.0 References: <20261026-drm-panel-funcs-v1-0-5e3070a3478f@oss.qualcomm.com> In-Reply-To: X-Last-TLS-Session-Version: TLSv1.3 Hi Dmitry, On Tue Oct 27, 2026 at 1:02 PM CET, Dmitry Baryshkov wrote: > On Mon, Oct 26, 2026 at 01:09:49PM +0200, Dmitry Baryshkov wrote: >> The panel is the only element of the display pipeline which never sees >> the atomic commit. Its prepare() and enable() callbacks get nothing but >> the panel, so a panel which has to be programmed differently depending >> on the mode can only guess it. The NT35950 driver, for example, saves >> the connector in get_modes() and reads connector->state->crtc->state >> while being prepared: without the locks, from the current state rather >> than from the one being committed, and with no way to reject a mode it >> doesn't know. >> >> Every panel has a struct drm_bridge embedded into it, and the bridge >> already has all the missing parts: atomic_check(), a state object which >> can be subclassed and the commit passed to the callbacks. Rather than >> growing struct drm_panel_funcs into a copy of that, let the panel driver >> provide struct drm_bridge_funcs for the embedded bridge. This is opt-in: >> the panels which have no use for the atomic state keep using struct >> drm_panel_funcs and are not touched by it. >> >> To get there the bridge callbacks become the entry point to the panel, >> with drm_panel_prepare() and friends calling them rather than the other >> way around. The panel core still has to track the panel state, notify >> the panel followers and handle the backlight, so the driver doesn't fill >> in the power callbacks directly, it wraps its functions with the macros >> doing that part. NT35950 is converted as the first user. >> >> The bulk of the series is the cleanup of what the panel core and the >> bridge need from the panel driver, so that a panel providing the bridge >> callbacks doesn't need struct drm_panel_funcs for anything: >> >> - get_timings() had no callers. >> >> - The connector type was stored both in the panel and in its bridge, and >> the display drivers could override it while creating the panel bridge. >> >> - The orientation was read from the DT, stored and returned by nearly >> identical code in more than twenty panel drivers, and some of them >> also had to set it on the connector from get_modes(), with a TODO >> asking for a better place. The core reads it now. It is applied to the >> connector from the new connector_init() bridge callback, which is not >> specific to the panels: other bridges have properties to set up on the >> connector being created too (HDCP, DP link properties), and currently >> have nowhere to do it. >> >> - disable() and unprepare() returned an error which nobody could act on. >> Worse, a failed unprepare() left the panel marked as prepared, so it >> was never initialised again. >> >> Behaviour changes worth knowing about: >> >> - Panels with the rotation property whose driver ignored it now get the >> orientation property. In the tree this is the Motorola Mapphone panel >> (panel-dsi-cm). >> >> - sun6i_mipi_dsi, sti_dvo and the Tegra DSI get their panel after the >> DRM device has been registered, which is too late to create the >> property, so they lose the orientation which the panel drivers used to >> set from get_modes(). None of the rotated panels in the tree are used >> with them. >> >> - A panel implementing atomic_check() can only be driven through the >> bridge chain. The display drivers calling drm_panel_prepare() directly >> have no commit to pass. >> >> Signed-off-by: Dmitry Baryshkov >> --- >> Dmitry Baryshkov (35): >> drm/panel: remove the get_timings() callback >> drm/panel: remove the unused struct panel_bridge >> drm/tidss: get the panel type from the embedded bridge >> drm/bridge: lvds-codec: use devm_drm_panel_bridge_add() >> drm/ingenic: use devm_drm_panel_bridge_add() >> drm: mxsfb: use devm_drm_panel_bridge_add() >> drm: rcar-du: use devm_drm_panel_bridge_add() >> drm: rz-du: use devm_drm_panel_bridge_add() >> drm/mcde: use drm_panel_bridge_add() >> drm/pl111: use drm_panel_bridge_add() >> drm/rockchip: lvds: use drm_panel_bridge_add() >> drm/rockchip: rgb: use drm_panel_bridge_add() >> drm/panel: remove the _typed() panel bridge functions > > Gmail barked at me for sending too many emails for too many recipients > in the middle of the series. I guess, I'll have to split the series into > smaller parts. Please consider reviewing the posted patches, letting me > split / land the series in parts. The first 13~14 patches are nice and fairly independent cleanups. I guess they can be sent separately, or just be applied. However I'd still want to review patch 14 and do some testing next week before I consider them ready for applying. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com