On Thu, May 7, 2026 at 6:55 AM Marco Felsch <[email protected]> wrote:
>
> On 26-05-06, Rob Herring wrote:
> > On Tue, May 5, 2026 at 10:46 AM Marco Felsch <[email protected]>
> > 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.
> >
> > It's not generally. There are some exceptions to define things at the
> > bit-offset level rather than byte level.
>
> Thanks for the clarification.
>
> > > Now the LDB is also part of this BLKCTRL syscon device but requires the
> > > reg property. TBH, I don't know why the reg property was added in the
> > > first place, due to the above fact (multiple sub-devs - same register).
> >
> > Probably because we asked for it, but we don't always get a complete
> > picture of all the h/w functions (though we ask for that too).
>
> I get your point completely and I don't blame anyone.
>
> > But nowhere have you said the LDB registers are mixed with other
> > functions. If they aren't, then there is absolutely nothing to change
> > in the binding. If they are, then yes, we shouldn't have 'reg'.
>
> No they aren't mixed with other functions (for now).
For now? Is the h/w going to change or is the binding *still* incomplete.
> Can you please
> confirm that mixing 'reg' based sub-device nodes with non 'reg' based
> sub-device nodes is allowed? E.g. if the below example is allowed?
>
> system-controller@4ac10000 {
> compatible = "fsl,imx93-media-blk-ctrl", "syscon";
> reg = <0x4ac10000 0x10000>;
> #address-cells = <1>;
> #size-cells = <1>;
>
> ...
>
> bridge@5c {
> compatible = "fsl,imx8mp-ldb";
> reg = <0x5c 0x4>, <0x128 0x4>;
> reg-names = "ldb", "lvds";
>
> ...
> };
>
> dpi-bridge {
> compatible = "nxp,imx93-pdfc";
>
> ...
Depends what is in "...". If only a compatible, then no. If there are
actual resources defined, then yes.
> };
> };
>
> Furthermore I thought that for the MMIO bridge@5c device, the 'reg'
> porperty would either require the full register address, e.g. 0x4ac1005c
> or there needs to be a ranges property.
There should be a ranges property no matter what.
Rob
