Move imx9*-{clock,power}.h headers into
include/dt-bindings/{clock,power}/ and fix up the DTs

Reported-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: E Shattow <e@freeshell.de>
---
 arch/arm64/boot/dts/freescale/imx94.dtsi                      | 4 ++--
 arch/arm64/boot/dts/freescale/imx95.dtsi                      | 4 ++--
 .../dts/freescale => include/dt-bindings/clock}/imx94-clock.h | 0
 .../dts/freescale => include/dt-bindings/clock}/imx95-clock.h | 0
 .../dts/freescale => include/dt-bindings/power}/imx94-power.h | 0
 .../dts/freescale => include/dt-bindings/power}/imx95-power.h | 0
 6 files changed, 4 insertions(+), 4 deletions(-)
 rename {arch/arm64/boot/dts/freescale => include/dt-bindings/clock}/imx94-clock.h (100%)
 rename {arch/arm64/boot/dts/freescale => include/dt-bindings/clock}/imx95-clock.h (100%)
 rename {arch/arm64/boot/dts/freescale => include/dt-bindings/power}/imx94-power.h (100%)
 rename {arch/arm64/boot/dts/freescale => include/dt-bindings/power}/imx95-power.h (100%)

diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index 44dee2cbd42d..1fe6ef4518a8 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -8,9 +8,9 @@
 #include <dt-bindings/input/input.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 
-#include "imx94-clock.h"
+#include <dt-bindings/clock/imx94-clock.h>
 #include "imx94-pinfunc.h"
-#include "imx94-power.h"
+#include <dt-bindings/power/imx94-power.h>
 
 / {
 	#address-cells = <2>;
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 4ca6a7ea586e..787d3f829816 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -10,9 +10,9 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/thermal/thermal.h>
 
-#include "imx95-clock.h"
+#include <dt-bindings/clock/imx95-clock.h>
 #include "imx95-pinfunc.h"
-#include "imx95-power.h"
+#include <dt-bindings/power/imx95-power.h>
 
 / {
 	interrupt-parent = <&gic>;
diff --git a/arch/arm64/boot/dts/freescale/imx94-clock.h b/include/dt-bindings/clock/imx94-clock.h
similarity index 100%
rename from arch/arm64/boot/dts/freescale/imx94-clock.h
rename to include/dt-bindings/clock/imx94-clock.h
diff --git a/arch/arm64/boot/dts/freescale/imx95-clock.h b/include/dt-bindings/clock/imx95-clock.h
similarity index 100%
rename from arch/arm64/boot/dts/freescale/imx95-clock.h
rename to include/dt-bindings/clock/imx95-clock.h
diff --git a/arch/arm64/boot/dts/freescale/imx94-power.h b/include/dt-bindings/power/imx94-power.h
similarity index 100%
rename from arch/arm64/boot/dts/freescale/imx94-power.h
rename to include/dt-bindings/power/imx94-power.h
diff --git a/arch/arm64/boot/dts/freescale/imx95-power.h b/include/dt-bindings/power/imx95-power.h
similarity index 100%
rename from arch/arm64/boot/dts/freescale/imx95-power.h
rename to include/dt-bindings/power/imx95-power.h

base-commit: 5c3b3264e5858813632031ba58bcd6e1eeb3b214
-- 
2.50.0

On 31/08/2025 22:04, E Shattow wrote:
> Move imx9*-{clock,power}.h headers into
> include/dt-bindings/{clock,power}/ and fix up the DTs

Huh? Why?

> 
> Reported-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

What sort of bug are you fixing? Nothing in commit msg explains that at all.

> Signed-off-by: E Shattow <e@freeshell.de>


Best regards,
Krzysztof

On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>Move imx9*-{clock,power}.h headers into
>include/dt-bindings/{clock,power}/ and fix up the DTs

No. The files should be under arch/arm64/boot/dts/freescale/
What issue are you trying to fix?

Regards
Peng

On 9/1/25 5:22 AM, Peng Fan wrote:
> On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>> Move imx9*-{clock,power}.h headers into
>> include/dt-bindings/{clock,power}/ and fix up the DTs
> 
> No. The files should be under arch/arm64/boot/dts/freescale/
Why ? Linux already has include/dt-bindings/clock/ and 
include/dt-bindings/power directories for exactly those headers , why 
did iMX9 suddenly start conflating them into arch/arm64/boot/dts/freescale ?

On 01/09/2025 04:22, Marek Vasut wrote:
> On 9/1/25 5:22 AM, Peng Fan wrote:
>> On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>>> Move imx9*-{clock,power}.h headers into
>>> include/dt-bindings/{clock,power}/ and fix up the DTs
>>
>> No. The files should be under arch/arm64/boot/dts/freescale/
> Why ? Linux already has include/dt-bindings/clock/ and 
> include/dt-bindings/power directories for exactly those headers , why 
> did iMX9 suddenly start conflating them into arch/arm64/boot/dts/freescale ?


Because maybe these are not bindings? Regardless whether you agree or
not, the commit should clearly explain the reason behind.


Best regards,
Krzysztof

On 9/1/25 5:33 AM, Krzysztof Kozlowski wrote:
> On 01/09/2025 04:22, Marek Vasut wrote:
>> On 9/1/25 5:22 AM, Peng Fan wrote:
>>> On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>>>> Move imx9*-{clock,power}.h headers into
>>>> include/dt-bindings/{clock,power}/ and fix up the DTs
>>>
>>> No. The files should be under arch/arm64/boot/dts/freescale/
>> Why ? Linux already has include/dt-bindings/clock/ and
>> include/dt-bindings/power directories for exactly those headers , why
>> did iMX9 suddenly start conflating them into arch/arm64/boot/dts/freescale ?
> 
> 
> Because maybe these are not bindings?

Please compare arch/arm64/boot/dts/freescale/imx95-clock.h and 
include/dt-bindings/clock/imx8mp-clock.h and clarify to me, why the 
imx95-clock.h is not bindings and the imx8mp-clock.h is bindings.

Both files list clock IDs for the clock nodes, one clock one is SCMI 
clock (iMX95), the other clock node is CCM clock (iMX8MP), and they are 
both (SCMI and CCM) clock nodes in DT. Both header files may have to be 
included in drivers, the iMX8MP headers already are, the iMX95 headers 
currently are included only in U-Boot drivers.

I really don't see the difference here, sorry.

> Regardless whether you agree or
> not, the commit should clearly explain the reason behind.
Which commit ?

On 01/09/2025 12:30, Marek Vasut wrote:
> On 9/1/25 5:33 AM, Krzysztof Kozlowski wrote:
>> On 01/09/2025 04:22, Marek Vasut wrote:
>>> On 9/1/25 5:22 AM, Peng Fan wrote:
>>>> On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>>>>> Move imx9*-{clock,power}.h headers into
>>>>> include/dt-bindings/{clock,power}/ and fix up the DTs
>>>>
>>>> No. The files should be under arch/arm64/boot/dts/freescale/
>>> Why ? Linux already has include/dt-bindings/clock/ and
>>> include/dt-bindings/power directories for exactly those headers , why
>>> did iMX9 suddenly start conflating them into arch/arm64/boot/dts/freescale ?
>>
>>
>> Because maybe these are not bindings?
> 
> Please compare arch/arm64/boot/dts/freescale/imx95-clock.h and 
> include/dt-bindings/clock/imx8mp-clock.h and clarify to me, why the 
> imx95-clock.h is not bindings and the imx8mp-clock.h is bindings.

That's uno reverse card. I do not have to prove why these are different.
You need to prove why imx95 are bindings.

> 
> Both files list clock IDs for the clock nodes, one clock one is SCMI 
> clock (iMX95), the other clock node is CCM clock (iMX8MP), and they are 

Yeah, entirely different things. Like comparing apples and oranges.

> both (SCMI and CCM) clock nodes in DT. Both header files may have to be 
> included in drivers, the iMX8MP headers already are, the iMX95 headers 

No, the SCMI cannot be used in the drivers, because these are not
abstract IDs mapping between driver and DTS.

> currently are included only in U-Boot drivers.
> 
> I really don't see the difference here, sorry.

You just pointed out difference - no usage in drivers, no ABI!

Instead of playing this "I found this code somewhere, so I can do
whatever the same" answer the first implied question - why these are
bindings? Provide arguments what do they bind.

> 
>> Regardless whether you agree or
>> not, the commit should clearly explain the reason behind.
> Which commit ?

This patch.


Best regards,
Krzysztof

On 9/1/25 12:54 PM, Krzysztof Kozlowski wrote:
> On 01/09/2025 12:30, Marek Vasut wrote:
>> On 9/1/25 5:33 AM, Krzysztof Kozlowski wrote:
>>> On 01/09/2025 04:22, Marek Vasut wrote:
>>>> On 9/1/25 5:22 AM, Peng Fan wrote:
>>>>> On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>>>>>> Move imx9*-{clock,power}.h headers into
>>>>>> include/dt-bindings/{clock,power}/ and fix up the DTs
>>>>>
>>>>> No. The files should be under arch/arm64/boot/dts/freescale/
>>>> Why ? Linux already has include/dt-bindings/clock/ and
>>>> include/dt-bindings/power directories for exactly those headers , why
>>>> did iMX9 suddenly start conflating them into arch/arm64/boot/dts/freescale ?
>>>
>>>
>>> Because maybe these are not bindings?
>>
>> Please compare arch/arm64/boot/dts/freescale/imx95-clock.h and
>> include/dt-bindings/clock/imx8mp-clock.h and clarify to me, why the
>> imx95-clock.h is not bindings and the imx8mp-clock.h is bindings.
> 
> That's uno reverse card. I do not have to prove why these are different.
> You need to prove why imx95 are bindings.
> 
>>
>> Both files list clock IDs for the clock nodes, one clock one is SCMI
>> clock (iMX95), the other clock node is CCM clock (iMX8MP), and they are
> 
> Yeah, entirely different things. Like comparing apples and oranges.
> 
>> both (SCMI and CCM) clock nodes in DT. Both header files may have to be
>> included in drivers, the iMX8MP headers already are, the iMX95 headers
> 
> No, the SCMI cannot be used in the drivers, because these are not
> abstract IDs mapping between driver and DTS.

The SCMI clock protocol on iMX9 uses fixed clock IDs (the ones in 
imx95-clock.h), just like the iMX CCM clock driver uses fixed clock IDs 
(the ones in imx8mp-clock.h).

Where does the "SCMI cannot be used in the drivers" come from ? Can you 
elaborate on this part ?

>> currently are included only in U-Boot drivers.
>>
>> I really don't see the difference here, sorry.
> 
> You just pointed out difference - no usage in drivers, no ABI!

Surely at least the SCMI clock protocol clock driver does use those SCMI 
clock IDs , so that is "yes usage in drivers" ?

Also, the SCMI clock protocol clock IDs are being used in U-Boot 
drivers, which does make those IDs an ABI .

> Instead of playing this "I found this code somewhere, so I can do
> whatever the same" answer the first implied question - why these are
> bindings? Provide arguments what do they bind.

I am not sure how to answer this, but what I can write is, that if I 
scramble these IDs in either the DT or the firmware (which provides the 
SCMI clock service), then the system cannot work. I am not sure if this 
is the answer you are looking for.

On Tue, Sep 02, 2025 at 01:32:38AM +0200, Marek Vasut wrote:
[snip]
> Instead of playing this "I found this code somewhere, so I can do
>> whatever the same" answer the first implied question - why these are
>> bindings? Provide arguments what do they bind.
>
>I am not sure how to answer this, but what I can write is, that if I scramble
>these IDs in either the DT or the firmware (which provides the SCMI clock
>service), then the system cannot work. I am not sure if this is the answer
>you are looking for.

Marek,
  Some U-Boot code indeed directly use the IDs to configure the clock without
  relying on any drivers. Since the SCMI IDs could not be moved to dt-bindings,
  the possible method to do in U-Boot is to duplicate a copy of the file,
  and highlight this files should be aligned with the ones under
  dts/upstream/src/arm64/freescale/imx95-*.h.

Regards
Peng

On 9/4/25 11:34 AM, Peng Fan wrote:

Hi,

sorry for my late reply.

>> Instead of playing this "I found this code somewhere, so I can do
>>> whatever the same" answer the first implied question - why these are
>>> bindings? Provide arguments what do they bind.
>>
>> I am not sure how to answer this, but what I can write is, that if I scramble
>> these IDs in either the DT or the firmware (which provides the SCMI clock
>> service), then the system cannot work. I am not sure if this is the answer
>> you are looking for.
> 
> Marek,
>    Some U-Boot code indeed directly use the IDs to configure the clock without
>    relying on any drivers. Since the SCMI IDs could not be moved to dt-bindings,

Why can they not be moved to DT bindings ?

They are part of the ABI.

This is the part I do not understand, the SCMI IDs are no different than 
any other clock IDs used in DT, is that not so ?

>    the possible method to do in U-Boot is to duplicate a copy of the file,

No.

On 9/1/25 03:54, Krzysztof Kozlowski wrote:
> On 01/09/2025 12:30, Marek Vasut wrote:
>> On 9/1/25 5:33 AM, Krzysztof Kozlowski wrote:
>>> On 01/09/2025 04:22, Marek Vasut wrote:
>>>> On 9/1/25 5:22 AM, Peng Fan wrote:
>>>>> On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>>>>>> Move imx9*-{clock,power}.h headers into
>>>>>> include/dt-bindings/{clock,power}/ and fix up the DTs
>>>>>
>>>>> No. The files should be under arch/arm64/boot/dts/freescale/
>>>> Why ? Linux already has include/dt-bindings/clock/ and
>>>> include/dt-bindings/power directories for exactly those headers , why
>>>> did iMX9 suddenly start conflating them into arch/arm64/boot/dts/freescale ?
>>>
>>>
>>> Because maybe these are not bindings?
>>
>> Please compare arch/arm64/boot/dts/freescale/imx95-clock.h and 
>> include/dt-bindings/clock/imx8mp-clock.h and clarify to me, why the 
>> imx95-clock.h is not bindings and the imx8mp-clock.h is bindings.
> 
> That's uno reverse card. I do not have to prove why these are different.
> You need to prove why imx95 are bindings.
> 
>>
>> Both files list clock IDs for the clock nodes, one clock one is SCMI 
>> clock (iMX95), the other clock node is CCM clock (iMX8MP), and they are 
> 
> Yeah, entirely different things. Like comparing apples and oranges.
> 
>> both (SCMI and CCM) clock nodes in DT. Both header files may have to be 
>> included in drivers, the iMX8MP headers already are, the iMX95 headers 
> 
> No, the SCMI cannot be used in the drivers, because these are not
> abstract IDs mapping between driver and DTS.
> 
>> currently are included only in U-Boot drivers.
>>
>> I really don't see the difference here, sorry.
> 
> You just pointed out difference - no usage in drivers, no ABI!
> 
> Instead of playing this "I found this code somewhere, so I can do
> whatever the same" answer the first implied question - why these are
> bindings? Provide arguments what do they bind.
> 
>>
>>> Regardless whether you agree or
>>> not, the commit should clearly explain the reason behind.
>> Which commit ?
> 
> This patch.
> 
> 
> Best regards,
> Krzysztof

Providing some clarification, the user of this (in U-Boot) via
devicetree-rebasing leads to some path gymnastics:

(U-Boot code base) arch/arm/mach-imx/imx9/scmi/clock.c:9:#include
"../../../../../dts/upstream/src/arm64/freescale/imx95-clock.h"

Compared to the patterns of what else is going on I would guess this
should instead be:

#include <dt-bindings/clock/imx95-clock.h>

which agrees with how it is done for all the other closely similar build
targets and is less fragile in that build context (although you may not
be interested in this since it's not Linux kernel code base). Ideally
I'm trying to make U-Boot flexible to build against different locations
of devicetree-rebasing or perhaps Linux kernel source tree. This is a
"one thing is not like the others" moment and it was suggested I send a
patch.

Whatever is best I'm open to improve the commit message, or take what
you think ought to be fixed in U-Boot there to improve.

What do we expect users of devicetree-rebasing to do, then?

Thanks,

E Shattow

On 01/09/2025 13:07, E Shattow wrote:
> 
> 
> On 9/1/25 03:54, Krzysztof Kozlowski wrote:
>> On 01/09/2025 12:30, Marek Vasut wrote:
>>> On 9/1/25 5:33 AM, Krzysztof Kozlowski wrote:
>>>> On 01/09/2025 04:22, Marek Vasut wrote:
>>>>> On 9/1/25 5:22 AM, Peng Fan wrote:
>>>>>> On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>>>>>>> Move imx9*-{clock,power}.h headers into
>>>>>>> include/dt-bindings/{clock,power}/ and fix up the DTs
>>>>>>
>>>>>> No. The files should be under arch/arm64/boot/dts/freescale/
>>>>> Why ? Linux already has include/dt-bindings/clock/ and
>>>>> include/dt-bindings/power directories for exactly those headers , why
>>>>> did iMX9 suddenly start conflating them into arch/arm64/boot/dts/freescale ?
>>>>
>>>>
>>>> Because maybe these are not bindings?
>>>
>>> Please compare arch/arm64/boot/dts/freescale/imx95-clock.h and 
>>> include/dt-bindings/clock/imx8mp-clock.h and clarify to me, why the 
>>> imx95-clock.h is not bindings and the imx8mp-clock.h is bindings.
>>
>> That's uno reverse card. I do not have to prove why these are different.
>> You need to prove why imx95 are bindings.
>>
>>>
>>> Both files list clock IDs for the clock nodes, one clock one is SCMI 
>>> clock (iMX95), the other clock node is CCM clock (iMX8MP), and they are 
>>
>> Yeah, entirely different things. Like comparing apples and oranges.
>>
>>> both (SCMI and CCM) clock nodes in DT. Both header files may have to be 
>>> included in drivers, the iMX8MP headers already are, the iMX95 headers 
>>
>> No, the SCMI cannot be used in the drivers, because these are not
>> abstract IDs mapping between driver and DTS.
>>
>>> currently are included only in U-Boot drivers.
>>>
>>> I really don't see the difference here, sorry.
>>
>> You just pointed out difference - no usage in drivers, no ABI!
>>
>> Instead of playing this "I found this code somewhere, so I can do
>> whatever the same" answer the first implied question - why these are
>> bindings? Provide arguments what do they bind.
>>
>>>
>>>> Regardless whether you agree or
>>>> not, the commit should clearly explain the reason behind.
>>> Which commit ?
>>
>> This patch.
>>
>>
>> Best regards,
>> Krzysztof
> 
> Providing some clarification, the user of this (in U-Boot) via
> devicetree-rebasing leads to some path gymnastics:
> 
> (U-Boot code base) arch/arm/mach-imx/imx9/scmi/clock.c:9:#include
> "../../../../../dts/upstream/src/arm64/freescale/imx95-clock.h"

Why nothing like this was described in the commit msg? We really do not
need lengthy discussions to discover the basic needs why patch is being
sent.

Anyway, U-boot driver requesting clocks in C code not via DTS is the
culprit here and not necessarily right approach.

> 
> Compared to the patterns of what else is going on I would guess this
> should instead be:
> 
> #include <dt-bindings/clock/imx95-clock.h>
> 
> which agrees with how it is done for all the other closely similar build
> targets and is less fragile in that build context (although you may not
> be interested in this since it's not Linux kernel code base). Ideally
> I'm trying to make U-Boot flexible to build against different locations
> of devicetree-rebasing or perhaps Linux kernel source tree. This is a
> "one thing is not like the others" moment and it was suggested I send a
> patch.

Why instead not fixing U-boot and not taking these via DT property, like
every other case? see include/clk.h for the API.

> 
> Whatever is best I'm open to improve the commit message, or take what
> you think ought to be fixed in U-Boot there to improve.

You should rather align with other U-boot maintainers and contributors
how clock consumers should be written. Proposed patches depend on that
outcome. If you just ask me, then I am telling you the same - requesting
clocks by consumers should be via DT, not via C code. Someone just added
ABI for driver consumers, not even providers...

Best regards,
Krzysztof