Message ID | 1526983321-41949-3-git-send-email-michel.pollet@bp.renesas.com (mailing list archive) |
---|---|
State | Changes Requested, archived |
Headers | show |
On Tue, May 22, 2018 at 11:01:22AM +0100, Michel Pollet wrote: > This adds the constants necessary to use the renesas,rzn1-clocks driver. > > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com> > --- > include/dt-bindings/clock/rzn1-clocks.h | 187 ++++++++++++++++++++++++++++++++ > 1 file changed, 187 insertions(+) > create mode 100644 include/dt-bindings/clock/rzn1-clocks.h Reviewed-by: Rob Herring <robh@kernel.org> -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Michel, On Tue, May 22, 2018 at 12:01 PM, Michel Pollet <michel.pollet@bp.renesas.com> wrote: > This adds the constants necessary to use the renesas,rzn1-clocks driver. > > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com> Thanks for your patch! > --- > include/dt-bindings/clock/rzn1-clocks.h | 187 ++++++++++++++++++++++++++++++++ > 1 file changed, 187 insertions(+) > create mode 100644 include/dt-bindings/clock/rzn1-clocks.h > > diff --git a/include/dt-bindings/clock/rzn1-clocks.h b/include/dt-bindings/clock/rzn1-clocks.h > new file mode 100644 > index 0000000..8a73db2 > --- /dev/null > +++ b/include/dt-bindings/clock/rzn1-clocks.h Given this is part of the DT ABI, and there exist multiple different RZ/N1 SoCs (and there are probably planned more), I wouldn't call this header file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h". > @@ -0,0 +1,187 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * RZ/N1 clock 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_RZN1_CLOCK_H__ > +#define __DT_BINDINGS_RZN1_CLOCK_H__ > + > +#define RZN1_CLKOUT 0 Similar for the RZN1 prefix. I'll look at the actual list of clocks later... Gr{oetje,eeting}s, Geert
On Tue, 22 May 2018 at 19:44, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Michel, > On Tue, May 22, 2018 at 12:01 PM, Michel Pollet > <michel.pollet@bp.renesas.com> wrote: > > This adds the constants necessary to use the renesas,rzn1-clocks driver. > > > > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com> > Thanks for your patch! > > --- > > include/dt-bindings/clock/rzn1-clocks.h | 187 ++++++++++++++++++++++++++++++++ > > 1 file changed, 187 insertions(+) > > create mode 100644 include/dt-bindings/clock/rzn1-clocks.h > > > > diff --git a/include/dt-bindings/clock/rzn1-clocks.h b/include/dt-bindings/clock/rzn1-clocks.h > > new file mode 100644 > > index 0000000..8a73db2 > > --- /dev/null > > +++ b/include/dt-bindings/clock/rzn1-clocks.h > Given this is part of the DT ABI, and there exist multiple different RZ/N1 > SoCs (and there are probably planned more), I wouldn't call this header > file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h". Actually, no, there already are two r906g03X devices that will work perfectly fine with this driver. We had that discussion before, and you insist and me removing mentions of the rzn1 everywhere, however, this applies to *two* devices already, and I'm supposed to upstream support for them. I can't rename r9g06g032 because it is *inexact* that's why it's called rzn1. So unless you let me call it r9a06g0xx-clocks.h (which i know you won't as per multiple previous discussions) this can't be called r9a06g032 because it won't be fit for my purpose when I try to bring back the RZ/N1S into the picture. There are minor difference to clocking, I don't know if Renesas plans to release any more rzn1's in this series, but my little finger tells me this isn't the case. But regardless of what we plan, Marketing will screw it up. Cheers, Michel > > @@ -0,0 +1,187 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * RZ/N1 clock 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_RZN1_CLOCK_H__ > > +#define __DT_BINDINGS_RZN1_CLOCK_H__ > > + > > +#define RZN1_CLKOUT 0 > Similar for the RZN1 prefix. > I'll look at the actual list of clocks later... > Gr{oetje,eeting}s, > Geert > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Michel, On Wed, May 23, 2018 at 8:44 AM, M P <buserror@gmail.com> wrote: > On Tue, 22 May 2018 at 19:44, Geert Uytterhoeven <geert@linux-m68k.org> > wrote: >> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet >> <michel.pollet@bp.renesas.com> wrote: >> > This adds the constants necessary to use the renesas,rzn1-clocks driver. >> > >> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com> >> > --- /dev/null >> > +++ b/include/dt-bindings/clock/rzn1-clocks.h > >> Given this is part of the DT ABI, and there exist multiple different RZ/N1 >> SoCs (and there are probably planned more), I wouldn't call this header >> file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h". > > Actually, no, there already are two r906g03X devices that will work > perfectly fine with this driver. We had that discussion before, and you > insist and me removing mentions of the rzn1 everywhere, however, this > applies to *two* devices already, and I'm supposed to upstream support for > them. I can't rename r9g06g032 because it is *inexact* that's why it's My worry is not that there are two r906g03X devices that will work fine with this driver, but that there will be other "rzn1" devices that will not work with these bindings (the header file is part of the bindings). Besides, RZ/N1D and RZ/N1S (Which apparently differ in packaging only? Oh no, RZ/N1D (the larger package) has less QSPI channels than RZ/N1S (the smaller package)), there's also (at least) RZ/N1L. > called rzn1. So unless you let me call it r9a06g0xx-clocks.h (which i know > you won't as per multiple previous discussions) this can't be called > r9a06g032 because it won't be fit for my purpose when I try to bring back > the RZ/N1S into the picture. You can add r9a06g033-clocks.h when adding support for RZ/N1S. > There are minor difference to clocking, Aha? > I don't know if Renesas plans to release any more rzn1's in this series, > but my little finger tells me this isn't the case. But regardless of what We thought the same thing when the first RZ member (RZ/A1H) showed up. Did we know this was not going to be the first SoC of a new RZ family, but the first SoC of the first subfamily (RZ/A) of the RZ family... And the various subfamilies bear not much similarity. > we plan, Marketing will screw it up. Correct. And to mitigate that, we have no other choice than to use the real part numbers to differentiate. Once bitten, twice shy. Gr{oetje,eeting}s, Geert
Morning Geert, On Wed, 23 May 2018 at 08:26, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Michel, > On Wed, May 23, 2018 at 8:44 AM, M P <buserror@gmail.com> wrote: > > On Tue, 22 May 2018 at 19:44, Geert Uytterhoeven <geert@linux-m68k.org> > > wrote: > >> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet > >> <michel.pollet@bp.renesas.com> wrote: > >> > This adds the constants necessary to use the renesas,rzn1-clocks driver. > >> > > >> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com> > >> > --- /dev/null > >> > +++ b/include/dt-bindings/clock/rzn1-clocks.h > > > >> Given this is part of the DT ABI, and there exist multiple different RZ/N1 > >> SoCs (and there are probably planned more), I wouldn't call this header > >> file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h". > > > > Actually, no, there already are two r906g03X devices that will work > > perfectly fine with this driver. We had that discussion before, and you > > insist and me removing mentions of the rzn1 everywhere, however, this > > applies to *two* devices already, and I'm supposed to upstream support for > > them. I can't rename r9g06g032 because it is *inexact* that's why it's > My worry is not that there are two r906g03X devices that will work fine > with this driver, but that there will be other "rzn1" devices that will not > work with these bindings (the header file is part of the bindings). > Besides, RZ/N1D and RZ/N1S (Which apparently differ in packaging only? > Oh no, RZ/N1D (the larger package) has less QSPI channels than RZ/N1S > (the smaller package)), there's also (at least) RZ/N1L. > > called rzn1. So unless you let me call it r9a06g0xx-clocks.h (which i know > > you won't as per multiple previous discussions) this can't be called > > r9a06g032 because it won't be fit for my purpose when I try to bring back > > the RZ/N1S into the picture. > You can add r9a06g033-clocks.h when adding support for RZ/N1S. So it is now acceptable to duplicate a huge amount of code, and constants when in fact there differences are so minor they would require minimal amount of code to take care of them? That just flies straight against my 30+ years of programming -- We're going to have twice the *identical* code, twice the header, and completely incompatible device tree files -- I mean, *right now* our rzn1.dtsi works *as is* on the 1D and 1S, we've got ONE file to maintain, and you can switch your CPU board from 1D to 1S and your 'board file' can stay the same. Wasn't it the idea of that stuff in the first place? Isn't it in the customer/engineer interest to be able to cross grade from one manufacturer's device *in the same series* to another without having to duplicate his whole board file? > > There are minor difference to clocking, > Aha? Sure, 1S doesn't' have DDR, 1D doesn't have the second QSPI. That's about it (I lie, theres a few other bits I'm sure). It's not like it won't even *work* or anything, the registers are there, the bit positions are there, all is the same, I'm *sure* that's what the compatible="" thing were supposed to be used for, isn't it? Heck, I'm pretty sure there's a register in sysctrl, that tells me that anyway, so I wouldn't even have to have a special compatible= -- I didn't do it since the driver is already so big. > > I don't know if Renesas plans to release any more rzn1's in this series, > > but my little finger tells me this isn't the case. But regardless of what > We thought the same thing when the first RZ member (RZ/A1H) showed up. > Did we know this was not going to be the first SoC of a new RZ family, but > the first SoC of the first subfamily (RZ/A) of the RZ family... And the > various subfamilies bear not much similarity. > > we plan, Marketing will screw it up. > Correct. And to mitigate that, we have no other choice than to use the real > part numbers to differentiate. Once bitten, twice shy. It's not mitigation from where I stand -- it's a gigantic kludge; To handle one exception, you throw away the baby with the bathwater. From where I sit, it's like having to a different screwdriver for the screws on the left of a panel vs the right of the panel. Sorry to come out as pretty miffed -- I've just spent weeks polishing up a driver to make it more or less similar to what they were 10 years ago (whoo look a platform file with a big table in it!), after throwing away all the work I had done to make it all device-tree based and make the code as agnostic as we could -- and now it turns out we need to make it even worse by throwing away the fact it actually *does* work on two SoC -- and that just because... because what, again? What about *making up names* -- The 'family names' can/will change -- the part numbers are *too limited in scope* -- why not just make up names? does it matter as long as it's close to reality and are documented? I dunno, "rzn1_18" or "rzn1_mk1" and so we have a way out when they release a new one next year? It seems to be working fine for cars "I got a 2018's <Manufacturer> <series>"... Cheers, Michel > Gr{oetje,eeting}s, > Geert > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Michel, On Wed, May 23, 2018 at 10:17 AM, M P <buserror@gmail.com> wrote: > On Wed, 23 May 2018 at 08:26, Geert Uytterhoeven <geert@linux-m68k.org> > wrote: >> On Wed, May 23, 2018 at 8:44 AM, M P <buserror@gmail.com> wrote: >> > On Tue, 22 May 2018 at 19:44, Geert Uytterhoeven <geert@linux-m68k.org> >> > wrote: >> >> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet >> >> <michel.pollet@bp.renesas.com> wrote: >> >> > --- /dev/null >> >> > +++ b/include/dt-bindings/clock/rzn1-clocks.h >> > >> >> Given this is part of the DT ABI, and there exist multiple different > RZ/N1 >> >> SoCs (and there are probably planned more), I wouldn't call this header >> >> file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h". >> > >> > Actually, no, there already are two r906g03X devices that will work >> > perfectly fine with this driver. We had that discussion before, and you >> > insist and me removing mentions of the rzn1 everywhere, however, this >> > applies to *two* devices already, and I'm supposed to upstream support > for >> > them. I can't rename r9g06g032 because it is *inexact* that's why it's > >> My worry is not that there are two r906g03X devices that will work fine >> with this driver, but that there will be other "rzn1" devices that will > not >> work with these bindings (the header file is part of the bindings). >> Besides, RZ/N1D and RZ/N1S (Which apparently differ in packaging only? >> Oh no, RZ/N1D (the larger package) has less QSPI channels than RZ/N1S >> (the smaller package)), there's also (at least) RZ/N1L. > >> > called rzn1. So unless you let me call it r9a06g0xx-clocks.h (which i > know >> > you won't as per multiple previous discussions) this can't be called >> > r9a06g032 because it won't be fit for my purpose when I try to bring > back >> > the RZ/N1S into the picture. > >> You can add r9a06g033-clocks.h when adding support for RZ/N1S. > > So it is now acceptable to duplicate a huge amount of code, and constants > when in fact there differences are so minor they would require minimal > amount of code to take care of them? That just flies straight against my > 30+ years of programming -- We're going to have twice the *identical* code, > twice the header, and completely incompatible device tree files -- I mean, > *right now* our rzn1.dtsi works *as is* on the 1D and 1S, we've got ONE > file to maintain, and you can switch your CPU board from 1D to 1S and your > 'board file' can stay the same. > > Wasn't it the idea of that stuff in the first place? Isn't it in the > customer/engineer interest to be able to cross grade from one > manufacturer's device *in the same series* to another without having to > duplicate his whole board file? Yes, all of these are desirable. Now, given the clock definitions for RZ/N1[DSL] are the same (although some don't exist on some variants), you could keep on using RZN1_CLK_FOO for the names of the defines, and store them in a common file, included by the soc-specific file. But please make clear the common file cannot be included directly, so the filename does not become part of the DT ABI, and you are shielded from future marketing silliness (e.g. next quarter's RZ/N1X being totally different). E.g.: include/dt-bindings/clock/r9a06g033-clocks.h: #ifndef __DT_BINDINGS_R9A06G033_CLOCK_H__ #define __DT_BINDINGS_R9A06G033_CLOCK_H__ #include "rzn1-clocks.h" // ... additions and fixups, if needed #endif // __DT_BINDINGS_R9A06G033_CLOCK_H__ include/dt-bindings/clock/rzn1-clocks.h: #ifndef __DT_BINDINGS_RZN1_CLOCK_H__ #define __DT_BINDINGS_RZN1_CLOCK_H__ #ifndef __DT_BINDINGS_R9A06G033_CLOCK_H__ #error Do not include rzn1-clocks.h directly #endif #define RZN1_CLK_FOO 0 #define RZN1_CLK_BAR 1 ... #endif // __DT_BINDINGS_RZN1_CLOCK_H__ As for the driver, I think you should make sure the driver instantiates no clocks that don't exist on the actual SoC it runs on. BTW, someone asked why I didn't use the same definitions for R-Car M3-W and R-Car H3 (there were only a few differences), and didn't use common definitions for all R-Car Gen3 SoCs. I doubted a long time that we made the right decision, but then V3M and V3H appeared in later revisions of the datasheet, and D3 and E3 later, reconfirming our decision. Even for compatible values for IP cores within the same family: there are differences, but usually we only discover them after a while. In theory all the same IP cores in R-Car Gen3 SoCs are the same (except for obvious differences like clocks and pinctrl), in practice they are not. So it may sound silly to have SoC-specific compatible values for the gross of the IP cores, but it would be worse if we got bitten later by not having them. BTW, you're too quick reposting your series. I can't finish my reviews in time ;-) Please give people a reasonable amount of time to handle them. Thanks! Gr{oetje,eeting}s, Geert
SGkgR2VlcnQsDQoNCk9uIDI1IE1heSAyMDE4IDEwOjEzIEdlZXJ0IFV5dHRlcmhvZXZlbiB3cm90 ZToNCiBbc25pcF0NCg0KPiBOb3csIGdpdmVuIHRoZSBjbG9jayBkZWZpbml0aW9ucyBmb3IgUlov TjFbRFNMXSBhcmUgdGhlIHNhbWUgKGFsdGhvdWdoIHNvbWUNCj4gZG9uJ3QgZXhpc3Qgb24gc29t ZSB2YXJpYW50cyksIHlvdSBjb3VsZCBrZWVwIG9uIHVzaW5nIFJaTjFfQ0xLX0ZPTyBmb3INCj4g dGhlIG5hbWVzIG9mIHRoZSBkZWZpbmVzLCBhbmQgc3RvcmUgdGhlbSBpbiBhIGNvbW1vbiBmaWxl LCBpbmNsdWRlZCBieSB0aGUNCj4gc29jLXNwZWNpZmljIGZpbGUuIEJ1dCBwbGVhc2UgbWFrZSBj bGVhciB0aGUgY29tbW9uIGZpbGUgY2Fubm90IGJlIGluY2x1ZGVkDQo+IGRpcmVjdGx5LCBzbyB0 aGUgZmlsZW5hbWUgZG9lcyBub3QgYmVjb21lIHBhcnQgb2YgdGhlIERUIEFCSSwgYW5kIHlvdSBh cmUNCj4gc2hpZWxkZWQgZnJvbSBmdXR1cmUgbWFya2V0aW5nIHNpbGxpbmVzcyAoZS5nLiBuZXh0 IHF1YXJ0ZXIncyBSWi9OMVggYmVpbmcNCj4gdG90YWxseSBkaWZmZXJlbnQpLg0KSG93IGRvZXMg YW4gaW5jbHVkZSBmaWxlbmFtZSBiZWNvbWUgcGFydCBvZiB0aGUgRFQgQUJJPw0KSSB0aG91Z2h0 IHRoZSBkdGIgaXMgdGhlIEFCSSwgbm90IHRoZSBkdHMuIEFtIEkgd3Jvbmc/DQoNClRoYW5rcw0K UGhpbA0K -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Phil, On Wed, May 30, 2018 at 3:30 PM, Phil Edworthy <phil.edworthy@renesas.com> wrote: > On 25 May 2018 10:13 Geert Uytterhoeven wrote: > [snip] > >> Now, given the clock definitions for RZ/N1[DSL] are the same (although some >> don't exist on some variants), you could keep on using RZN1_CLK_FOO for >> the names of the defines, and store them in a common file, included by the >> soc-specific file. But please make clear the common file cannot be included >> directly, so the filename does not become part of the DT ABI, and you are >> shielded from future marketing silliness (e.g. next quarter's RZ/N1X being >> totally different). > How does an include filename become part of the DT ABI? > I thought the dtb is the ABI, not the dts. Am I wrong? You're right. In se the DT ABI applies to the DTB, not to the DTS. The definitions inside the include file are part of the DT bindings, and thus cannot be changed. Your DTS files get these definitions by including the header file, so the header filename is also part of the bindings, and thus can't be changed that easily. Gr{oetje,eeting}s, Geert
Hi Geert, On 30 May 2018 14:37 Geert Uytterhoeven wrote: > On Wed, May 30, 2018 at 3:30 PM, Phil Edworthy wrote: > > On 25 May 2018 10:13 Geert Uytterhoeven wrote: > > [snip] > > > >> Now, given the clock definitions for RZ/N1[DSL] are the same > >> (although some don't exist on some variants), you could keep on using > >> RZN1_CLK_FOO for the names of the defines, and store them in a > common > >> file, included by the soc-specific file. But please make clear the > >> common file cannot be included directly, so the filename does not > >> become part of the DT ABI, and you are shielded from future marketing > >> silliness (e.g. next quarter's RZ/N1X being totally different). > > How does an include filename become part of the DT ABI? > > I thought the dtb is the ABI, not the dts. Am I wrong? > > You're right. In se the DT ABI applies to the DTB, not to the DTS. > > The definitions inside the include file are part of the DT bindings, and thus > cannot be changed. Your DTS files get these definitions by including the > header file, so the header filename is also part of the bindings, and thus can't > be changed that easily. That seems a bit onerous... It makes sense that bindings that affect the dtb can only be added to, so that an old dtb still works. However, I would have thought it's the value of the constant that is the ABI, not the symbol name used to specify it. Thanks for you feedback! Phil
diff --git a/include/dt-bindings/clock/rzn1-clocks.h b/include/dt-bindings/clock/rzn1-clocks.h new file mode 100644 index 0000000..8a73db2 --- /dev/null +++ b/include/dt-bindings/clock/rzn1-clocks.h @@ -0,0 +1,187 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * RZ/N1 clock 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_RZN1_CLOCK_H__ +#define __DT_BINDINGS_RZN1_CLOCK_H__ + +#define RZN1_CLKOUT 0 +#define RZN1_CLK_PLL_USB 1 +#define RZN1_CLK_48 1 /* AKA CLK_PLL_USB */ +#define RZN1_CLKOUT_D10 2 +#define RZN1_CLKOUT_D16 3 +#define RZN1_MSEBIS_CLK 3 /* AKA CLKOUT_D16 */ +#define RZN1_MSEBIM_CLK 3 /* AKA CLKOUT_D16 */ +#define RZN1_CLKOUT_D160 4 +#define RZN1_CLKOUT_D1OR2 5 +#define RZN1_CLK_DDRPHY_PLLCLK 5 /* AKA CLKOUT_D1OR2 */ +#define RZN1_CLKOUT_D20 6 +#define RZN1_CLK50 6 /* AKA CLKOUT_D20 */ +#define RZN1_CLKOUT_D40 7 +#define RZN1_CLK25 7 /* AKA CLKOUT_D40 */ +#define RZN1_CLKOUT_D5 8 +#define RZN1_CLKOUT_D8 9 +#define RZN1_CLK125 9 /* AKA CLKOUT_D8 */ +#define RZN1_DIV_ADC 10 +#define RZN1_DIV_I2C 11 +#define RZN1_DIV_NAND 12 +#define RZN1_DIV_P1_PG 13 +#define RZN1_DIV_P2_PG 14 +#define RZN1_DIV_P3_PG 15 +#define RZN1_DIV_P4_PG 16 +#define RZN1_DIV_P5_PG 17 +#define RZN1_CLK_P5_PG1 17 /* AKA DIV_P5_PG */ +#define RZN1_DIV_P6_PG 18 +#define RZN1_DIV_QSPI0 19 +#define RZN1_DIV_QSPI1 20 +#define RZN1_DIV_REF_SYNC 21 +#define RZN1_CLK_REF_SYNC 21 /* AKA DIV_REF_SYNC */ +#define RZN1_DIV_SDIO0 22 +#define RZN1_DIV_SDIO1 23 +#define RZN1_DIV_SWITCH 24 +#define RZN1_DIV_UART 25 +#define RZN1_CLK_25_PG4 26 +#define RZN1_CLK_25_PG5 27 +#define RZN1_CLK_25_PG6 28 +#define RZN1_CLK_25_PG7 29 +#define RZN1_CLK_25_PG8 30 +#define RZN1_CLK_ADC 31 +#define RZN1_CLK_ECAT100 32 +#define RZN1_CLK_HSR100 33 +#define RZN1_CLK_I2C0 34 +#define RZN1_CLK_I2C1 35 +#define RZN1_CLK_MII_REF 36 +#define RZN1_CLK_NAND 37 +#define RZN1_CLK_NOUSBP2_PG6 38 +#define RZN1_CLK_P1_PG2 39 +#define RZN1_CLK_P1_PG3 40 +#define RZN1_CLK_P1_PG4 41 +#define RZN1_CLK_P4_PG3 42 +#define RZN1_CLK_P4_PG4 43 +#define RZN1_CLK_P6_PG1 44 +#define RZN1_CLK_P6_PG2 45 +#define RZN1_CLK_P6_PG3 46 +#define RZN1_CLK_P6_PG4 47 +#define RZN1_CLK_PCI_USB 48 +#define RZN1_CLK_QSPI0 49 +#define RZN1_CLK_QSPI1 50 +#define RZN1_CLK_RGMII_REF 51 +#define RZN1_CLK_RMII_REF 52 +#define RZN1_CLK_SDIO0 53 +#define RZN1_CLK_SDIO1 54 +#define RZN1_CLK_SERCOS100 55 +#define RZN1_CLK_SLCD 56 +#define RZN1_CLK_SPI0 57 +#define RZN1_CLK_SPI1 58 +#define RZN1_CLK_SPI2 59 +#define RZN1_CLK_SPI3 60 +#define RZN1_CLK_SPI4 61 +#define RZN1_CLK_SPI5 62 +#define RZN1_CLK_SWITCH 63 +#define RZN1_DIV_MOTOR 64 +#define RZN1_HCLK_ECAT125 65 +#define RZN1_HCLK_PINCONFIG 66 +#define RZN1_HCLK_SERCOS 67 +#define RZN1_HCLK_SGPIO2 68 +#define RZN1_HCLK_SGPIO3 69 +#define RZN1_HCLK_SGPIO4 70 +#define RZN1_HCLK_TIMER0 71 +#define RZN1_HCLK_TIMER1 72 +#define RZN1_HCLK_USBF 73 +#define RZN1_HCLK_USBH 74 +#define RZN1_HCLK_USBPM 75 +#define RZN1_CLK_48_PG_F 76 +#define RZN1_CLK_48_PG4 77 +#define RZN1_CLK_DDRPHY_PLLCLK_D4 78 +#define RZN1_CLK_ECAT100_D4 79 +#define RZN1_CLK_HSR100_D2 80 +#define RZN1_CLK_REF_SYNC_D4 81 +#define RZN1_CLK_DDRPHY_PCLK 81 /* AKA CLK_REF_SYNC_D4 */ +#define RZN1_CLK_FW 81 /* AKA CLK_REF_SYNC_D4 */ +#define RZN1_CLK_CRYPTO 81 /* AKA CLK_REF_SYNC_D4 */ +#define RZN1_CLK_REF_SYNC_D8 82 +#define RZN1_CLK_SERCOS100_D2 83 +#define RZN1_DIV_CA7 84 +#define RZN1_CLK_A7MP 84 /* AKA DIV_CA7 */ +#define RZN1_HCLK_CAN0 85 +#define RZN1_HCLK_CAN1 86 +#define RZN1_HCLK_DELTASIGMA 87 +#define RZN1_HCLK_PWMPTO 88 +#define RZN1_HCLK_RSV 89 +#define RZN1_HCLK_SGPIO0 90 +#define RZN1_HCLK_SGPIO1 91 +#define RZN1_RTOS_MDC 92 +#define RZN1_CLK_CM3 93 +#define RZN1_CLK_DDRC 94 +#define RZN1_CLK_ECAT25 95 +#define RZN1_CLK_HSR50 96 +#define RZN1_CLK_HW_RTOS 97 +#define RZN1_CLK_SERCOS50 98 +#define RZN1_HCLK_ADC 99 +#define RZN1_HCLK_CM3 100 +#define RZN1_HCLK_CRYPTO_EIP150 101 +#define RZN1_HCLK_CRYPTO_EIP93 102 +#define RZN1_HCLK_DDRC 103 +#define RZN1_HCLK_DMA0 104 +#define RZN1_HCLK_DMA1 105 +#define RZN1_HCLK_GMAC0 106 +#define RZN1_HCLK_GMAC1 107 +#define RZN1_HCLK_GPIO0 108 +#define RZN1_HCLK_GPIO1 109 +#define RZN1_HCLK_GPIO2 110 +#define RZN1_HCLK_HSR 111 +#define RZN1_HCLK_I2C0 112 +#define RZN1_HCLK_I2C1 113 +#define RZN1_HCLK_LCD 114 +#define RZN1_HCLK_MSEBI_M 115 +#define RZN1_HCLK_MSEBI_S 116 +#define RZN1_HCLK_NAND 117 +#define RZN1_HCLK_PG_I 118 +#define RZN1_HCLK_PG19 119 +#define RZN1_HCLK_PG20 120 +#define RZN1_HCLK_PG3 121 +#define RZN1_HCLK_PG4 122 +#define RZN1_HCLK_QSPI0 123 +#define RZN1_HCLK_QSPI1 124 +#define RZN1_HCLK_ROM 125 +#define RZN1_HCLK_RTC 126 +#define RZN1_HCLK_SDIO0 127 +#define RZN1_HCLK_SDIO1 128 +#define RZN1_HCLK_SEMAP 129 +#define RZN1_HCLK_SPI0 130 +#define RZN1_HCLK_SPI1 131 +#define RZN1_HCLK_SPI2 132 +#define RZN1_HCLK_SPI3 133 +#define RZN1_HCLK_SPI4 134 +#define RZN1_HCLK_SPI5 135 +#define RZN1_HCLK_SWITCH 136 +#define RZN1_HCLK_SWITCH_RG 137 +#define RZN1_HCLK_UART0 138 +#define RZN1_HCLK_UART1 139 +#define RZN1_HCLK_UART2 140 +#define RZN1_HCLK_UART3 141 +#define RZN1_HCLK_UART4 142 +#define RZN1_HCLK_UART5 143 +#define RZN1_HCLK_UART6 144 +#define RZN1_HCLK_UART7 145 +#define RZN1_CLK_UART0 146 +#define RZN1_CLK_UART1 147 +#define RZN1_CLK_UART2 148 +#define RZN1_CLK_UART3 149 +#define RZN1_CLK_UART4 150 +#define RZN1_CLK_UART5 151 +#define RZN1_CLK_UART6 152 +#define RZN1_CLK_UART7 153 + +#define RZN1_UART_GROUP_012 154 +#define RZN1_UART_GROUP_34567 155 + +#define RZN1_CLOCK_COUNT (RZN1_UART_GROUP_34567 + 1) + +#endif /* __DT_BINDINGS_RZN1_CLOCK_H__ */
This adds the constants necessary to use the renesas,rzn1-clocks driver. Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com> --- include/dt-bindings/clock/rzn1-clocks.h | 187 ++++++++++++++++++++++++++++++++ 1 file changed, 187 insertions(+) create mode 100644 include/dt-bindings/clock/rzn1-clocks.h