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 0A9ACC531F8 for ; Thu, 23 Jul 2026 15:53:50 +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=YhpAS7Om2Wra7yiqumfKj7cTlrvtZmIj2tUBITAsZvk=; b=M3pdrPwXZ+PKDNFgS/HaAzf2z6 +QNp4GU/mF2iQDtvLWnUDXYTmawfpP/hB0WV4Q0joCH47KTiHkNdC32krBkRLRHrMOoCqYDJBfP9L cparo2cj1qcztPUXTWyhVpbcBeYSjPuJ8G4YCyApeWnGDV27NAPO4O+8gLUHAN/7/XYTGeWVIp+aM HmF2jus5yQNSaNTsOWAazmr3M6dOD2B2Mx+z4JMhDpb25mlg5uiG5dbI3HadlNCIKpS0GYEysEVps KUB28VF/GMecXRGYcuP1FC1uLV3VgJrydRhPBQtXhvcoS+jSkbJ4VNOVt/9AwR8PsJY7OjFhtAUP4 +ZSaUKRQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wmvjy-0000000Ee9H-3wHH; Thu, 23 Jul 2026 15:53:42 +0000 Received: from mail11.truemail.it ([217.194.8.81]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wmvjv-0000000Ee7Y-3uVY for linux-arm-kernel@lists.infradead.org; Thu, 23 Jul 2026 15:53:41 +0000 Received: from francesco-nb (93-49-2-63.ip317.fastwebnet.it [93.49.2.63]) by mail11.truemail.it (Postfix) with ESMTPA id 3177F1F967; Thu, 23 Jul 2026 17:53:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolcini.it; s=default; t=1784822014; bh=YhpAS7Om2Wra7yiqumfKj7cTlrvtZmIj2tUBITAsZvk=; h=From:To:Subject; b=SnRBk3RlpWy7u4WPPOyFWREbUvUtiNbNhbllHu76fVTCIMuhI7O6uU7+mlMU9CekF nfDCEkZ0oZBRhROcj4OM6DB9ADCV6ZZkO9Jg9uXtqB0Ap4GNgAoQqQeFLA1JxrHxvf jG0qx1gh8NPyNoygqfQsrNEsJut0n2F2TR8/m52Yt2DpUO9Bp1j7UeGLfjDKDJ+APY LTtejBGO1ZmhFIG0XocNaxlCtXQPVe3uzmxO7HG4AhLjseyoOMPFcSUNeaEYHzNvkP EO1j9FJBvmfTCRGGLlKkFjVSD8NUj/atnNkj7C9AgzF6QguBKvrkgRGRjkueFA7yPV /BXTp5/IWtbtg== Date: Thu, 23 Jul 2026 17:53:32 +0200 From: Francesco Dolcini To: Frank Li Cc: Francesco Dolcini , Marek Vasut , Stefan Agner , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Alexander Stein , Francesco Dolcini , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 2/4] drm: mxsfb: Add optional DPI output bus-width configuration Message-ID: <20260723155332.GB4453@francesco-nb> References: <20260723093813.180089-1-francesco@dolcini.it> <20260723093813.180089-3-francesco@dolcini.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260723_085340_146129_3EBC3AC9 X-CRM114-Status: GOOD ( 24.06 ) 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 On Thu, Jul 23, 2026 at 10:47:36AM -0500, Frank Li wrote: > On Thu, Jul 23, 2026 at 11:38:09AM +0200, Francesco Dolcini wrote: > > From: Francesco Dolcini > > > > LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The > > format reported by the downstream panel or bridge describes the display > > input, but it does not describe how the LCDIF data pins are physically > > wired on the board. > > > > These can differ. For example, a 16-bit LCDIF bus can be connected to a > > 24-bit display by wiring the available color bits to the corresponding > > display inputs. In that case, using the display's 24-bit format to > > configure LCDIF selects the wrong data-bus mode and changes the assignment > > of color bits on the LCD_DATA pins. > > > > Read the optional bus-width endpoint property from the LCDIF output port > > and use it to select the media bus format used to configure LCDIF. This > > allows the LCDIF bus mode to describe the physical interface > > independently of the downstream display format. > > > > When the optional property is absent, continue using the format reported > > by the downstream display device, preserving the existing behavior. > > > > Signed-off-by: Francesco Dolcini > > --- > > v2: use the common bus-width property instead of the legacy interface-pix-fmt > > --- > > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 24 ++++++++++++++++++++++++ > > drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 ++ > > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 12 ++++++++++++ > > 3 files changed, 38 insertions(+) > > > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > > index 9b8fbda85d28..0545718a4b65 100644 > > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > > @@ -12,7 +12,10 @@ > > #include > > #include > > #include > > +#include > > #include > > +#include > > +#include > > #include > > #include > > #include > > @@ -209,7 +212,10 @@ static int mxsfb_load(struct drm_device *drm, > > const struct mxsfb_devdata *devdata) > > { > > struct platform_device *pdev = to_platform_device(drm->dev); > > + struct device_node *np = pdev->dev.of_node; > > struct mxsfb_drm_private *mxsfb; > > + struct device_node *ep; > > + u32 bus_width = 0; > > int ret; > > > > mxsfb = devm_kzalloc(&pdev->dev, sizeof(*mxsfb), GFP_KERNEL); > > @@ -236,6 +242,24 @@ static int mxsfb_load(struct drm_device *drm, > > if (IS_ERR(mxsfb->clk_disp_axi)) > > mxsfb->clk_disp_axi = NULL; > > > > + ep = of_graph_get_next_endpoint(np, NULL); > > use auto cleanup > > struct device_node *ep __free(device_node) = of_graph_get_next_endpoint(np, NULL); Does it makes the code more read-able or better in this specific case? I would say no, to me it is more compact and clear the way it is.