The imx8m-clock.yaml binding covers the clock controller inside all
of the i.MX8M Q/M/N/P SoCs. All of them have in common that they
support two operating modes: nominal and overdrive mode.
While the overdrive mode allows for higher frequencies for many IPs,
the nominal mode needs a lower SoC voltage, thereby reducing
heat generation and power usage.
In any case, software should respect the maximum clock rate limits
described in the datasheet for each of the two operating modes.
To allow device tree consumers to enforce these limits, document two new
optional properties that can be used to sanity check the clock tree.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
Documentation/devicetree/bindings/clock/imx8m-clock.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
index c643d4a81478..a6ae5257ef53 100644
--- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
@@ -43,6 +43,14 @@ properties:
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h
for the full list of i.MX8M clock IDs.
+ fsl,nominal-mode:
+ description: Set if SoC is operated in nominal mode
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ fsl,overdrive-mode:
+ description: Set if SoC is operated in overdrive mode
+ $ref: /schemas/types.yaml#/definitions/flag
+
required:
- compatible
- reg
@@ -95,6 +103,12 @@ allOf:
- const: clk_ext2
- const: clk_ext3
- const: clk_ext4
+ - if:
+ required:
+ - fsl,overdrive-mode
+ then:
+ properties:
+ fsl,nominal-mode: false
additionalProperties: false
--
2.39.5On Thu, Dec 19, 2024 at 08:27:32AM +0100, Ahmad Fatoum wrote: > The imx8m-clock.yaml binding covers the clock controller inside all > of the i.MX8M Q/M/N/P SoCs. All of them have in common that they > support two operating modes: nominal and overdrive mode. This implies that only the two modes you mention are possible, but you leave the option open to a dts author to use either. How come? Makes it seem like we only need one of these, for whatever the non-default option is? > > While the overdrive mode allows for higher frequencies for many IPs, > the nominal mode needs a lower SoC voltage, thereby reducing > heat generation and power usage. > > In any case, software should respect the maximum clock rate limits > described in the datasheet for each of the two operating modes. > > To allow device tree consumers to enforce these limits, document two new > optional properties that can be used to sanity check the clock tree. > > Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> > --- > Documentation/devicetree/bindings/clock/imx8m-clock.yaml | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml > index c643d4a81478..a6ae5257ef53 100644 > --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml > +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml > @@ -43,6 +43,14 @@ properties: > ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h > for the full list of i.MX8M clock IDs. > > + fsl,nominal-mode: > + description: Set if SoC is operated in nominal mode > + $ref: /schemas/types.yaml#/definitions/flag > + > + fsl,overdrive-mode: > + description: Set if SoC is operated in overdrive mode > + $ref: /schemas/types.yaml#/definitions/flag > + > required: > - compatible > - reg > @@ -95,6 +103,12 @@ allOf: > - const: clk_ext2 > - const: clk_ext3 > - const: clk_ext4 > + - if: > + required: > + - fsl,overdrive-mode > + then: > + properties: > + fsl,nominal-mode: false > > additionalProperties: false > > > -- > 2.39.5 >
Hello Conor, On 19.12.24 20:49, Conor Dooley wrote: > On Thu, Dec 19, 2024 at 08:27:32AM +0100, Ahmad Fatoum wrote: >> The imx8m-clock.yaml binding covers the clock controller inside all >> of the i.MX8M Q/M/N/P SoCs. All of them have in common that they >> support two operating modes: nominal and overdrive mode. > > This implies that only the two modes you mention are possible, but you > leave the option open to a dts author to use either. How come? > > Makes it seem like we only need one of these, for whatever the > non-default option is? There is no real default. The mode is configured implicitly by the bootloader setting VDD_SOC and then kernel needs to adhere to the limits that imposes. For i.MX8M Mini and Nano, the kernel SoC DTSIs has assigned-clock-rates that are all achievable in nominal mode. For i.MX8MP, there are some rates only validated for overdrive mode. But even for the i.MX8M Mini/Nano boards, we don't know what rates they may configure at runtime, so it's not possible to infer from just the device tree what the mode is, which is why I need to allow for absence of either property. I can make it a single property with two possible values though if that's preferable. Theoretically, we could infer mode at runtime from VDD_SOC voltage, but we need to set up clocks to read out the PMIC and I want to apply the constraints as early as possible as I don't want the SoC to run outside of spec even for a short while. Thanks, Ahmad > >> >> While the overdrive mode allows for higher frequencies for many IPs, >> the nominal mode needs a lower SoC voltage, thereby reducing >> heat generation and power usage. >> >> In any case, software should respect the maximum clock rate limits >> described in the datasheet for each of the two operating modes. >> >> To allow device tree consumers to enforce these limits, document two new >> optional properties that can be used to sanity check the clock tree. >> >> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> >> --- >> Documentation/devicetree/bindings/clock/imx8m-clock.yaml | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml >> index c643d4a81478..a6ae5257ef53 100644 >> --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml >> +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml >> @@ -43,6 +43,14 @@ properties: >> ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h >> for the full list of i.MX8M clock IDs. >> >> + fsl,nominal-mode: >> + description: Set if SoC is operated in nominal mode >> + $ref: /schemas/types.yaml#/definitions/flag >> + >> + fsl,overdrive-mode: >> + description: Set if SoC is operated in overdrive mode >> + $ref: /schemas/types.yaml#/definitions/flag >> + >> required: >> - compatible >> - reg >> @@ -95,6 +103,12 @@ allOf: >> - const: clk_ext2 >> - const: clk_ext3 >> - const: clk_ext4 >> + - if: >> + required: >> + - fsl,overdrive-mode >> + then: >> + properties: >> + fsl,nominal-mode: false >> >> additionalProperties: false >> >> >> -- >> 2.39.5 >> -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Thu, Dec 19, 2024 at 09:14:10PM +0100, Ahmad Fatoum wrote: > Hello Conor, > > On 19.12.24 20:49, Conor Dooley wrote: > > On Thu, Dec 19, 2024 at 08:27:32AM +0100, Ahmad Fatoum wrote: > >> The imx8m-clock.yaml binding covers the clock controller inside all > >> of the i.MX8M Q/M/N/P SoCs. All of them have in common that they > >> support two operating modes: nominal and overdrive mode. > > > > This implies that only the two modes you mention are possible, but you > > leave the option open to a dts author to use either. How come? > > > > Makes it seem like we only need one of these, for whatever the > > non-default option is? > > There is no real default. The mode is configured implicitly by the > bootloader setting VDD_SOC and then kernel needs to adhere to the > limits that imposes. > > For i.MX8M Mini and Nano, the kernel SoC DTSIs has assigned-clock-rates > that are all achievable in nominal mode. For i.MX8MP, there are some > rates only validated for overdrive mode. > > But even for the i.MX8M Mini/Nano boards, we don't know what rates they > may configure at runtime, so it's not possible to infer from just the > device tree what the mode is, which is why I need to allow for absence > of either property. I can make it a single property with two possible > values though if that's preferable. > > Theoretically, we could infer mode at runtime from VDD_SOC voltage, > but we need to set up clocks to read out the PMIC and I want to > apply the constraints as early as possible as I don't want the SoC > to run outside of spec even for a short while. Apologies for the delay responding to you, doing it today cos I feel guilty! I think what you've explained here is fine, but could you add a bit more of that info to the commit message, explaining why one cannot be default? With that, Acked-by: Conor Dooley <conor.dooley@microchip.com> Cheers, Conor. > > Thanks, > Ahmad > > > > >> > >> While the overdrive mode allows for higher frequencies for many IPs, > >> the nominal mode needs a lower SoC voltage, thereby reducing > >> heat generation and power usage. > >> > >> In any case, software should respect the maximum clock rate limits > >> described in the datasheet for each of the two operating modes. > >> > >> To allow device tree consumers to enforce these limits, document two new > >> optional properties that can be used to sanity check the clock tree. > >> > >> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> > >> --- > >> Documentation/devicetree/bindings/clock/imx8m-clock.yaml | 14 ++++++++++++++ > >> 1 file changed, 14 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml > >> index c643d4a81478..a6ae5257ef53 100644 > >> --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml > >> +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml > >> @@ -43,6 +43,14 @@ properties: > >> ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h > >> for the full list of i.MX8M clock IDs. > >> > >> + fsl,nominal-mode: > >> + description: Set if SoC is operated in nominal mode > >> + $ref: /schemas/types.yaml#/definitions/flag > >> + > >> + fsl,overdrive-mode: > >> + description: Set if SoC is operated in overdrive mode > >> + $ref: /schemas/types.yaml#/definitions/flag > >> + > >> required: > >> - compatible > >> - reg > >> @@ -95,6 +103,12 @@ allOf: > >> - const: clk_ext2 > >> - const: clk_ext3 > >> - const: clk_ext4 > >> + - if: > >> + required: > >> + - fsl,overdrive-mode > >> + then: > >> + properties: > >> + fsl,nominal-mode: false > >> > >> additionalProperties: false > >> > >> > >> -- > >> 2.39.5 > >> > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi Conor, On 25.12.24 15:20, Conor Dooley wrote: > On Thu, Dec 19, 2024 at 09:14:10PM +0100, Ahmad Fatoum wrote: >> On 19.12.24 20:49, Conor Dooley wrote: >>> On Thu, Dec 19, 2024 at 08:27:32AM +0100, Ahmad Fatoum wrote: >> Theoretically, we could infer mode at runtime from VDD_SOC voltage, >> but we need to set up clocks to read out the PMIC and I want to >> apply the constraints as early as possible as I don't want the SoC >> to run outside of spec even for a short while. > > Apologies for the delay responding to you, doing it today cos I feel > guilty! I am fully aware that I needn't expect prompt review feedback so late in December. Thanks a lot for taking the time still. > I think what you've explained here is fine, but could you add a > bit more of that info to the commit message, explaining why one cannot > be default? With that, > Acked-by: Conor Dooley <conor.dooley@microchip.com> Thanks. I will await further review feedback and adjust this commit's message for v2 as requested. Wishing you nice holidays, Ahmad > > Cheers, > Conor. > >> >> Thanks, >> Ahmad >> >>> >>>> >>>> While the overdrive mode allows for higher frequencies for many IPs, >>>> the nominal mode needs a lower SoC voltage, thereby reducing >>>> heat generation and power usage. >>>> >>>> In any case, software should respect the maximum clock rate limits >>>> described in the datasheet for each of the two operating modes. >>>> >>>> To allow device tree consumers to enforce these limits, document two new >>>> optional properties that can be used to sanity check the clock tree. >>>> >>>> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> >>>> --- >>>> Documentation/devicetree/bindings/clock/imx8m-clock.yaml | 14 ++++++++++++++ >>>> 1 file changed, 14 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml >>>> index c643d4a81478..a6ae5257ef53 100644 >>>> --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml >>>> +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml >>>> @@ -43,6 +43,14 @@ properties: >>>> ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h >>>> for the full list of i.MX8M clock IDs. >>>> >>>> + fsl,nominal-mode: >>>> + description: Set if SoC is operated in nominal mode >>>> + $ref: /schemas/types.yaml#/definitions/flag >>>> + >>>> + fsl,overdrive-mode: >>>> + description: Set if SoC is operated in overdrive mode >>>> + $ref: /schemas/types.yaml#/definitions/flag >>>> + >>>> required: >>>> - compatible >>>> - reg >>>> @@ -95,6 +103,12 @@ allOf: >>>> - const: clk_ext2 >>>> - const: clk_ext3 >>>> - const: clk_ext4 >>>> + - if: >>>> + required: >>>> + - fsl,overdrive-mode >>>> + then: >>>> + properties: >>>> + fsl,nominal-mode: false >>>> >>>> additionalProperties: false >>>> >>>> >>>> -- >>>> 2.39.5 >>>> >> >> >> -- >> Pengutronix e.K. | | >> Steuerwalder Str. 21 | http://www.pengutronix.de/ | >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Thu, Dec 26, 2024 at 05:54:15PM +0100, Ahmad Fatoum wrote: > Hi Conor, > > On 25.12.24 15:20, Conor Dooley wrote: > > On Thu, Dec 19, 2024 at 09:14:10PM +0100, Ahmad Fatoum wrote: > >> On 19.12.24 20:49, Conor Dooley wrote: > >>> On Thu, Dec 19, 2024 at 08:27:32AM +0100, Ahmad Fatoum wrote: > >> Theoretically, we could infer mode at runtime from VDD_SOC voltage, > >> but we need to set up clocks to read out the PMIC and I want to > >> apply the constraints as early as possible as I don't want the SoC > >> to run outside of spec even for a short while. > > > > Apologies for the delay responding to you, doing it today cos I feel > > guilty! > > I am fully aware that I needn't expect prompt review feedback so late in > December. Thanks a lot for taking the time still. I guess, but I /had/ replied to other things that came in after your mail, which is where my guilt comes from! > > I think what you've explained here is fine, but could you add a > > bit more of that info to the commit message, explaining why one cannot > > be default? With that, > > Acked-by: Conor Dooley <conor.dooley@microchip.com> > > Thanks. I will await further review feedback and adjust this commit's > message for v2 as requested. > > Wishing you nice holidays, You too (or what's left of em at least).
© 2016 - 2025 Red Hat, Inc.