Re: [PATCH] dt-bindings: display: bridge: ldb: Require reg property only for i.MX6SX/8MP LDBs

[Laurentiu Palcu]

Hi Marco, Marek, Ying,

On Tue, Mar 31, 2026 at 01:22:19AM +0200, Marek Vasut wrote:
> On 3/30/26 8:29 AM, Marco Felsch wrote:
> 
> Hello Marco,
> 
> > > > On 26-03-29, Liu Ying wrote:
> > > > > LDB's parent device could be a syscon which doesn't allow a reg property
> > > > > to be present in it's child devices, e.g., NXP i.MX93 Media blk-ctrl
> > > > > has a child device NXP i.MX93 Parallel Display Format Configuration(PDFC)
> > > > > without a reg property(LDB is also a child device of the Media blk-ctrl).
> > > > > To make the LDB schema be able to describe LDBs without the reg property
> > > > > like i.MX93 LDB, require the reg property only for i.MX6SX/8MP LDBs.
> > > > 
> > > > NACK, we want to describe the HW and from HW PoV the LDB is and was
> > > > always part of a syscon. This is the case for all SoCs i.MX6SX/8MP/93.
> > > > 
> > > > > Fixes: 8aa2f0ac08d3 ("dt-bindings: display: bridge: ldb: Add check for reg and reg-names")
> > > > 
> > > > Therefore I would just revert this patch completely.
> > > Last time, I pointed out the hardware is part of syscon, but as a subnode
> > > and therefore with reg properties. What is the problem there ?
> > 
> > To quote the DT spec here:
> > 
> > """
> > The reg property describes the address of the device’s resources within
> > the address space defined by its parent bus.
> > """
> 
> That parent bus would be the syscon, wouldn't it.
> 
> > The parent bus is not the parent iomuxc (i.MX6X) nor the blk-ctrl
> > (i.MX8MP/93) device. Therefore this is wrong IMHO and should be dropped.
> 
> How so ? What is the parent bus ?

It looks like the discussion is stuck on 2 things:

1. DT spec argument hasn't been fully addressed: Marek asked "what is
   the parent bus if not the syscon?". That question is still open. Syscon
   children carrying 'reg' to express their offset within the parent's MMIO
   range is a common upstream pattern. Marco, can you explain why syscon
   doesn't qualify as the address space provider here?

2. Regardless of (1), removing 'reg' from the imx6sx/imx8mp DT nodes is
   an ABI break, those nodes are already upstream. Ying's patch is
   the minimal fix that respects that constraint while unblocking imx93.

Marco, a broader cleanup of 'reg' from imx6sx/imx8mp would need to be a
separate patch with an explicit plan for the ABI impact... So, for now, my
suggestion is to move forward with Ying's solution.

-- 
Thanks,
Laurentiu