Re: [PATCH v5 1/4] media: dt-bindings: nxp,imx8mq-mipi-csi2: Add i.MX8ULP compatible string

[Frank Li <Frank.li@nxp.com>]

On Tue, Sep 02, 2025 at 05:53:39PM +0200, Krzysztof Kozlowski wrote:
> On 02/09/2025 14:35, Laurent Pinchart wrote:
> > On Tue, Sep 02, 2025 at 02:26:53PM +0200, Krzysztof Kozlowski wrote:
> >> On 02/09/2025 10:35, Laurent Pinchart wrote:
> >>>>>>          compatible:
> >>>>>>            contains:
> >>>>>>              enum:
> >>>>>> -              - fsl,imx8qxp-mipi-csi2
> >>>>>> +              - fsl,imx8ulp-mipi-csi2
> >>>>>> +    then:
> >>>>>> +      properties:
> >>>>>> +        reg:
> >>>>>> +          minItems: 2
> >>>>>> +        resets:
> >>>>>> +          minItems: 2
> >>>>>> +          maxItems: 2
> >>>>>> +        clocks:
> >>>>>> +          minItems: 4
> >>>>>> +        clock-names:
> >>>>>> +          minItems: 4
> >>>>>
> >>>>> But according to this, the ULP version requires more clocks than the QXP
> >>>>> version.
> >>>>
> >>>> If only clock number difference, generally, it is still compatible and can
> >>>> be fallback, especialy driver use devm_bulk_clk_get_all().
> >>>
> >>> That's a driver-specific implementation decision, so I don't think it
> >>> should be taken into account to decide on compatibility.
> >>
> >> The clock inputs do not restrict compatibility. If Linux can use
> >> fallback to bind and operate properly, then it's a strong indication
> >> devices are compatible.
> >>
> >> Imagine exactly the same registers, so same programming interface, but
> >> one device takes one more clock which just needs to be enabled through
> >> its lifetime. Such devices are fully compatible, even though clock
> >> inputs differ.
> >
> > That's only the case if someone enables the clock, isn't it ? From a DT
> > binding point of view, how can we know that the extra clock will be
>
> We talk about software using the binding in this particular case. Can
> the software use fallback? Yes, it can.
>
> > enabled by a component separate from the driver (in this case by the
> > fact that the devm_bulk_clk_get_all() function gets all clocks) ?
>
> If you go that way, only 100% identical devices are compatible.
>
> >
> >> I also wanted to express exactly that case on my slides from OSSE -
> >> slide 28:
> >> https://osseu2025.sched.com/event/25Vsl/dts-101-from-roots-to-trees-aka-devicetree-for-beginners-krzysztof-kozlowski-linaro
> >
> > Quoting that slide, you wrote
> >
> > "Two devices are compatible when the new device works with Linux drivers
> > bound via fallback (old) compatible".
> >
> > That is clearly the case here for the existing *Linux* driver. But what
> > if the driver called devm_bulkd_clk_get() with a device-specific list of
> > clocks ? Or what if the same DT bindings are used on an OS that has no
> > clk_get_all() equivalent ? This is my concern with declaring those two
> > devices as compatible: they may be from the point of view of the current
> > implementation of the corresponding Linux kernel driver, but DT bindings
> > are not Linux-specific.
>
> It seems you think of compatibility as new device is compatible with old
> kernel, e.g. one not requesting that clock. We don't talk about such case.
>
> >
> > Or do DT bindings assume that drivers have to always enable all clocks
> > declared in DT, even if they don't know what those clocks are ? That
> > seems error-prone, in quite a few cases drivers need to handle separate
> > clocks in a device-specific way, with for instance a particular
> > ordering, preventing them from using devm_bulk_clk_get_all(). If all
> > drivers are required to manage all clocks declared in DT, this would get
> > messy quite quickly.
> >
> I don't really want to dive into such specifics, because it is
> impossible to create a generic rule of out. We decide here about
> programming interface mostly. Can Linux use the one from fallback-device
> to properly operate the new one? Can the same driver bind to fallback
> and operate the new device?

So my understand is correct. we should use fallback string if driver can
work with it.

Frank

>
> If you enable clock by clock for whatever reason, e.g. very specific
> programming power up sequence, then answer would be: no, Linux cannot
> use fallback because handling clocks differ.
>
> Best regards,
> Krzysztof