From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail11.truemail.it (mail11.truemail.it [217.194.8.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 205282D3739; Thu, 23 Jul 2026 15:53:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.194.8.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784822020; cv=none; b=p26BN90JhqDt9HBgDULkS+EvFdmrojJgfwfBJFhYHTwTCNx+Jj21/YJdHphN7BAoHaaLZMVeKIPhF4bj01P6zJBluJ3z09HZCb8OfDX1ChQSMvgwPSE5irUwJBeECPgLV7yfNfxpf7mTWfb2wBQiuh5OCLUQ9bHdmP5dN5UH9Pg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784822020; c=relaxed/simple; bh=vj3aE85hDbw7uCURSaP7IQSnQ+S1YI+vBlGTt2ixjNY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WYG4pxpTdeUm4JCX/iMTiHQM9TS3PNKlnCqJc3+2coV7vmHUKrINqtr//3LAaswz7C8GqnwNjg32gih+ZKO//nbbJy6QHgxBNtKb2juf7wy2heJwpwcmpaEDBhrA/oL2Z1xWW46U9+ztK2vX6u7HuVCzQSGmqa6wFwh0uNMDwHQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=dolcini.it; spf=pass smtp.mailfrom=dolcini.it; dkim=pass (2048-bit key) header.d=dolcini.it header.i=@dolcini.it header.b=SnRBk3Rl; arc=none smtp.client-ip=217.194.8.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=dolcini.it Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=dolcini.it Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=dolcini.it header.i=@dolcini.it header.b="SnRBk3Rl" 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> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.