The 'syspll' PLL is a general-purpose PLL designed specifically for the
CPU clock. It is capable of producing output frequencies within the
range of 768MHz to 1536MHz.
The clock source sys_pll_div16, being one of the GEN clock parents,
plays a crucial role and cannot be tagged as "optional". Unfortunately,
it was not implemented earlier due to the cpu clock ctrl driver's
pending status on the TODO list.
Signed-off-by: Dmitry Rokosov <[email protected]>
---
.../devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml | 7 +++++--
include/dt-bindings/clock/amlogic,a1-pll-clkc.h | 2 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
index a59b188a8bf5..fbba57031278 100644
--- a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
+++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
@@ -26,11 +26,13 @@ properties:
items:
- description: input fixpll_in
- description: input hifipll_in
+ - description: input syspll_in
clock-names:
items:
- const: fixpll_in
- const: hifipll_in
+ - const: syspll_in
required:
- compatible
@@ -53,7 +55,8 @@ examples:
reg = <0 0x7c80 0 0x18c>;
#clock-cells = <1>;
clocks = <&clkc_periphs CLKID_FIXPLL_IN>,
- <&clkc_periphs CLKID_HIFIPLL_IN>;
- clock-names = "fixpll_in", "hifipll_in";
+ <&clkc_periphs CLKID_HIFIPLL_IN>,
+ <&clkc_periphs CLKID_SYSPLL_IN>;
+ clock-names = "fixpll_in", "hifipll_in", "syspll_in";
};
};
diff --git a/include/dt-bindings/clock/amlogic,a1-pll-clkc.h b/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
index 2b660c0f2c9f..a702d610589c 100644
--- a/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
+++ b/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
@@ -21,5 +21,7 @@
#define CLKID_FCLK_DIV5 8
#define CLKID_FCLK_DIV7 9
#define CLKID_HIFI_PLL 10
+#define CLKID_SYS_PLL 11
+#define CLKID_SYS_PLL_DIV16 12
#endif /* __A1_PLL_CLKC_H */
--
2.43.0
On Fri, May 10, 2024 at 12:08:54PM +0300, Dmitry Rokosov wrote:
> The 'syspll' PLL is a general-purpose PLL designed specifically for the
> CPU clock. It is capable of producing output frequencies within the
> range of 768MHz to 1536MHz.
>
> The clock source sys_pll_div16, being one of the GEN clock parents,
> plays a crucial role and cannot be tagged as "optional". Unfortunately,
> it was not implemented earlier due to the cpu clock ctrl driver's
> pending status on the TODO list.
It's fine to not mark it optional in the binding, but it should be
optional in the driver as otherwise backwards compatibility will be
broken. Given this is an integral clock driver, sounds like it would
quite likely break booting on these devices if the driver doesn't treat
syspll_in as optional.
A lesson perhaps in describing the hardware entirely, even if the
drivers don't make use of all the information yet?
Cheers,
Conor.
>
> Signed-off-by: Dmitry Rokosov <[email protected]>
> ---
> .../devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml | 7 +++++--
> include/dt-bindings/clock/amlogic,a1-pll-clkc.h | 2 ++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> index a59b188a8bf5..fbba57031278 100644
> --- a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> @@ -26,11 +26,13 @@ properties:
> items:
> - description: input fixpll_in
> - description: input hifipll_in
> + - description: input syspll_in
>
> clock-names:
> items:
> - const: fixpll_in
> - const: hifipll_in
> + - const: syspll_in
>
> required:
> - compatible
> @@ -53,7 +55,8 @@ examples:
> reg = <0 0x7c80 0 0x18c>;
> #clock-cells = <1>;
> clocks = <&clkc_periphs CLKID_FIXPLL_IN>,
> - <&clkc_periphs CLKID_HIFIPLL_IN>;
> - clock-names = "fixpll_in", "hifipll_in";
> + <&clkc_periphs CLKID_HIFIPLL_IN>,
> + <&clkc_periphs CLKID_SYSPLL_IN>;
> + clock-names = "fixpll_in", "hifipll_in", "syspll_in";
> };
> };
> diff --git a/include/dt-bindings/clock/amlogic,a1-pll-clkc.h b/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
> index 2b660c0f2c9f..a702d610589c 100644
> --- a/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
> +++ b/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
> @@ -21,5 +21,7 @@
> #define CLKID_FCLK_DIV5 8
> #define CLKID_FCLK_DIV7 9
> #define CLKID_HIFI_PLL 10
> +#define CLKID_SYS_PLL 11
> +#define CLKID_SYS_PLL_DIV16 12
>
> #endif /* __A1_PLL_CLKC_H */
> --
> 2.43.0
>
>
Hello Conor,
Thank you for quick review!
On Sat, May 11, 2024 at 02:08:03PM +0100, Conor Dooley wrote:
> On Fri, May 10, 2024 at 12:08:54PM +0300, Dmitry Rokosov wrote:
> > The 'syspll' PLL is a general-purpose PLL designed specifically for the
> > CPU clock. It is capable of producing output frequencies within the
> > range of 768MHz to 1536MHz.
> >
> > The clock source sys_pll_div16, being one of the GEN clock parents,
> > plays a crucial role and cannot be tagged as "optional". Unfortunately,
> > it was not implemented earlier due to the cpu clock ctrl driver's
> > pending status on the TODO list.
>
> It's fine to not mark it optional in the binding, but it should be
> optional in the driver as otherwise backwards compatibility will be
> broken. Given this is an integral clock driver, sounds like it would
> quite likely break booting on these devices if the driver doesn't treat
> syspll_in as optional.
> A lesson perhaps in describing the hardware entirely, even if the
> drivers don't make use of all the information yet?
Yes, it's definitely the right lesson for me. However, without syspll or
syspll_in, we cannot utilize CPU power management at all. I will attempt
to make it an optional feature on the driver side, but it might
necessitate additional conditions to disable CPU clock handling when
syspll is unavailable.
> >
> > Signed-off-by: Dmitry Rokosov <[email protected]>
> > ---
> > .../devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml | 7 +++++--
> > include/dt-bindings/clock/amlogic,a1-pll-clkc.h | 2 ++
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> > index a59b188a8bf5..fbba57031278 100644
> > --- a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> > +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> > @@ -26,11 +26,13 @@ properties:
> > items:
> > - description: input fixpll_in
> > - description: input hifipll_in
> > + - description: input syspll_in
> >
> > clock-names:
> > items:
> > - const: fixpll_in
> > - const: hifipll_in
> > + - const: syspll_in
> >
> > required:
> > - compatible
> > @@ -53,7 +55,8 @@ examples:
> > reg = <0 0x7c80 0 0x18c>;
> > #clock-cells = <1>;
> > clocks = <&clkc_periphs CLKID_FIXPLL_IN>,
> > - <&clkc_periphs CLKID_HIFIPLL_IN>;
> > - clock-names = "fixpll_in", "hifipll_in";
> > + <&clkc_periphs CLKID_HIFIPLL_IN>,
> > + <&clkc_periphs CLKID_SYSPLL_IN>;
> > + clock-names = "fixpll_in", "hifipll_in", "syspll_in";
> > };
> > };
> > diff --git a/include/dt-bindings/clock/amlogic,a1-pll-clkc.h b/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
> > index 2b660c0f2c9f..a702d610589c 100644
> > --- a/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
> > +++ b/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
> > @@ -21,5 +21,7 @@
> > #define CLKID_FCLK_DIV5 8
> > #define CLKID_FCLK_DIV7 9
> > #define CLKID_HIFI_PLL 10
> > +#define CLKID_SYS_PLL 11
> > +#define CLKID_SYS_PLL_DIV16 12
> >
> > #endif /* __A1_PLL_CLKC_H */
> > --
> > 2.43.0
> >
> >
--
Thank you,
Dmitry
On Sat 11 May 2024 at 14:08, Conor Dooley <[email protected]> wrote:
> [[PGP Signed Part:Undecided]]
> On Fri, May 10, 2024 at 12:08:54PM +0300, Dmitry Rokosov wrote:
>> The 'syspll' PLL is a general-purpose PLL designed specifically for the
>> CPU clock. It is capable of producing output frequencies within the
>> range of 768MHz to 1536MHz.
>>
>> The clock source sys_pll_div16, being one of the GEN clock parents,
>> plays a crucial role and cannot be tagged as "optional". Unfortunately,
>> it was not implemented earlier due to the cpu clock ctrl driver's
>> pending status on the TODO list.
>
> It's fine to not mark it optional in the binding, but it should be
> optional in the driver as otherwise backwards compatibility will be
> broken. Given this is an integral clock driver, sounds like it would
> quite likely break booting on these devices if the driver doesn't treat
> syspll_in as optional.
> A lesson perhaps in describing the hardware entirely, even if the
> drivers don't make use of all the information yet?
That is nice but it is only possible if/when we have perfect knowledge
of the HW being implemented. I don't know about you, but I rarely get
perfect documentation for HW, let alone a public one.
Those things are bound to happen as we implement support for the HW and
discover how it works, not to mention the mistakes humans will
inevitably do. If Linux was only supporting perfectly documented HW, it
would not be supporting much of them I suspect.
Stable API is already hard with ioctl but there, both sides are
perfectly known. That is a fundamental difference with the 'DT ABI'
Getting it right on day 1, every time - because things are set in stone
afterwards - is unrealistic. As a maintainer, I do spend a
disproportionate amount of time checking the bindings submission because
I know how painful it gets to fix things up down the line.
Unless I missed the simple solution to this problem, we can expect the
problem keep happening again and again, no matter the number of lessons
learned.
>
> Cheers,
> Conor.
>
>>
>> Signed-off-by: Dmitry Rokosov <[email protected]>
>> ---
>> .../devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml | 7 +++++--
>> include/dt-bindings/clock/amlogic,a1-pll-clkc.h | 2 ++
>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
>> index a59b188a8bf5..fbba57031278 100644
>> --- a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
>> @@ -26,11 +26,13 @@ properties:
>> items:
>> - description: input fixpll_in
>> - description: input hifipll_in
>> + - description: input syspll_in
>>
>> clock-names:
>> items:
>> - const: fixpll_in
>> - const: hifipll_in
>> + - const: syspll_in
>>
>> required:
>> - compatible
>> @@ -53,7 +55,8 @@ examples:
>> reg = <0 0x7c80 0 0x18c>;
>> #clock-cells = <1>;
>> clocks = <&clkc_periphs CLKID_FIXPLL_IN>,
>> - <&clkc_periphs CLKID_HIFIPLL_IN>;
>> - clock-names = "fixpll_in", "hifipll_in";
>> + <&clkc_periphs CLKID_HIFIPLL_IN>,
>> + <&clkc_periphs CLKID_SYSPLL_IN>;
>> + clock-names = "fixpll_in", "hifipll_in", "syspll_in";
>> };
>> };
>> diff --git a/include/dt-bindings/clock/amlogic,a1-pll-clkc.h b/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
>> index 2b660c0f2c9f..a702d610589c 100644
>> --- a/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
>> +++ b/include/dt-bindings/clock/amlogic,a1-pll-clkc.h
>> @@ -21,5 +21,7 @@
>> #define CLKID_FCLK_DIV5 8
>> #define CLKID_FCLK_DIV7 9
>> #define CLKID_HIFI_PLL 10
>> +#define CLKID_SYS_PLL 11
>> +#define CLKID_SYS_PLL_DIV16 12
>>
>> #endif /* __A1_PLL_CLKC_H */
>> --
>> 2.43.0
>>
>>
>
> [[End of PGP Signed Part]]
--
Jerome
On Mon, May 13, 2024 at 02:04:41PM +0200, Jerome Brunet wrote:
>
> On Sat 11 May 2024 at 14:08, Conor Dooley <[email protected]> wrote:
>
> > [[PGP Signed Part:Undecided]]
> > On Fri, May 10, 2024 at 12:08:54PM +0300, Dmitry Rokosov wrote:
> >> The 'syspll' PLL is a general-purpose PLL designed specifically for the
> >> CPU clock. It is capable of producing output frequencies within the
> >> range of 768MHz to 1536MHz.
> >>
> >> The clock source sys_pll_div16, being one of the GEN clock parents,
> >> plays a crucial role and cannot be tagged as "optional". Unfortunately,
> >> it was not implemented earlier due to the cpu clock ctrl driver's
> >> pending status on the TODO list.
> >
> > It's fine to not mark it optional in the binding, but it should be
> > optional in the driver as otherwise backwards compatibility will be
> > broken. Given this is an integral clock driver, sounds like it would
> > quite likely break booting on these devices if the driver doesn't treat
> > syspll_in as optional.
> > A lesson perhaps in describing the hardware entirely, even if the
> > drivers don't make use of all the information yet?
>
> That is nice but it is only possible if/when we have perfect knowledge
> of the HW being implemented. I don't know about you, but I rarely get
> perfect documentation for HW, let alone a public one.
>
> Those things are bound to happen as we implement support for the HW and
> discover how it works, not to mention the mistakes humans will
> inevitably do. If Linux was only supporting perfectly documented HW, it
> would not be supporting much of them I suspect.
I mean, you can say what you want chief about what you did or didn't
know, but there's a line in one of the drivers that was added back when
the original driver was that talks about the missing clock, so you can't
really act as if there was no knowledge about it. If it hadn't been
previously known about and TODO-listed, I would not have made these
comments.
> Stable API is already hard with ioctl but there, both sides are
> perfectly known. That is a fundamental difference with the 'DT ABI'
>
> Getting it right on day 1, every time
Wind your neck in, I don't expect you (or anyone else) to get it right
on "day 1, every time". I only expect it to be dealt with in a way that
is compatible with the existing devicetree.
Thanks,
Conor.
> - because things are set in stone
> afterwards - is unrealistic. As a maintainer, I do spend a
> disproportionate amount of time checking the bindings submission because
> I know how painful it gets to fix things up down the line.
>
> Unless I missed the simple solution to this problem, we can expect the
> problem keep happening again and again, no matter the number of lessons
> learned.
On Mon, May 13, 2024 at 12:18:02PM +0300, Dmitry Rokosov wrote:
> Hello Conor,
>
> Thank you for quick review!
>
> On Sat, May 11, 2024 at 02:08:03PM +0100, Conor Dooley wrote:
> > On Fri, May 10, 2024 at 12:08:54PM +0300, Dmitry Rokosov wrote:
> > > The 'syspll' PLL is a general-purpose PLL designed specifically for the
> > > CPU clock. It is capable of producing output frequencies within the
> > > range of 768MHz to 1536MHz.
> > >
> > > The clock source sys_pll_div16, being one of the GEN clock parents,
> > > plays a crucial role and cannot be tagged as "optional". Unfortunately,
> > > it was not implemented earlier due to the cpu clock ctrl driver's
> > > pending status on the TODO list.
> >
> > It's fine to not mark it optional in the binding, but it should be
> > optional in the driver as otherwise backwards compatibility will be
> > broken. Given this is an integral clock driver, sounds like it would
> > quite likely break booting on these devices if the driver doesn't treat
> > syspll_in as optional.
> > A lesson perhaps in describing the hardware entirely, even if the
> > drivers don't make use of all the information yet?
>
> Yes, it's definitely the right lesson for me. However, without syspll or
> syspll_in, we cannot utilize CPU power management at all.
That's the status-quo, right? The incorrect dts would continue to not
support CPU power management and the new one with the correct description
would?
On Mon, May 13, 2024 at 04:48:33PM +0100, Conor Dooley wrote:
> On Mon, May 13, 2024 at 12:18:02PM +0300, Dmitry Rokosov wrote:
> > Hello Conor,
> >
> > Thank you for quick review!
> >
> > On Sat, May 11, 2024 at 02:08:03PM +0100, Conor Dooley wrote:
> > > On Fri, May 10, 2024 at 12:08:54PM +0300, Dmitry Rokosov wrote:
> > > > The 'syspll' PLL is a general-purpose PLL designed specifically for the
> > > > CPU clock. It is capable of producing output frequencies within the
> > > > range of 768MHz to 1536MHz.
> > > >
> > > > The clock source sys_pll_div16, being one of the GEN clock parents,
> > > > plays a crucial role and cannot be tagged as "optional". Unfortunately,
> > > > it was not implemented earlier due to the cpu clock ctrl driver's
> > > > pending status on the TODO list.
> > >
> > > It's fine to not mark it optional in the binding, but it should be
> > > optional in the driver as otherwise backwards compatibility will be
> > > broken. Given this is an integral clock driver, sounds like it would
> > > quite likely break booting on these devices if the driver doesn't treat
> > > syspll_in as optional.
> > > A lesson perhaps in describing the hardware entirely, even if the
> > > drivers don't make use of all the information yet?
> >
> > Yes, it's definitely the right lesson for me. However, without syspll or
> > syspll_in, we cannot utilize CPU power management at all.
>
> That's the status-quo, right? The incorrect dts would continue to not
> support CPU power management and the new one with the correct description
> would?
Hmmm, correct. Okay, I see, I will support sys_pll as optional
connection :)
--
Thank you,
Dmitry
On Mon 13 May 2024 at 21:30, Dmitry Rokosov <[email protected]> wrote:
> On Mon, May 13, 2024 at 04:48:33PM +0100, Conor Dooley wrote:
>> On Mon, May 13, 2024 at 12:18:02PM +0300, Dmitry Rokosov wrote:
>> > Hello Conor,
>> >
>> > Thank you for quick review!
>> >
>> > On Sat, May 11, 2024 at 02:08:03PM +0100, Conor Dooley wrote:
>> > > On Fri, May 10, 2024 at 12:08:54PM +0300, Dmitry Rokosov wrote:
>> > > > The 'syspll' PLL is a general-purpose PLL designed specifically for the
>> > > > CPU clock. It is capable of producing output frequencies within the
>> > > > range of 768MHz to 1536MHz.
>> > > >
>> > > > The clock source sys_pll_div16, being one of the GEN clock parents,
>> > > > plays a crucial role and cannot be tagged as "optional". Unfortunately,
>> > > > it was not implemented earlier due to the cpu clock ctrl driver's
>> > > > pending status on the TODO list.
>> > >
>> > > It's fine to not mark it optional in the binding, but it should be
>> > > optional in the driver as otherwise backwards compatibility will be
>> > > broken. Given this is an integral clock driver, sounds like it would
>> > > quite likely break booting on these devices if the driver doesn't treat
>> > > syspll_in as optional.
>> > > A lesson perhaps in describing the hardware entirely, even if the
>> > > drivers don't make use of all the information yet?
>> >
>> > Yes, it's definitely the right lesson for me. However, without syspll or
>> > syspll_in, we cannot utilize CPU power management at all.
>>
>> That's the status-quo, right? The incorrect dts would continue to not
>> support CPU power management and the new one with the correct description
>> would?
>
> Hmmm, correct. Okay, I see, I will support sys_pll as optional
> connection :)
Again, the way controller is written, all inputs are actually optional.
The controller does not error out if an input is missing, it behave as
if the input is disconnected
--
Jerome