* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-04 3:45 [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support Magnus Damm
@ 2013-09-04 3:45 ` Magnus Damm
2013-09-06 16:21 ` Linus Walleij
2013-09-04 3:46 ` [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support Magnus Damm
` (3 subsequent siblings)
4 siblings, 1 reply; 24+ messages in thread
From: Magnus Damm @ 2013-09-04 3:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
Add initial support for the r8a7791 SoC including:
- Single Cortex-A15 CPU Core
- GIC
No static virtual mappings are used, all the components
make use of ioremap(). DT_MACHINE_START is still wrapped
in CONFIG_USE_OF to match other mach-shmobile code.
Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
Signed-off-by: Ryo Kataoka <ryo.kataoka.wt@renesas.com>
[damm at opensource.se: Forward ported to upstream, dropped not-yet-ready code]
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/boot/dts/r8a7791.dtsi | 41 +++++
arch/arm/mach-shmobile/Kconfig | 6
arch/arm/mach-shmobile/Makefile | 2
arch/arm/mach-shmobile/clock-r8a7791.c | 198 +++++++++++++++++++++++++
arch/arm/mach-shmobile/include/mach/r8a7791.h | 6
arch/arm/mach-shmobile/setup-r8a7791.c | 38 ++++
6 files changed, 291 insertions(+)
--- /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 at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1300000000>;
+ };
+ };
+
+ gic: interrupt-controller at 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 */
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-04 3:45 ` [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support Magnus Damm
@ 2013-09-06 16:21 ` Linus Walleij
2013-09-09 0:16 ` Simon Horman
2013-09-09 7:21 ` Magnus Damm
0 siblings, 2 replies; 24+ messages in thread
From: Linus Walleij @ 2013-09-06 16:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-06 16:21 ` Linus Walleij
@ 2013-09-09 0:16 ` Simon Horman
2013-09-09 6:55 ` Linus Walleij
2013-09-09 7:21 ` Magnus Damm
1 sibling, 1 reply; 24+ messages in thread
From: Simon Horman @ 2013-09-09 0:16 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-09 0:16 ` Simon Horman
@ 2013-09-09 6:55 ` Linus Walleij
2013-09-09 7:37 ` Magnus Damm
0 siblings, 1 reply; 24+ messages in thread
From: Linus Walleij @ 2013-09-09 6:55 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-09 6:55 ` Linus Walleij
@ 2013-09-09 7:37 ` Magnus Damm
0 siblings, 0 replies; 24+ messages in thread
From: Magnus Damm @ 2013-09-09 7:37 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-06 16:21 ` Linus Walleij
2013-09-09 0:16 ` Simon Horman
@ 2013-09-09 7:21 ` Magnus Damm
2013-09-09 7:45 ` Linus Walleij
1 sibling, 1 reply; 24+ messages in thread
From: Magnus Damm @ 2013-09-09 7:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-09 7:21 ` Magnus Damm
@ 2013-09-09 7:45 ` Linus Walleij
2013-09-09 8:05 ` Magnus Damm
0 siblings, 1 reply; 24+ messages in thread
From: Linus Walleij @ 2013-09-09 7:45 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-09 7:45 ` Linus Walleij
@ 2013-09-09 8:05 ` Magnus Damm
2013-09-09 9:15 ` Linus Walleij
2013-09-18 17:20 ` Olof Johansson
0 siblings, 2 replies; 24+ messages in thread
From: Magnus Damm @ 2013-09-09 8:05 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-09 8:05 ` Magnus Damm
@ 2013-09-09 9:15 ` Linus Walleij
2013-09-09 10:32 ` Magnus Damm
2013-09-18 17:20 ` Olof Johansson
1 sibling, 1 reply; 24+ messages in thread
From: Linus Walleij @ 2013-09-09 9:15 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-09 9:15 ` Linus Walleij
@ 2013-09-09 10:32 ` Magnus Damm
0 siblings, 0 replies; 24+ messages in thread
From: Magnus Damm @ 2013-09-09 10:32 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
2013-09-09 8:05 ` Magnus Damm
2013-09-09 9:15 ` Linus Walleij
@ 2013-09-18 17:20 ` Olof Johansson
1 sibling, 0 replies; 24+ messages in thread
From: Olof Johansson @ 2013-09-18 17:20 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
2013-09-04 3:45 [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support Magnus Damm
2013-09-04 3:45 ` [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support Magnus Damm
@ 2013-09-04 3:46 ` Magnus Damm
2013-09-06 16:27 ` Linus Walleij
2013-09-04 3:46 ` [PATCH 03/04] ARM: shmobile: r8a7791 CMT support Magnus Damm
` (2 subsequent siblings)
4 siblings, 1 reply; 24+ messages in thread
From: Magnus Damm @ 2013-09-04 3:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Yoshikazu Fujikawa <yoshikazu.fujikawa.ue@renesas.com>
Add SCIF serial port support to the r8a7791 SoC by
adding platform devices for SCIFA0 -> SCIFA5 as well
as SCIFB0 -> SCIFB2 and SCIF0 -> SCIF5 together with
clock bindings. DT device description is excluded at
this point since such bindings are still under
development.
Signed-off-by: Yoshikazu Fujikawa <yoshikazu.fujikawa.ue@renesas.com>
Signed-off-by: Ryo Kataoka <ryo.kataoka.wt@renesas.com>
[damm at opensource.se: Forward ported to upstream, dropped holes in enum]
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/clock-r8a7791.c | 36 ++++++++++
arch/arm/mach-shmobile/include/mach/r8a7791.h | 1
arch/arm/mach-shmobile/setup-r8a7791.c | 82 +++++++++++++++++++++++++
3 files changed, 118 insertions(+), 1 deletion(-)
--- 0003/arch/arm/mach-shmobile/clock-r8a7791.c
+++ work/arch/arm/mach-shmobile/clock-r8a7791.c 2013-09-03 20:54:28.000000000 +0900
@@ -48,6 +48,7 @@
#define CPG_BASE 0xe6150000
#define CPG_LEN 0x1000
+#define SMSTPCR0 0xE6150130
#define SMSTPCR1 0xE6150134
#define SMSTPCR2 0xe6150138
#define SMSTPCR3 0xE615013C
@@ -56,6 +57,7 @@
#define SMSTPCR8 0xE6150990
#define SMSTPCR9 0xE6150994
#define SMSTPCR10 0xE6150998
+#define SMSTPCR11 0xE615099C
#define MODEMR 0xE6160060
#define SDCKCR 0xE6150074
@@ -118,13 +120,28 @@ static struct clk *main_clks[] = {
/* MSTP */
enum {
MSTP721, MSTP720,
-/* MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP202,*/
+ MSTP719, MSTP718, MSTP715, MSTP714,
+ MSTP216, MSTP207, MSTP206,
+ MSTP204, MSTP203, MSTP202, MSTP1105, MSTP1106, MSTP1107,
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 */
+ [MSTP719] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 19, 0), /* SCIF2 */
+ [MSTP718] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 18, 0), /* SCIF3 */
+ [MSTP715] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 15, 0), /* SCIF4 */
+ [MSTP714] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 14, 0), /* SCIF5 */
+ [MSTP216] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 16, 0), /* SCIFB2 */
+ [MSTP207] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 7, 0), /* SCIFB1 */
+ [MSTP206] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 6, 0), /* SCIFB0 */
+ [MSTP204] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
+ [MSTP203] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
+ [MSTP202] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 2, 0), /* SCIFA2 */
+ [MSTP1105] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 5, 0), /* SCIFA3 */
+ [MSTP1106] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 6, 0), /* SCIFA4 */
+ [MSTP1107] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 7, 0), /* SCIFA5 */
};
static struct clk_lookup lookups[] = {
@@ -141,6 +158,23 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID("mp", &mp_clk),
CLKDEV_CON_ID("cp", &cp_clk),
CLKDEV_CON_ID("peripheral_clk", &hp_clk),
+
+ /* MSTP */
+ CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP204]), /* SCIFA0 */
+ CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP203]), /* SCIFA1 */
+ CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP206]), /* SCIFB0 */
+ CLKDEV_DEV_ID("sh-sci.3", &mstp_clks[MSTP207]), /* SCIFB1 */
+ CLKDEV_DEV_ID("sh-sci.4", &mstp_clks[MSTP216]), /* SCIFB2 */
+ CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP202]), /* SCIFA2 */
+ CLKDEV_DEV_ID("sh-sci.6", &mstp_clks[MSTP721]), /* SCIF0 */
+ CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP720]), /* SCIF1 */
+ CLKDEV_DEV_ID("sh-sci.8", &mstp_clks[MSTP719]), /* SCIF2 */
+ CLKDEV_DEV_ID("sh-sci.9", &mstp_clks[MSTP718]), /* SCIF3 */
+ CLKDEV_DEV_ID("sh-sci.10", &mstp_clks[MSTP715]), /* SCIF4 */
+ CLKDEV_DEV_ID("sh-sci.11", &mstp_clks[MSTP714]), /* SCIF5 */
+ CLKDEV_DEV_ID("sh-sci.12", &mstp_clks[MSTP1105]), /* SCIFA3 */
+ CLKDEV_DEV_ID("sh-sci.13", &mstp_clks[MSTP1106]), /* SCIFA4 */
+ CLKDEV_DEV_ID("sh-sci.14", &mstp_clks[MSTP1107]), /* SCIFA5 */
};
#define R8A7791_CLOCK_ROOT(e, m, p0, p1, p30, p31) \
--- 0003/arch/arm/mach-shmobile/include/mach/r8a7791.h
+++ work/arch/arm/mach-shmobile/include/mach/r8a7791.h 2013-09-03 20:49:08.000000000 +0900
@@ -1,6 +1,7 @@
#ifndef __ASM_R8A7791_H__
#define __ASM_R8A7791_H__
+void r8a7791_add_dt_devices(void);
void r8a7791_clock_init(void);
#endif /* __ASM_R8A7791_H__ */
--- 0003/arch/arm/mach-shmobile/setup-r8a7791.c
+++ work/arch/arm/mach-shmobile/setup-r8a7791.c 2013-09-03 20:49:08.000000000 +0900
@@ -22,10 +22,92 @@
#include <linux/irq.h>
#include <linux/kernel.h>
#include <linux/of_platform.h>
+#include <linux/serial_sci.h>
#include <mach/common.h>
+#include <mach/irqs.h>
#include <mach/r8a7791.h>
#include <asm/mach/arch.h>
+#define SCIF_COMMON(scif_type, baseaddr, irq) \
+ .type = scif_type, \
+ .mapbase = baseaddr, \
+ .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP, \
+ .irqs = SCIx_IRQ_MUXED(irq)
+
+#define SCIFA_DATA(index, baseaddr, irq) \
+[index] = { \
+ SCIF_COMMON(PORT_SCIFA, baseaddr, irq), \
+ .scbrr_algo_id = SCBRR_ALGO_4, \
+ .scscr = SCSCR_RE | SCSCR_TE, \
+}
+
+#define SCIFB_DATA(index, baseaddr, irq) \
+[index] = { \
+ SCIF_COMMON(PORT_SCIFB, baseaddr, irq), \
+ .scbrr_algo_id = SCBRR_ALGO_4, \
+ .scscr = SCSCR_RE | SCSCR_TE, \
+}
+
+#define SCIF_DATA(index, baseaddr, irq) \
+[index] = { \
+ SCIF_COMMON(PORT_SCIF, baseaddr, irq), \
+ .scbrr_algo_id = SCBRR_ALGO_2, \
+ .scscr = SCSCR_RE | SCSCR_TE, \
+}
+
+#define HSCIF_DATA(index, baseaddr, irq) \
+[index] = { \
+ SCIF_COMMON(PORT_HSCIF, baseaddr, irq), \
+ .scbrr_algo_id = SCBRR_ALGO_6, \
+ .scscr = SCSCR_RE | SCSCR_TE, \
+}
+
+enum { SCIFA0, SCIFA1, SCIFB0, SCIFB1, SCIFB2, SCIFA2, SCIF0, SCIF1,
+ SCIF2, SCIF3, SCIF4, SCIF5, SCIFA3, SCIFA4, SCIFA5 };
+
+static const struct plat_sci_port scif[] __initconst = {
+ SCIFA_DATA(SCIFA0, 0xe6c40000, gic_spi(144)), /* SCIFA0 */
+ SCIFA_DATA(SCIFA1, 0xe6c50000, gic_spi(145)), /* SCIFA1 */
+ SCIFB_DATA(SCIFB0, 0xe6c20000, gic_spi(148)), /* SCIFB0 */
+ SCIFB_DATA(SCIFB1, 0xe6c30000, gic_spi(149)), /* SCIFB1 */
+ SCIFB_DATA(SCIFB2, 0xe6ce0000, gic_spi(150)), /* SCIFB2 */
+ SCIFA_DATA(SCIFA2, 0xe6c60000, gic_spi(151)), /* SCIFA2 */
+ SCIF_DATA(SCIF0, 0xe6e60000, gic_spi(152)), /* SCIF0 */
+ SCIF_DATA(SCIF1, 0xe6e68000, gic_spi(153)), /* SCIF1 */
+ SCIF_DATA(SCIF2, 0xe6e58000, gic_spi(22)), /* SCIF2 */
+ SCIF_DATA(SCIF3, 0xe6ea8000, gic_spi(23)), /* SCIF3 */
+ SCIF_DATA(SCIF4, 0xe6ee0000, gic_spi(24)), /* SCIF4 */
+ SCIF_DATA(SCIF5, 0xe6ee8000, gic_spi(25)), /* SCIF5 */
+ SCIFA_DATA(SCIFA3, 0xe6c70000, gic_spi(29)), /* SCIFA3 */
+ SCIFA_DATA(SCIFA4, 0xe6c78000, gic_spi(30)), /* SCIFA4 */
+ SCIFA_DATA(SCIFA5, 0xe6c80000, gic_spi(31)), /* SCIFA5 */
+};
+
+static inline void r8a7791_register_scif(int idx)
+{
+ platform_device_register_data(&platform_bus, "sh-sci", idx, &scif[idx],
+ sizeof(struct plat_sci_port));
+}
+
+void __init r8a7791_add_dt_devices(void)
+{
+ r8a7791_register_scif(SCIFA0);
+ r8a7791_register_scif(SCIFA1);
+ r8a7791_register_scif(SCIFB0);
+ r8a7791_register_scif(SCIFB1);
+ r8a7791_register_scif(SCIFB2);
+ r8a7791_register_scif(SCIFA2);
+ r8a7791_register_scif(SCIF0);
+ r8a7791_register_scif(SCIF1);
+ r8a7791_register_scif(SCIF2);
+ r8a7791_register_scif(SCIF3);
+ r8a7791_register_scif(SCIF4);
+ r8a7791_register_scif(SCIF5);
+ r8a7791_register_scif(SCIFA3);
+ r8a7791_register_scif(SCIFA4);
+ r8a7791_register_scif(SCIFA5);
+}
+
#ifdef CONFIG_USE_OF
static const char *r8a7791_boards_compat_dt[] __initdata = {
"renesas,r8a7791",
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
2013-09-04 3:46 ` [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support Magnus Damm
@ 2013-09-06 16:27 ` Linus Walleij
2013-09-09 0:15 ` Simon Horman
2013-09-09 7:24 ` Magnus Damm
0 siblings, 2 replies; 24+ messages in thread
From: Linus Walleij @ 2013-09-06 16:27 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Sep 4, 2013 at 5:46 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> From: Yoshikazu Fujikawa <yoshikazu.fujikawa.ue@renesas.com>
>
> Add SCIF serial port support to the r8a7791 SoC by
> adding platform devices for SCIFA0 -> SCIFA5 as well
> as SCIFB0 -> SCIFB2 and SCIF0 -> SCIF5 together with
> clock bindings. DT device description is excluded at
> this point since such bindings are still under
> development.
A good way to get started with clock bindings may be to
move the clocks to drivers/clk because in the neighboring
drivers over there are many good examples of how to do
this.
Again this looks like it is piling up more legacy clk
code instead of moving to the new frameworks.
Please include Mike Turquette on future postings of the
clk code, he's definately our best clock code reviewer.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
2013-09-06 16:27 ` Linus Walleij
@ 2013-09-09 0:15 ` Simon Horman
2013-09-09 6:54 ` Linus Walleij
2013-09-09 7:24 ` Magnus Damm
1 sibling, 1 reply; 24+ messages in thread
From: Simon Horman @ 2013-09-09 0:15 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 06, 2013 at 06:27:22PM +0200, Linus Walleij wrote:
> On Wed, Sep 4, 2013 at 5:46 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>
> > From: Yoshikazu Fujikawa <yoshikazu.fujikawa.ue@renesas.com>
> >
> > Add SCIF serial port support to the r8a7791 SoC by
> > adding platform devices for SCIFA0 -> SCIFA5 as well
> > as SCIFB0 -> SCIFB2 and SCIF0 -> SCIF5 together with
> > clock bindings. DT device description is excluded at
> > this point since such bindings are still under
> > development.
>
> A good way to get started with clock bindings may be to
> move the clocks to drivers/clk because in the neighboring
> drivers over there are many good examples of how to do
> this.
>
> Again this looks like it is piling up more legacy clk
> code instead of moving to the new frameworks.
>
> Please include Mike Turquette on future postings of the
> clk code, he's definately our best clock code reviewer.
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
2013-09-09 0:15 ` Simon Horman
@ 2013-09-09 6:54 ` Linus Walleij
2013-09-09 7:09 ` Simon Horman
0 siblings, 1 reply; 24+ messages in thread
From: Linus Walleij @ 2013-09-09 6:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 9, 2013 at 2:15 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Sep 06, 2013 at 06:27:22PM +0200, Linus Walleij wrote:
>> Again this looks like it is piling up more legacy clk
>> code instead of moving to the new frameworks.
>>
>> Please include Mike Turquette on future postings of the
>> clk code, he's definately our best clock code reviewer.
>
> 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.
That sounds like you're a bit too trigger-happy ;-)
> So on those two counts my preference would be for any enhancements
> to be done as incremental patches on top of this series.
Hm hm. I am worried that it is taken as an OK to proceed
extending old cruft for new SoCs rather than moving to new
frameworks. I would agree if such migration patches were
floating the lists but I am not aware of any patches starting
to create drivers/clk/sh*, are you?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
2013-09-09 6:54 ` Linus Walleij
@ 2013-09-09 7:09 ` Simon Horman
2013-09-09 7:28 ` Magnus Damm
0 siblings, 1 reply; 24+ messages in thread
From: Simon Horman @ 2013-09-09 7:09 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 09, 2013 at 08:54:59AM +0200, Linus Walleij wrote:
> On Mon, Sep 9, 2013 at 2:15 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Sep 06, 2013 at 06:27:22PM +0200, Linus Walleij wrote:
>
> >> Again this looks like it is piling up more legacy clk
> >> code instead of moving to the new frameworks.
> >>
> >> Please include Mike Turquette on future postings of the
> >> clk code, he's definately our best clock code reviewer.
> >
> > 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.
>
> That sounds like you're a bit too trigger-happy ;-)
Perhaps.
> > So on those two counts my preference would be for any enhancements
> > to be done as incremental patches on top of this series.
>
> Hm hm. I am worried that it is taken as an OK to proceed
> extending old cruft for new SoCs rather than moving to new
> frameworks. I would agree if such migration patches were
> floating the lists but I am not aware of any patches starting
> to create drivers/clk/sh*, are you?
I am not aware of such patches.
I will defer this to Magnus who is both the author of this series
and I believe the person who knows the most about the plans for
drivers/clk/sh*.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
2013-09-09 7:09 ` Simon Horman
@ 2013-09-09 7:28 ` Magnus Damm
0 siblings, 0 replies; 24+ messages in thread
From: Magnus Damm @ 2013-09-09 7:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon,
On Mon, Sep 9, 2013 at 4:09 PM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Sep 09, 2013 at 08:54:59AM +0200, Linus Walleij wrote:
>> On Mon, Sep 9, 2013 at 2:15 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Fri, Sep 06, 2013 at 06:27:22PM +0200, Linus Walleij wrote:
>>
>> >> Again this looks like it is piling up more legacy clk
>> >> code instead of moving to the new frameworks.
>> >>
>> >> Please include Mike Turquette on future postings of the
>> >> clk code, he's definately our best clock code reviewer.
>> >
>> > 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.
>>
>> That sounds like you're a bit too trigger-happy ;-)
>
> Perhaps.
>
>> > So on those two counts my preference would be for any enhancements
>> > to be done as incremental patches on top of this series.
>>
>> Hm hm. I am worried that it is taken as an OK to proceed
>> extending old cruft for new SoCs rather than moving to new
>> frameworks. I would agree if such migration patches were
>> floating the lists but I am not aware of any patches starting
>> to create drivers/clk/sh*, are you?
>
> I am not aware of such patches.
Several people have spent time on common clocks, the most recent
efforts have been for the EMEV2 SoC. Nothing is upstream yet though,
but if all goes according to our plan then we will start seeing common
clock patches in october-november some time.
> I will defer this to Magnus who is both the author of this series
> and I believe the person who knows the most about the plans for
> drivers/clk/sh*.
I'm actually only the author of some portions of this series, but sure. =)
If there is anything special you'd like to know about common clocks on
mach-shmobile then please let me know.
Cheers,
/ magnus
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
2013-09-06 16:27 ` Linus Walleij
2013-09-09 0:15 ` Simon Horman
@ 2013-09-09 7:24 ` Magnus Damm
1 sibling, 0 replies; 24+ messages in thread
From: Magnus Damm @ 2013-09-09 7:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
On Sat, Sep 7, 2013 at 1:27 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Sep 4, 2013 at 5:46 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>
>> From: Yoshikazu Fujikawa <yoshikazu.fujikawa.ue@renesas.com>
>>
>> Add SCIF serial port support to the r8a7791 SoC by
>> adding platform devices for SCIFA0 -> SCIFA5 as well
>> as SCIFB0 -> SCIFB2 and SCIF0 -> SCIF5 together with
>> clock bindings. DT device description is excluded at
>> this point since such bindings are still under
>> development.
>
> A good way to get started with clock bindings may be to
> move the clocks to drivers/clk because in the neighboring
> drivers over there are many good examples of how to do
> this.
>
> Again this looks like it is piling up more legacy clk
> code instead of moving to the new frameworks.
>
> Please include Mike Turquette on future postings of the
> clk code, he's definately our best clock code reviewer.
Thanks for your recommendation about common clocks, but I believe this
patch really has nothing todo with clocks. It's about SCIF UART
support. The state for SCIF DT support is however similar to common
clocks, so we don't have any DT bindings yet.
Fortunately, SCIF DT support is also planned for the next 6 months, so
over time we can kill off these platform device bits.
Cheers,
/ magnus
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 03/04] ARM: shmobile: r8a7791 CMT support
2013-09-04 3:45 [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support Magnus Damm
2013-09-04 3:45 ` [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support Magnus Damm
2013-09-04 3:46 ` [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support Magnus Damm
@ 2013-09-04 3:46 ` Magnus Damm
2013-09-04 3:46 ` [PATCH 04/04] ARM: shmobile: Koelsch support Magnus Damm
2013-09-04 8:38 ` [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support Simon Horman
4 siblings, 0 replies; 24+ messages in thread
From: Magnus Damm @ 2013-09-04 3:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm@opensource.se>
Add r8a7791 CMT support via channel 0 of CMT0. At this
point the CMT is used for clock event operation, but in
the future the arch timer will be the main timer and the
CMT will be used for deep sleep wake up only.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/clock-r8a7791.c | 7 +++++-
arch/arm/mach-shmobile/include/mach/r8a7791.h | 1
arch/arm/mach-shmobile/setup-r8a7791.c | 29 +++++++++++++++++++++++++
3 files changed, 36 insertions(+), 1 deletion(-)
--- 0004/arch/arm/mach-shmobile/clock-r8a7791.c
+++ work/arch/arm/mach-shmobile/clock-r8a7791.c 2013-09-03 21:02:44.000000000 +0900
@@ -101,7 +101,7 @@ SH_FIXED_RATIO_CLK_SET(cp_clk, extal_c
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(rclk_clk, pll1_clk, 1, (48 * 1024));
SH_FIXED_RATIO_CLK_SET(mp_clk, pll1_div2_clk, 1, 15);
static struct clk *main_clks[] = {
@@ -113,6 +113,7 @@ static struct clk *main_clks[] = {
&pll3_clk,
&hp_clk,
&p_clk,
+ &rclk_clk,
&mp_clk,
&cp_clk,
};
@@ -123,6 +124,7 @@ enum {
MSTP719, MSTP718, MSTP715, MSTP714,
MSTP216, MSTP207, MSTP206,
MSTP204, MSTP203, MSTP202, MSTP1105, MSTP1106, MSTP1107,
+ MSTP124,
MSTP_NR
};
@@ -142,6 +144,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP1105] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 5, 0), /* SCIFA3 */
[MSTP1106] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 6, 0), /* SCIFA4 */
[MSTP1107] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 7, 0), /* SCIFA5 */
+ [MSTP124] = SH_CLK_MSTP32(&rclk_clk, SMSTPCR1, 24, 0), /* CMT0 */
};
static struct clk_lookup lookups[] = {
@@ -155,6 +158,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID("pll3", &pll3_clk),
CLKDEV_CON_ID("hp", &hp_clk),
CLKDEV_CON_ID("p", &p_clk),
+ CLKDEV_CON_ID("rclk", &rclk_clk),
CLKDEV_CON_ID("mp", &mp_clk),
CLKDEV_CON_ID("cp", &cp_clk),
CLKDEV_CON_ID("peripheral_clk", &hp_clk),
@@ -175,6 +179,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh-sci.12", &mstp_clks[MSTP1105]), /* SCIFA3 */
CLKDEV_DEV_ID("sh-sci.13", &mstp_clks[MSTP1106]), /* SCIFA4 */
CLKDEV_DEV_ID("sh-sci.14", &mstp_clks[MSTP1107]), /* SCIFA5 */
+ CLKDEV_DEV_ID("sh_cmt.0", &mstp_clks[MSTP124]),
};
#define R8A7791_CLOCK_ROOT(e, m, p0, p1, p30, p31) \
--- 0004/arch/arm/mach-shmobile/include/mach/r8a7791.h
+++ work/arch/arm/mach-shmobile/include/mach/r8a7791.h 2013-09-03 20:56:52.000000000 +0900
@@ -3,5 +3,6 @@
void r8a7791_add_dt_devices(void);
void r8a7791_clock_init(void);
+void r8a7791_init_early(void);
#endif /* __ASM_R8A7791_H__ */
--- 0004/arch/arm/mach-shmobile/setup-r8a7791.c
+++ work/arch/arm/mach-shmobile/setup-r8a7791.c 2013-09-03 20:57:19.000000000 +0900
@@ -23,6 +23,7 @@
#include <linux/kernel.h>
#include <linux/of_platform.h>
#include <linux/serial_sci.h>
+#include <linux/sh_timer.h>
#include <mach/common.h>
#include <mach/irqs.h>
#include <mach/r8a7791.h>
@@ -89,6 +90,25 @@ static inline void r8a7791_register_scif
sizeof(struct plat_sci_port));
}
+static const struct sh_timer_config cmt00_platform_data __initconst = {
+ .name = "CMT00",
+ .timer_bit = 0,
+ .clockevent_rating = 80,
+};
+
+static const struct resource cmt00_resources[] __initconst = {
+ DEFINE_RES_MEM(0xffca0510, 0x0c),
+ DEFINE_RES_MEM(0xffca0500, 0x04),
+ DEFINE_RES_IRQ(gic_spi(142)), /* CMT0_0 */
+};
+
+#define r8a7791_register_cmt(idx) \
+ platform_device_register_resndata(&platform_bus, "sh_cmt", \
+ idx, cmt##idx##_resources, \
+ ARRAY_SIZE(cmt##idx##_resources), \
+ &cmt##idx##_platform_data, \
+ sizeof(struct sh_timer_config))
+
void __init r8a7791_add_dt_devices(void)
{
r8a7791_register_scif(SCIFA0);
@@ -106,6 +126,14 @@ void __init r8a7791_add_dt_devices(void)
r8a7791_register_scif(SCIFA3);
r8a7791_register_scif(SCIFA4);
r8a7791_register_scif(SCIFA5);
+ r8a7791_register_cmt(00);
+}
+
+void __init r8a7791_init_early(void)
+{
+#ifndef CONFIG_ARM_ARCH_TIMER
+ shmobile_setup_delay(1300, 2, 4); /* Cortex-A15 @ 1300MHz */
+#endif
}
#ifdef CONFIG_USE_OF
@@ -115,6 +143,7 @@ static const char *r8a7791_boards_compat
};
DT_MACHINE_START(R8A7791_DT, "Generic R8A7791 (Flattened Device Tree)")
+ .init_early = r8a7791_init_early,
.dt_compat = r8a7791_boards_compat_dt,
MACHINE_END
#endif /* CONFIG_USE_OF */
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 04/04] ARM: shmobile: Koelsch support
2013-09-04 3:45 [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support Magnus Damm
` (2 preceding siblings ...)
2013-09-04 3:46 ` [PATCH 03/04] ARM: shmobile: r8a7791 CMT support Magnus Damm
@ 2013-09-04 3:46 ` Magnus Damm
2013-09-04 8:38 ` [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support Simon Horman
4 siblings, 0 replies; 24+ messages in thread
From: Magnus Damm @ 2013-09-04 3:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
Koelsch base board support making use of 2 GiB of memory,
the r8a7791 SoC with the SCIF0 serial port and CA15 with
CMT timer.
Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
Signed-off-by: Ryo Kataoka <ryo.kataoka.wt@renesas.com>
[damm at opensource.se: Forward ported to upstream, dropped not-yet-ready SMP/PFC]
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/boot/dts/Makefile | 1
arch/arm/boot/dts/r8a7791-koelsch.dts | 32 +++++++++++++++++++++++
arch/arm/mach-shmobile/Kconfig | 5 +++
arch/arm/mach-shmobile/Makefile | 1
arch/arm/mach-shmobile/Makefile.boot | 1
arch/arm/mach-shmobile/board-koelsch.c | 44 ++++++++++++++++++++++++++++++++
6 files changed, 84 insertions(+)
--- 0001/arch/arm/boot/dts/Makefile
+++ work/arch/arm/boot/dts/Makefile 2013-09-03 21:18:57.000000000 +0900
@@ -190,6 +190,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm
r8a7740-armadillo800eva-reference.dtb \
r8a7779-marzen.dtb \
r8a7779-marzen-reference.dtb \
+ r8a7791-koelsch.dtb \
r8a7790-lager.dtb \
r8a7790-lager-reference.dtb \
sh73a0-kzm9g.dtb \
--- /dev/null
+++ work/arch/arm/boot/dts/r8a7791-koelsch.dts 2013-09-03 21:18:58.000000000 +0900
@@ -0,0 +1,32 @@
+/*
+ * Device Tree Source for the Koelsch board
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "r8a7791.dtsi"
+
+/ {
+ model = "Koelsch";
+ compatible = "renesas,koelsch", "renesas,r8a7791";
+
+ chosen {
+ bootargs = "console=ttySC6,115200 ignore_loglevel rw root=/dev/nfs ip=dhcp";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x80000000>;
+ };
+
+ lbsc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
--- 0003/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig 2013-09-03 21:18:57.000000000 +0900
@@ -219,6 +219,11 @@ config MACH_LAGER_REFERENCE
This is intended to aid developers
+config MACH_KOELSCH
+ bool "Koelsch board"
+ depends on ARCH_R8A7791
+ select USE_OF
+
config MACH_KZM9D
bool "KZM9D board"
depends on ARCH_EMEV2
--- 0003/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile 2013-09-03 21:18:57.000000000 +0900
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_LAGER) += board-lager.
obj-$(CONFIG_MACH_LAGER_REFERENCE) += board-lager-reference.o
obj-$(CONFIG_MACH_ARMADILLO800EVA) += board-armadillo800eva.o
obj-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE) += board-armadillo800eva-reference.o
+obj-$(CONFIG_MACH_KOELSCH) += board-koelsch.o
obj-$(CONFIG_MACH_KZM9D) += board-kzm9d.o
obj-$(CONFIG_MACH_KZM9D_REFERENCE) += board-kzm9d-reference.o
obj-$(CONFIG_MACH_KZM9G) += board-kzm9g.o
--- 0001/arch/arm/mach-shmobile/Makefile.boot
+++ work/arch/arm/mach-shmobile/Makefile.boot 2013-09-03 21:22:48.000000000 +0900
@@ -6,6 +6,7 @@ loadaddr-$(CONFIG_MACH_ARMADILLO800EVA)
loadaddr-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE) += 0x40008000
loadaddr-$(CONFIG_MACH_BOCKW) += 0x60008000
loadaddr-$(CONFIG_MACH_BOCKW_REFERENCE) += 0x60008000
+loadaddr-$(CONFIG_MACH_KOELSCH) += 0x40008000
loadaddr-$(CONFIG_MACH_KZM9D) += 0x40008000
loadaddr-$(CONFIG_MACH_KZM9D_REFERENCE) += 0x40008000
loadaddr-$(CONFIG_MACH_KZM9G) += 0x41008000
--- /dev/null
+++ work/arch/arm/mach-shmobile/board-koelsch.c 2013-09-03 21:18:58.000000000 +0900
@@ -0,0 +1,44 @@
+/*
+ * Koelsch board 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/kernel.h>
+#include <linux/platform_device.h>
+#include <mach/common.h>
+#include <mach/r8a7791.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static void __init koelsch_add_standard_devices(void)
+{
+ r8a7791_clock_init();
+ r8a7791_add_dt_devices();
+}
+
+static const char * const koelsch_boards_compat_dt[] __initconst = {
+ "renesas,koelsch",
+ NULL,
+};
+
+DT_MACHINE_START(KOELSCH_DT, "koelsch")
+ .init_early = r8a7791_init_early,
+ .init_machine = koelsch_add_standard_devices,
+ .dt_compat = koelsch_boards_compat_dt,
+MACHINE_END
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support
2013-09-04 3:45 [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support Magnus Damm
` (3 preceding siblings ...)
2013-09-04 3:46 ` [PATCH 04/04] ARM: shmobile: Koelsch support Magnus Damm
@ 2013-09-04 8:38 ` Simon Horman
2013-09-06 7:09 ` Simon Horman
4 siblings, 1 reply; 24+ messages in thread
From: Simon Horman @ 2013-09-04 8:38 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Sep 04, 2013 at 12:45:25PM +0900, Magnus Damm wrote:
> ARM: shmobile: Initial r8a7791 SoC and Koelsch board supp
>
> [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
> [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
> [PATCH 03/04] ARM: shmobile: r8a7791 CMT support
> [PATCH 04/04] ARM: shmobile: Koelsch support
>
> This series adds initial support for r8a7791 and Koelsch. The SoC
> is known as r8a7791 which is based on a single cluster Cortex-A15
> and makes use of SCIF for serial and CMT for timer. Many other
> on-chip I/O devices are available, and support for those will be
> added by incremental feature patches.
>
> This initial SoC and board support is providing limited DT-only
> support and a very basic C-version of board support. In the future
> improved PINCTRL and clock framework support will be added together
> with arch timer and SMP support.
>
> Implemented in same style as r8a7790 SoC V1.
>
> Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
> Signed-off-by: Yoshikazu Fujikawa <yoshikazu.fujikawa.ue@renesas.com>
> Signed-off-by: Ryo Kataoka <ryo.kataoka.wt@renesas.com>
> [damm at opensource.se: forward porting, cleanups, commit logs, CMT support]
> Signed-off-by: Magnus Damm <damm@opensource.se>
I have lightly tested these and they seem good to me.
I have posted a defconfig patch as a follow-up.
I would to let these sit for a little bit to give them time to
be reviewed by others.
Tested-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>
> Written against renesas.git tag renesas-devel-20130822
>
> arch/arm/boot/dts/Makefile | 1
> arch/arm/boot/dts/r8a7791-koelsch.dts | 32 +++
> arch/arm/boot/dts/r8a7791.dtsi | 41 ++++
> arch/arm/mach-shmobile/Kconfig | 11 +
> arch/arm/mach-shmobile/Makefile | 3
> arch/arm/mach-shmobile/Makefile.boot | 1
> arch/arm/mach-shmobile/board-koelsch.c | 44 ++++
> arch/arm/mach-shmobile/clock-r8a7791.c | 241 ++++++++++++++++++++++++-
> arch/arm/mach-shmobile/include/mach/r8a7791.h | 8
> arch/arm/mach-shmobile/setup-r8a7791.c | 149 +++++++++++++++
> 10 files changed, 529 insertions(+), 2 deletions(-)
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support
2013-09-04 8:38 ` [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support Simon Horman
@ 2013-09-06 7:09 ` Simon Horman
2013-09-09 7:39 ` Magnus Damm
0 siblings, 1 reply; 24+ messages in thread
From: Simon Horman @ 2013-09-06 7:09 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Sep 04, 2013 at 05:38:35PM +0900, Simon Horman wrote:
> On Wed, Sep 04, 2013 at 12:45:25PM +0900, Magnus Damm wrote:
> > ARM: shmobile: Initial r8a7791 SoC and Koelsch board supp
> >
> > [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
> > [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
> > [PATCH 03/04] ARM: shmobile: r8a7791 CMT support
> > [PATCH 04/04] ARM: shmobile: Koelsch support
> >
> > This series adds initial support for r8a7791 and Koelsch. The SoC
> > is known as r8a7791 which is based on a single cluster Cortex-A15
> > and makes use of SCIF for serial and CMT for timer. Many other
> > on-chip I/O devices are available, and support for those will be
> > added by incremental feature patches.
> >
> > This initial SoC and board support is providing limited DT-only
> > support and a very basic C-version of board support. In the future
> > improved PINCTRL and clock framework support will be added together
> > with arch timer and SMP support.
> >
> > Implemented in same style as r8a7790 SoC V1.
> >
> > Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
> > Signed-off-by: Yoshikazu Fujikawa <yoshikazu.fujikawa.ue@renesas.com>
> > Signed-off-by: Ryo Kataoka <ryo.kataoka.wt@renesas.com>
> > [damm at opensource.se: forward porting, cleanups, commit logs, CMT support]
> > Signed-off-by: Magnus Damm <damm@opensource.se>
>
> I have lightly tested these and they seem good to me.
> I have posted a defconfig patch as a follow-up.
> I would to let these sit for a little bit to give them time to
> be reviewed by others.
>
> Tested-by: Simon Horman <horms+renesas@verge.net.au>
I have queued these up for v3.13.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 00/04] ARM: shmobile: Initial r8a7791 SoC and Koelsch board support
2013-09-06 7:09 ` Simon Horman
@ 2013-09-09 7:39 ` Magnus Damm
0 siblings, 0 replies; 24+ messages in thread
From: Magnus Damm @ 2013-09-09 7:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon,
On Fri, Sep 6, 2013 at 4:09 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Sep 04, 2013 at 05:38:35PM +0900, Simon Horman wrote:
>> On Wed, Sep 04, 2013 at 12:45:25PM +0900, Magnus Damm wrote:
>> > ARM: shmobile: Initial r8a7791 SoC and Koelsch board supp
>> >
>> > [PATCH 01/04] ARM: shmobile: Initial r8a7791 SoC support
>> > [PATCH 02/04] ARM: shmobile: r8a7791 SCIF support
>> > [PATCH 03/04] ARM: shmobile: r8a7791 CMT support
>> > [PATCH 04/04] ARM: shmobile: Koelsch support
>> >
>> > This series adds initial support for r8a7791 and Koelsch. The SoC
>> > is known as r8a7791 which is based on a single cluster Cortex-A15
>> > and makes use of SCIF for serial and CMT for timer. Many other
>> > on-chip I/O devices are available, and support for those will be
>> > added by incremental feature patches.
>> >
>> > This initial SoC and board support is providing limited DT-only
>> > support and a very basic C-version of board support. In the future
>> > improved PINCTRL and clock framework support will be added together
>> > with arch timer and SMP support.
>> >
>> > Implemented in same style as r8a7790 SoC V1.
>> >
>> > Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
>> > Signed-off-by: Yoshikazu Fujikawa <yoshikazu.fujikawa.ue@renesas.com>
>> > Signed-off-by: Ryo Kataoka <ryo.kataoka.wt@renesas.com>
>> > [damm at opensource.se: forward porting, cleanups, commit logs, CMT support]
>> > Signed-off-by: Magnus Damm <damm@opensource.se>
>>
>> I have lightly tested these and they seem good to me.
>> I have posted a defconfig patch as a follow-up.
>> I would to let these sit for a little bit to give them time to
>> be reviewed by others.
>>
>> Tested-by: Simon Horman <horms+renesas@verge.net.au>
>
> I have queued these up for v3.13.
Thanks. I intend to send incremental patches on top of this series.
Cheers,
/ magnus
^ permalink raw reply [flat|nested] 24+ messages in thread