From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=185.171.202.116 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793381493; b=Ed0MOS1H2fSCMMT2xYuNbfnmdG6vnYEDcufKhO5GWcXOm+8U8yd7FWSCVOo6ByF6Q2YJ steqfFyX0h6nwteLFR2GTl/4izas5alYk3hwx/MQ79DM2cwZcExXmJGyv0iV6vEhh3SEm TdIGiZ9cxPX9AhyWQkg2sTXNcThXwOlhPlAl53/CSPLTn5y/FNgFl+EQw7mA7H/o0iqxX O65QUhVtKNrnhsQAvOTLFG2bfvTtR76G/SzI0YetA2S+m6RtvxtfLiyv92fO467hUt1NM bvG2uGMznssu1AxYC2qASFo778B8DXRXiAOsqXKKPimrG4RCO8uuWf5QRaRW4FOZvUA== 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=uT/fNvfZqu7j2NS69BCVaNpgkHPYH4tcp/blT9q8k7Ht7dVvMdDcmHHB6chDBYzlNasO dAhptaCO/uDNN5GpyifBgLxhlHbUbeZCVkiWY9xvQ/WIQ28vBPDRfhF5irXtyNRTsCfJj EOkbcL17Bl4HWZ7XcXHNJ1JXcdnU4eB27zRtLFo2AnNBdumF5BeGBZxuRlCkVB3Lrl3Ht Rtfyswoj/NUTztC9AS+ioDqrmCCF5CoIkvnXEzWSJxH/exeOAPX5gUKoIC/LoRe2dLZTv x/hbaKGFkkScfJZsSpCGTdeSxPoUDcxekMY+oJVR0syNMqCUCcFMT6OHSJiRZ/mYEzA== 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.171.202.116 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (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 B2428606A31F for ; Fri, 30 Oct 2026 17:31:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org B2428606A31F 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-04.galae.net (Postfix) with ESMTPS id 010A4C49F6C; Fri, 30 Oct 2026 17:32:34 +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-doc@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