diff mbox series

[v7,1/5] dt-bindings: Add the r9a06g032-sysctrl.h file

Message ID 1527154169-32380-2-git-send-email-michel.pollet@bp.renesas.com
State Not Applicable, archived
Headers show
Series arm: Base support for Renesas RZN1D-DB Board | expand

Commit Message

Michel Pollet May 24, 2018, 9:28 a.m. UTC
This adds the constants necessary to use the renesas,r9a06g032-sysctrl node.

Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 include/dt-bindings/clock/r9a06g032-sysctrl.h | 187 ++++++++++++++++++++++++++
 1 file changed, 187 insertions(+)
 create mode 100644 include/dt-bindings/clock/r9a06g032-sysctrl.h

Comments

Geert Uytterhoeven May 25, 2018, 10:31 a.m. UTC | #1
Hi Michel,

On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> This adds the constants necessary to use the renesas,r9a06g032-sysctrl node.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>

Thanks for your patch!

> --- /dev/null
> +++ b/include/dt-bindings/clock/r9a06g032-sysctrl.h

You can still call this file r9a06g032-clocks.h, if you want, as it
contains clock definitions only.

> @@ -0,0 +1,187 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * R9A06G032 sysctrl IDs
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> + * Derived from zx-reboot.c
> + */
> +
> +#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> +#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> +
> +#define R9A06G032_CLKOUT                       0
> +#define R9A06G032_CLK_PLL_USB                  1
> +#define R9A06G032_CLK_48                       1 /* AKA CLK_PLL_USB */
> +#define R9A06G032_CLKOUT_D10                   2
> +#define R9A06G032_CLKOUT_D16                   3
> +#define R9A06G032_MSEBIS_CLK                   3 /* AKA CLKOUT_D16 */
> +#define R9A06G032_MSEBIM_CLK                   3 /* AKA CLKOUT_D16 */
> +#define R9A06G032_CLKOUT_D160                  4
> +#define R9A06G032_CLKOUT_D1OR2                 5
> +#define R9A06G032_CLK_DDRPHY_PLLCLK            5 /* AKA CLKOUT_D1OR2 */

[...]

I have 3 comments:

  1. I had expected this list to match (both name- and order-wise) Appendix
     C ("Clock Tree Structure") in the RZ/N1[DSL] User’s Manual: System
     Introduction, Multiplexing, Electrical and Mechanical Information.
     That would make it easier to review.

  2. These definitions seems to be a mix of:
       1. Internal core clocks,
       2. Other core clocks,
       3. Module clocks.

     The internal clocks do not need to be referenced from DT, so I would
     not make them part of the DT bindings.

  3. It looks like the module clocks can be referred to by register offset
     and bit position, which is similar to how this is handled on R-Car
     SoCs.
     Perhaps you can just drop the definitions for these from the header
     file, and refer to them by (combined) register offset and bit position
     instead?
     Or am I missing something?
     I believe this can also be done for the module resets (later).

Thanks again!

Gr{oetje,eeting}s,

                        Geert
M P May 31, 2018, 9:11 a.m. UTC | #2
On Fri, 25 May 2018 at 11:31, Geert Uytterhoeven <geert@linux-m68k.org>
wrote:

> Hi Michel,

Hi Geert,


> On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
> <michel.pollet@bp.renesas.com> wrote:
> > This adds the constants necessary to use the renesas,r9a06g032-sysctrl
node.
> >
> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>

> Thanks for your patch!

> > --- /dev/null
> > +++ b/include/dt-bindings/clock/r9a06g032-sysctrl.h

> You can still call this file r9a06g032-clocks.h, if you want, as it
> contains clock definitions only.

Well, having renamed the node, I thought it made sense to keep the naming
consistent. Any further #define could be added to here instead of having to
add another file...


> > @@ -0,0 +1,187 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * R9A06G032 sysctrl IDs
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
> > + *
> > + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> > + * Derived from zx-reboot.c
> > + */
> > +
> > +#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> > +#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> > +
> > +#define R9A06G032_CLKOUT                       0
> > +#define R9A06G032_CLK_PLL_USB                  1
> > +#define R9A06G032_CLK_48                       1 /* AKA CLK_PLL_USB */
> > +#define R9A06G032_CLKOUT_D10                   2
> > +#define R9A06G032_CLKOUT_D16                   3
> > +#define R9A06G032_MSEBIS_CLK                   3 /* AKA CLKOUT_D16 */
> > +#define R9A06G032_MSEBIM_CLK                   3 /* AKA CLKOUT_D16 */
> > +#define R9A06G032_CLKOUT_D160                  4
> > +#define R9A06G032_CLKOUT_D1OR2                 5
> > +#define R9A06G032_CLK_DDRPHY_PLLCLK            5 /* AKA CLKOUT_D1OR2 */

> [...]

> I have 3 comments:

>    1. I had expected this list to match (both name- and order-wise)
Appendix
>       C ("Clock Tree Structure") in the RZ/N1[DSL] User’s Manual: System
>       Introduction, Multiplexing, Electrical and Mechanical Information.
>       That would make it easier to review.

Well, that document was made a *long* time after the internal documentation
we used to generate the clock lists. There are a few things we had to do:

* Renumber peripherals. We decided a long time ago that u-boot and linux
would stick to zero based peripherals, and not one based numbers. It's next
to impossible to keep mixing number based across software base, so we use
UART0 while the hardware manual mentions UART1 -- It *is* documented
extensively with out SDK, and makes life using linux a lot easier. It's
across all our SDK, u-boot, webapps readmes, howtos etc.

* Rename some peripherals. Plenty of peripherals names made little sense
and had zero consistency, in fact, many names were different depending on
the place they were used! -- "flashnand"+"nand_flash"+"FNAND" etc,
"QUADSPI"+"QSPI" etc etc so we also re-normalized the names to match linux
conventions.

* Other internal reasons I can't document here

Also, the value here are made up anyway -- so I've decided to sort them to
make sure any clock that has a parent is numbered *after* the parent...

>    2. These definitions seems to be a mix of:
>         1. Internal core clocks,
>         2. Other core clocks,
>         3. Module clocks.

>       The internal clocks do not need to be referenced from DT, so I would
>       not make them part of the DT bindings.

Why? I'm told that "Bindings aren't for linux" -- why can't I imagine
'something' needing them? Why would I decide NOT to include them,
as they are there? I 'factored' a few of them to the same number when
applicable.

This is all done automatically BTW -- a script takes the original clocking
spreadsheet, and converts it into a table, correcting 'human input' as it
goes along.

>    3. It looks like the module clocks can be referred to by register offset
>       and bit position, which is similar to how this is handled on R-Car
>       SoCs.
>       Perhaps you can just drop the definitions for these from the header
>       file, and refer to them by (combined) register offset and bit
position
>       instead?
>       Or am I missing something?
>       I believe this can also be done for the module resets (later).

If you look in the .c file, you'll see that most gate have not just one
register/bit pair associated with them -- there are several, spread
across registers.. Also, there are clocks in there with two gates,
or none. Given that, I've decided a separate numbering
made sense.
As mentioned, it's arbitrary, with 'root' clocks numbered lowered than
sub-clocks.

Thank you!

Michel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven May 31, 2018, 9:32 a.m. UTC | #3
Hi Michel,

On Thu, May 31, 2018 at 11:11 AM, M P <buserror@gmail.com> wrote:
> On Fri, 25 May 2018 at 11:31, Geert Uytterhoeven <geert@linux-m68k.org>
> wrote:
>> On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
>> <michel.pollet@bp.renesas.com> wrote:
>> > This adds the constants necessary to use the renesas,r9a06g032-sysctrl
> node.

>> > @@ -0,0 +1,187 @@
>> > +/* SPDX-License-Identifier: GPL-2.0 */
>> > +/*
>> > + * R9A06G032 sysctrl IDs
>> > + *
>> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
>> > + *
>> > + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
>> > + * Derived from zx-reboot.c
>> > + */
>> > +
>> > +#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
>> > +#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
>> > +
>> > +#define R9A06G032_CLKOUT                       0
>> > +#define R9A06G032_CLK_PLL_USB                  1
>> > +#define R9A06G032_CLK_48                       1 /* AKA CLK_PLL_USB */
>> > +#define R9A06G032_CLKOUT_D10                   2
>> > +#define R9A06G032_CLKOUT_D16                   3
>> > +#define R9A06G032_MSEBIS_CLK                   3 /* AKA CLKOUT_D16 */
>> > +#define R9A06G032_MSEBIM_CLK                   3 /* AKA CLKOUT_D16 */
>> > +#define R9A06G032_CLKOUT_D160                  4
>> > +#define R9A06G032_CLKOUT_D1OR2                 5
>> > +#define R9A06G032_CLK_DDRPHY_PLLCLK            5 /* AKA CLKOUT_D1OR2 */
>
>> [...]
>
>> I have 3 comments:
>
>>    1. I had expected this list to match (both name- and order-wise)
> Appendix
>>       C ("Clock Tree Structure") in the RZ/N1[DSL] User’s Manual: System
>>       Introduction, Multiplexing, Electrical and Mechanical Information.
>>       That would make it easier to review.
>
> Well, that document was made a *long* time after the internal documentation
> we used to generate the clock lists. There are a few things we had to do:
>
> * Renumber peripherals. We decided a long time ago that u-boot and linux
> would stick to zero based peripherals, and not one based numbers. It's next
> to impossible to keep mixing number based across software base, so we use
> UART0 while the hardware manual mentions UART1 -- It *is* documented
> extensively with out SDK, and makes life using linux a lot easier. It's
> across all our SDK, u-boot, webapps readmes, howtos etc.
>
> * Rename some peripherals. Plenty of peripherals names made little sense
> and had zero consistency, in fact, many names were different depending on
> the place they were used! -- "flashnand"+"nand_flash"+"FNAND" etc,
> "QUADSPI"+"QSPI" etc etc so we also re-normalized the names to match linux
> conventions.
>
> * Other internal reasons I can't document here
>
> Also, the value here are made up anyway -- so I've decided to sort them to
> make sure any clock that has a parent is numbered *after* the parent...

Well, all of that combines makes it very hard for us to review the list.

>>    2. These definitions seems to be a mix of:
>>         1. Internal core clocks,
>>         2. Other core clocks,
>>         3. Module clocks.
>
>>       The internal clocks do not need to be referenced from DT, so I would
>>       not make them part of the DT bindings.
>
> Why? I'm told that "Bindings aren't for linux" -- why can't I imagine
> 'something' needing them? Why would I decide NOT to include them,
> as they are there? I 'factored' a few of them to the same number when

Just general safety w.r.t. unchangeable DT definitions: anything that is
not listed here cannot be declared wrong later.

> applicable.

You're 100% sure they're the same?

> This is all done automatically BTW -- a script takes the original clocking
> spreadsheet, and converts it into a table, correcting 'human input' as it
> goes along.

So the internal spreadsheet doesn't match the public documentation neither?

>>    3. It looks like the module clocks can be referred to by register offset
>>       and bit position, which is similar to how this is handled on R-Car
>>       SoCs.
>>       Perhaps you can just drop the definitions for these from the header
>>       file, and refer to them by (combined) register offset and bit
> position
>>       instead?
>>       Or am I missing something?
>>       I believe this can also be done for the module resets (later).
>
> If you look in the .c file, you'll see that most gate have not just one
> register/bit pair associated with them -- there are several, spread
> across registers.. Also, there are clocks in there with two gates,
> or none. Given that, I've decided a separate numbering
> made sense.

OK, fair enough.

Gr{oetje,eeting}s,

                        Geert
M P May 31, 2018, 10:01 a.m. UTC | #4
Hi Geert,

On Thu, 31 May 2018 at 10:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Michel,
>
> On Thu, May 31, 2018 at 11:11 AM, M P <buserror@gmail.com> wrote:
> > On Fri, 25 May 2018 at 11:31, Geert Uytterhoeven <geert@linux-m68k.org>
> > wrote:
> >> On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
> >> <michel.pollet@bp.renesas.com> wrote:
> >> > This adds the constants necessary to use the renesas,r9a06g032-sysctrl
> > node.
>
> >> > @@ -0,0 +1,187 @@
> >> > +/* SPDX-License-Identifier: GPL-2.0 */
> >> > +/*
> >> > + * R9A06G032 sysctrl IDs
> >> > + *
> >> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
> >> > + *
> >> > + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> >> > + * Derived from zx-reboot.c
> >> > + */
> >> > +
> >> > +#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> >> > +#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> >> > +
> >> > +#define R9A06G032_CLKOUT                       0
> >> > +#define R9A06G032_CLK_PLL_USB                  1
> >> > +#define R9A06G032_CLK_48                       1 /* AKA CLK_PLL_USB */
> >> > +#define R9A06G032_CLKOUT_D10                   2
> >> > +#define R9A06G032_CLKOUT_D16                   3
> >> > +#define R9A06G032_MSEBIS_CLK                   3 /* AKA CLKOUT_D16 */
> >> > +#define R9A06G032_MSEBIM_CLK                   3 /* AKA CLKOUT_D16 */
> >> > +#define R9A06G032_CLKOUT_D160                  4
> >> > +#define R9A06G032_CLKOUT_D1OR2                 5
> >> > +#define R9A06G032_CLK_DDRPHY_PLLCLK            5 /* AKA CLKOUT_D1OR2 */
> >
> >> [...]
> >
> >> I have 3 comments:
> >
> >>    1. I had expected this list to match (both name- and order-wise)
> > Appendix
> >>       C ("Clock Tree Structure") in the RZ/N1[DSL] User’s Manual: System
> >>       Introduction, Multiplexing, Electrical and Mechanical Information.
> >>       That would make it easier to review.
> >
> > Well, that document was made a *long* time after the internal documentation
> > we used to generate the clock lists. There are a few things we had to do:
> >
> > * Renumber peripherals. We decided a long time ago that u-boot and linux
> > would stick to zero based peripherals, and not one based numbers. It's next
> > to impossible to keep mixing number based across software base, so we use
> > UART0 while the hardware manual mentions UART1 -- It *is* documented
> > extensively with out SDK, and makes life using linux a lot easier. It's
> > across all our SDK, u-boot, webapps readmes, howtos etc.
> >
> > * Rename some peripherals. Plenty of peripherals names made little sense
> > and had zero consistency, in fact, many names were different depending on
> > the place they were used! -- "flashnand"+"nand_flash"+"FNAND" etc,
> > "QUADSPI"+"QSPI" etc etc so we also re-normalized the names to match linux
> > conventions.
> >
> > * Other internal reasons I can't document here
> >
> > Also, the value here are made up anyway -- so I've decided to sort them to
> > make sure any clock that has a parent is numbered *after* the parent...
>
> Well, all of that combines makes it very hard for us to review the list.

I understand -- the previous format was a lot more readable, here I had to
work to make the table as small as I could, and quite a few bits of readability
were lost in the process. It's already a huge file.

I'm not sure if that would help, but here is the link to the old table
format I used
https://github.com/renesas-rz/rzn1_linux/blob/rzn1-stable/drivers/clk/rzn1/rzn1-clkctrl-tables.h

I had to throw that away to make up the new composite table that now contains
what was in the device tree file before. However the names are the same.

Perhaps I could change how I encode the register/bit pairs to use 8+8 bits to
make the hex constants more readable?

>
> >>    2. These definitions seems to be a mix of:
> >>         1. Internal core clocks,
> >>         2. Other core clocks,
> >>         3. Module clocks.
> >
> >>       The internal clocks do not need to be referenced from DT, so I would
> >>       not make them part of the DT bindings.
> >
> > Why? I'm told that "Bindings aren't for linux" -- why can't I imagine
> > 'something' needing them? Why would I decide NOT to include them,
> > as they are there? I 'factored' a few of them to the same number when
>
> Just general safety w.r.t. unchangeable DT definitions: anything that is
> not listed here cannot be declared wrong later.

Well, I need these #define *somewhere* as I use them in my driver. So what
do you want me to do?
+ Remove the header, move the constants into the driver?
+ Use hard coded numbers in the DT and remove the header entirely?
+ Duplicate the header, keep the full one with the driver, and only list
the CA7+UART0 one in the dt-binding and duplicate the ones I need as
I go along?

>
> > applicable.
>
> You're 100% sure they're the same?

Yes, the script logic hasn't changed in 2 years, and we've been using that
hierarchy extensively since.
Basically the logic is that if a clock doesn't have a gate and isn't a divisor
of some sort, it's factored with it's parent clock... it used to be
done with a DT
alias of the same name.

>
> > This is all done automatically BTW -- a script takes the original clocking
> > spreadsheet, and converts it into a table, correcting 'human input' as it
> > goes along.
>
> So the internal spreadsheet doesn't match the public documentation neither?

Nope, as usual, people who wrote the documentation went their own way at
some point, and didn't backport any changes they made.

> Gr{oetje,eeting}s,
>
>                         Geert

Cheers,
Michel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven June 1, 2018, 8:18 a.m. UTC | #5
Hi Michel,

On Thu, May 31, 2018 at 12:01 PM, M P <buserror@gmail.com> wrote:
> On Thu, 31 May 2018 at 10:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Thu, May 31, 2018 at 11:11 AM, M P <buserror@gmail.com> wrote:
>> > On Fri, 25 May 2018 at 11:31, Geert Uytterhoeven <geert@linux-m68k.org>
>> > wrote:
>> >> On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
>> >> <michel.pollet@bp.renesas.com> wrote:
>> >> > This adds the constants necessary to use the renesas,r9a06g032-sysctrl
>> > node.
>>
>> >> > @@ -0,0 +1,187 @@
>> >> > +/* SPDX-License-Identifier: GPL-2.0 */
>> >> > +/*
>> >> > + * R9A06G032 sysctrl IDs
>> >> > + *
>> >> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
>> >> > + *
>> >> > + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
>> >> > + * Derived from zx-reboot.c
>> >> > + */
>> >> > +
>> >> > +#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
>> >> > +#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
>> >> > +
>> >> > +#define R9A06G032_CLKOUT                       0
>> >> > +#define R9A06G032_CLK_PLL_USB                  1
>> >> > +#define R9A06G032_CLK_48                       1 /* AKA CLK_PLL_USB */
>> >> > +#define R9A06G032_CLKOUT_D10                   2
>> >> > +#define R9A06G032_CLKOUT_D16                   3
>> >> > +#define R9A06G032_MSEBIS_CLK                   3 /* AKA CLKOUT_D16 */
>> >> > +#define R9A06G032_MSEBIM_CLK                   3 /* AKA CLKOUT_D16 */
>> >> > +#define R9A06G032_CLKOUT_D160                  4
>> >> > +#define R9A06G032_CLKOUT_D1OR2                 5
>> >> > +#define R9A06G032_CLK_DDRPHY_PLLCLK            5 /* AKA CLKOUT_D1OR2 */
>> >
>> >> [...]
>> >
>> >> I have 3 comments:
>> >
>> >>    1. I had expected this list to match (both name- and order-wise)
>> > Appendix
>> >>       C ("Clock Tree Structure") in the RZ/N1[DSL] User’s Manual: System
>> >>       Introduction, Multiplexing, Electrical and Mechanical Information.
>> >>       That would make it easier to review.
>> >
>> > Well, that document was made a *long* time after the internal documentation
>> > we used to generate the clock lists. There are a few things we had to do:
>> >
>> > * Renumber peripherals. We decided a long time ago that u-boot and linux
>> > would stick to zero based peripherals, and not one based numbers. It's next
>> > to impossible to keep mixing number based across software base, so we use
>> > UART0 while the hardware manual mentions UART1 -- It *is* documented
>> > extensively with out SDK, and makes life using linux a lot easier. It's
>> > across all our SDK, u-boot, webapps readmes, howtos etc.
>> >
>> > * Rename some peripherals. Plenty of peripherals names made little sense
>> > and had zero consistency, in fact, many names were different depending on
>> > the place they were used! -- "flashnand"+"nand_flash"+"FNAND" etc,
>> > "QUADSPI"+"QSPI" etc etc so we also re-normalized the names to match linux
>> > conventions.
>> >
>> > * Other internal reasons I can't document here
>> >
>> > Also, the value here are made up anyway -- so I've decided to sort them to
>> > make sure any clock that has a parent is numbered *after* the parent...
>>
>> Well, all of that combines makes it very hard for us to review the list.
>
> I understand -- the previous format was a lot more readable, here I had to
> work to make the table as small as I could, and quite a few bits of readability
> were lost in the process. It's already a huge file.
>
> I'm not sure if that would help, but here is the link to the old table
> format I used
> https://github.com/renesas-rz/rzn1_linux/blob/rzn1-stable/drivers/clk/rzn1/rzn1-clkctrl-tables.h
>
> I had to throw that away to make up the new composite table that now contains
> what was in the device tree file before. However the names are the same.
>
> Perhaps I could change how I encode the register/bit pairs to use 8+8 bits to
> make the hex constants more readable?

Alternatively, you can use a macro to pack them, cfr. MOD_CLK_PACK()
in renesas-cpg-mssr.

>> >>    2. These definitions seems to be a mix of:
>> >>         1. Internal core clocks,
>> >>         2. Other core clocks,
>> >>         3. Module clocks.
>> >
>> >>       The internal clocks do not need to be referenced from DT, so I would
>> >>       not make them part of the DT bindings.
>> >
>> > Why? I'm told that "Bindings aren't for linux" -- why can't I imagine
>> > 'something' needing them? Why would I decide NOT to include them,
>> > as they are there? I 'factored' a few of them to the same number when
>>
>> Just general safety w.r.t. unchangeable DT definitions: anything that is
>> not listed here cannot be declared wrong later.
>
> Well, I need these #define *somewhere* as I use them in my driver. So what
> do you want me to do?
> + Remove the header, move the constants into the driver?
> + Use hard coded numbers in the DT and remove the header entirely?
> + Duplicate the header, keep the full one with the driver, and only list
> the CA7+UART0 one in the dt-binding and duplicate the ones I need as
> I go along?

None of these. You can just move the #defines that will never be needed
from DT into the driver source file.

Cfr. "Internal Core Clocks" in drivers/clk/renesas/r8a7795-cpg-mssr.c.

>> > applicable.
>>
>> You're 100% sure they're the same?
>
> Yes, the script logic hasn't changed in 2 years, and we've been using that
> hierarchy extensively since.
> Basically the logic is that if a clock doesn't have a gate and isn't a divisor
> of some sort, it's factored with it's parent clock... it used to be
> done with a DT
> alias of the same name.

OK.

>> > This is all done automatically BTW -- a script takes the original clocking
>> > spreadsheet, and converts it into a table, correcting 'human input' as it
>> > goes along.
>>
>> So the internal spreadsheet doesn't match the public documentation neither?
>
> Nope, as usual, people who wrote the documentation went their own way at
> some point, and didn't backport any changes they made.

Well, I guess we'll have to live with that...

Gr{oetje,eeting}s,

                        Geert
diff mbox series

Patch

diff --git a/include/dt-bindings/clock/r9a06g032-sysctrl.h b/include/dt-bindings/clock/r9a06g032-sysctrl.h
new file mode 100644
index 0000000..e3fe69e
--- /dev/null
+++ b/include/dt-bindings/clock/r9a06g032-sysctrl.h
@@ -0,0 +1,187 @@ 
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * R9A06G032 sysctrl IDs
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
+ * Derived from zx-reboot.c
+ */
+
+#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
+#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
+
+#define R9A06G032_CLKOUT			0
+#define R9A06G032_CLK_PLL_USB			1
+#define R9A06G032_CLK_48			1 /* AKA CLK_PLL_USB */
+#define R9A06G032_CLKOUT_D10			2
+#define R9A06G032_CLKOUT_D16			3
+#define R9A06G032_MSEBIS_CLK			3 /* AKA CLKOUT_D16 */
+#define R9A06G032_MSEBIM_CLK			3 /* AKA CLKOUT_D16 */
+#define R9A06G032_CLKOUT_D160			4
+#define R9A06G032_CLKOUT_D1OR2			5
+#define R9A06G032_CLK_DDRPHY_PLLCLK		5 /* AKA CLKOUT_D1OR2 */
+#define R9A06G032_CLKOUT_D20			6
+#define R9A06G032_CLK50				6 /* AKA CLKOUT_D20 */
+#define R9A06G032_CLKOUT_D40			7
+#define R9A06G032_CLK25				7 /* AKA CLKOUT_D40 */
+#define R9A06G032_CLKOUT_D5			8
+#define R9A06G032_CLKOUT_D8			9
+#define R9A06G032_CLK125			9 /* AKA CLKOUT_D8 */
+#define R9A06G032_DIV_ADC			10
+#define R9A06G032_DIV_I2C			11
+#define R9A06G032_DIV_NAND			12
+#define R9A06G032_DIV_P1_PG			13
+#define R9A06G032_DIV_P2_PG			14
+#define R9A06G032_DIV_P3_PG			15
+#define R9A06G032_DIV_P4_PG			16
+#define R9A06G032_DIV_P5_PG			17
+#define R9A06G032_CLK_P5_PG1			17 /* AKA DIV_P5_PG */
+#define R9A06G032_DIV_P6_PG			18
+#define R9A06G032_DIV_QSPI0			19
+#define R9A06G032_DIV_QSPI1			20
+#define R9A06G032_DIV_REF_SYNC			21
+#define R9A06G032_CLK_REF_SYNC			21 /* AKA DIV_REF_SYNC */
+#define R9A06G032_DIV_SDIO0			22
+#define R9A06G032_DIV_SDIO1			23
+#define R9A06G032_DIV_SWITCH			24
+#define R9A06G032_DIV_UART			25
+#define R9A06G032_CLK_25_PG4			26
+#define R9A06G032_CLK_25_PG5			27
+#define R9A06G032_CLK_25_PG6			28
+#define R9A06G032_CLK_25_PG7			29
+#define R9A06G032_CLK_25_PG8			30
+#define R9A06G032_CLK_ADC			31
+#define R9A06G032_CLK_ECAT100			32
+#define R9A06G032_CLK_HSR100			33
+#define R9A06G032_CLK_I2C0			34
+#define R9A06G032_CLK_I2C1			35
+#define R9A06G032_CLK_MII_REF			36
+#define R9A06G032_CLK_NAND			37
+#define R9A06G032_CLK_NOUSBP2_PG6		38
+#define R9A06G032_CLK_P1_PG2			39
+#define R9A06G032_CLK_P1_PG3			40
+#define R9A06G032_CLK_P1_PG4			41
+#define R9A06G032_CLK_P4_PG3			42
+#define R9A06G032_CLK_P4_PG4			43
+#define R9A06G032_CLK_P6_PG1			44
+#define R9A06G032_CLK_P6_PG2			45
+#define R9A06G032_CLK_P6_PG3			46
+#define R9A06G032_CLK_P6_PG4			47
+#define R9A06G032_CLK_PCI_USB			48
+#define R9A06G032_CLK_QSPI0			49
+#define R9A06G032_CLK_QSPI1			50
+#define R9A06G032_CLK_RGMII_REF			51
+#define R9A06G032_CLK_RMII_REF			52
+#define R9A06G032_CLK_SDIO0			53
+#define R9A06G032_CLK_SDIO1			54
+#define R9A06G032_CLK_SERCOS100			55
+#define R9A06G032_CLK_SLCD			56
+#define R9A06G032_CLK_SPI0			57
+#define R9A06G032_CLK_SPI1			58
+#define R9A06G032_CLK_SPI2			59
+#define R9A06G032_CLK_SPI3			60
+#define R9A06G032_CLK_SPI4			61
+#define R9A06G032_CLK_SPI5			62
+#define R9A06G032_CLK_SWITCH			63
+#define R9A06G032_DIV_MOTOR			64
+#define R9A06G032_HCLK_ECAT125			65
+#define R9A06G032_HCLK_PINCONFIG		66
+#define R9A06G032_HCLK_SERCOS			67
+#define R9A06G032_HCLK_SGPIO2			68
+#define R9A06G032_HCLK_SGPIO3			69
+#define R9A06G032_HCLK_SGPIO4			70
+#define R9A06G032_HCLK_TIMER0			71
+#define R9A06G032_HCLK_TIMER1			72
+#define R9A06G032_HCLK_USBF			73
+#define R9A06G032_HCLK_USBH			74
+#define R9A06G032_HCLK_USBPM			75
+#define R9A06G032_CLK_48_PG_F			76
+#define R9A06G032_CLK_48_PG4			77
+#define R9A06G032_CLK_DDRPHY_PLLCLK_D4		78
+#define R9A06G032_CLK_ECAT100_D4		79
+#define R9A06G032_CLK_HSR100_D2			80
+#define R9A06G032_CLK_REF_SYNC_D4		81
+#define R9A06G032_CLK_DDRPHY_PCLK		81 /* AKA CLK_REF_SYNC_D4 */
+#define R9A06G032_CLK_FW			81 /* AKA CLK_REF_SYNC_D4 */
+#define R9A06G032_CLK_CRYPTO			81 /* AKA CLK_REF_SYNC_D4 */
+#define R9A06G032_CLK_REF_SYNC_D8		82
+#define R9A06G032_CLK_SERCOS100_D2		83
+#define R9A06G032_DIV_CA7			84
+#define R9A06G032_CLK_A7MP			84 /* AKA DIV_CA7 */
+#define R9A06G032_HCLK_CAN0			85
+#define R9A06G032_HCLK_CAN1			86
+#define R9A06G032_HCLK_DELTASIGMA		87
+#define R9A06G032_HCLK_PWMPTO			88
+#define R9A06G032_HCLK_RSV			89
+#define R9A06G032_HCLK_SGPIO0			90
+#define R9A06G032_HCLK_SGPIO1			91
+#define R9A06G032_RTOS_MDC			92
+#define R9A06G032_CLK_CM3			93
+#define R9A06G032_CLK_DDRC			94
+#define R9A06G032_CLK_ECAT25			95
+#define R9A06G032_CLK_HSR50			96
+#define R9A06G032_CLK_HW_RTOS			97
+#define R9A06G032_CLK_SERCOS50			98
+#define R9A06G032_HCLK_ADC			99
+#define R9A06G032_HCLK_CM3			100
+#define R9A06G032_HCLK_CRYPTO_EIP150		101
+#define R9A06G032_HCLK_CRYPTO_EIP93		102
+#define R9A06G032_HCLK_DDRC			103
+#define R9A06G032_HCLK_DMA0			104
+#define R9A06G032_HCLK_DMA1			105
+#define R9A06G032_HCLK_GMAC0			106
+#define R9A06G032_HCLK_GMAC1			107
+#define R9A06G032_HCLK_GPIO0			108
+#define R9A06G032_HCLK_GPIO1			109
+#define R9A06G032_HCLK_GPIO2			110
+#define R9A06G032_HCLK_HSR			111
+#define R9A06G032_HCLK_I2C0			112
+#define R9A06G032_HCLK_I2C1			113
+#define R9A06G032_HCLK_LCD			114
+#define R9A06G032_HCLK_MSEBI_M			115
+#define R9A06G032_HCLK_MSEBI_S			116
+#define R9A06G032_HCLK_NAND			117
+#define R9A06G032_HCLK_PG_I			118
+#define R9A06G032_HCLK_PG19			119
+#define R9A06G032_HCLK_PG20			120
+#define R9A06G032_HCLK_PG3			121
+#define R9A06G032_HCLK_PG4			122
+#define R9A06G032_HCLK_QSPI0			123
+#define R9A06G032_HCLK_QSPI1			124
+#define R9A06G032_HCLK_ROM			125
+#define R9A06G032_HCLK_RTC			126
+#define R9A06G032_HCLK_SDIO0			127
+#define R9A06G032_HCLK_SDIO1			128
+#define R9A06G032_HCLK_SEMAP			129
+#define R9A06G032_HCLK_SPI0			130
+#define R9A06G032_HCLK_SPI1			131
+#define R9A06G032_HCLK_SPI2			132
+#define R9A06G032_HCLK_SPI3			133
+#define R9A06G032_HCLK_SPI4			134
+#define R9A06G032_HCLK_SPI5			135
+#define R9A06G032_HCLK_SWITCH			136
+#define R9A06G032_HCLK_SWITCH_RG		137
+#define R9A06G032_HCLK_UART0			138
+#define R9A06G032_HCLK_UART1			139
+#define R9A06G032_HCLK_UART2			140
+#define R9A06G032_HCLK_UART3			141
+#define R9A06G032_HCLK_UART4			142
+#define R9A06G032_HCLK_UART5			143
+#define R9A06G032_HCLK_UART6			144
+#define R9A06G032_HCLK_UART7			145
+#define R9A06G032_CLK_UART0			146
+#define R9A06G032_CLK_UART1			147
+#define R9A06G032_CLK_UART2			148
+#define R9A06G032_CLK_UART3			149
+#define R9A06G032_CLK_UART4			150
+#define R9A06G032_CLK_UART5			151
+#define R9A06G032_CLK_UART6			152
+#define R9A06G032_CLK_UART7			153
+
+#define R9A06G032_UART_GROUP_012		154
+#define R9A06G032_UART_GROUP_34567		155
+
+#define R9A06G032_CLOCK_COUNT		(R9A06G032_UART_GROUP_34567 + 1)
+
+#endif /* __DT_BINDINGS_R9A06G032_SYSCTRL_H__ */