[v4,1/7] dt-bindings: clock: Add StarFive JH7110 PLL clock generator

  Add bindings for the PLL clock generator on the JH7110 RISC-V SoC.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
---
 .../bindings/clock/starfive,jh7110-pll.yaml   | 46 +++++++++++++++++++
 .../dt-bindings/clock/starfive,jh7110-crg.h   |  6 +++
 2 files changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml
  

On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
[...]
>  #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
>  #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
>  
> +/* PLL clocks */
> +#define JH7110_CLK_PLL0_OUT			0
> +#define JH7110_CLK_PLL1_OUT			1
> +#define JH7110_CLK_PLL2_OUT			2

In U-Boot commit 58c9c60b Yanhong Wang added:

+
+#define JH7110_SYSCLK_PLL0_OUT                       190
+#define JH7110_SYSCLK_PLL1_OUT                       191
+#define JH7110_SYSCLK_PLL2_OUT                       192
+
+#define JH7110_SYSCLK_END                    193

in that respective file.

> +#define JH7110_PLLCLK_END			3
> +
>  /* SYSCRG clocks */
>  #define JH7110_SYSCLK_CPU_ROOT			0

If the symbolic names referred to the same items, would it be possible
to keep the two files in sync somehow?

	Torsten
  

On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> [...]
> >  #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
> >  #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
> >  
> > +/* PLL clocks */
> > +#define JH7110_CLK_PLL0_OUT			0
> > +#define JH7110_CLK_PLL1_OUT			1
> > +#define JH7110_CLK_PLL2_OUT			2
> 
> In U-Boot commit 58c9c60b Yanhong Wang added:
> 
> +
> +#define JH7110_SYSCLK_PLL0_OUT                       190
> +#define JH7110_SYSCLK_PLL1_OUT                       191
> +#define JH7110_SYSCLK_PLL2_OUT                       192
> +
> +#define JH7110_SYSCLK_END                    193
> 
> in that respective file.
> 
> > +#define JH7110_PLLCLK_END			3
> > +
> >  /* SYSCRG clocks */
> >  #define JH7110_SYSCLK_CPU_ROOT			0
> 
> If the symbolic names referred to the same items, would it be possible
> to keep the two files in sync somehow?

Ohh, that's not good.. If you pass the U-Boot dtb to Linux it won't
understand the numbering. The headers are part of the dt-binding :/
  

On 2023/5/19 22:16, Conor Dooley wrote:
> On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
>> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
>> [...]
>> >  #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
>> >  #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
>> >  
>> > +/* PLL clocks */
>> > +#define JH7110_CLK_PLL0_OUT			0
>> > +#define JH7110_CLK_PLL1_OUT			1
>> > +#define JH7110_CLK_PLL2_OUT			2
>> 
>> In U-Boot commit 58c9c60b Yanhong Wang added:
>> 
>> +
>> +#define JH7110_SYSCLK_PLL0_OUT                       190
>> +#define JH7110_SYSCLK_PLL1_OUT                       191
>> +#define JH7110_SYSCLK_PLL2_OUT                       192
>> +
>> +#define JH7110_SYSCLK_END                    193
>> 
>> in that respective file.
>> 
>> > +#define JH7110_PLLCLK_END			3
>> > +
>> >  /* SYSCRG clocks */
>> >  #define JH7110_SYSCLK_CPU_ROOT			0
>> 
>> If the symbolic names referred to the same items, would it be possible
>> to keep the two files in sync somehow?
> 
> Ohh, that's not good.. If you pass the U-Boot dtb to Linux it won't
> understand the numbering. The headers are part of the dt-binding :/

Because in Linux, the PLL driver is separate from SYSCRG driver and the
numbering starts from 0. But in Uboot, the PLL driver is included in
the SYSCRG driver and the numbering follows the SYSCRG.

Best regards,
Xingyu Wu
  

On 2023/5/19 22:16, Conor Dooley wrote:
> On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
>> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
>> [...]
>> >  #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
>> >  #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
>> >  
>> > +/* PLL clocks */
>> > +#define JH7110_CLK_PLL0_OUT			0
>> > +#define JH7110_CLK_PLL1_OUT			1
>> > +#define JH7110_CLK_PLL2_OUT			2
>> 
>> In U-Boot commit 58c9c60b Yanhong Wang added:
>> 
>> +
>> +#define JH7110_SYSCLK_PLL0_OUT                       190
>> +#define JH7110_SYSCLK_PLL1_OUT                       191
>> +#define JH7110_SYSCLK_PLL2_OUT                       192
>> +
>> +#define JH7110_SYSCLK_END                    193
>> 
>> in that respective file.
>> 
>> > +#define JH7110_PLLCLK_END			3
>> > +
>> >  /* SYSCRG clocks */
>> >  #define JH7110_SYSCLK_CPU_ROOT			0
>> 
>> If the symbolic names referred to the same items, would it be possible
>> to keep the two files in sync somehow?
> 
> Ohh, that's not good.. If you pass the U-Boot dtb to Linux it won't
> understand the numbering. The headers are part of the dt-binding :/

Because PLL driver is separated from SYSCRG driver in Linux,
the numbering starts from 0. But in Uboot, the PLL driver is
included in the SYSCRG driver, and the number follows the SYSCRG.

Best regards,
Xingyu Wu
  

On 2023/5/19 22:16, Conor Dooley wrote:
> On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
>> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
>> [...]
>> >  #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
>> >  #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
>> >  
>> > +/* PLL clocks */
>> > +#define JH7110_CLK_PLL0_OUT			0
>> > +#define JH7110_CLK_PLL1_OUT			1
>> > +#define JH7110_CLK_PLL2_OUT			2
>> 
>> In U-Boot commit 58c9c60b Yanhong Wang added:
>> 
>> +
>> +#define JH7110_SYSCLK_PLL0_OUT                       190
>> +#define JH7110_SYSCLK_PLL1_OUT                       191
>> +#define JH7110_SYSCLK_PLL2_OUT                       192
>> +
>> +#define JH7110_SYSCLK_END                    193
>> 
>> in that respective file.
>> 
>> > +#define JH7110_PLLCLK_END			3
>> > +
>> >  /* SYSCRG clocks */
>> >  #define JH7110_SYSCLK_CPU_ROOT			0
>> 
>> If the symbolic names referred to the same items, would it be possible
>> to keep the two files in sync somehow?
> 
> Ohh, that's not good.. If you pass the U-Boot dtb to Linux it won't
> understand the numbering. The headers are part of the dt-binding :/

Because PLL driver is separated from SYSCRG drivers in Linux, the numbering
starts from 0. But in Uboot, the PLL driver is included in the SYSCRG driver,
and the number follows the SYSCRG.

Best regards,
Xingyu Wu
  

On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> On 2023/5/19 22:16, Conor Dooley wrote:
> > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
> >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> >> [...]
> >> >  #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
> >> >  #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
> >> >  
> >> > +/* PLL clocks */
> >> > +#define JH7110_CLK_PLL0_OUT			0
> >> > +#define JH7110_CLK_PLL1_OUT			1
> >> > +#define JH7110_CLK_PLL2_OUT			2
> >> 
> >> In U-Boot commit 58c9c60b Yanhong Wang added:
> >> 
> >> +
> >> +#define JH7110_SYSCLK_PLL0_OUT                       190
> >> +#define JH7110_SYSCLK_PLL1_OUT                       191
> >> +#define JH7110_SYSCLK_PLL2_OUT                       192
> >> +
> >> +#define JH7110_SYSCLK_END                    193
> >> 
> >> in that respective file.
> >> 
> >> > +#define JH7110_PLLCLK_END			3
> >> > +
> >> >  /* SYSCRG clocks */
> >> >  #define JH7110_SYSCLK_CPU_ROOT			0
> >> 
> >> If the symbolic names referred to the same items, would it be possible
> >> to keep the two files in sync somehow?
> > 
> > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it won't
> > understand the numbering. The headers are part of the dt-binding :/
> 
> Because PLL driver is separated from SYSCRG drivers in Linux, the numbering
> starts from 0. But in Uboot, the PLL driver is included in the SYSCRG driver,
> and the number follows the SYSCRG.

Unfortunately, how you choose to construct your drivers has nothing to
do with this.
These defines/numbers appear in the dts and are part of the DT ABI.
The same dts is supposed to work for Linux & U-Boot.
  

On Tue, 23 May 2023 09:28:39 +0100
Conor Dooley <conor.dooley@microchip.com> wrote:

> On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> > On 2023/5/19 22:16, Conor Dooley wrote:
> > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
> > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> > >> [...]

> > >> > +/* PLL clocks */
> > >> > +#define JH7110_CLK_PLL0_OUT			0
> > >> > +#define JH7110_CLK_PLL1_OUT			1
> > >> > +#define JH7110_CLK_PLL2_OUT			2
> > >> 
> > >> In U-Boot commit 58c9c60b Yanhong Wang added:
> > >> 
> > >> +
> > >> +#define JH7110_SYSCLK_PLL0_OUT                       190
> > >> +#define JH7110_SYSCLK_PLL1_OUT                       191
> > >> +#define JH7110_SYSCLK_PLL2_OUT                       192
> > >> +
> > >> +#define JH7110_SYSCLK_END                    193
[...]
> > > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it
> > > won't understand the numbering. The headers are part of the
> > > dt-binding :/

In fact, the clock index >= 190 makes linux hang on boot, waiting with
EPROBE_DEFER for every device's clock, because the sysclk driver errors
out with EINVAL (jh7110_sysclk_get()).

> > Because PLL driver is separated from SYSCRG drivers in Linux, the
> > numbering starts from 0. But in Uboot, the PLL driver is included
> > in the SYSCRG driver, and the number follows the SYSCRG.
> 
> Unfortunately, how you choose to construct your drivers has nothing to
> do with this.
> These defines/numbers appear in the dts and are part of the DT ABI.
> The same dts is supposed to work for Linux & U-Boot.

The JH7110 has 6 blocks of 64k iomem in that functional area:
{SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
The good news: the current DTS, as proposed here and in U-Boot master,
provides nodes for all 6 entities. The bad news is that the clock
assignments to those nodes and their numbering is messed up.

AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot gets it
wrong, in addition to the erroneous DTS.

	Torsten
  

On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> On Tue, 23 May 2023 09:28:39 +0100
> Conor Dooley <conor.dooley@microchip.com> wrote:
> 
> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> > > On 2023/5/19 22:16, Conor Dooley wrote:
> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> > > >> [...]
> 
> > > >> > +/* PLL clocks */
> > > >> > +#define JH7110_CLK_PLL0_OUT			0
> > > >> > +#define JH7110_CLK_PLL1_OUT			1
> > > >> > +#define JH7110_CLK_PLL2_OUT			2
> > > >> 
> > > >> In U-Boot commit 58c9c60b Yanhong Wang added:
> > > >> 
> > > >> +
> > > >> +#define JH7110_SYSCLK_PLL0_OUT                       190
> > > >> +#define JH7110_SYSCLK_PLL1_OUT                       191
> > > >> +#define JH7110_SYSCLK_PLL2_OUT                       192
> > > >> +
> > > >> +#define JH7110_SYSCLK_END                    193
> [...]
> > > > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it
> > > > won't understand the numbering. The headers are part of the
> > > > dt-binding :/
> 
> In fact, the clock index >= 190 makes linux hang on boot, waiting with
> EPROBE_DEFER for every device's clock, because the sysclk driver errors
> out with EINVAL (jh7110_sysclk_get()).

Yup, that's about what I expected to happen.

> > > Because PLL driver is separated from SYSCRG drivers in Linux, the
> > > numbering starts from 0. But in Uboot, the PLL driver is included
> > > in the SYSCRG driver, and the number follows the SYSCRG.
> > 
> > Unfortunately, how you choose to construct your drivers has nothing to
> > do with this.
> > These defines/numbers appear in the dts and are part of the DT ABI.
> > The same dts is supposed to work for Linux & U-Boot.
> 
> The JH7110 has 6 blocks of 64k iomem in that functional area:
> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
> The good news: the current DTS, as proposed here and in U-Boot master,
> provides nodes for all 6 entities. The bad news is that the clock
> assignments to those nodes and their numbering is messed up.
> 
> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot gets it
> wrong, in addition to the erroneous DTS.

The numbers are kinda hocus-pocus anyway, they are just made up since the
clock numbering usually isn't something with a nice TRM to go and
reference (unlike interrupts which usually are documented in that way).
It is very helpful to make them aligned some register/bit positions or,
but that is not required.
IOW U-Boot is not wrong per se to use 190 instead of 0, but it is wrong
to have different numbers in both places.

It sounds like you're saying that (and I have not looked) the U-Boot dts
actually has structural difference w.r.t. what provides which clock?
If so, that'll need to be fixed independently of the numbering problem.

Otherwise Xingyu & Yanhong should coordinate on which is the "correct"
way of doing things & do it in both places.

Thanks,
Conor.
  

On 2023/5/23 19:28, Conor Dooley wrote:
> On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
>> On Tue, 23 May 2023 09:28:39 +0100
>> Conor Dooley <conor.dooley@microchip.com> wrote:
>> 
>> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
>> > > On 2023/5/19 22:16, Conor Dooley wrote:
>> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
>> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
>> > > >> [...]
>> 
>> > > >> > +/* PLL clocks */
>> > > >> > +#define JH7110_CLK_PLL0_OUT			0
>> > > >> > +#define JH7110_CLK_PLL1_OUT			1
>> > > >> > +#define JH7110_CLK_PLL2_OUT			2
>> > > >> 
>> > > >> In U-Boot commit 58c9c60b Yanhong Wang added:
>> > > >> 
>> > > >> +
>> > > >> +#define JH7110_SYSCLK_PLL0_OUT                       190
>> > > >> +#define JH7110_SYSCLK_PLL1_OUT                       191
>> > > >> +#define JH7110_SYSCLK_PLL2_OUT                       192
>> > > >> +
>> > > >> +#define JH7110_SYSCLK_END                    193
>> [...]
>> > > > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it
>> > > > won't understand the numbering. The headers are part of the
>> > > > dt-binding :/
>> 
>> In fact, the clock index >= 190 makes linux hang on boot, waiting with
>> EPROBE_DEFER for every device's clock, because the sysclk driver errors
>> out with EINVAL (jh7110_sysclk_get()).
> 
> Yup, that's about what I expected to happen.
> 
>> > > Because PLL driver is separated from SYSCRG drivers in Linux, the
>> > > numbering starts from 0. But in Uboot, the PLL driver is included
>> > > in the SYSCRG driver, and the number follows the SYSCRG.
>> > 
>> > Unfortunately, how you choose to construct your drivers has nothing to
>> > do with this.
>> > These defines/numbers appear in the dts and are part of the DT ABI.
>> > The same dts is supposed to work for Linux & U-Boot.
>> 
>> The JH7110 has 6 blocks of 64k iomem in that functional area:
>> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
>> The good news: the current DTS, as proposed here and in U-Boot master,
>> provides nodes for all 6 entities. The bad news is that the clock
>> assignments to those nodes and their numbering is messed up.
>> 
>> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot gets it
>> wrong, in addition to the erroneous DTS.
> 
> The numbers are kinda hocus-pocus anyway, they are just made up since the
> clock numbering usually isn't something with a nice TRM to go and
> reference (unlike interrupts which usually are documented in that way).
> It is very helpful to make them aligned some register/bit positions or,
> but that is not required.
> IOW U-Boot is not wrong per se to use 190 instead of 0, but it is wrong
> to have different numbers in both places.
> 
> It sounds like you're saying that (and I have not looked) the U-Boot dts
> actually has structural difference w.r.t. what provides which clock?
> If so, that'll need to be fixed independently of the numbering problem.
> 
> Otherwise Xingyu & Yanhong should coordinate on which is the "correct"
> way of doing things & do it in both places.
> 

Oh, unfortunately, the 7110 can not support to mix the uboot dtb and linux dtb up.
If boot the Linux and should use the linux dtb instead of the uboot dtb.
Because all clock ids and reset ids in Linux and Uboot are different include
PLL, and some modules can work in Linux but not in uboot.
I suggest to boot Linux with its own linux dtb.

Best regards,
Xingyu Wu
  

On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> On 2023/5/23 19:28, Conor Dooley wrote:
> > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> >> On Tue, 23 May 2023 09:28:39 +0100
> >> Conor Dooley <conor.dooley@microchip.com> wrote:
> >> 
> >> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> >> > > On 2023/5/19 22:16, Conor Dooley wrote:
> >> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
> >> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> >> > > >> [...]
> >> 
> >> > > >> > +/* PLL clocks */
> >> > > >> > +#define JH7110_CLK_PLL0_OUT			0
> >> > > >> > +#define JH7110_CLK_PLL1_OUT			1
> >> > > >> > +#define JH7110_CLK_PLL2_OUT			2
> >> > > >> 
> >> > > >> In U-Boot commit 58c9c60b Yanhong Wang added:
> >> > > >> 
> >> > > >> +
> >> > > >> +#define JH7110_SYSCLK_PLL0_OUT                       190
> >> > > >> +#define JH7110_SYSCLK_PLL1_OUT                       191
> >> > > >> +#define JH7110_SYSCLK_PLL2_OUT                       192
> >> > > >> +
> >> > > >> +#define JH7110_SYSCLK_END                    193
> >> [...]
> >> > > > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it
> >> > > > won't understand the numbering. The headers are part of the
> >> > > > dt-binding :/
> >> 
> >> In fact, the clock index >= 190 makes linux hang on boot, waiting with
> >> EPROBE_DEFER for every device's clock, because the sysclk driver errors
> >> out with EINVAL (jh7110_sysclk_get()).
> > 
> > Yup, that's about what I expected to happen.
> > 
> >> > > Because PLL driver is separated from SYSCRG drivers in Linux, the
> >> > > numbering starts from 0. But in Uboot, the PLL driver is included
> >> > > in the SYSCRG driver, and the number follows the SYSCRG.
> >> > 
> >> > Unfortunately, how you choose to construct your drivers has nothing to
> >> > do with this.
> >> > These defines/numbers appear in the dts and are part of the DT ABI.
> >> > The same dts is supposed to work for Linux & U-Boot.
> >> 
> >> The JH7110 has 6 blocks of 64k iomem in that functional area:
> >> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
> >> The good news: the current DTS, as proposed here and in U-Boot master,
> >> provides nodes for all 6 entities. The bad news is that the clock
> >> assignments to those nodes and their numbering is messed up.
> >> 
> >> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot gets it
> >> wrong, in addition to the erroneous DTS.
> > 
> > The numbers are kinda hocus-pocus anyway, they are just made up since the
> > clock numbering usually isn't something with a nice TRM to go and
> > reference (unlike interrupts which usually are documented in that way).
> > It is very helpful to make them aligned some register/bit positions or,
> > but that is not required.
> > IOW U-Boot is not wrong per se to use 190 instead of 0, but it is wrong
> > to have different numbers in both places.
> > 
> > It sounds like you're saying that (and I have not looked) the U-Boot dts
> > actually has structural difference w.r.t. what provides which clock?
> > If so, that'll need to be fixed independently of the numbering problem.
> > 
> > Otherwise Xingyu & Yanhong should coordinate on which is the "correct"
> > way of doing things & do it in both places.
> > 
> 
> Oh, unfortunately, the 7110 can not support to mix the uboot dtb and linux dtb up.

What does "cannot support" mean? It's normal and desirable for the same
dtb to be usable for both. The Linux kernel's dt-bindings are used for
multiple projects, not just Linux - it'd be silly for U-Boot, FreeBSD
etc etc to go off and each have their open set of (incompatible) bindings.

> If boot the Linux and should use the linux dtb instead of the uboot dtb.
> Because all clock ids and reset ids in Linux and Uboot are different include
> PLL, and some modules can work in Linux but not in uboot.

What do you mean by "modules"? It is fine for either Linux or U-Boot to
not have drivers for particular peripherals - for example, there might
be no driver for your camera related bits in U-Boot, or for controlling
DRAM in Linux.

The description of the hardware should not change though, as the
hardware has not.

> I suggest to boot Linux with its own linux dtb.

I suggest to make sure that you can use the same dtb for both.

Thanks,
Conor.
  

On Wed, 24 May 2023 11:19:48 +0100
Conor Dooley <conor.dooley@microchip.com> wrote:

> On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> > On 2023/5/23 19:28, Conor Dooley wrote:
> > > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> > >> On Tue, 23 May 2023 09:28:39 +0100
> > >> Conor Dooley <conor.dooley@microchip.com> wrote:
> > >> 
> > >> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> > >> > > On 2023/5/19 22:16, Conor Dooley wrote:
> > >> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe
> > >> > > > wrote:
> > >> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
[...]

> > >> > > Because PLL driver is separated from SYSCRG drivers in
> > >> > > Linux, the numbering starts from 0. But in Uboot, the PLL
> > >> > > driver is included in the SYSCRG driver, and the number
> > >> > > follows the SYSCRG.
> > >> > 
> > >> > Unfortunately, how you choose to construct your drivers has
> > >> > nothing to do with this.

Exactly. As I wrote (quote below), the PLLx frequencies are controlled
by the I/O block SYS_SYSCON (starting there at offset 0x18), according
to the public datasheets. All(?) other clocks are derived from those in
the *_CRG units. That *is* the hardware to be described, in *the* (one
and only!) DT. U-Boot, and any OS, are free to reorganise their driver
framework around that, but the hardware description is quite clear.

> > >> > These defines/numbers appear in the dts and are part of the DT
> > >> > ABI. The same dts is supposed to work for Linux & U-Boot.
> > >> 
> > >> The JH7110 has 6 blocks of 64k iomem in that functional area:
> > >> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
> > >> The good news: the current DTS, as proposed here and in U-Boot
> > >> master, provides nodes for all 6 entities. The bad news is that
> > >> the clock assignments to those nodes and their numbering is
> > >> messed up.
> > >> 
> > >> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot
> > >> gets it wrong, in addition to the erroneous DTS.
> > > 
> > > The numbers are kinda hocus-pocus anyway, they are just made up
> > > since the clock numbering usually isn't something with a nice TRM
> > > to go and reference (unlike interrupts which usually are
> > > documented in that way). It is very helpful to make them aligned
> > > some register/bit positions or, but that is not required.
> > > IOW U-Boot is not wrong per se to use 190 instead of 0, but it is
> > > wrong to have different numbers in both places.

U-Boot reuses the Common Clock Framework from Linux, and I'm not sure
whether the clock IDs need to be unique in order for the appropriate
clock to be found. But that would be the only restriction, if it
applies. Even then, each driver could register a clock with its own,
arbitrarily chosen base offset with the CCF, so each CRG unit could
still have its own clocks enumerated starting with 0 in the DTB.

> > > It sounds like you're saying that (and I have not looked) the
> > > U-Boot dts actually has structural difference w.r.t. what
> > > provides which clock? If so, that'll need to be fixed
> > > independently of the numbering problem.

> > 
> > Oh, unfortunately, the 7110 can not support to mix the uboot dtb
> > and linux dtb up.
> 
> What does "cannot support" mean? It's normal and desirable for the

IMHO "desirable" is too weak.

> same dtb to be usable for both. The Linux kernel's dt-bindings are
> used for multiple projects, not just Linux - it'd be silly for
> U-Boot, FreeBSD etc etc to go off and each have their open set of
> (incompatible) bindings.
> 
> > If boot the Linux and should use the linux dtb instead of the uboot
> > dtb. Because all clock ids and reset ids in Linux and Uboot are
> > different include PLL, and some modules can work in Linux but not
> > in uboot.
[...]
> 
> > I suggest to boot Linux with its own linux dtb.

This is a fragile band-aid, to be used only as a last resort. It
creates more problems than it solves. Your DTB will then match your
kernel, but whether it describes the actual hardware is a game of
chance. Doesn't the VisionFive2 have an RPi connector... ?

One of the IMO few valid use cases of adding a DTB to the kernel
at boot is OpenWRT, when you build an OS Image for a particular piece
of hardware you have at hand.

> I suggest to make sure that you can use the same dtb for both.

Interestingly enough, U-Boot already has the PLL driver in a separate
file. I have a half-baked patch here that moves the sys_syscon DT
matching into that file...

	Torsten
  

On Fri, May 26, 2023 at 09:34:32AM +0200, Torsten Duwe wrote:
> On Wed, 24 May 2023 11:19:48 +0100
> Conor Dooley <conor.dooley@microchip.com> wrote:
> 
> > On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> > > On 2023/5/23 19:28, Conor Dooley wrote:
> > > > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> > > >> On Tue, 23 May 2023 09:28:39 +0100
> > > >> Conor Dooley <conor.dooley@microchip.com> wrote:
> > > >> 
> > > >> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> > > >> > > On 2023/5/19 22:16, Conor Dooley wrote:
> > > >> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe
> > > >> > > > wrote:
> > > >> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> [...]
> 
> > > >> > > Because PLL driver is separated from SYSCRG drivers in
> > > >> > > Linux, the numbering starts from 0. But in Uboot, the PLL
> > > >> > > driver is included in the SYSCRG driver, and the number
> > > >> > > follows the SYSCRG.
> > > >> > 
> > > >> > Unfortunately, how you choose to construct your drivers has
> > > >> > nothing to do with this.
> 
> Exactly. As I wrote (quote below), the PLLx frequencies are controlled
> by the I/O block SYS_SYSCON (starting there at offset 0x18), according
> to the public datasheets. All(?) other clocks are derived from those in
> the *_CRG units. That *is* the hardware to be described, in *the* (one
> and only!) DT. U-Boot, and any OS, are free to reorganise their driver
> framework around that, but the hardware description is quite clear.

The dt-binding that is in this series specifies that the pll clock
controller is a child of the syscon:
https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#Z2e.:..:20230512022036.97987-6-xingyu.wu::40starfivetech.com:1soc:starfive:starfive::2cjh7110-syscon.yaml

That seems correct to me & U-Boot's devicetree is not compliant.

> > > >> > These defines/numbers appear in the dts and are part of the DT
> > > >> > ABI. The same dts is supposed to work for Linux & U-Boot.
> > > >> 
> > > >> The JH7110 has 6 blocks of 64k iomem in that functional area:
> > > >> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
> > > >> The good news: the current DTS, as proposed here and in U-Boot
> > > >> master, provides nodes for all 6 entities. The bad news is that
> > > >> the clock assignments to those nodes and their numbering is
> > > >> messed up.
> > > >> 
> > > >> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot
> > > >> gets it wrong, in addition to the erroneous DTS.
> > > > 
> > > > The numbers are kinda hocus-pocus anyway, they are just made up
> > > > since the clock numbering usually isn't something with a nice TRM
> > > > to go and reference (unlike interrupts which usually are
> > > > documented in that way). It is very helpful to make them aligned
> > > > some register/bit positions or, but that is not required.
> > > > IOW U-Boot is not wrong per se to use 190 instead of 0, but it is
> > > > wrong to have different numbers in both places.
> 
> U-Boot reuses the Common Clock Framework from Linux, and I'm not sure
> whether the clock IDs need to be unique in order for the appropriate
> clock to be found.

Unique within the clock controller, otherwise it is impossible to tell
the difference between <&cctrl 1> and <&cctrl 1> apart! (The same
follows even with increased #clock-cells, something must be unique).
That's besides the point of this particular issue though.

> But that would be the only restriction, if it
> applies. Even then, each driver could register a clock with its own,
> arbitrarily chosen base offset with the CCF, so each CRG unit could
> still have its own clocks enumerated starting with 0 in the DTB.
> 
> > > > It sounds like you're saying that (and I have not looked) the
> > > > U-Boot dts actually has structural difference w.r.t. what
> > > > provides which clock? If so, that'll need to be fixed
> > > > independently of the numbering problem.
> 
> > > 
> > > Oh, unfortunately, the 7110 can not support to mix the uboot dtb
> > > and linux dtb up.
> > 
> > What does "cannot support" mean? It's normal and desirable for the
> 
> IMHO "desirable" is too weak.

Yeah, agreed. I just don't like being prescriptive about what happens in
projects that I do not maintain things for I guess.

> > same dtb to be usable for both. The Linux kernel's dt-bindings are
> > used for multiple projects, not just Linux - it'd be silly for
> > U-Boot, FreeBSD etc etc to go off and each have their open set of
> > (incompatible) bindings.
> > 
> > > If boot the Linux and should use the linux dtb instead of the uboot
> > > dtb. Because all clock ids and reset ids in Linux and Uboot are
> > > different include PLL, and some modules can work in Linux but not
> > > in uboot.
> [...]
> > 
> > > I suggest to boot Linux with its own linux dtb.
> 
> This is a fragile band-aid, to be used only as a last resort. It
> creates more problems than it solves. Your DTB will then match your
> kernel, but whether it describes the actual hardware is a game of
> chance. Doesn't the VisionFive2 have an RPi connector... ?
> 
> One of the IMO few valid use cases of adding a DTB to the kernel
> at boot is OpenWRT, when you build an OS Image for a particular piece
> of hardware you have at hand.
> 
> > I suggest to make sure that you can use the same dtb for both.
> 
> Interestingly enough, U-Boot already has the PLL driver in a separate
> file. I have a half-baked patch here that moves the sys_syscon DT
> matching into that file...

If you have patches that fix the devicetree & drivers in U-Boot, please
post them. I don't really care at all which set of arbitrary numbers are
chosen (as long as there is one and one only) but it looks like U-Boot's
devicetree has an incorrect description of the clock controllers.

Thanks,
Conor.
  

On 2023/5/26 20:23, Conor Dooley wrote:
> On Fri, May 26, 2023 at 09:34:32AM +0200, Torsten Duwe wrote:
>> On Wed, 24 May 2023 11:19:48 +0100
>> Conor Dooley <conor.dooley@microchip.com> wrote:
>> 
>> > On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
>> > > On 2023/5/23 19:28, Conor Dooley wrote:
>> > > > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
>> > > >> On Tue, 23 May 2023 09:28:39 +0100
>> > > >> Conor Dooley <conor.dooley@microchip.com> wrote:
>> > > >> 
>> > > >> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
>> > > >> > > On 2023/5/19 22:16, Conor Dooley wrote:
>> > > >> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe
>> > > >> > > > wrote:
>> > > >> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
>> [...]
>> 
>> > > >> > > Because PLL driver is separated from SYSCRG drivers in
>> > > >> > > Linux, the numbering starts from 0. But in Uboot, the PLL
>> > > >> > > driver is included in the SYSCRG driver, and the number
>> > > >> > > follows the SYSCRG.
>> > > >> > 
>> > > >> > Unfortunately, how you choose to construct your drivers has
>> > > >> > nothing to do with this.
>> 
>> Exactly. As I wrote (quote below), the PLLx frequencies are controlled
>> by the I/O block SYS_SYSCON (starting there at offset 0x18), according
>> to the public datasheets. All(?) other clocks are derived from those in
>> the *_CRG units. That *is* the hardware to be described, in *the* (one
>> and only!) DT. U-Boot, and any OS, are free to reorganise their driver
>> framework around that, but the hardware description is quite clear.
> 
> The dt-binding that is in this series specifies that the pll clock
> controller is a child of the syscon:
> https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#Z2e.:..:20230512022036.97987-6-xingyu.wu::40starfivetech.com:1soc:starfive:starfive::2cjh7110-syscon.yaml
> 
> That seems correct to me & U-Boot's devicetree is not compliant.
> 
>> > > >> > These defines/numbers appear in the dts and are part of the DT
>> > > >> > ABI. The same dts is supposed to work for Linux & U-Boot.
>> > > >> 
>> > > >> The JH7110 has 6 blocks of 64k iomem in that functional area:
>> > > >> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
>> > > >> The good news: the current DTS, as proposed here and in U-Boot
>> > > >> master, provides nodes for all 6 entities. The bad news is that
>> > > >> the clock assignments to those nodes and their numbering is
>> > > >> messed up.
>> > > >> 
>> > > >> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot
>> > > >> gets it wrong, in addition to the erroneous DTS.
>> > > > 
>> > > > The numbers are kinda hocus-pocus anyway, they are just made up
>> > > > since the clock numbering usually isn't something with a nice TRM
>> > > > to go and reference (unlike interrupts which usually are
>> > > > documented in that way). It is very helpful to make them aligned
>> > > > some register/bit positions or, but that is not required.
>> > > > IOW U-Boot is not wrong per se to use 190 instead of 0, but it is
>> > > > wrong to have different numbers in both places.
>> 
>> U-Boot reuses the Common Clock Framework from Linux, and I'm not sure
>> whether the clock IDs need to be unique in order for the appropriate
>> clock to be found.
> 
> Unique within the clock controller, otherwise it is impossible to tell
> the difference between <&cctrl 1> and <&cctrl 1> apart! (The same
> follows even with increased #clock-cells, something must be unique).
> That's besides the point of this particular issue though.
> 
>> But that would be the only restriction, if it
>> applies. Even then, each driver could register a clock with its own,
>> arbitrarily chosen base offset with the CCF, so each CRG unit could
>> still have its own clocks enumerated starting with 0 in the DTB.
>> 
>> > > > It sounds like you're saying that (and I have not looked) the
>> > > > U-Boot dts actually has structural difference w.r.t. what
>> > > > provides which clock? If so, that'll need to be fixed
>> > > > independently of the numbering problem.
>> 
>> > > 
>> > > Oh, unfortunately, the 7110 can not support to mix the uboot dtb
>> > > and linux dtb up.
>> > 
>> > What does "cannot support" mean? It's normal and desirable for the
>> 
>> IMHO "desirable" is too weak.
> 
> Yeah, agreed. I just don't like being prescriptive about what happens in
> projects that I do not maintain things for I guess.
> 
>> > same dtb to be usable for both. The Linux kernel's dt-bindings are
>> > used for multiple projects, not just Linux - it'd be silly for
>> > U-Boot, FreeBSD etc etc to go off and each have their open set of
>> > (incompatible) bindings.
>> > 
>> > > If boot the Linux and should use the linux dtb instead of the uboot
>> > > dtb. Because all clock ids and reset ids in Linux and Uboot are
>> > > different include PLL, and some modules can work in Linux but not
>> > > in uboot.
>> [...]
>> > 
>> > > I suggest to boot Linux with its own linux dtb.
>> 
>> This is a fragile band-aid, to be used only as a last resort. It
>> creates more problems than it solves. Your DTB will then match your
>> kernel, but whether it describes the actual hardware is a game of
>> chance. Doesn't the VisionFive2 have an RPi connector... ?
>> 
>> One of the IMO few valid use cases of adding a DTB to the kernel
>> at boot is OpenWRT, when you build an OS Image for a particular piece
>> of hardware you have at hand.
>> 
>> > I suggest to make sure that you can use the same dtb for both.
>> 
>> Interestingly enough, U-Boot already has the PLL driver in a separate
>> file. I have a half-baked patch here that moves the sys_syscon DT
>> matching into that file...
> 
> If you have patches that fix the devicetree & drivers in U-Boot, please
> post them. I don't really care at all which set of arbitrary numbers are
> chosen (as long as there is one and one only) but it looks like U-Boot's
> devicetree has an incorrect description of the clock controllers.
> 

Thank you for your suggestions. I will discuss with my partners how to solve this problem.

Best regards,
Xingyu Wu
  

On Tue, 23 May 2023 10:56:43 +0800
Xingyu Wu <xingyu.wu@starfivetech.com> wrote:

> On 2023/5/19 22:16, Conor Dooley wrote:
> > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
> >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> >> [...]
> >> >  #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
> >> >  #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
> >> >  
> >> > +/* PLL clocks */
> >> > +#define JH7110_CLK_PLL0_OUT			0
> >> > +#define JH7110_CLK_PLL1_OUT			1
> >> > +#define JH7110_CLK_PLL2_OUT			2
> >> 
> >> In U-Boot commit 58c9c60b Yanhong Wang added:
> >> 
> >> +
> >> +#define JH7110_SYSCLK_PLL0_OUT                       190
> >> +#define JH7110_SYSCLK_PLL1_OUT                       191
> >> +#define JH7110_SYSCLK_PLL2_OUT                       192
> >> +
> >> +#define JH7110_SYSCLK_END                    193
> >> 
> >> in that respective file.
> >> 
> >> > +#define JH7110_PLLCLK_END			3
> >> > +
> >> >  /* SYSCRG clocks */
> >> >  #define JH7110_SYSCLK_CPU_ROOT			0
> >> 
> >> If the symbolic names referred to the same items, would it be possible
> >> to keep the two files in sync somehow?
> > 
> > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it won't
> > understand the numbering. The headers are part of the dt-binding :/
> 
> Because PLL driver is separated from SYSCRG drivers in Linux,

Can you _please_ point me at that "PLL driver" "in Linux" ?
I seem to be unable to find it. All I can see is a stub in
drivers/clk/starfive/clk-starfive-jh7110-sys.c, which simply
sets the PLLs to 1000, 1066 and 1188 MHz fixed, respectively.

The comment above says

| They will be dropped and registered in the PLL clock driver instead.

and that's the one I'm looking for.

Thanks,

	Torsten
  

On Fri, Jun 02, 2023 at 06:39:22PM +0200, Torsten Duwe wrote:
> On Tue, 23 May 2023 10:56:43 +0800
> Xingyu Wu <xingyu.wu@starfivetech.com> wrote:
> 
> > On 2023/5/19 22:16, Conor Dooley wrote:
> > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
> > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> > >> [...]
> > >> >  #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
> > >> >  #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__
> > >> >  
> > >> > +/* PLL clocks */
> > >> > +#define JH7110_CLK_PLL0_OUT			0
> > >> > +#define JH7110_CLK_PLL1_OUT			1
> > >> > +#define JH7110_CLK_PLL2_OUT			2
> > >> 
> > >> In U-Boot commit 58c9c60b Yanhong Wang added:
> > >> 
> > >> +
> > >> +#define JH7110_SYSCLK_PLL0_OUT                       190
> > >> +#define JH7110_SYSCLK_PLL1_OUT                       191
> > >> +#define JH7110_SYSCLK_PLL2_OUT                       192
> > >> +
> > >> +#define JH7110_SYSCLK_END                    193
> > >> 
> > >> in that respective file.
> > >> 
> > >> > +#define JH7110_PLLCLK_END			3
> > >> > +
> > >> >  /* SYSCRG clocks */
> > >> >  #define JH7110_SYSCLK_CPU_ROOT			0
> > >> 
> > >> If the symbolic names referred to the same items, would it be possible
> > >> to keep the two files in sync somehow?
> > > 
> > > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it won't
> > > understand the numbering. The headers are part of the dt-binding :/
> > 
> > Because PLL driver is separated from SYSCRG drivers in Linux,
> 
> Can you _please_ point me at that "PLL driver" "in Linux" ?

It's patch 2 in this series:
https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#m4b2d74c36b3bb961a1187ec5cda1a0a0de875f0e

HTH,
Conor.

> I seem to be unable to find it. All I can see is a stub in
> drivers/clk/starfive/clk-starfive-jh7110-sys.c, which simply
> sets the PLLs to 1000, 1066 and 1188 MHz fixed, respectively.
> 
> The comment above says
> 
> | They will be dropped and registered in the PLL clock driver instead.
> 
> and that's the one I'm looking for.
> 
> Thanks,
> 
> 	Torsten
  

On Fri, Jun 02, 2023 at 05:43:25PM +0100, Conor Dooley wrote:
> > 
> > Can you _please_ point me at that "PLL driver" "in Linux" ?
> 
> It's patch 2 in this series:
> https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#m4b2d74c36b3bb961a1187ec5cda1a0a0de875f0e
> 
Unfortunately, it's not, AFAICS. I'm looking for the driver that
will control the PLLs' parameters, grepping for "pll" should yield
results, to start with. The thing should act on the SYS_SYSCON iomem,
at 0x13030000. Ideally, a DT node should point it there...

	Torsten
  

On Fri, Jun 02, 2023 at 06:57:13PM +0200, Torsten Duwe wrote:
> On Fri, Jun 02, 2023 at 05:43:25PM +0100, Conor Dooley wrote:
> > > 
> > > Can you _please_ point me at that "PLL driver" "in Linux" ?
> > 
> > It's patch 2 in this series:
> > https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#m4b2d74c36b3bb961a1187ec5cda1a0a0de875f0e
> > 
> Unfortunately, it's not, AFAICS. I'm looking for the driver that
> will control the PLLs' parameters, grepping for "pll" should yield
> results, to start with. The thing should act on the SYS_SYSCON iomem,
> at 0x13030000. Ideally, a DT node should point it there...

The driver binds against a child node of the syscon @ 1303_0000:
https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#m882de9210850eb6f871cafc3418f3202ba915de8

Am I missing something?

Cheers,
Conor.
  

On Fri, Jun 02, 2023 at 05:59:29PM +0100, Conor Dooley wrote:
> On Fri, Jun 02, 2023 at 06:57:13PM +0200, Torsten Duwe wrote:
> > On Fri, Jun 02, 2023 at 05:43:25PM +0100, Conor Dooley wrote:
> > > > 
> > > > Can you _please_ point me at that "PLL driver" "in Linux" ?
> > > 
> > > It's patch 2 in this series:
> > > https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#m4b2d74c36b3bb961a1187ec5cda1a0a0de875f0e
> > > 
> > Unfortunately, it's not, AFAICS. I'm looking for the driver that
> > will control the PLLs' parameters, grepping for "pll" should yield
> > results, to start with. The thing should act on the SYS_SYSCON iomem,
> > at 0x13030000. Ideally, a DT node should point it there...
> 
> The driver binds against a child node of the syscon @ 1303_0000:
> https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#m882de9210850eb6f871cafc3418f3202ba915de8
> 
> Am I missing something?

No, you're right. Seems I took a wrong turn somewhere. I prefer
patchwork, where available, and probably got into the wrong series.
Found the correct one:

https://patchwork.kernel.org/project/linux-riscv/patch/20230512022036.97987-3-xingyu.wu@starfivetech.com/

Now only the device tree needs to match against that, and U-Boot
needs to remain still functional...

Thanks and sorry for the noise.

	Torsten
  

On 2023/5/26 20:23, Conor Dooley wrote:
> On Fri, May 26, 2023 at 09:34:32AM +0200, Torsten Duwe wrote:
>> On Wed, 24 May 2023 11:19:48 +0100
>> Conor Dooley <conor.dooley@microchip.com> wrote:
>> 
>> > On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
>> > > On 2023/5/23 19:28, Conor Dooley wrote:
>> > > > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
>> > > >> On Tue, 23 May 2023 09:28:39 +0100
>> > > >> Conor Dooley <conor.dooley@microchip.com> wrote:
>> > > >> 
>> > > >> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
>> > > >> > > On 2023/5/19 22:16, Conor Dooley wrote:
>> > > >> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe
>> > > >> > > > wrote:
>> > > >> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
>> [...]
>> 
>> > > >> > > Because PLL driver is separated from SYSCRG drivers in
>> > > >> > > Linux, the numbering starts from 0. But in Uboot, the PLL
>> > > >> > > driver is included in the SYSCRG driver, and the number
>> > > >> > > follows the SYSCRG.
>> > > >> > 
>> > > >> > Unfortunately, how you choose to construct your drivers has
>> > > >> > nothing to do with this.
>> 
>> Exactly. As I wrote (quote below), the PLLx frequencies are controlled
>> by the I/O block SYS_SYSCON (starting there at offset 0x18), according
>> to the public datasheets. All(?) other clocks are derived from those in
>> the *_CRG units. That *is* the hardware to be described, in *the* (one
>> and only!) DT. U-Boot, and any OS, are free to reorganise their driver
>> framework around that, but the hardware description is quite clear.
> 
> The dt-binding that is in this series specifies that the pll clock
> controller is a child of the syscon:
> https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu.wu@starfivetech.com/T/#Z2e.:..:20230512022036.97987-6-xingyu.wu::40starfivetech.com:1soc:starfive:starfive::2cjh7110-syscon.yaml
> 
> That seems correct to me & U-Boot's devicetree is not compliant.
> 
>> > > >> > These defines/numbers appear in the dts and are part of the DT
>> > > >> > ABI. The same dts is supposed to work for Linux & U-Boot.
>> > > >> 
>> > > >> The JH7110 has 6 blocks of 64k iomem in that functional area:
>> > > >> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
>> > > >> The good news: the current DTS, as proposed here and in U-Boot
>> > > >> master, provides nodes for all 6 entities. The bad news is that
>> > > >> the clock assignments to those nodes and their numbering is
>> > > >> messed up.
>> > > >> 
>> > > >> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot
>> > > >> gets it wrong, in addition to the erroneous DTS.
>> > > > 
>> > > > The numbers are kinda hocus-pocus anyway, they are just made up
>> > > > since the clock numbering usually isn't something with a nice TRM
>> > > > to go and reference (unlike interrupts which usually are
>> > > > documented in that way). It is very helpful to make them aligned
>> > > > some register/bit positions or, but that is not required.
>> > > > IOW U-Boot is not wrong per se to use 190 instead of 0, but it is
>> > > > wrong to have different numbers in both places.
>> 
>> U-Boot reuses the Common Clock Framework from Linux, and I'm not sure
>> whether the clock IDs need to be unique in order for the appropriate
>> clock to be found.
> 
> Unique within the clock controller, otherwise it is impossible to tell
> the difference between <&cctrl 1> and <&cctrl 1> apart! (The same
> follows even with increased #clock-cells, something must be unique).
> That's besides the point of this particular issue though.
> 
>> But that would be the only restriction, if it
>> applies. Even then, each driver could register a clock with its own,
>> arbitrarily chosen base offset with the CCF, so each CRG unit could
>> still have its own clocks enumerated starting with 0 in the DTB.
>> 
>> > > > It sounds like you're saying that (and I have not looked) the
>> > > > U-Boot dts actually has structural difference w.r.t. what
>> > > > provides which clock? If so, that'll need to be fixed
>> > > > independently of the numbering problem.
>> 
>> > > 
>> > > Oh, unfortunately, the 7110 can not support to mix the uboot dtb
>> > > and linux dtb up.
>> > 
>> > What does "cannot support" mean? It's normal and desirable for the
>> 
>> IMHO "desirable" is too weak.
> 
> Yeah, agreed. I just don't like being prescriptive about what happens in
> projects that I do not maintain things for I guess.
> 
>> > same dtb to be usable for both. The Linux kernel's dt-bindings are
>> > used for multiple projects, not just Linux - it'd be silly for
>> > U-Boot, FreeBSD etc etc to go off and each have their open set of
>> > (incompatible) bindings.
>> > 
>> > > If boot the Linux and should use the linux dtb instead of the uboot
>> > > dtb. Because all clock ids and reset ids in Linux and Uboot are
>> > > different include PLL, and some modules can work in Linux but not
>> > > in uboot.
>> [...]
>> > 
>> > > I suggest to boot Linux with its own linux dtb.
>> 
>> This is a fragile band-aid, to be used only as a last resort. It
>> creates more problems than it solves. Your DTB will then match your
>> kernel, but whether it describes the actual hardware is a game of
>> chance. Doesn't the VisionFive2 have an RPi connector... ?
>> 
>> One of the IMO few valid use cases of adding a DTB to the kernel
>> at boot is OpenWRT, when you build an OS Image for a particular piece
>> of hardware you have at hand.
>> 
>> > I suggest to make sure that you can use the same dtb for both.
>> 
>> Interestingly enough, U-Boot already has the PLL driver in a separate
>> file. I have a half-baked patch here that moves the sys_syscon DT
>> matching into that file...
> 
> If you have patches that fix the devicetree & drivers in U-Boot, please
> post them. I don't really care at all which set of arbitrary numbers are
> chosen (as long as there is one and one only) but it looks like U-Boot's
> devicetree has an incorrect description of the clock controllers.
> 

Hi Conor and Torsten,
After our internal discussions, it was decided to make the change on Uboot.
The clock id in Uboot are changed to be same with Linux and the PLL clocks become the child node of SYSCON.
And we will send this patch on Uboot soon.

Best Regards,
Xingyu Wu