Re: [PATCH v8 1/9] dt-bindings: display: fsl,ldb: Add i.MX94 LDB

[Marek Vasut <marex@nabladev.com>]

On 3/25/26 9:02 AM, Laurentiu Palcu wrote:
> On Mon, Mar 23, 2026 at 03:22:35PM +0800, Liu Ying wrote:
>> On Sat, Mar 21, 2026 at 03:37:47AM +0100, Marek Vasut wrote:
>>> On 3/20/26 9:23 AM, Marco Felsch wrote:
>>>
>>> Hello Marco,
>>>
>>>>> The LDB driver was always written with parsing 'reg' out of the DT, so
>>>>
>>>> Not sure what you mean by always.
>>>
>>> By always, I mean since the very beginning.
>>
>> Marek, your below patch is not accepted(at least for now).  In that patch,
>> register offset(s) are directly parsed by calling of_property_read_reg().
>> Without that patch, register offset(s) are determined via device data in
>> driver according to compatible string.
>>
>> [PATCH v3] drm/bridge: fsl-ldb: Parse register offsets from DT
>> https://lore.kernel.org/all/20260104213712.128982-1-marek.vasut@mailbox.org/
>>
>> [...]
>>
>>>
>>>>> encoding the register offsets into the driver was a mistake. The LDB
>>>>> controls two registers, which can be comfortably described in DT.
>>>>
>>>> Sorry but I have to disagree on this. It's no about if it's possible,
>>>> it's about if the abstraction is correct and IMHO the LDB is just one
>>>> subdevice of the syscon. For i.MX6SX the syscon is the iomuxc-gpr for
>>>> the i.MX8M and i.MX9 this is now a blkctrl.
>>>
>>> Right, and the "reg" DT property specifies at which offsets are the LDB
>>> control registers from the start of that blkctrl. What is the problem
>>> with that ?
>>
>> The problem is that ...
>>
>>>
>>> Look at e.g. imx8mp.dtsi as an example with blkctrl and LDB as a subnode
>>> with "reg" DT properties:
>>>
>>> 1938                         media_blk_ctrl: blk-ctrl@32ec0000 {
>>> 1939                                 compatible = "fsl,imx8mp-media-blk-ctrl",
>>> 1940                                              "syscon";
>>> ...
>>> 2003                                 lvds_bridge: bridge@5c {
>>> 2004                                         compatible = "fsl,imx8mp-ldb";
>>> 2005                                         reg = <0x5c 0x4>, <0x128 0x4>;
>>> 2006                                         reg-names = "ldb", "lvds";
>>
>> ... i.MX8MP LVDS bridge node is fine with the reg property, but the property
>> is not allowed for i.MX93 LVDS bridge node according to commit[1] while
>> commit[2] requires the property for all LVDS bridge nodes.  See the contradict
>> here?
>>
>> [1] 3feaa4342637 dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC subnode to schema and example
>> [2] 8aa2f0ac08d3 dt-bindings: display: bridge: ldb: Add check for reg and reg-names
>>
>> To avoid the contradict, how about requiring the reg property only for i.MX6SX
>> and i.MX8MP LVDS bridge nodes and making it kind of optional for i.MX93 and
>> i.MX94 LVDS bridge nodes?  Overall, in terms of the reg property, I feel the
>> LVDS bridge nodes look similar to reg-mux/mmio-mux(See reg-mux.yaml) where
>> the property is optional.  BTW, there is a mux-controller node with 'mmio-mux'
>> compatible string in i.MX8mq syscon@30340000:
>>
>> iomuxc_gpr: syscon@30340000 {
>> 	compatible = "fsl,imx8mq-iomuxc-gpr", "syscon", "simple-mfd";
>> 	reg = <0x30340000 0x10000>;
>>
>> 	mux: mux-controller {
>> 		compatible = "mmio-mux";
>> 		#mux-control-cells = <1>;
>> 		mux-reg-masks = <0x34 0x00000004>; /* MIPI_MUX_SEL */
>> 	};
>> };
>>
>> We never know if HW designer would put a mux-controller next to a LVDS
>> bridge under a syscon device like gpr or blk-ctrl in future i.MX SoCs,
>> so the optional reg property would buy us some flexibility.
>>
>> The below patch is what I propose together with a Fixes tag for commit[2].
>> Since commit[2] is not in v6.19 and v7.0-rc5 was just released, it seems
>> that we have time to land the proposal fix if it makes sense.  WDYT?
> 
> Marek, Marco,
> 
> Does Ying's proposed solution sound reasonable? Having the 'reg'
> property optional for i.MX93 and i.MX94 platforms seems like  a good
> compromise. Can we move forward with this?
I only skimmed through it thus far, I need to read through it again when 
time permits, after which I will reply to it.