[PATCH 2/4] Revert "dt-bindings: display: bridge: ldb: Fill in reg property"
Liu Ying
victor.liu at nxp.com
Wed May 6 01:09:01 PDT 2026
On Tue, May 05, 2026 at 05:45:56PM +0200, Marco Felsch wrote:
> On 26-05-05, Rob Herring wrote:
> > On Mon, May 04, 2026 at 10:21:42PM +0200, Marco Felsch wrote:
> > > This reverts commit 16c8d76abe83d75b578d72ee22d25a52c764e14a.
> > >
> > > Remove the 'reg' and 'reg-names' property from the LDB.
> > >
> > > The LDB is either part of the IOMUX_GPR (i.MX6SX) or the BLKCTRL
> > > (i.MX8MP, i.MX93) register space. Both IOMUX_GPR and BLKCTRL are
> > > register ranges with loose register definitions. E.g.
> > >
> > > - On the i.MX8MP there is one register which controls the AXI
> > > threshold for two different IPs (BIT(31:16) - IP1, BIT(15:0) - IP2).
> > > - On the i.MX6SX IOMUXC_GPR5 controlls: CSI2 mux, WDOG3 settings, PXP
> > > handshake, ...
> > >
> > > In conclusion: it can't be ensured that one register belongs to one
> > > dedicated IP and the LDB is rather an exception than the rule.
> >
> > It is fine if there's a child node for LDB if the LDB registers are
> > consistent, but the other misc things are represented by the parent
> > node. It is certainly not a requirement that either everything be in
> > child nodes or nothing be in child nodes.
> >
> > What I don't see in this series is what problem does this fix? If you
> > are going to break compatibility, then there had better be a good
> > reason.
>
> Hi Rob,
>
> with the upcoming i.MX9x SoCs the parent syscon (BLKCTRL) controlls
> multiple other IPs, e.g. a DPI mux added by commit 3feaa4342637
> ("dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC subnode to schema and
> example").
>
> During the discussion of the above commit we agreed that the sub-devices
> of the syscon shall not use the reg property due to the fact that one
> register serves multiple purposes. In the above case the same register
> controlling the dpi-mux also controlls MIPI-DSI bits. The MIPI-DSI bits
> can be abstracted as drm-bridge as well. Two sub-devs using the same
> 'reg' property below the same parent seems odd and I don't know if this
> allowed either.
The MIPI-DSI bits are not modelled as sub-devs, but instead,
according to fsl,imx93-mipi-dsi.yaml[1], an i.MX93 MIPI DSI driver would
access the bits directly through the syscon.
Here, dpi-mux is a sub-dev while the MIPI-DSI bits are "misc things
represented by the parent node"(Rob's words). I don't see any problem
here at least for Linux since regmap provides register access synchronization
if everyone accesses registers through parent node's regmap.
[1] https://elixir.bootlin.com/linux/v7.0/source/Documentation/devicetree/bindings/display/bridge/fsl,imx93-mipi-dsi.yaml#L43-L47
--
Regards,
Liu Ying
More information about the linux-arm-kernel
mailing list