Message ID | 20180205235757.246758-3-brendanhiggins@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hi Brendan, On Tue, Feb 6, 2018 at 10:27 AM, Brendan Higgins <brendanhiggins@google.com> wrote: > Add a common device tree for all Nuvoton NPCM750 BMCs and a board > specific device tree for the NPCM750 (Poleg) evaluation board. > > Signed-off-by: Brendan Higgins <brendanhiggins@google.com> > Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> > Reviewed-by: Avi Fishman <avifishman70@gmail.com> > Reviewed-by: Joel Stanley <joel@jms.id.au> > Reviewed-by: Rob Herring <robh@kernel.org> > Tested-by: Tomer Maimon <tmaimon77@gmail.com> > Tested-by: Avi Fishman <avifishman70@gmail.com> This looks well acked, reviewed and tested. How do you plan to have the ARM SoC maintainers merge your patches? > --- > .../arm/cpu-enable-method/nuvoton,npcm7xx-smp | 42 ++++++ > .../devicetree/bindings/arm/npcm/npcm.txt | 6 + > arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 35 +++++ > arch/arm/boot/dts/nuvoton-npcm750.dtsi | 162 +++++++++++++++++++++ > include/dt-bindings/clock/nuvoton,npcm7xx-clks.h | 35 +++++ > 5 files changed, 280 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/nuvoton,npcm7xx-smp > create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt > create mode 100644 arch/arm/boot/dts/nuvoton-npcm750-evb.dts > create mode 100644 arch/arm/boot/dts/nuvoton-npcm750.dtsi > create mode 100644 include/dt-bindings/clock/nuvoton,npcm7xx-clks.h You need to add nuvoton-npcm750-evb.dts to arch/arm/boot/dts/Makefile Once you've done that you can add Tested-by: Joel Stanley <joel@jms.id.au> as I tested this on an EVB. > diff --git a/arch/arm/boot/dts/nuvoton-npcm750.dtsi b/arch/arm/boot/dts/nuvoton-npcm750.dtsi > new file mode 100644 > index 000000000000..08e906f88c49 > --- /dev/null > +++ b/arch/arm/boot/dts/nuvoton-npcm750.dtsi > @@ -0,0 +1,162 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (c) 2018 Nuvoton Technology corporation. > +// Copyright 2018 Google, Inc. > + > +#include <dt-bindings/interrupt-controller/arm-gic.h> > +#include <dt-bindings/clock/nuvoton,npcm7xx-clks.h> > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + interrupt-parent = <&gic>; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + enable-method = "nuvoton,npcm7xx-smp"; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a9"; > + clocks = <&clk NPCM7XX_CLK_CPU>; > + clock-names = "clk_cpu"; > + reg = <0>; > + next-level-cache = <&l2>; > + }; > + > + cpu@1 { > + device_type = "cpu"; > + compatible = "arm,cortex-a9"; > + clocks = <&clk NPCM7XX_CLK_CPU>; > + clock-names = "clk_cpu"; > + reg = <1>; > + next-level-cache = <&l2>; > + }; > + }; > + > +/* external clock signal rg1refck, supplied by the phy */ > +clk-rg1refck { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <125000000>; > +}; > + > +/* external clock signal rg2refck, supplied by the phy */ > +clk-rg2refck { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <125000000>; > +}; > + > +clk-xin { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <50000000>; > +}; The whitespace here needs to be fixed. Cheers, Joel > + > + soc { > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "simple-bus"; > + interrupt-parent = <&gic>; > + ranges = <0x0 0xf0000000 0x00900000>; > +
On Tue, Feb 6, 2018 at 12:57 AM, Brendan Higgins <brendanhiggins@google.com> wrote: > Add a common device tree for all Nuvoton NPCM750 BMCs and a board > specific device tree for the NPCM750 (Poleg) evaluation board. > > Signed-off-by: Brendan Higgins <brendanhiggins@google.com> > Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> > Reviewed-by: Avi Fishman <avifishman70@gmail.com> > Reviewed-by: Joel Stanley <joel@jms.id.au> > Reviewed-by: Rob Herring <robh@kernel.org> > Tested-by: Tomer Maimon <tmaimon77@gmail.com> > Tested-by: Avi Fishman <avifishman70@gmail.com> ... > + enable-method = "nuvoton,npcm7xx-smp"; I see this has already been reviewed quite a bit, but I'm curious about the 'npcm7xx' part here. Shouldn't that be a real chip name rather than a wildcard? Arnd
On Tue, Feb 13, 2018 at 10:30 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tue, Feb 6, 2018 at 12:57 AM, Brendan Higgins > <brendanhiggins@google.com> wrote: >> Add a common device tree for all Nuvoton NPCM750 BMCs and a board >> specific device tree for the NPCM750 (Poleg) evaluation board. >> >> Signed-off-by: Brendan Higgins <brendanhiggins@google.com> >> Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> >> Reviewed-by: Avi Fishman <avifishman70@gmail.com> >> Reviewed-by: Joel Stanley <joel@jms.id.au> >> Reviewed-by: Rob Herring <robh@kernel.org> >> Tested-by: Tomer Maimon <tmaimon77@gmail.com> >> Tested-by: Avi Fishman <avifishman70@gmail.com> > ... >> + enable-method = "nuvoton,npcm7xx-smp"; > > I see this has already been reviewed quite a bit, but I'm curious > about the 'npcm7xx' > part here. Shouldn't that be a real chip name rather than a wildcard? > > Arnd There is a family of npcm7xx, some with SMP and some without. For those who has it, it is common for all to use the same "nuvoton,npcm7xx-smp". Avi
On Tue, Feb 13, 2018 at 1:29 AM, Avi Fishman <avifishman70@gmail.com> wrote: > On Tue, Feb 13, 2018 at 10:30 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Tue, Feb 6, 2018 at 12:57 AM, Brendan Higgins >> <brendanhiggins@google.com> wrote: >>> Add a common device tree for all Nuvoton NPCM750 BMCs and a board >>> specific device tree for the NPCM750 (Poleg) evaluation board. >>> >>> Signed-off-by: Brendan Higgins <brendanhiggins@google.com> >>> Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> >>> Reviewed-by: Avi Fishman <avifishman70@gmail.com> >>> Reviewed-by: Joel Stanley <joel@jms.id.au> >>> Reviewed-by: Rob Herring <robh@kernel.org> >>> Tested-by: Tomer Maimon <tmaimon77@gmail.com> >>> Tested-by: Avi Fishman <avifishman70@gmail.com> >> ... >>> + enable-method = "nuvoton,npcm7xx-smp"; >> >> I see this has already been reviewed quite a bit, but I'm curious >> about the 'npcm7xx' >> part here. Shouldn't that be a real chip name rather than a wildcard? >> >> Arnd > > There is a family of npcm7xx, some with SMP and some without. > For those who has it, it is common for all to use the same > "nuvoton,npcm7xx-smp". I think Arnd is right. In this case it should be "nuvoton,npcm750-smp". We can use CPU_METHOD_OF_DECLARE to alias to as many compatible properties as needed. Although everything in the 7xx family currently is either single core or has the same SMP behavior, you could paint yourself into a corner if you were to make one SMP device in the 7xx family which behaves differently from all other devices and then need to come up with new compatible string names just for that. > > Avi
On Tue, Feb 13, 2018 at 8:12 PM, Brendan Higgins <brendanhiggins@google.com> wrote: > On Tue, Feb 13, 2018 at 1:29 AM, Avi Fishman <avifishman70@gmail.com> wrote: >> On Tue, Feb 13, 2018 at 10:30 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>> On Tue, Feb 6, 2018 at 12:57 AM, Brendan Higgins >>> <brendanhiggins@google.com> wrote: >>>> Add a common device tree for all Nuvoton NPCM750 BMCs and a board >>>> specific device tree for the NPCM750 (Poleg) evaluation board. >>>> >>>> Signed-off-by: Brendan Higgins <brendanhiggins@google.com> >>>> Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> >>>> Reviewed-by: Avi Fishman <avifishman70@gmail.com> >>>> Reviewed-by: Joel Stanley <joel@jms.id.au> >>>> Reviewed-by: Rob Herring <robh@kernel.org> >>>> Tested-by: Tomer Maimon <tmaimon77@gmail.com> >>>> Tested-by: Avi Fishman <avifishman70@gmail.com> >>> ... >>>> + enable-method = "nuvoton,npcm7xx-smp"; >>> >>> I see this has already been reviewed quite a bit, but I'm curious >>> about the 'npcm7xx' >>> part here. Shouldn't that be a real chip name rather than a wildcard? >> >> There is a family of npcm7xx, some with SMP and some without. >> For those who has it, it is common for all to use the same >> "nuvoton,npcm7xx-smp". > > I think Arnd is right. In this case it should be "nuvoton,npcm750-smp". We can > use CPU_METHOD_OF_DECLARE to alias to as many compatible properties as needed. > > Although everything in the 7xx family currently is either single core or has the > same SMP behavior, you could paint yourself into a corner if you were to make > one SMP device in the 7xx family which behaves differently from all other > devices and then need to come up with new compatible string names just for that. Right, this is the reason for the very simple 'no wildcards in DT identifiers' rule. There simply isn't a reason to make an exception here. Arnd
On Tue, Feb 13, 2018 at 4:52 PM, Joel Stanley <joel@jms.id.au> wrote: > Hi Brendan, > > On Tue, Feb 6, 2018 at 10:27 AM, Brendan Higgins > <brendanhiggins@google.com> wrote: >> Add a common device tree for all Nuvoton NPCM750 BMCs and a board >> specific device tree for the NPCM750 (Poleg) evaluation board. >> >> Signed-off-by: Brendan Higgins <brendanhiggins@google.com> >> Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> >> Reviewed-by: Avi Fishman <avifishman70@gmail.com> >> Reviewed-by: Joel Stanley <joel@jms.id.au> >> Reviewed-by: Rob Herring <robh@kernel.org> >> Tested-by: Tomer Maimon <tmaimon77@gmail.com> >> Tested-by: Avi Fishman <avifishman70@gmail.com> > > This looks well acked, reviewed and tested. How do you plan to have > the ARM SoC maintainers merge your patches? Following up on an IRC conversation with Brendan: The process is normally to create a git branch based on on -rc1, apply your patches, and send them to the ARM maintainers. You then push a signed tag to a repository somewhere, send a pull request (a git request-pull email, not a Github PR) and Arnd, Olof or one of the other maintainers will pull your tree some time before the next merge window opens. Arnd, do we have this documented somewhere for new maintainers to follow? Cheers, Joel
On February 14, 2018 6:28:51 PM PST, Joel Stanley <joel@jms.id.au> wrote: >On Tue, Feb 13, 2018 at 4:52 PM, Joel Stanley <joel@jms.id.au> wrote: >> Hi Brendan, >> >> On Tue, Feb 6, 2018 at 10:27 AM, Brendan Higgins >> <brendanhiggins@google.com> wrote: >>> Add a common device tree for all Nuvoton NPCM750 BMCs and a board >>> specific device tree for the NPCM750 (Poleg) evaluation board. >>> >>> Signed-off-by: Brendan Higgins <brendanhiggins@google.com> >>> Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> >>> Reviewed-by: Avi Fishman <avifishman70@gmail.com> >>> Reviewed-by: Joel Stanley <joel@jms.id.au> >>> Reviewed-by: Rob Herring <robh@kernel.org> >>> Tested-by: Tomer Maimon <tmaimon77@gmail.com> >>> Tested-by: Avi Fishman <avifishman70@gmail.com> >> >> This looks well acked, reviewed and tested. How do you plan to have >> the ARM SoC maintainers merge your patches? > >Following up on an IRC conversation with Brendan: > >The process is normally to create a git branch based on on -rc1, apply >your patches, and send them to the ARM maintainers. You then push a >signed tag to a repository somewhere, send a pull request (a git >request-pull email, not a Github PR) and Arnd, Olof or one of the >other maintainers will pull your tree some time before the next merge >window opens. > >Arnd, do we have this documented somewhere for new maintainers to >follow? I would add a few things that we had to go through before for Broadcom SoCs: - send your pull requests to arm@kernel.org and copy Arnd, Olof and Kevin - you would want to get your PGP key signed by as many people as people as possible which should not be a problem if you are in an area with lots of kernel people like the Bay Area (which reminds me I should do that) - if you are going to be reasonably active every cycle consider getting a kernel.org account to host your tree (we are still not doing that...) - for future pull requests, you might want to break them into e.g: DTS, board/Kconfig, drivers, defconfig, maintainers file, and have as little dependencies between each branch to minimize merge conflicts - build test and run test your changes against at least one other platform, e.g: QEMU to check for multiplatform issues In case this is of any value, there is a script here that will automatically generate pull requests emails for you based on branches matching what was mentioned above, it will also take care of CC'ing the people involved in the different patches: https://github.com/ffainelli/misc-scripts/blob/master/gen-pull.pl It still requires you to create an appropriate tag for the pull requests, though I might semi-automate that in the future, at least spawn an editor and offer some guidance, based on commit messages as to what should be in the pull request email/tag. HTH
<snip> >>Arnd, do we have this documented somewhere for new maintainers to >>follow? > > I would add a few things that we had to go through before for Broadcom SoCs: > > - send your pull requests to arm@kernel.org and copy Arnd, Olof and Kevin > > - you would want to get your PGP key signed by as many people as people as possible which should not be a problem if you are in an area with lots of kernel people like the Bay Area (which reminds me I should do that) > > - if you are going to be reasonably active every cycle consider getting a kernel.org account to host your tree (we are still not doing that...) > > - for future pull requests, you might want to break them into e.g: DTS, board/Kconfig, drivers, defconfig, maintainers file, and have as little dependencies between each branch to minimize merge conflicts > > - build test and run test your changes against at least one other platform, e.g: QEMU to check for multiplatform issues > > In case this is of any value, there is a script here that will automatically generate pull requests emails for you based on branches matching what was mentioned above, it will also take care of CC'ing the people involved in the different patches: > > https://github.com/ffainelli/misc-scripts/blob/master/gen-pull.pl > > It still requires you to create an appropriate tag for the pull requests, though I might semi-automate that in the future, at least spawn an editor and offer some guidance, based on commit messages as to what should be in the pull request email/tag. > > HTH > > -- > Florian Thanks Florian, this was extremely helpful!
diff --git a/Documentation/devicetree/bindings/arm/cpu-enable-method/nuvoton,npcm7xx-smp b/Documentation/devicetree/bindings/arm/cpu-enable-method/nuvoton,npcm7xx-smp new file mode 100644 index 000000000000..e81f85b400cf --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/nuvoton,npcm7xx-smp @@ -0,0 +1,42 @@ +========================================================= +Secondary CPU enable-method "nuvoton,npcm7xx-smp" binding +========================================================= + +To apply to all CPUs, a single "nuvoton,npcm7xx-smp" enable method should be +defined in the "cpus" node. + +Enable method name: "nuvoton,npcm7xx-smp" +Compatible machines: "nuvoton,npcm750" +Compatible CPUs: "arm,cortex-a9" +Related properties: (none) + +Note: +This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and +"nuvoton,npcm750-gcr". + +Example: + + cpus { + #address-cells = <1>; + #size-cells = <0>; + enable-method = "nuvoton,npcm7xx-smp"; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a9"; + clocks = <&clk NPCM7XX_CLK_CPU>; + clock-names = "clk_cpu"; + reg = <0>; + next-level-cache = <&L2>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a9"; + clocks = <&clk NPCM7XX_CLK_CPU>; + clock-names = "clk_cpu"; + reg = <1>; + next-level-cache = <&L2>; + }; + }; + diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.txt b/Documentation/devicetree/bindings/arm/npcm/npcm.txt new file mode 100644 index 000000000000..2d87d9ecea85 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/npcm/npcm.txt @@ -0,0 +1,6 @@ +NPCM Platforms Device Tree Bindings +----------------------------------- +NPCM750 SoC +Required root node properties: + - compatible = "nuvoton,npcm750"; + diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts new file mode 100644 index 000000000000..cabde3d5be8a --- /dev/null +++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts @@ -0,0 +1,35 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2018 Nuvoton Technology corporation. +// Copyright 2018 Google, Inc. + +/dts-v1/; +#include "nuvoton-npcm750.dtsi" + +/ { + model = "Nuvoton npcm750 Development Board (Device Tree)"; + compatible = "nuvoton,npcm750"; + + chosen { + stdout-path = &serial3; + }; + + memory { + reg = <0 0x40000000>; + }; +}; + +&serial0 { + status = "okay"; +}; + +&serial1 { + status = "okay"; +}; + +&serial2 { + status = "okay"; +}; + +&serial3 { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/nuvoton-npcm750.dtsi b/arch/arm/boot/dts/nuvoton-npcm750.dtsi new file mode 100644 index 000000000000..08e906f88c49 --- /dev/null +++ b/arch/arm/boot/dts/nuvoton-npcm750.dtsi @@ -0,0 +1,162 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2018 Nuvoton Technology corporation. +// Copyright 2018 Google, Inc. + +#include <dt-bindings/interrupt-controller/arm-gic.h> +#include <dt-bindings/clock/nuvoton,npcm7xx-clks.h> + +/ { + #address-cells = <1>; + #size-cells = <1>; + interrupt-parent = <&gic>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + enable-method = "nuvoton,npcm7xx-smp"; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a9"; + clocks = <&clk NPCM7XX_CLK_CPU>; + clock-names = "clk_cpu"; + reg = <0>; + next-level-cache = <&l2>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a9"; + clocks = <&clk NPCM7XX_CLK_CPU>; + clock-names = "clk_cpu"; + reg = <1>; + next-level-cache = <&l2>; + }; + }; + +/* external clock signal rg1refck, supplied by the phy */ +clk-rg1refck { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <125000000>; +}; + +/* external clock signal rg2refck, supplied by the phy */ +clk-rg2refck { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <125000000>; +}; + +clk-xin { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <50000000>; +}; + + soc { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + interrupt-parent = <&gic>; + ranges = <0x0 0xf0000000 0x00900000>; + + gcr: gcr@800000 { + compatible = "nuvoton,npcm750-gcr", "syscon", + "simple-mfd"; + reg = <0x800000 0x1000>; + }; + + scu: scu@3fe000 { + compatible = "arm,cortex-a9-scu"; + reg = <0x3fe000 0x1000>; + }; + + l2: cache-controller@3fc000 { + compatible = "arm,pl310-cache"; + reg = <0x3fc000 0x1000>; + interrupts = <0 21 4>; + cache-unified; + cache-level = <2>; + clocks = <&clk NPCM7XX_CLK_AXI>; + arm,shared-override; + }; + + gic: interrupt-controller@3ff000 { + compatible = "arm,cortex-a9-gic"; + interrupt-controller; + #interrupt-cells = <3>; + reg = <0x3ff000 0x1000>, + <0x3fe100 0x100>; + }; + + timer@3fe600 { + compatible = "arm,cortex-a9-twd-timer"; + reg = <0x3fe600 0x20>; + interrupts = <1 13 0x304>; + clocks = <&clk NPCM7XX_CLK_TIMER>; + }; + }; + + ahb { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + interrupt-parent = <&gic>; + ranges; + + clk: clock-controller@f0801000 { + compatible = "nuvoton,npcm750-clk"; + #clock-cells = <1>; + reg = <0xf0801000 0x1000>; + status = "okay"; + }; + + apb { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + interrupt-parent = <&gic>; + ranges = <0x0 0xf0000000 0x00300000>; + + timer0: timer@8000 { + compatible = "nuvoton,npcm750-timer"; + interrupts = <0 32 4>; + reg = <0x8000 0x1000>; + clocks = <&clk NPCM7XX_CLK_TIMER>; + }; + + serial0: serial@1000 { + compatible = "nuvoton,npcm750-uart"; + reg = <0x1000 0x1000>; + clocks = <&clk NPCM7XX_CLK_UART_CORE>; + interrupts = <0 2 4>; + status = "disabled"; + }; + + serial1: serial@2000 { + compatible = "nuvoton,npcm750-uart"; + reg = <0x2000 0x1000>; + clocks = <&clk NPCM7XX_CLK_UART_CORE>; + interrupts = <0 3 4>; + status = "disabled"; + }; + + serial2: serial@3000 { + compatible = "nuvoton,npcm750-uart"; + reg = <0x3000 0x1000>; + clocks = <&clk NPCM7XX_CLK_UART_CORE>; + interrupts = <0 4 4>; + status = "disabled"; + }; + + serial3: serial@4000 { + compatible = "nuvoton,npcm750-uart"; + reg = <0x4000 0x1000>; + clocks = <&clk NPCM7XX_CLK_UART_CORE>; + interrupts = <0 5 4>; + status = "disabled"; + }; + }; + }; +}; diff --git a/include/dt-bindings/clock/nuvoton,npcm7xx-clks.h b/include/dt-bindings/clock/nuvoton,npcm7xx-clks.h new file mode 100644 index 000000000000..93918714f16c --- /dev/null +++ b/include/dt-bindings/clock/nuvoton,npcm7xx-clks.h @@ -0,0 +1,35 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2018 Nuvoton Technology corporation. +// Copyright 2018 Google, Inc. + +#ifndef _DT_BINDINGS_CLK_NPCM7XX_H +#define _DT_BINDINGS_CLK_NPCM7XX_H + +#define NPCM7XX_CLK_PLL0 0 +#define NPCM7XX_CLK_PLL1 1 +#define NPCM7XX_CLK_PLL2 2 +#define NPCM7XX_CLK_GFX 3 +#define NPCM7XX_CLK_APB1 4 +#define NPCM7XX_CLK_APB2 5 +#define NPCM7XX_CLK_APB3 6 +#define NPCM7XX_CLK_APB4 7 +#define NPCM7XX_CLK_APB5 8 +#define NPCM7XX_CLK_MC 9 +#define NPCM7XX_CLK_CPU 10 +#define NPCM7XX_CLK_SPI0 11 +#define NPCM7XX_CLK_SPI3 12 +#define NPCM7XX_CLK_SPIX 13 +#define NPCM7XX_CLK_UART_CORE 14 +#define NPCM7XX_CLK_TIMER 15 +#define NPCM7XX_CLK_HOST_UART 16 +#define NPCM7XX_CLK_MMC 17 +#define NPCM7XX_CLK_SDHC 18 +#define NPCM7XX_CLK_ADC 19 +#define NPCM7XX_CLK_GFX_MEM 20 +#define NPCM7XX_CLK_USB_BRIDGE 21 +#define NPCM7XX_CLK_AXI 22 +#define NPCM7XX_CLK_AHB 23 +#define NPCM7XX_CLK_EMC 24 +#define NPCM7XX_CLK_GMAC 25 + +#endif