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

On Tue, Sep 02, 2025 at 05:53:39PM +0200, Krzysztof Kozlowski wrote:

On 02/09/2025 14:35, Laurent Pinchart wrote:

quoted

On Tue, Sep 02, 2025 at 02:26:53PM +0200, Krzysztof Kozlowski wrote:

quoted

On 02/09/2025 10:35, Laurent Pinchart wrote:

quoted

quoted

quoted

quoted

         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.

quoted

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.

quoted

quoted

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.

quoted

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