| Message ID | 20130904034557.12546.97503.sendpatchset@w520 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Sep 4, 2013 at 5:45 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > From: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com> (...) > arch/arm/mach-shmobile/clock-r8a7791.c | 198 +++++++++++++++++++++++++ So what about starting afresh by letting this new SoC use the generic clk framework in drivers/clk from day one instead of adding another chunk of custom clk code to the kernel? (There may be reasons for this, but I have to ask the inevitable question.) Yours, Linus Walleij
On Fri, Sep 06, 2013 at 06:21:23PM +0200, Linus Walleij wrote: > On Wed, Sep 4, 2013 at 5:45 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > > > From: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com> > (...) > > arch/arm/mach-shmobile/clock-r8a7791.c | 198 +++++++++++++++++++++++++ > > So what about starting afresh by letting this new SoC use the > generic clk framework in drivers/clk from day one instead of > adding another chunk of custom clk code to the kernel? > > (There may be reasons for this, but I have to ask the > inevitable question.) Perhaps I was a bit hasty, but I have already queued up these changes. And moreover I believe they are useful in their current form for back-porting to LTSI-3.4, which I have also already done. So on those two counts my preference would be for any enhancements to be done as incremental patches on top of this series.
On Mon, Sep 9, 2013 at 2:16 AM, Simon Horman <horms@verge.net.au> wrote: > So on those two counts my preference would be for any enhancements > to be done as incremental patches on top of this series. Again: do such enhancements even exist? Yours, Linus Walleij
Hi Linus, On Sat, Sep 7, 2013 at 1:21 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Wed, Sep 4, 2013 at 5:45 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > >> From: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com> > (...) >> arch/arm/mach-shmobile/clock-r8a7791.c | 198 +++++++++++++++++++++++++ > > So what about starting afresh by letting this new SoC use the > generic clk framework in drivers/clk from day one instead of > adding another chunk of custom clk code to the kernel? I agree that we should use common clocks as soon as ever possible, but as you can see in the actual patch, Nakamura-san has already written code using the old framework. So unless you have a time machine... =) The use of legacy clocks has happened because we so far haven't done enough upfront development of Renesas-specific clock hardware drivers for CCF. So it's understandable that SoC-specific code is written towards already existing code. At the same time I agree that blindly sticking to legacy code can't work, so yes, we need to work on CCF. Fortunately there are plans to convert several mach-shmobile SoCs to common clocks over the next 6 months. As you know, we spent much time and efforts converting to pinctrl last two 6 month periods, and now we will be targeting common clocks. > (There may be reasons for this, but I have to ask the > inevitable question.) The reason why you see a new SoC with legacy clock code is that we have to add support for the new hardware when it is being released. The hardware development schedule does unfortunately not follow the upstream release schedule. =) (yet) So when a new SoW needs software support we write support towards whichever latest frameworks that we support. In parallel with this we consolidate and move over to new frameworks. It is all happening in public and we use source control we can track history if things fail. Hope this clarifies! / magnus
Hi Linus, On Mon, Sep 9, 2013 at 3:55 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Sep 9, 2013 at 2:16 AM, Simon Horman <horms@verge.net.au> wrote: > >> So on those two counts my preference would be for any enhancements >> to be done as incremental patches on top of this series. > > Again: do such enhancements even exist? There are several incremental patches available for r8a7791, but since this is a new and rare platform it won't be the first SoC we convert to common clocks. So CCF development will happen on r8a7791, but it won't be the first platform. To be able to start using common clocks we first need to break out the basic building blocks and then tie them in on one SoC at a time. These basic building blocks of course need to use already-existing CCF bits for gating, dividers and plls. We will also need some special handling like for instance polling of registers to wait for rate change. So the issue in my opinion is not so much the SoC specific bits. Instead it's the shared CCF bits that need work. The real question is probably if new SoC support needs to block on framework support. I'm all about incremental changes. If there is something special that needs extra focus then of course we will work on that. Cheers, / magnus
On Mon, Sep 9, 2013 at 9:21 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > Fortunately there are plans to convert several mach-shmobile SoCs to > common clocks over the next 6 months. As you know, we spent much time > and efforts converting to pinctrl last two 6 month periods, and now we > will be targeting common clocks. I trust you on this, it's not for me to decide but for the ARM SoC maintainers. I think Arnd basically said at one point that it is OK to add some new cruft as long as you remove more old cruft at the same time, so I guess you will have to make an argument that this is happening. > There are several incremental patches available for r8a7791, but since > this is a new and rare platform it won't be the first SoC we convert > to common clocks. So CCF development will happen on r8a7791, but it > won't be the first platform. This is pretty much the inverse argument of the usual stance of the ARM SoC tree - usually we ask that new platforms should use new frameworks. I do understand it from a practical point of view, that new SoCs only exist in few prototypes. But again, this is up for the ARM SoC folks to decide. Yours, Linus Walleij
On Mon, Sep 9, 2013 at 4:45 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Sep 9, 2013 at 9:21 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > >> Fortunately there are plans to convert several mach-shmobile SoCs to >> common clocks over the next 6 months. As you know, we spent much time >> and efforts converting to pinctrl last two 6 month periods, and now we >> will be targeting common clocks. > > I trust you on this, it's not for me to decide but for the ARM SoC > maintainers. I think Arnd basically said at one point that it is OK > to add some new cruft as long as you remove more old cruft at > the same time, so I guess you will have to make an argument that > this is happening. Yeah, I agree. I hope to discuss this in person later this Autumn. >> There are several incremental patches available for r8a7791, but since >> this is a new and rare platform it won't be the first SoC we convert >> to common clocks. So CCF development will happen on r8a7791, but it >> won't be the first platform. > > This is pretty much the inverse argument of the usual stance of > the ARM SoC tree - usually we ask that new platforms should use > new frameworks. I do understand it from a practical point of view, > that new SoCs only exist in few prototypes. I suppose negotiation has to happen on some level, and I appreciate the higher level give-and-take approach that Arnd has been taking. At this time though, apart from common clocks, extended DT support and multiplatform I'm not so sure what desired cleanup-wise. > But again, this is up for the ARM SoC folks to decide. Yep. Thanks for your comments! / magnus
On Mon, Sep 9, 2013 at 10:05 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > At > this time though, apart from common clocks, extended DT support and > multiplatform I'm not so sure what desired cleanup-wise. It'd be nice to switch shmobile to use AUTO_ZRELADDR, as it is the other criteria (apart from common clock) standing in the way for multiplatform. (Maybe this just works if you turn it on?) For multiplatform you also have to depopulate <mach/*> completely, either move stuff down into the mach-folder or to <linux/platform_data/*> if absolutely necessary. This will be quite some work, especially if the <mach/*> path is used in a lot of drivers... Then we have a quite broad consensus to depopulate arch/arm/* of drivers, so for shmobile: clock* -> drivers/clk cpuidle.c -> drivers/cpuidle (or was this just fixed?) intc* -> drivers/irqchips sh-gpio.c -> drivers/pinctrl/gpio The last one I know you will soon finish. Then deleteing all board file stuff that is not using DT. After all that it's top-notch I think :-) Yours, Linus Walleij
Hi Linus, On Mon, Sep 9, 2013 at 6:15 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Sep 9, 2013 at 10:05 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > >> At >> this time though, apart from common clocks, extended DT support and >> multiplatform I'm not so sure what desired cleanup-wise. > > It'd be nice to switch shmobile to use AUTO_ZRELADDR, as it is > the other criteria (apart from common clock) standing in the way > for multiplatform. (Maybe this just works if you turn it on?) This works already for the majority of the boards. My gut feeling is that it should be the default for multiplatform. There is one special case when AUTO_ZRELADDR is not working today - both Laurent and I spent a bit of time trying to figure it out - but it is currently not moving anywhere due to focus elsewhere. It is however only triggering on one board - KZM9G - and that board is not yet supported by neither common clocks nor multiplatform yet anyway, so it's a problem pretty far away in the future. > For multiplatform you also have to depopulate <mach/*> > completely, either move stuff down into the mach-folder > or to <linux/platform_data/*> if absolutely necessary. > This will be quite some work, especially if the <mach/*> > path is used in a lot of drivers... Fortunately we don't use mach/ in our drivers, so that shouldn't be any issue. At least that used to be the case. See it as a nice side effect of doing both SH and ARM. =) > Then we have a quite broad consensus to depopulate arch/arm/* > of drivers, so for shmobile: > > clock* -> drivers/clk Sure, here we have quite a bit to do, no doubt about that! > cpuidle.c -> drivers/cpuidle (or was this just fixed?) I don't know the latest state here. For me it would make sense that arch/arm actually contained some shared sleep mode support, but if that should be in drivers/ instead then that's really no biggie for me. We have some cpuidle code that wants to be moved. > intc* -> drivers/irqchips We have some legacy SoCs using INTC tables under mach-shmobile/, but it is likely that those SoCs will be phased out before we have working generic INTC DT binding support. Everything modern is using GIC plus drivers under drivers/irqchips already. > sh-gpio.c -> drivers/pinctrl/gpio > > The last one I know you will soon finish. I believe Laurent has this under control. Actually, from the top of my head I don't even know which IP sh-gpio.c is tied to. I know we have a couple of drivers in drivers/gpio and also stuff in drivers/pinctrl/, but apart from that.. > Then deleteing all board file stuff that is not using DT. As you noticed, we sort of have a flow of code coming in that is written for currently-existing frameworks. Then we have the upstream rework and DT support going on in parallel. To aid this we have something called DT reference board support, which is basically board support code where we add DT bit by bit. Those DT reference boards can also be used together with common clocks and multiplatform kernels. KZM9D and EMEV2 are multiplatform ready, but lack CCF at this point. So the idea is that we move individual SoCs and boards over to multiplatform and then remove the old board code bit by bit. In parallel with this we may phase out old boards and old SoCs. > After all that it's top-notch I think :-) Thanks for your suggestions!! / magnus
Hi, Coming across this somewhat old email thread, apologies for the delay in response. On Mon, Sep 09, 2013 at 05:05:18PM +0900, Magnus Damm wrote: > On Mon, Sep 9, 2013 at 4:45 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > > On Mon, Sep 9, 2013 at 9:21 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > > > >> Fortunately there are plans to convert several mach-shmobile SoCs to > >> common clocks over the next 6 months. As you know, we spent much time > >> and efforts converting to pinctrl last two 6 month periods, and now we > >> will be targeting common clocks. > > > > I trust you on this, it's not for me to decide but for the ARM SoC > > maintainers. I think Arnd basically said at one point that it is OK > > to add some new cruft as long as you remove more old cruft at > > the same time, so I guess you will have to make an argument that > > this is happening. > > Yeah, I agree. I hope to discuss this in person later this Autumn. > > >> There are several incremental patches available for r8a7791, but since > >> this is a new and rare platform it won't be the first SoC we convert > >> to common clocks. So CCF development will happen on r8a7791, but it > >> won't be the first platform. > > > > This is pretty much the inverse argument of the usual stance of > > the ARM SoC tree - usually we ask that new platforms should use > > new frameworks. I do understand it from a practical point of view, > > that new SoCs only exist in few prototypes. > > I suppose negotiation has to happen on some level, and I appreciate > the higher level give-and-take approach that Arnd has been taking. At > this time though, apart from common clocks, extended DT support and > multiplatform I'm not so sure what desired cleanup-wise. We have definitely been OK with new code going in together with cleanups, but I think we're reaching a point where there's a lot of new code going in on shmobile platforms now, and we've had some growing pains on the platform for it -- conflicts with other maintainer trees because they have picked up board file changes, etc. I think much of this wouldn't be a problem if the conversions to DT/multiplatform was completed, so it would be great if the conversion could be given priority on the Renesas side, especially given the rate of new additions as of late -- I think we're seeing new SoCs almost every release cycle as of late. So, bottom line: I'm not going to refuse taking this new platform, but you're close to the limits and please try to prioritize finishing conversion. In particular since all this "new legacy code" you're adding will all have to be converted soon -- in some cases it might be better to wait with adding it until after conversion. -Olof
--- /dev/null +++ work/arch/arm/boot/dts/r8a7791.dtsi 2013-09-03 20:44:56.000000000 +0900 @@ -0,0 +1,41 @@ +/* + * Device Tree Source for the r8a7791 SoC + * + * Copyright (C) 2013 Renesas Electronics Corporation + * Copyright (C) 2013 Renesas Solutions Corp. + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +/ { + compatible = "renesas,r8a7791"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0>; + clock-frequency = <1300000000>; + }; + }; + + gic: interrupt-controller@f1001000 { + compatible = "arm,cortex-a15-gic"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0 0xf1001000 0 0x1000>, + <0 0xf1002000 0 0x1000>, + <0 0xf1004000 0 0x2000>, + <0 0xf1006000 0 0x2000>; + interrupts = <1 9 0xf04>; + }; +}; --- 0001/arch/arm/mach-shmobile/Kconfig +++ work/arch/arm/mach-shmobile/Kconfig 2013-09-03 20:44:32.000000000 +0900 @@ -101,6 +101,12 @@ config ARCH_R8A7790 select SH_CLK_CPG select RENESAS_IRQC +config ARCH_R8A7791 + bool "R-Car M2 (R8A77910)" + select ARM_GIC + select CPU_V7 + select SH_CLK_CPG + config ARCH_EMEV2 bool "Emma Mobile EV2" select ARCH_WANT_OPTIONAL_GPIOLIB --- 0001/arch/arm/mach-shmobile/Makefile +++ work/arch/arm/mach-shmobile/Makefile 2013-09-03 20:44:32.000000000 +0900 @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_R8A7740) += setup-r8a7 obj-$(CONFIG_ARCH_R8A7778) += setup-r8a7778.o obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o obj-$(CONFIG_ARCH_R8A7790) += setup-r8a7790.o +obj-$(CONFIG_ARCH_R8A7791) += setup-r8a7791.o obj-$(CONFIG_ARCH_EMEV2) += setup-emev2.o # Clock objects @@ -27,6 +28,7 @@ obj-$(CONFIG_ARCH_R8A7740) += clock-r8a7 obj-$(CONFIG_ARCH_R8A7778) += clock-r8a7778.o obj-$(CONFIG_ARCH_R8A7779) += clock-r8a7779.o obj-$(CONFIG_ARCH_R8A7790) += clock-r8a7790.o +obj-$(CONFIG_ARCH_R8A7791) += clock-r8a7791.o obj-$(CONFIG_ARCH_EMEV2) += clock-emev2.o endif --- /dev/null +++ work/arch/arm/mach-shmobile/clock-r8a7791.c 2013-09-03 20:44:33.000000000 +0900 @@ -0,0 +1,198 @@ +/* + * r8a7791 clock framework support + * + * Copyright (C) 2013 Renesas Electronics Corporation + * Copyright (C) 2013 Renesas Solutions Corp. + * Copyright (C) 2013 Magnus Damm + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ +#include <linux/init.h> +#include <linux/io.h> +#include <linux/kernel.h> +#include <linux/sh_clk.h> +#include <linux/clkdev.h> +#include <mach/clock.h> +#include <mach/common.h> + +/* + * MD EXTAL PLL0 PLL1 PLL3 + * 14 13 19 (MHz) *1 *1 + *--------------------------------------------------- + * 0 0 0 15 x 1 x172/2 x208/2 x106 + * 0 0 1 15 x 1 x172/2 x208/2 x88 + * 0 1 0 20 x 1 x130/2 x156/2 x80 + * 0 1 1 20 x 1 x130/2 x156/2 x66 + * 1 0 0 26 / 2 x200/2 x240/2 x122 + * 1 0 1 26 / 2 x200/2 x240/2 x102 + * 1 1 0 30 / 2 x172/2 x208/2 x106 + * 1 1 1 30 / 2 x172/2 x208/2 x88 + * + * *1 : Table 7.6 indicates VCO ouput (PLLx = VCO/2) + * see "p1 / 2" on R8A7791_CLOCK_ROOT() below + */ + +#define MD(nr) (1 << nr) + +#define CPG_BASE 0xe6150000 +#define CPG_LEN 0x1000 + +#define SMSTPCR1 0xE6150134 +#define SMSTPCR2 0xe6150138 +#define SMSTPCR3 0xE615013C +#define SMSTPCR5 0xE6150144 +#define SMSTPCR7 0xe615014c +#define SMSTPCR8 0xE6150990 +#define SMSTPCR9 0xE6150994 +#define SMSTPCR10 0xE6150998 + +#define MODEMR 0xE6160060 +#define SDCKCR 0xE6150074 +#define SD2CKCR 0xE6150078 +#define SD3CKCR 0xE615007C +#define MMC0CKCR 0xE6150240 +#define MMC1CKCR 0xE6150244 +#define SSPCKCR 0xE6150248 +#define SSPRSCKCR 0xE615024C + +static struct clk_mapping cpg_mapping = { + .phys = CPG_BASE, + .len = CPG_LEN, +}; + +static struct clk extal_clk = { + /* .rate will be updated on r8a7791_clock_init() */ + .mapping = &cpg_mapping, +}; + +static struct sh_clk_ops followparent_clk_ops = { + .recalc = followparent_recalc, +}; + +static struct clk main_clk = { + /* .parent will be set r8a73a4_clock_init */ + .ops = &followparent_clk_ops, +}; + +/* + * clock ratio of these clock will be updated + * on r8a7791_clock_init() + */ +SH_FIXED_RATIO_CLK_SET(pll1_clk, main_clk, 1, 1); +SH_FIXED_RATIO_CLK_SET(pll3_clk, main_clk, 1, 1); + +/* fixed ratio clock */ +SH_FIXED_RATIO_CLK_SET(extal_div2_clk, extal_clk, 1, 2); +SH_FIXED_RATIO_CLK_SET(cp_clk, extal_clk, 1, 2); + +SH_FIXED_RATIO_CLK_SET(pll1_div2_clk, pll1_clk, 1, 2); +SH_FIXED_RATIO_CLK_SET(hp_clk, pll1_clk, 1, 12); +SH_FIXED_RATIO_CLK_SET(p_clk, pll1_clk, 1, 24); + +SH_FIXED_RATIO_CLK_SET(mp_clk, pll1_div2_clk, 1, 15); + +static struct clk *main_clks[] = { + &extal_clk, + &extal_div2_clk, + &main_clk, + &pll1_clk, + &pll1_div2_clk, + &pll3_clk, + &hp_clk, + &p_clk, + &mp_clk, + &cp_clk, +}; + +/* MSTP */ +enum { + MSTP721, MSTP720, +/* MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP202,*/ + MSTP_NR +}; + +static struct clk mstp_clks[MSTP_NR] = { + [MSTP721] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 21, 0), /* SCIF0 */ + [MSTP720] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 20, 0), /* SCIF1 */ +}; + +static struct clk_lookup lookups[] = { + + /* main clocks */ + CLKDEV_CON_ID("extal", &extal_clk), + CLKDEV_CON_ID("extal_div2", &extal_div2_clk), + CLKDEV_CON_ID("main", &main_clk), + CLKDEV_CON_ID("pll1", &pll1_clk), + CLKDEV_CON_ID("pll1_div2", &pll1_div2_clk), + CLKDEV_CON_ID("pll3", &pll3_clk), + CLKDEV_CON_ID("hp", &hp_clk), + CLKDEV_CON_ID("p", &p_clk), + CLKDEV_CON_ID("mp", &mp_clk), + CLKDEV_CON_ID("cp", &cp_clk), + CLKDEV_CON_ID("peripheral_clk", &hp_clk), +}; + +#define R8A7791_CLOCK_ROOT(e, m, p0, p1, p30, p31) \ + extal_clk.rate = e * 1000 * 1000; \ + main_clk.parent = m; \ + SH_CLK_SET_RATIO(&pll1_clk_ratio, p1 / 2, 1); \ + if (mode & MD(19)) \ + SH_CLK_SET_RATIO(&pll3_clk_ratio, p31, 1); \ + else \ + SH_CLK_SET_RATIO(&pll3_clk_ratio, p30, 1) + + +void __init r8a7791_clock_init(void) +{ + void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE); + u32 mode; + int k, ret = 0; + + BUG_ON(!modemr); + mode = ioread32(modemr); + iounmap(modemr); + + switch (mode & (MD(14) | MD(13))) { + case 0: + R8A7791_CLOCK_ROOT(15, &extal_clk, 172, 208, 106, 88); + break; + case MD(13): + R8A7791_CLOCK_ROOT(20, &extal_clk, 130, 156, 80, 66); + break; + case MD(14): + R8A7791_CLOCK_ROOT(26, &extal_div2_clk, 200, 240, 122, 102); + break; + case MD(13) | MD(14): + R8A7791_CLOCK_ROOT(30, &extal_div2_clk, 172, 208, 106, 88); + break; + } + + for (k = 0; !ret && (k < ARRAY_SIZE(main_clks)); k++) + ret = clk_register(main_clks[k]); + + if (!ret) + ret = sh_clk_mstp_register(mstp_clks, MSTP_NR); + + clkdev_add_table(lookups, ARRAY_SIZE(lookups)); + + if (!ret) + shmobile_clk_init(); + else + goto epanic; + + return; + +epanic: + panic("failed to setup r8a7791 clocks\n"); +} --- /dev/null +++ work/arch/arm/mach-shmobile/include/mach/r8a7791.h 2013-09-03 20:44:33.000000000 +0900 @@ -0,0 +1,6 @@ +#ifndef __ASM_R8A7791_H__ +#define __ASM_R8A7791_H__ + +void r8a7791_clock_init(void); + +#endif /* __ASM_R8A7791_H__ */ --- /dev/null +++ work/arch/arm/mach-shmobile/setup-r8a7791.c 2013-09-03 20:44:33.000000000 +0900 @@ -0,0 +1,38 @@ +/* + * r8a7791 processor support + * + * Copyright (C) 2013 Renesas Electronics Corporation + * Copyright (C) 2013 Renesas Solutions Corp. + * Copyright (C) 2013 Magnus Damm + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include <linux/irq.h> +#include <linux/kernel.h> +#include <linux/of_platform.h> +#include <mach/common.h> +#include <mach/r8a7791.h> +#include <asm/mach/arch.h> + +#ifdef CONFIG_USE_OF +static const char *r8a7791_boards_compat_dt[] __initdata = { + "renesas,r8a7791", + NULL, +}; + +DT_MACHINE_START(R8A7791_DT, "Generic R8A7791 (Flattened Device Tree)") + .dt_compat = r8a7791_boards_compat_dt, +MACHINE_END +#endif /* CONFIG_USE_OF */