diff mbox

[02/04] ARM: shmobile: r8a7791 SCIF support

Message ID 20130904034608.12546.79411.sendpatchset@w520 (mailing list archive)
State New, archived
Headers show

Commit Message

Magnus Damm Sept. 4, 2013, 3:46 a.m. UTC 
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@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(-)

Comments

Linus Walleij Sept. 6, 2013, 4:27 p.m. UTC | #1 
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
Simon Horman Sept. 9, 2013, 12:15 a.m. UTC | #2 
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.
Linus Walleij Sept. 9, 2013, 6:54 a.m. UTC | #3 
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
Simon Horman Sept. 9, 2013, 7:09 a.m. UTC | #4 
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*.
Magnus Damm Sept. 9, 2013, 7:24 a.m. UTC | #5 
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
Magnus Damm Sept. 9, 2013, 7:28 a.m. UTC | #6 
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
diff mbox

Patch

--- 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",