The CSI-2 receiver in the i.MX8ULP is almost identical to the version
present in the i.MX8QXP/QM, but i.MX8ULP CSI-2 controller needs pclk
clock as the input clock for its APB interface of Control and Status
register(CSR). So add compatible string fsl,imx8ulp-mipi-csi2 and
increase maxItems of Clocks (clock-names) to 4 from 3. And keep the
same restriction for existed compatible.
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
---
.../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 46 ++++++++++++++++++++--
1 file changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
index 3389bab266a9adbda313c8ad795b998641df12f3..412cedddb0efee1a49d1b90b02baa7a625c797ec 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
@@ -21,7 +21,9 @@ properties:
- fsl,imx8mq-mipi-csi2
- fsl,imx8qxp-mipi-csi2
- items:
- - const: fsl,imx8qm-mipi-csi2
+ - enum:
+ - fsl,imx8qm-mipi-csi2
+ - fsl,imx8ulp-mipi-csi2
- const: fsl,imx8qxp-mipi-csi2
reg:
@@ -39,12 +41,16 @@ properties:
clock that the RX DPHY receives.
- description: ui is the pixel clock (phy_ref up to 333Mhz).
See the reference manual for details.
+ - description: pclk is clock for csr APB interface.
+ minItems: 3
clock-names:
items:
- const: core
- const: esc
- const: ui
+ - const: pclk
+ minItems: 3
power-domains:
maxItems: 1
@@ -130,19 +136,53 @@ allOf:
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
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-mipi-csi2
+ const: fsl,imx8qxp-mipi-csi2
then:
properties:
reg:
minItems: 2
resets:
maxItems: 1
- else:
+ clocks:
+ maxItems: 3
+ clock-names:
+ maxItems: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mq-mipi-csi2
+ then:
properties:
reg:
maxItems: 1
resets:
minItems: 3
+ clocks:
+ maxItems: 3
+ clock-names:
+ maxItems: 3
required:
- fsl,mipi-phy-gpr
--
2.34.1Hi Guoniu,
Thank you for the patch.
On Mon, Sep 01, 2025 at 02:25:29PM +0800, Guoniu Zhou wrote:
> The CSI-2 receiver in the i.MX8ULP is almost identical to the version
> present in the i.MX8QXP/QM, but i.MX8ULP CSI-2 controller needs pclk
> clock as the input clock for its APB interface of Control and Status
> register(CSR). So add compatible string fsl,imx8ulp-mipi-csi2 and
> increase maxItems of Clocks (clock-names) to 4 from 3. And keep the
> same restriction for existed compatible.
s/existed/existing/
> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> ---
> .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 46 ++++++++++++++++++++--
> 1 file changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
> index 3389bab266a9adbda313c8ad795b998641df12f3..412cedddb0efee1a49d1b90b02baa7a625c797ec 100644
> --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
> +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
> @@ -21,7 +21,9 @@ properties:
> - fsl,imx8mq-mipi-csi2
> - fsl,imx8qxp-mipi-csi2
> - items:
> - - const: fsl,imx8qm-mipi-csi2
> + - enum:
> + - fsl,imx8qm-mipi-csi2
> + - fsl,imx8ulp-mipi-csi2
> - const: fsl,imx8qxp-mipi-csi2
According to this, the ULP version is compatible with the QXP version.
>
> reg:
> @@ -39,12 +41,16 @@ properties:
> clock that the RX DPHY receives.
> - description: ui is the pixel clock (phy_ref up to 333Mhz).
> See the reference manual for details.
> + - description: pclk is clock for csr APB interface.
> + minItems: 3
>
> clock-names:
> items:
> - const: core
> - const: esc
> - const: ui
> + - const: pclk
> + minItems: 3
>
> power-domains:
> maxItems: 1
> @@ -130,19 +136,53 @@ allOf:
> 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:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - fsl,imx8qm-mipi-csi2
QM is compatible with the QXP, so you don't need to list it here.
contains:
const: fsl,imx8qxp-mipi-csi2
is enough to cover both.
> + const: fsl,imx8qxp-mipi-csi2
> then:
> properties:
> reg:
> minItems: 2
> resets:
> maxItems: 1
> - else:
> + clocks:
> + maxItems: 3
> + clock-names:
> + maxItems: 3
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - fsl,imx8mq-mipi-csi2
> + then:
> properties:
> reg:
> maxItems: 1
> resets:
> minItems: 3
> + clocks:
> + maxItems: 3
> + clock-names:
> + maxItems: 3
> required:
> - fsl,mipi-phy-gpr
>
--
Regards,
Laurent Pinchart
On Mon, Sep 01, 2025 at 05:46:10PM +0200, Laurent Pinchart wrote: > Hi Guoniu, > > Thank you for the patch. > > On Mon, Sep 01, 2025 at 02:25:29PM +0800, Guoniu Zhou wrote: > > The CSI-2 receiver in the i.MX8ULP is almost identical to the version > > present in the i.MX8QXP/QM, but i.MX8ULP CSI-2 controller needs pclk > > clock as the input clock for its APB interface of Control and Status > > register(CSR). So add compatible string fsl,imx8ulp-mipi-csi2 and > > increase maxItems of Clocks (clock-names) to 4 from 3. And keep the > > same restriction for existed compatible. > > s/existed/existing/ > > > Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> > > --- > > .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 46 ++++++++++++++++++++-- > > 1 file changed, 43 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > index 3389bab266a9adbda313c8ad795b998641df12f3..412cedddb0efee1a49d1b90b02baa7a625c797ec 100644 > > --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > @@ -21,7 +21,9 @@ properties: > > - fsl,imx8mq-mipi-csi2 > > - fsl,imx8qxp-mipi-csi2 > > - items: > > - - const: fsl,imx8qm-mipi-csi2 > > + - enum: > > + - fsl,imx8qm-mipi-csi2 > > + - fsl,imx8ulp-mipi-csi2 > > - const: fsl,imx8qxp-mipi-csi2 > > According to this, the ULP version is compatible with the QXP version. > > > > > reg: > > @@ -39,12 +41,16 @@ properties: > > clock that the RX DPHY receives. > > - description: ui is the pixel clock (phy_ref up to 333Mhz). > > See the reference manual for details. > > + - description: pclk is clock for csr APB interface. > > + minItems: 3 > > > > clock-names: > > items: > > - const: core > > - const: esc > > - const: ui > > + - const: pclk > > + minItems: 3 > > > > power-domains: > > maxItems: 1 > > @@ -130,19 +136,53 @@ allOf: > > 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(). If driver have not sperated drvdata for it, we can fallback to it. It is quite common. Frank > > > + > > + - if: > > + properties: > > + compatible: > > + contains: > > + enum: > > + - fsl,imx8qm-mipi-csi2 > > QM is compatible with the QXP, so you don't need to list it here. > > contains: > const: fsl,imx8qxp-mipi-csi2 > > is enough to cover both. > > > + const: fsl,imx8qxp-mipi-csi2 > > then: > > properties: > > reg: > > minItems: 2 > > resets: > > maxItems: 1 > > - else: > > + clocks: > > + maxItems: 3 > > + clock-names: > > + maxItems: 3 > > + > > + - if: > > + properties: > > + compatible: > > + contains: > > + enum: > > + - fsl,imx8mq-mipi-csi2 > > + then: > > properties: > > reg: > > maxItems: 1 > > resets: > > minItems: 3 > > + clocks: > > + maxItems: 3 > > + clock-names: > > + maxItems: 3 > > required: > > - fsl,mipi-phy-gpr > > > > -- > Regards, > > Laurent Pinchart
On Mon, Sep 01, 2025 at 09:45:39PM -0400, Frank Li wrote: > On Mon, Sep 01, 2025 at 05:46:10PM +0200, Laurent Pinchart wrote: > > On Mon, Sep 01, 2025 at 02:25:29PM +0800, Guoniu Zhou wrote: > > > The CSI-2 receiver in the i.MX8ULP is almost identical to the version > > > present in the i.MX8QXP/QM, but i.MX8ULP CSI-2 controller needs pclk > > > clock as the input clock for its APB interface of Control and Status > > > register(CSR). So add compatible string fsl,imx8ulp-mipi-csi2 and > > > increase maxItems of Clocks (clock-names) to 4 from 3. And keep the > > > same restriction for existed compatible. > > > > s/existed/existing/ > > > > > Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> > > > --- > > > .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 46 ++++++++++++++++++++-- > > > 1 file changed, 43 insertions(+), 3 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > > index 3389bab266a9adbda313c8ad795b998641df12f3..412cedddb0efee1a49d1b90b02baa7a625c797ec 100644 > > > --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > > +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > > @@ -21,7 +21,9 @@ properties: > > > - fsl,imx8mq-mipi-csi2 > > > - fsl,imx8qxp-mipi-csi2 > > > - items: > > > - - const: fsl,imx8qm-mipi-csi2 > > > + - enum: > > > + - fsl,imx8qm-mipi-csi2 > > > + - fsl,imx8ulp-mipi-csi2 > > > - const: fsl,imx8qxp-mipi-csi2 > > > > According to this, the ULP version is compatible with the QXP version. > > > > > > > > reg: > > > @@ -39,12 +41,16 @@ properties: > > > clock that the RX DPHY receives. > > > - description: ui is the pixel clock (phy_ref up to 333Mhz). > > > See the reference manual for details. > > > + - description: pclk is clock for csr APB interface. > > > + minItems: 3 > > > > > > clock-names: > > > items: > > > - const: core > > > - const: esc > > > - const: ui > > > + - const: pclk > > > + minItems: 3 > > > > > > power-domains: > > > maxItems: 1 > > > @@ -130,19 +136,53 @@ allOf: > > > 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. > If driver have not sperated drvdata for it, we can fallback to it. It is > quite common. > > > > + > > > + - if: > > > + properties: > > > + compatible: > > > + contains: > > > + enum: > > > + - fsl,imx8qm-mipi-csi2 > > > > QM is compatible with the QXP, so you don't need to list it here. > > > > contains: > > const: fsl,imx8qxp-mipi-csi2 > > > > is enough to cover both. > > > > > + const: fsl,imx8qxp-mipi-csi2 > > > then: > > > properties: > > > reg: > > > minItems: 2 > > > resets: > > > maxItems: 1 > > > - else: > > > + clocks: > > > + maxItems: 3 > > > + clock-names: > > > + maxItems: 3 > > > + > > > + - if: > > > + properties: > > > + compatible: > > > + contains: > > > + enum: > > > + - fsl,imx8mq-mipi-csi2 > > > + then: > > > properties: > > > reg: > > > maxItems: 1 > > > resets: > > > minItems: 3 > > > + clocks: > > > + maxItems: 3 > > > + clock-names: > > > + maxItems: 3 > > > required: > > > - fsl,mipi-phy-gpr > > > -- Regards, Laurent Pinchart
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. 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 (although I focused on reversed case when devices are not compatible, because that is decisive case). Best regards, Krzysztof
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 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) ? > 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. 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. > (although I focused on reversed case when devices are not compatible, > because that is decisive case). -- Regards, Laurent Pinchart
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? 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
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. The Linux kernel driver, in its current implementation, can, yes. No disagreement about that. > > 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. No no, I'm considering compatibility in the same sense as you. Sorry if that wasn't clear. > > 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're on the same page there :-) Compatible strings model compatibility with software. As DT bindings are not OS-specific, they should be designed based on the concept of a driver, and not on a particular driver implementation. As a conceptual generic driver can't be precisely defined, we will always have edge cases. In this specific case, I think that devm_bulk_clk_get_all() is too much of a Linux-specific concept to consider that devices with different clocks are compatible. Even considering Linux only, a driver that needs to handle at least one of the clocks in a particular way (for instance to guarantee a device-specific clock sequencing requirement, or to retrieve or set the frequency of a particular clock) will need to get clocks by their names, making fully generic handling of all clocks not possible. For such drivers, difference in clocks will preclude considering two devices as compatible. As this is somewhat of an edge case someone will need to make a decision, and I won't fight tooth and nail over it. > 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? > > 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. -- Regards, Laurent Pinchart
On Wed, Sep 03, 2025 at 09:21:43PM +0200, Laurent Pinchart wrote: > 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. > > The Linux kernel driver, in its current implementation, can, yes. No > disagreement about that. > > > > 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. > > No no, I'm considering compatibility in the same sense as you. Sorry if > that wasn't clear. > > > > 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're on the same page there :-) > > Compatible strings model compatibility with software. As DT bindings are > not OS-specific, they should be designed based on the concept of a > driver, and not on a particular driver implementation. As a conceptual > generic driver can't be precisely defined, we will always have edge > cases. > > In this specific case, I think that devm_bulk_clk_get_all() is too much > of a Linux-specific concept to consider that devices with different > clocks are compatible. Even considering Linux only, a driver that needs > to handle at least one of the clocks in a particular way (for instance > to guarantee a device-specific clock sequencing requirement, or to > retrieve or set the frequency of a particular clock) will need to get > clocks by their names, making fully generic handling of all clocks not > possible. New added clocks is simple clock, needn't specific handler. Only need enable at runtime resume. Back compatible is hard to decouple with driver's implement 100%. Compatible string C1 have clock A, B, C Compatible string C2 have clock A, B, C, D, E, F A, B, C is common for both C1 and C2, which need special handle. D, E, F is simple enable at probe or runtime resume. Can C1 be back compatible C2 (assume all the same except only D, E, F clock difference)? It is always depend on drivers' implemment. Add back compatible have NOT bad impact for drivers and bindings. Although back compatible "C1", "C2", driver still use can use C1 firstly to do special process. > For such drivers, difference in clocks will preclude > considering two devices as compatible. > > As this is somewhat of an edge case someone will need to make a > decision, and I won't fight tooth and nail over it. Agree. Need a guide line. My opinion is back compatible if there are no new drvdata (pltdata) in drivers. Needn't back compatible if need add new item in drvdata(pltdata) in drivers. Frank > > > 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? > > > > 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. > > -- > Regards, > > Laurent Pinchart
On Thu, Sep 04, 2025 at 10:49:48AM -0400, Frank Li wrote: > On Wed, Sep 03, 2025 at 09:21:43PM +0200, Laurent Pinchart wrote: > > 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. > > > > The Linux kernel driver, in its current implementation, can, yes. No > > disagreement about that. > > > > > > 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. > > > > No no, I'm considering compatibility in the same sense as you. Sorry if > > that wasn't clear. > > > > > > 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're on the same page there :-) > > > > Compatible strings model compatibility with software. As DT bindings are > > not OS-specific, they should be designed based on the concept of a > > driver, and not on a particular driver implementation. As a conceptual > > generic driver can't be precisely defined, we will always have edge > > cases. > > > > In this specific case, I think that devm_bulk_clk_get_all() is too much > > of a Linux-specific concept to consider that devices with different > > clocks are compatible. Even considering Linux only, a driver that needs > > to handle at least one of the clocks in a particular way (for instance > > to guarantee a device-specific clock sequencing requirement, or to > > retrieve or set the frequency of a particular clock) will need to get > > clocks by their names, making fully generic handling of all clocks not > > possible. > > New added clocks is simple clock, needn't specific handler. Only need > enable at runtime resume. > > Back compatible is hard to decouple with driver's implement 100%. > > Compatible string C1 have clock A, B, C > Compatible string C2 have clock A, B, C, D, E, F > > A, B, C is common for both C1 and C2, which need special handle. > D, E, F is simple enable at probe or runtime resume. I think it would only be backwards compatible if clocks D, E, and F were entirely optional and could be left unmanaged. > > Can C1 be back compatible C2 (assume all the same except only D, E, F > clock difference)? It is always depend on drivers' implemment. > > Add back compatible have NOT bad impact for drivers and bindings. Although > back compatible "C1", "C2", driver still use can use C1 firstly to do > special process. > > > > For such drivers, difference in clocks will preclude > > considering two devices as compatible. > > > > As this is somewhat of an edge case someone will need to make a > > decision, and I won't fight tooth and nail over it. > > Agree. Need a guide line. My opinion is > > back compatible if there are no new drvdata (pltdata) in drivers. > Needn't back compatible if need add new item in drvdata(pltdata) in drivers. That's a good indication, but not 100%. If the chip overall needs kernel changes anyways, then backwards compatibility for 1 block doesn't really matter so much other than 1 less patch. Rob
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
On Tue, Sep 02, 2025 at 10:35:54AM +0200, Laurent Pinchart wrote: > On Mon, Sep 01, 2025 at 09:45:39PM -0400, Frank Li wrote: > > On Mon, Sep 01, 2025 at 05:46:10PM +0200, Laurent Pinchart wrote: > > > On Mon, Sep 01, 2025 at 02:25:29PM +0800, Guoniu Zhou wrote: > > > > The CSI-2 receiver in the i.MX8ULP is almost identical to the version > > > > present in the i.MX8QXP/QM, but i.MX8ULP CSI-2 controller needs pclk > > > > clock as the input clock for its APB interface of Control and Status > > > > register(CSR). So add compatible string fsl,imx8ulp-mipi-csi2 and > > > > increase maxItems of Clocks (clock-names) to 4 from 3. And keep the > > > > same restriction for existed compatible. > > > > > > s/existed/existing/ > > > > > > > Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> > > > > --- > > > > .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 46 ++++++++++++++++++++-- > > > > 1 file changed, 43 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > > > index 3389bab266a9adbda313c8ad795b998641df12f3..412cedddb0efee1a49d1b90b02baa7a625c797ec 100644 > > > > --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > > > +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml > > > > @@ -21,7 +21,9 @@ properties: > > > > - fsl,imx8mq-mipi-csi2 > > > > - fsl,imx8qxp-mipi-csi2 > > > > - items: > > > > - - const: fsl,imx8qm-mipi-csi2 > > > > + - enum: > > > > + - fsl,imx8qm-mipi-csi2 > > > > + - fsl,imx8ulp-mipi-csi2 > > > > - const: fsl,imx8qxp-mipi-csi2 > > > > > > According to this, the ULP version is compatible with the QXP version. > > > > > > > > > > > reg: > > > > @@ -39,12 +41,16 @@ properties: > > > > clock that the RX DPHY receives. > > > > - description: ui is the pixel clock (phy_ref up to 333Mhz). > > > > See the reference manual for details. > > > > + - description: pclk is clock for csr APB interface. > > > > + minItems: 3 > > > > > > > > clock-names: > > > > items: > > > > - const: core > > > > - const: esc > > > > - const: ui > > > > + - const: pclk > > > > + minItems: 3 > > > > > > > > power-domains: > > > > maxItems: 1 > > > > @@ -130,19 +136,53 @@ allOf: > > > > 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. It is easy to follow to decide if fallback to existing compatible string. If driver can work with fallback string for new compatible string, we can add it as fallback string. Use fallback string don't affect ABI if we find new feature or bugs need handle specific in drivers. Anyways, at other binding review, most only clk number difference can treat as back compatible string. Frank > > > If driver have not sperated drvdata for it, we can fallback to it. It is > > quite common. > > > > > > + > > > > + - if: > > > > + properties: > > > > + compatible: > > > > + contains: > > > > + enum: > > > > + - fsl,imx8qm-mipi-csi2 > > > > > > QM is compatible with the QXP, so you don't need to list it here. > > > > > > contains: > > > const: fsl,imx8qxp-mipi-csi2 > > > > > > is enough to cover both. > > > > > > > + const: fsl,imx8qxp-mipi-csi2 > > > > then: > > > > properties: > > > > reg: > > > > minItems: 2 > > > > resets: > > > > maxItems: 1 > > > > - else: > > > > + clocks: > > > > + maxItems: 3 > > > > + clock-names: > > > > + maxItems: 3 > > > > + > > > > + - if: > > > > + properties: > > > > + compatible: > > > > + contains: > > > > + enum: > > > > + - fsl,imx8mq-mipi-csi2 > > > > + then: > > > > properties: > > > > reg: > > > > maxItems: 1 > > > > resets: > > > > minItems: 3 > > > > + clocks: > > > > + maxItems: 3 > > > > + clock-names: > > > > + maxItems: 3 > > > > required: > > > > - fsl,mipi-phy-gpr > > > > > > -- > Regards, > > Laurent Pinchart
© 2016 - 2025 Red Hat, Inc.