[PATCH v3 2/3] ARM: mach-shmobile: r8a7740: Add DT names to clock list

[PATCH v3 2/3] ARM: mach-shmobile: r8a7740: Add DT names to clock list

[Bastian Hecht]

This adds temporarily the alternative device names to the clock list
that are used when booting via Device Tree setup.

Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
---
v3:
no changes

 arch/arm/mach-shmobile/clock-r8a7740.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 71fc400..0f77823 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -593,18 +593,27 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_ceu.1",	&mstp_clks[MSTP128]),
 
 	CLKDEV_DEV_ID("sh-sci.4",		&mstp_clks[MSTP200]),
+	CLKDEV_DEV_ID("e6c80000.sci",		&mstp_clks[MSTP200]),
 	CLKDEV_DEV_ID("sh-sci.3",		&mstp_clks[MSTP201]),
+	CLKDEV_DEV_ID("e6c70000.sci",		&mstp_clks[MSTP201]),
 	CLKDEV_DEV_ID("sh-sci.2",		&mstp_clks[MSTP202]),
+	CLKDEV_DEV_ID("e6c60000.sci",		&mstp_clks[MSTP202]),
 	CLKDEV_DEV_ID("sh-sci.1",		&mstp_clks[MSTP203]),
+	CLKDEV_DEV_ID("e6c50000.sci",		&mstp_clks[MSTP203]),
 	CLKDEV_DEV_ID("sh-sci.0",		&mstp_clks[MSTP204]),
+	CLKDEV_DEV_ID("e6c40000.sci",		&mstp_clks[MSTP204]),
 	CLKDEV_DEV_ID("sh-sci.8",		&mstp_clks[MSTP206]),
+	CLKDEV_DEV_ID("e6c30000.sci",		&mstp_clks[MSTP206]),
 	CLKDEV_DEV_ID("sh-sci.5",		&mstp_clks[MSTP207]),
+	CLKDEV_DEV_ID("e6cb0000.sci",		&mstp_clks[MSTP207]),
 	CLKDEV_DEV_ID("sh-dma-engine.3",	&mstp_clks[MSTP214]),
 	CLKDEV_DEV_ID("sh-dma-engine.2",	&mstp_clks[MSTP216]),
 	CLKDEV_DEV_ID("sh-dma-engine.1",	&mstp_clks[MSTP217]),
 	CLKDEV_DEV_ID("sh-dma-engine.0",	&mstp_clks[MSTP218]),
 	CLKDEV_DEV_ID("sh-sci.7",		&mstp_clks[MSTP222]),
+	CLKDEV_DEV_ID("e6cd0000.sci",		&mstp_clks[MSTP222]),
 	CLKDEV_DEV_ID("sh-sci.6",		&mstp_clks[MSTP230]),
+	CLKDEV_DEV_ID("e6cc0000.sci",		&mstp_clks[MSTP230]),
 
 	CLKDEV_DEV_ID("sh_cmt.10",		&mstp_clks[MSTP329]),
 	CLKDEV_DEV_ID("sh_fsi2",		&mstp_clks[MSTP328]),
-- 
1.7.9.5

[PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Bastian Hecht]

We can now use the Device Tree for bringing up our serial devices. We
need to add an alternative early_devices list in setup-r8a7740 without
the serial devices and move them into the Armadillo-reference .dts config file.

Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
---
v3:
no changes

 .../boot/dts/r8a7740-armadillo800eva-reference.dts |   94 ++++++++++++++++++++
 arch/arm/mach-shmobile/setup-r8a7740.c             |   15 +++-
 2 files changed, 105 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 1e339cd..52645b6 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -134,6 +134,100 @@
 		renesas,pins = "eth_base";
 		renesas,function = "eth";
 	};
+
+	sci@0xe6c40000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c40000 0x100>;
+		interrupts = <0x0c00>, <0x0c00>, <0x0c00>, <0x0c00>;
+		cell-index = <0>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c50000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c50000 0x100>;
+		interrupts = <0x0c20>, <0x0c20>, <0x0c20>, <0x0c20>;
+		cell-index = <1>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c60000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c60000 0x100>;
+		interrupts = <0x0c40>, <0x0c40>, <0x0c40>, <0x0c40>;
+		cell-index = <2>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c70000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c70000 0x100>;
+		interrupts = <0x0c60>, <0x0c60>, <0x0c60>, <0x0c60>;
+		cell-index = <3>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6c80000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c80000 0x100>;
+		interrupts = <0x0d20>, <0x0d20>, <0x0d20>, <0x0d20>;
+		cell-index = <4>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cb0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cb0000 0x100>;
+		interrupts = <0x0d40>, <0x0d40>, <0x0d40>, <0x0d40>;
+		cell-index = <5>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cc0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cc0000 0x100>;
+		interrupts = <0x04c0>, <0x04c0>, <0x04c0>, <0x04c0>;
+		cell-index = <6>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cd0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cd0000 0x100>;
+		interrupts = <0x04e0>, <0x04e0>, <0x04e0>, <0x04e0>;
+		cell-index = <7>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6c30000 {
+		compatible = "renesas,sci-SCIFB-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c30000 0x100>;
+		interrupts = <0x0d60>, <0x0d60>, <0x0d60>, <0x0d60>;
+		cell-index = <8>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
 };
 
 &gpio {
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 5312aad..5f7597a 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -394,6 +394,13 @@ static struct platform_device *r8a7740_early_devices[] __initdata = {
 	&tmu02_device,
 };
 
+static struct platform_device *r8a7740_early_devices_dt[] __initdata = {
+	&cmt10_device,
+	&tmu00_device,
+	&tmu01_device,
+	&tmu02_device,
+};
+
 /* DMA */
 static const struct sh_dmae_slave_config r8a7740_dmae_slaves[] = {
 	{
@@ -839,8 +846,8 @@ void __init r8a7740_add_early_devices_dt(void)
 {
 	shmobile_setup_delay(800, 1, 3); /* Cortex-A9 @ 800MHz */
 
-	early_platform_add_devices(r8a7740_early_devices,
-				   ARRAY_SIZE(r8a7740_early_devices));
+	early_platform_add_devices(r8a7740_early_devices_dt,
+				   ARRAY_SIZE(r8a7740_early_devices_dt));
 
 	/* setup early console here as well */
 	shmobile_setup_console();
@@ -852,8 +859,8 @@ static const struct of_dev_auxdata r8a7740_auxdata_lookup[] __initconst = {
 
 void __init r8a7740_add_standard_devices_dt(void)
 {
-	platform_add_devices(r8a7740_early_devices,
-			    ARRAY_SIZE(r8a7740_early_devices));
+	platform_add_devices(r8a7740_early_devices_dt,
+			    ARRAY_SIZE(r8a7740_early_devices_dt));
 
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     r8a7740_auxdata_lookup, NULL);
-- 
1.7.9.5

[PATCH v3 1/3] serial: sh-sci: Add OF support

[Bastian Hecht]

We add the capabilty to probe Renesas SCI devices using Device Tree setup.

Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
---
v3:
- add remaining register layouts to bindings
- remove register set mapping sci_regtype_modes[]
- adapt renesas,regtype probing

- add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
- check renesas,scbrr-algo-id boundaries using new enums

 .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
 drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
 include/linux/serial_sci.h                         |    4 +
 3 files changed, 179 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt

diff --git a/Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
new file mode 100644
index 0000000..6ad1adf
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
@@ -0,0 +1,53 @@
+* Renesas SH-Mobile Serial Communication Interface
+
+Required properties:
+- compatible : Should be "renesas,sci-<port type>-uart", where <port type> may be
+  SCI, SCIF, IRDA, SCIFA or SCIFB.
+- reg : Address and length of the register set for the device
+- interrupts : Should contain the following IRQs: ERI, RXI, TXI and BRI.
+- cell-index : The device id.
+- renesas,scscr : Should contain a bitfield used by the Serial Control Register.
+  b7 = SCSCR_TIE
+  b6 = SCSCR_RIE
+  b5 = SCSCR_TE
+  b4 = SCSCR_RE
+  b3 = SCSCR_REIE
+  b2 = SCSCR_TOIE
+  b1 = SCSCR_CKE1
+  b0 = SCSCR_CKE0
+- renesas,scbrr-algo-id : Algorithm ID for the Bit Rate Register
+  1 = SCBRR_ALGO_1 ((clk + 16 * bps) / (16 * bps) - 1)
+  2 = SCBRR_ALGO_2 ((clk + 16 * bps) / (32 * bps) - 1)
+  3 = SCBRR_ALGO_3 (((clk * 2) + 16 * bps) / (16 * bps) - 1)
+  4 = SCBRR_ALGO_4 (((clk * 2) + 16 * bps) / (32 * bps) - 1)
+  5 = SCBRR_ALGO_5 (((clk * 1000 / 32) / bps) - 1)
+
+Optional properties:
+- renesas,autoconf : Set if device is capable of auto configuration
+- renesas,regtype : Overwrite the register layout. In most cases you can rely
+  on auto-probing (omit this property or set to 0) but some legacy devices
+  use a non-default register layout. Possible layouts are
+  0 = SCIx_PROBE_REGTYPE (default)
+  1 = SCIx_SCI_REGTYPE
+  2 = SCIx_IRDA_REGTYPE
+  3 = SCIx_SCIFA_REGTYPE
+  4 = SCIx_SCIFB_REGTYPE
+  5 = SCIx_SH2_SCIF_FIFODATA_REGTYPE
+  6 = SCIx_SH3_SCIF_REGTYPE
+  7 = SCIx_SH4_SCIF_REGTYPE
+  8 = SCIx_SH4_SCIF_NO_SCSPTR_REGTYPE
+  9 = SCIx_SH4_SCIF_FIFODATA_REGTYPE
+ 10 = SCIx_SH7705_SCIF_REGTYPE
+
+
+Example:
+	sci@0xe6c50000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c50000 0x100>;
+		interrupts = <0x0c20>, <0x0c20>, <0x0c20>, <0x0c20>;
+		cell-index = <1>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 6147756..1976ef9 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2353,6 +2353,112 @@ static int sci_remove(struct platform_device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id of_sci_match[] = {
+	{ .compatible = "renesas,sci-SCI-uart",
+		.data = (void *)PORT_SCI },
+	{ .compatible = "renesas,sci-SCIF-uart",
+		.data = (void *)PORT_SCIF },
+	{ .compatible = "renesas,sci-IRDA-uart",
+		.data = (void *)PORT_IRDA },
+	{ .compatible = "renesas,sci-SCIFA-uart",
+		.data = (void *)PORT_SCIFA },
+	{ .compatible = "renesas,sci-SCIFB-uart",
+		.data = (void *)PORT_SCIFB },
+	{},
+};
+MODULE_DEVICE_TABLE(of, of_sci_match);
+
+static struct plat_sci_port *sci_parse_dt(struct platform_device *pdev,
+								int *dev_id)
+{
+	struct plat_sci_port *p;
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match;
+	struct resource *res;
+	const __be32 *prop;
+	int i, irq, val;
+
+	match = of_match_node(of_sci_match, pdev->dev.of_node);
+	if (!match || !match->data) {
+		dev_err(&pdev->dev, "OF match error\n");
+		return NULL;
+	}
+
+	p = devm_kzalloc(&pdev->dev, sizeof(struct plat_sci_port), GFP_KERNEL);
+	if (!p) {
+		dev_err(&pdev->dev, "failed to allocate DT config data\n");
+		return NULL;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "failed to get I/O memory\n");
+		return NULL;
+	}
+	p->mapbase = res->start;
+
+	for (i = 0; i < SCIx_NR_IRQS; i++) {
+		irq = platform_get_irq(pdev, i);
+		if (irq < 0) {
+			dev_err(&pdev->dev, "failed to get irq data %d\n", i);
+			return NULL;
+		}
+		p->irqs[i] = irq;
+	}
+
+	prop = of_get_property(np, "cell-index", NULL);
+	if (!prop) {
+		dev_err(&pdev->dev, "required DT prop cell-index missing\n");
+		return NULL;
+	}
+	*dev_id = be32_to_cpup(prop);
+
+	prop = of_get_property(np, "renesas,scscr", NULL);
+	if (!prop) {
+		dev_err(&pdev->dev, "required DT prop scscr missing\n");
+		return NULL;
+	}
+	p->scscr = be32_to_cpup(prop);
+
+	prop = of_get_property(np, "renesas,scbrr-algo-id", NULL);
+	if (!prop) {
+		dev_err(&pdev->dev, "required DT prop scbrr-algo-id missing\n");
+		return NULL;
+	}
+	val = be32_to_cpup(prop);
+	if (val <= SCBRR_ALGO_INVALID || val >= SCBRR_NR_ALGOS) {
+		dev_err(&pdev->dev, "DT prop scbrr-algo-id out of range\n");
+		return NULL;
+	}
+	p->scbrr_algo_id = val;
+
+	p->flags = UPF_IOREMAP;
+	if (of_get_property(np, "renesas,autoconf", NULL))
+		p->flags |= UPF_BOOT_AUTOCONF;
+
+	prop = of_get_property(np, "renesas,regtype", NULL);
+	if (prop) {
+		val = be32_to_cpup(prop);
+		if (val < SCIx_PROBE_REGTYPE || val >= SCIx_NR_REGTYPES) {
+			dev_err(&pdev->dev, "DT prop regtype out of range\n");
+			return NULL;
+		}
+		p->regtype = val;
+	}
+
+	p->type = (unsigned int)match->data;
+
+	return p;
+}
+#else
+static struct plat_sci_port *sci_parse_dt(struct platform_device *pdev,
+								int *dev_id)
+{
+	return NULL;
+}
+#endif /* CONFIG_OF */
+
 static int sci_probe_single(struct platform_device *dev,
 				      unsigned int index,
 				      struct plat_sci_port *p,
@@ -2385,9 +2491,9 @@ static int sci_probe_single(struct platform_device *dev,
 
 static int sci_probe(struct platform_device *dev)
 {
-	struct plat_sci_port *p = dev->dev.platform_data;
-	struct sci_port *sp = &sci_ports[dev->id];
-	int ret;
+	struct plat_sci_port *p;
+	struct sci_port *sp;
+	int ret, dev_id = dev->id;
 
 	/*
 	 * If we've come here via earlyprintk initialization, head off to
@@ -2397,9 +2503,20 @@ static int sci_probe(struct platform_device *dev)
 	if (is_early_platform_device(dev))
 		return sci_probe_earlyprintk(dev);
 
+	if (dev->dev.of_node)
+		p = sci_parse_dt(dev, &dev_id);
+	else
+		p = dev->dev.platform_data;
+
+	if (!p) {
+		dev_err(&dev->dev, "no setup data supplied\n");
+		return -EINVAL;
+	}
+
+	sp = &sci_ports[dev_id];
 	platform_set_drvdata(dev, sp);
 
-	ret = sci_probe_single(dev, dev->id, p, sp);
+	ret = sci_probe_single(dev, dev_id, p, sp);
 	if (ret)
 		return ret;
 
@@ -2451,6 +2568,7 @@ static struct platform_driver sci_driver = {
 		.name	= "sh-sci",
 		.owner	= THIS_MODULE,
 		.pm	= &sci_dev_pm_ops,
+		.of_match_table = of_match_ptr(of_sci_match),
 	},
 };
 
diff --git a/include/linux/serial_sci.h b/include/linux/serial_sci.h
index eb763ad..857eec4 100644
--- a/include/linux/serial_sci.h
+++ b/include/linux/serial_sci.h
@@ -11,11 +11,15 @@
 #define SCIx_NOT_SUPPORTED	(-1)
 
 enum {
+	SCBRR_ALGO_INVALID,
+
 	SCBRR_ALGO_1,		/* ((clk + 16 * bps) / (16 * bps) - 1) */
 	SCBRR_ALGO_2,		/* ((clk + 16 * bps) / (32 * bps) - 1) */
 	SCBRR_ALGO_3,		/* (((clk * 2) + 16 * bps) / (16 * bps) - 1) */
 	SCBRR_ALGO_4,		/* (((clk * 2) + 16 * bps) / (32 * bps) - 1) */
 	SCBRR_ALGO_5,		/* (((clk * 1000 / 32) / bps) - 1) */
+
+	SCBRR_NR_ALGOS,
 };
 
 #define SCSCR_TIE	(1 << 7)
-- 
1.7.9.5

[PATCH v3 1/3] serial: sh-sci: Add OF support

[Bastian Hecht]

We add the capabilty to probe Renesas SCI devices using Device Tree setup.

Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
---
v3:
- add remaining register layouts to bindings
- remove register set mapping sci_regtype_modes[]
- adapt renesas,regtype probing

- add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
- check renesas,scbrr-algo-id boundaries using new enums

 .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
 drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
 include/linux/serial_sci.h                         |    4 +
 3 files changed, 179 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt

diff --git a/Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
new file mode 100644
index 0000000..6ad1adf
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
@@ -0,0 +1,53 @@
+* Renesas SH-Mobile Serial Communication Interface
+
+Required properties:
+- compatible : Should be "renesas,sci-<port type>-uart", where <port type> may be
+  SCI, SCIF, IRDA, SCIFA or SCIFB.
+- reg : Address and length of the register set for the device
+- interrupts : Should contain the following IRQs: ERI, RXI, TXI and BRI.
+- cell-index : The device id.
+- renesas,scscr : Should contain a bitfield used by the Serial Control Register.
+  b7 = SCSCR_TIE
+  b6 = SCSCR_RIE
+  b5 = SCSCR_TE
+  b4 = SCSCR_RE
+  b3 = SCSCR_REIE
+  b2 = SCSCR_TOIE
+  b1 = SCSCR_CKE1
+  b0 = SCSCR_CKE0
+- renesas,scbrr-algo-id : Algorithm ID for the Bit Rate Register
+  1 = SCBRR_ALGO_1 ((clk + 16 * bps) / (16 * bps) - 1)
+  2 = SCBRR_ALGO_2 ((clk + 16 * bps) / (32 * bps) - 1)
+  3 = SCBRR_ALGO_3 (((clk * 2) + 16 * bps) / (16 * bps) - 1)
+  4 = SCBRR_ALGO_4 (((clk * 2) + 16 * bps) / (32 * bps) - 1)
+  5 = SCBRR_ALGO_5 (((clk * 1000 / 32) / bps) - 1)
+
+Optional properties:
+- renesas,autoconf : Set if device is capable of auto configuration
+- renesas,regtype : Overwrite the register layout. In most cases you can rely
+  on auto-probing (omit this property or set to 0) but some legacy devices
+  use a non-default register layout. Possible layouts are
+  0 = SCIx_PROBE_REGTYPE (default)
+  1 = SCIx_SCI_REGTYPE
+  2 = SCIx_IRDA_REGTYPE
+  3 = SCIx_SCIFA_REGTYPE
+  4 = SCIx_SCIFB_REGTYPE
+  5 = SCIx_SH2_SCIF_FIFODATA_REGTYPE
+  6 = SCIx_SH3_SCIF_REGTYPE
+  7 = SCIx_SH4_SCIF_REGTYPE
+  8 = SCIx_SH4_SCIF_NO_SCSPTR_REGTYPE
+  9 = SCIx_SH4_SCIF_FIFODATA_REGTYPE
+ 10 = SCIx_SH7705_SCIF_REGTYPE
+
+
+Example:
+	sci@0xe6c50000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c50000 0x100>;
+		interrupts = <0x0c20>, <0x0c20>, <0x0c20>, <0x0c20>;
+		cell-index = <1>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 6147756..1976ef9 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2353,6 +2353,112 @@ static int sci_remove(struct platform_device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id of_sci_match[] = {
+	{ .compatible = "renesas,sci-SCI-uart",
+		.data = (void *)PORT_SCI },
+	{ .compatible = "renesas,sci-SCIF-uart",
+		.data = (void *)PORT_SCIF },
+	{ .compatible = "renesas,sci-IRDA-uart",
+		.data = (void *)PORT_IRDA },
+	{ .compatible = "renesas,sci-SCIFA-uart",
+		.data = (void *)PORT_SCIFA },
+	{ .compatible = "renesas,sci-SCIFB-uart",
+		.data = (void *)PORT_SCIFB },
+	{},
+};
+MODULE_DEVICE_TABLE(of, of_sci_match);
+
+static struct plat_sci_port *sci_parse_dt(struct platform_device *pdev,
+								int *dev_id)
+{
+	struct plat_sci_port *p;
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match;
+	struct resource *res;
+	const __be32 *prop;
+	int i, irq, val;
+
+	match = of_match_node(of_sci_match, pdev->dev.of_node);
+	if (!match || !match->data) {
+		dev_err(&pdev->dev, "OF match error\n");
+		return NULL;
+	}
+
+	p = devm_kzalloc(&pdev->dev, sizeof(struct plat_sci_port), GFP_KERNEL);
+	if (!p) {
+		dev_err(&pdev->dev, "failed to allocate DT config data\n");
+		return NULL;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "failed to get I/O memory\n");
+		return NULL;
+	}
+	p->mapbase = res->start;
+
+	for (i = 0; i < SCIx_NR_IRQS; i++) {
+		irq = platform_get_irq(pdev, i);
+		if (irq < 0) {
+			dev_err(&pdev->dev, "failed to get irq data %d\n", i);
+			return NULL;
+		}
+		p->irqs[i] = irq;
+	}
+
+	prop = of_get_property(np, "cell-index", NULL);
+	if (!prop) {
+		dev_err(&pdev->dev, "required DT prop cell-index missing\n");
+		return NULL;
+	}
+	*dev_id = be32_to_cpup(prop);
+
+	prop = of_get_property(np, "renesas,scscr", NULL);
+	if (!prop) {
+		dev_err(&pdev->dev, "required DT prop scscr missing\n");
+		return NULL;
+	}
+	p->scscr = be32_to_cpup(prop);
+
+	prop = of_get_property(np, "renesas,scbrr-algo-id", NULL);
+	if (!prop) {
+		dev_err(&pdev->dev, "required DT prop scbrr-algo-id missing\n");
+		return NULL;
+	}
+	val = be32_to_cpup(prop);
+	if (val <= SCBRR_ALGO_INVALID || val >= SCBRR_NR_ALGOS) {
+		dev_err(&pdev->dev, "DT prop scbrr-algo-id out of range\n");
+		return NULL;
+	}
+	p->scbrr_algo_id = val;
+
+	p->flags = UPF_IOREMAP;
+	if (of_get_property(np, "renesas,autoconf", NULL))
+		p->flags |= UPF_BOOT_AUTOCONF;
+
+	prop = of_get_property(np, "renesas,regtype", NULL);
+	if (prop) {
+		val = be32_to_cpup(prop);
+		if (val < SCIx_PROBE_REGTYPE || val >= SCIx_NR_REGTYPES) {
+			dev_err(&pdev->dev, "DT prop regtype out of range\n");
+			return NULL;
+		}
+		p->regtype = val;
+	}
+
+	p->type = (unsigned int)match->data;
+
+	return p;
+}
+#else
+static struct plat_sci_port *sci_parse_dt(struct platform_device *pdev,
+								int *dev_id)
+{
+	return NULL;
+}
+#endif /* CONFIG_OF */
+
 static int sci_probe_single(struct platform_device *dev,
 				      unsigned int index,
 				      struct plat_sci_port *p,
@@ -2385,9 +2491,9 @@ static int sci_probe_single(struct platform_device *dev,
 
 static int sci_probe(struct platform_device *dev)
 {
-	struct plat_sci_port *p = dev->dev.platform_data;
-	struct sci_port *sp = &sci_ports[dev->id];
-	int ret;
+	struct plat_sci_port *p;
+	struct sci_port *sp;
+	int ret, dev_id = dev->id;
 
 	/*
 	 * If we've come here via earlyprintk initialization, head off to
@@ -2397,9 +2503,20 @@ static int sci_probe(struct platform_device *dev)
 	if (is_early_platform_device(dev))
 		return sci_probe_earlyprintk(dev);
 
+	if (dev->dev.of_node)
+		p = sci_parse_dt(dev, &dev_id);
+	else
+		p = dev->dev.platform_data;
+
+	if (!p) {
+		dev_err(&dev->dev, "no setup data supplied\n");
+		return -EINVAL;
+	}
+
+	sp = &sci_ports[dev_id];
 	platform_set_drvdata(dev, sp);
 
-	ret = sci_probe_single(dev, dev->id, p, sp);
+	ret = sci_probe_single(dev, dev_id, p, sp);
 	if (ret)
 		return ret;
 
@@ -2451,6 +2568,7 @@ static struct platform_driver sci_driver = {
 		.name	= "sh-sci",
 		.owner	= THIS_MODULE,
 		.pm	= &sci_dev_pm_ops,
+		.of_match_table = of_match_ptr(of_sci_match),
 	},
 };
 
diff --git a/include/linux/serial_sci.h b/include/linux/serial_sci.h
index eb763ad..857eec4 100644
--- a/include/linux/serial_sci.h
+++ b/include/linux/serial_sci.h
@@ -11,11 +11,15 @@
 #define SCIx_NOT_SUPPORTED	(-1)
 
 enum {
+	SCBRR_ALGO_INVALID,
+
 	SCBRR_ALGO_1,		/* ((clk + 16 * bps) / (16 * bps) - 1) */
 	SCBRR_ALGO_2,		/* ((clk + 16 * bps) / (32 * bps) - 1) */
 	SCBRR_ALGO_3,		/* (((clk * 2) + 16 * bps) / (16 * bps) - 1) */
 	SCBRR_ALGO_4,		/* (((clk * 2) + 16 * bps) / (32 * bps) - 1) */
 	SCBRR_ALGO_5,		/* (((clk * 1000 / 32) / bps) - 1) */
+
+	SCBRR_NR_ALGOS,
 };
 
 #define SCSCR_TIE	(1 << 7)
-- 
1.7.9.5

[PATCH v3 2/3] ARM: mach-shmobile: r8a7740: Add DT names to clock list

[Bastian Hecht]

This adds temporarily the alternative device names to the clock list
that are used when booting via Device Tree setup.

Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
---
v3:
no changes

 arch/arm/mach-shmobile/clock-r8a7740.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 71fc400..0f77823 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -593,18 +593,27 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_ceu.1",	&mstp_clks[MSTP128]),
 
 	CLKDEV_DEV_ID("sh-sci.4",		&mstp_clks[MSTP200]),
+	CLKDEV_DEV_ID("e6c80000.sci",		&mstp_clks[MSTP200]),
 	CLKDEV_DEV_ID("sh-sci.3",		&mstp_clks[MSTP201]),
+	CLKDEV_DEV_ID("e6c70000.sci",		&mstp_clks[MSTP201]),
 	CLKDEV_DEV_ID("sh-sci.2",		&mstp_clks[MSTP202]),
+	CLKDEV_DEV_ID("e6c60000.sci",		&mstp_clks[MSTP202]),
 	CLKDEV_DEV_ID("sh-sci.1",		&mstp_clks[MSTP203]),
+	CLKDEV_DEV_ID("e6c50000.sci",		&mstp_clks[MSTP203]),
 	CLKDEV_DEV_ID("sh-sci.0",		&mstp_clks[MSTP204]),
+	CLKDEV_DEV_ID("e6c40000.sci",		&mstp_clks[MSTP204]),
 	CLKDEV_DEV_ID("sh-sci.8",		&mstp_clks[MSTP206]),
+	CLKDEV_DEV_ID("e6c30000.sci",		&mstp_clks[MSTP206]),
 	CLKDEV_DEV_ID("sh-sci.5",		&mstp_clks[MSTP207]),
+	CLKDEV_DEV_ID("e6cb0000.sci",		&mstp_clks[MSTP207]),
 	CLKDEV_DEV_ID("sh-dma-engine.3",	&mstp_clks[MSTP214]),
 	CLKDEV_DEV_ID("sh-dma-engine.2",	&mstp_clks[MSTP216]),
 	CLKDEV_DEV_ID("sh-dma-engine.1",	&mstp_clks[MSTP217]),
 	CLKDEV_DEV_ID("sh-dma-engine.0",	&mstp_clks[MSTP218]),
 	CLKDEV_DEV_ID("sh-sci.7",		&mstp_clks[MSTP222]),
+	CLKDEV_DEV_ID("e6cd0000.sci",		&mstp_clks[MSTP222]),
 	CLKDEV_DEV_ID("sh-sci.6",		&mstp_clks[MSTP230]),
+	CLKDEV_DEV_ID("e6cc0000.sci",		&mstp_clks[MSTP230]),
 
 	CLKDEV_DEV_ID("sh_cmt.10",		&mstp_clks[MSTP329]),
 	CLKDEV_DEV_ID("sh_fsi2",		&mstp_clks[MSTP328]),
-- 
1.7.9.5

[PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Bastian Hecht]

We can now use the Device Tree for bringing up our serial devices. We
need to add an alternative early_devices list in setup-r8a7740 without
the serial devices and move them into the Armadillo-reference .dts config file.

Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
---
v3:
no changes

 .../boot/dts/r8a7740-armadillo800eva-reference.dts |   94 ++++++++++++++++++++
 arch/arm/mach-shmobile/setup-r8a7740.c             |   15 +++-
 2 files changed, 105 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 1e339cd..52645b6 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -134,6 +134,100 @@
 		renesas,pins = "eth_base";
 		renesas,function = "eth";
 	};
+
+	sci@0xe6c40000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c40000 0x100>;
+		interrupts = <0x0c00>, <0x0c00>, <0x0c00>, <0x0c00>;
+		cell-index = <0>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c50000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c50000 0x100>;
+		interrupts = <0x0c20>, <0x0c20>, <0x0c20>, <0x0c20>;
+		cell-index = <1>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c60000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c60000 0x100>;
+		interrupts = <0x0c40>, <0x0c40>, <0x0c40>, <0x0c40>;
+		cell-index = <2>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c70000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c70000 0x100>;
+		interrupts = <0x0c60>, <0x0c60>, <0x0c60>, <0x0c60>;
+		cell-index = <3>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6c80000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c80000 0x100>;
+		interrupts = <0x0d20>, <0x0d20>, <0x0d20>, <0x0d20>;
+		cell-index = <4>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cb0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cb0000 0x100>;
+		interrupts = <0x0d40>, <0x0d40>, <0x0d40>, <0x0d40>;
+		cell-index = <5>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cc0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cc0000 0x100>;
+		interrupts = <0x04c0>, <0x04c0>, <0x04c0>, <0x04c0>;
+		cell-index = <6>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cd0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cd0000 0x100>;
+		interrupts = <0x04e0>, <0x04e0>, <0x04e0>, <0x04e0>;
+		cell-index = <7>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6c30000 {
+		compatible = "renesas,sci-SCIFB-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c30000 0x100>;
+		interrupts = <0x0d60>, <0x0d60>, <0x0d60>, <0x0d60>;
+		cell-index = <8>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
 };
 
 &gpio {
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 5312aad..5f7597a 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -394,6 +394,13 @@ static struct platform_device *r8a7740_early_devices[] __initdata = {
 	&tmu02_device,
 };
 
+static struct platform_device *r8a7740_early_devices_dt[] __initdata = {
+	&cmt10_device,
+	&tmu00_device,
+	&tmu01_device,
+	&tmu02_device,
+};
+
 /* DMA */
 static const struct sh_dmae_slave_config r8a7740_dmae_slaves[] = {
 	{
@@ -839,8 +846,8 @@ void __init r8a7740_add_early_devices_dt(void)
 {
 	shmobile_setup_delay(800, 1, 3); /* Cortex-A9 @ 800MHz */
 
-	early_platform_add_devices(r8a7740_early_devices,
-				   ARRAY_SIZE(r8a7740_early_devices));
+	early_platform_add_devices(r8a7740_early_devices_dt,
+				   ARRAY_SIZE(r8a7740_early_devices_dt));
 
 	/* setup early console here as well */
 	shmobile_setup_console();
@@ -852,8 +859,8 @@ static const struct of_dev_auxdata r8a7740_auxdata_lookup[] __initconst = {
 
 void __init r8a7740_add_standard_devices_dt(void)
 {
-	platform_add_devices(r8a7740_early_devices,
-			    ARRAY_SIZE(r8a7740_early_devices));
+	platform_add_devices(r8a7740_early_devices_dt,
+			    ARRAY_SIZE(r8a7740_early_devices_dt));
 
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     r8a7740_auxdata_lookup, NULL);
-- 
1.7.9.5

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Paul Mundt]

On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
> 
> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> ---
> v3:
> - add remaining register layouts to bindings
> - remove register set mapping sci_regtype_modes[]
> - adapt renesas,regtype probing
> 
> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
> - check renesas,scbrr-algo-id boundaries using new enums
> 
>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
>  include/linux/serial_sci.h                         |    4 +
>  3 files changed, 179 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
> 
Looks good to me.

Reviewed-by: Paul Mundt <lethal@linux-sh.org>

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Paul Mundt]

On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
> 
> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> ---
> v3:
> - add remaining register layouts to bindings
> - remove register set mapping sci_regtype_modes[]
> - adapt renesas,regtype probing
> 
> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
> - check renesas,scbrr-algo-id boundaries using new enums
> 
>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
>  include/linux/serial_sci.h                         |    4 +
>  3 files changed, 179 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
> 
Looks good to me.

Reviewed-by: Paul Mundt <lethal@linux-sh.org>

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Magnus Damm]

On Wed, Feb 27, 2013 at 5:07 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
>> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
>>
>> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
>> ---
>> v3:
>> - add remaining register layouts to bindings
>> - remove register set mapping sci_regtype_modes[]
>> - adapt renesas,regtype probing
>>
>> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
>> - check renesas,scbrr-algo-id boundaries using new enums
>>
>>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
>>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
>>  include/linux/serial_sci.h                         |    4 +
>>  3 files changed, 179 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
>>
> Looks good to me.
>
> Reviewed-by: Paul Mundt <lethal@linux-sh.org>

Thanks. Do you intend to merge this yourself at some point, or do you
have some other preferred way to deal with this?

Cheers,

/ magnus

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Magnus Damm]

On Wed, Feb 27, 2013 at 5:07 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
>> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
>>
>> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
>> ---
>> v3:
>> - add remaining register layouts to bindings
>> - remove register set mapping sci_regtype_modes[]
>> - adapt renesas,regtype probing
>>
>> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
>> - check renesas,scbrr-algo-id boundaries using new enums
>>
>>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
>>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
>>  include/linux/serial_sci.h                         |    4 +
>>  3 files changed, 179 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
>>
> Looks good to me.
>
> Reviewed-by: Paul Mundt <lethal@linux-sh.org>

Thanks. Do you intend to merge this yourself at some point, or do you
have some other preferred way to deal with this?

Cheers,

/ magnus

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Paul Mundt]

On Wed, Feb 27, 2013 at 05:11:34PM +0900, Magnus Damm wrote:
> On Wed, Feb 27, 2013 at 5:07 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
> >> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
> >>
> >> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> >> ---
> >> v3:
> >> - add remaining register layouts to bindings
> >> - remove register set mapping sci_regtype_modes[]
> >> - adapt renesas,regtype probing
> >>
> >> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
> >> - check renesas,scbrr-algo-id boundaries using new enums
> >>
> >>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
> >>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
> >>  include/linux/serial_sci.h                         |    4 +
> >>  3 files changed, 179 insertions(+), 4 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
> >>
> > Looks good to me.
> >
> > Reviewed-by: Paul Mundt <lethal@linux-sh.org>
> 
> Thanks. Do you intend to merge this yourself at some point, or do you
> have some other preferred way to deal with this?
> 
I can merge it if you like, but then obviously the ARM patches will have
to wait until that part is upstream. I assumed you would want them all
grouped together, at which point I don't mind if it goes through some
other tree.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Paul Mundt]

On Wed, Feb 27, 2013 at 05:11:34PM +0900, Magnus Damm wrote:
> On Wed, Feb 27, 2013 at 5:07 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
> >> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
> >>
> >> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> >> ---
> >> v3:
> >> - add remaining register layouts to bindings
> >> - remove register set mapping sci_regtype_modes[]
> >> - adapt renesas,regtype probing
> >>
> >> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
> >> - check renesas,scbrr-algo-id boundaries using new enums
> >>
> >>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
> >>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
> >>  include/linux/serial_sci.h                         |    4 +
> >>  3 files changed, 179 insertions(+), 4 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
> >>
> > Looks good to me.
> >
> > Reviewed-by: Paul Mundt <lethal@linux-sh.org>
> 
> Thanks. Do you intend to merge this yourself at some point, or do you
> have some other preferred way to deal with this?
> 
I can merge it if you like, but then obviously the ARM patches will have
to wait until that part is upstream. I assumed you would want them all
grouped together, at which point I don't mind if it goes through some
other tree.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Magnus Damm]

On Wed, Feb 27, 2013 at 5:19 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Wed, Feb 27, 2013 at 05:11:34PM +0900, Magnus Damm wrote:
>> On Wed, Feb 27, 2013 at 5:07 PM, Paul Mundt <lethal@linux-sh.org> wrote:
>> > On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
>> >> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
>> >>
>> >> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
>> >> ---
>> >> v3:
>> >> - add remaining register layouts to bindings
>> >> - remove register set mapping sci_regtype_modes[]
>> >> - adapt renesas,regtype probing
>> >>
>> >> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
>> >> - check renesas,scbrr-algo-id boundaries using new enums
>> >>
>> >>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
>> >>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
>> >>  include/linux/serial_sci.h                         |    4 +
>> >>  3 files changed, 179 insertions(+), 4 deletions(-)
>> >>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
>> >>
>> > Looks good to me.
>> >
>> > Reviewed-by: Paul Mundt <lethal@linux-sh.org>
>>
>> Thanks. Do you intend to merge this yourself at some point, or do you
>> have some other preferred way to deal with this?
>>
> I can merge it if you like, but then obviously the ARM patches will have
> to wait until that part is upstream. I assumed you would want them all
> grouped together, at which point I don't mind if it goes through some
> other tree.

[Added Simon as CC]

My personal preference would be that you (Paul) merge this patch by yourself:
[PATCH v3 1/3] serial: sh-sci: Add OF support

I believe we can deal with the SoC bits easily afterwards. Simon may
however prefer to deal with it differently.

Simon, how do you prefer to handle merge of DT support for the SCIF driver?

Thanks,

/ magnus

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Magnus Damm]

On Wed, Feb 27, 2013 at 5:19 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Wed, Feb 27, 2013 at 05:11:34PM +0900, Magnus Damm wrote:
>> On Wed, Feb 27, 2013 at 5:07 PM, Paul Mundt <lethal@linux-sh.org> wrote:
>> > On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
>> >> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
>> >>
>> >> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
>> >> ---
>> >> v3:
>> >> - add remaining register layouts to bindings
>> >> - remove register set mapping sci_regtype_modes[]
>> >> - adapt renesas,regtype probing
>> >>
>> >> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
>> >> - check renesas,scbrr-algo-id boundaries using new enums
>> >>
>> >>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
>> >>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
>> >>  include/linux/serial_sci.h                         |    4 +
>> >>  3 files changed, 179 insertions(+), 4 deletions(-)
>> >>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
>> >>
>> > Looks good to me.
>> >
>> > Reviewed-by: Paul Mundt <lethal@linux-sh.org>
>>
>> Thanks. Do you intend to merge this yourself at some point, or do you
>> have some other preferred way to deal with this?
>>
> I can merge it if you like, but then obviously the ARM patches will have
> to wait until that part is upstream. I assumed you would want them all
> grouped together, at which point I don't mind if it goes through some
> other tree.

[Added Simon as CC]

My personal preference would be that you (Paul) merge this patch by yourself:
[PATCH v3 1/3] serial: sh-sci: Add OF support

I believe we can deal with the SoC bits easily afterwards. Simon may
however prefer to deal with it differently.

Simon, how do you prefer to handle merge of DT support for the SCIF driver?

Thanks,

/ magnus

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Simon Horman]

On Wed, Feb 27, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
> On Wed, Feb 27, 2013 at 5:19 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Wed, Feb 27, 2013 at 05:11:34PM +0900, Magnus Damm wrote:
> >> On Wed, Feb 27, 2013 at 5:07 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> >> > On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
> >> >> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
> >> >>
> >> >> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> >> >> ---
> >> >> v3:
> >> >> - add remaining register layouts to bindings
> >> >> - remove register set mapping sci_regtype_modes[]
> >> >> - adapt renesas,regtype probing
> >> >>
> >> >> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
> >> >> - check renesas,scbrr-algo-id boundaries using new enums
> >> >>
> >> >>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
> >> >>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
> >> >>  include/linux/serial_sci.h                         |    4 +
> >> >>  3 files changed, 179 insertions(+), 4 deletions(-)
> >> >>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
> >> >>
> >> > Looks good to me.
> >> >
> >> > Reviewed-by: Paul Mundt <lethal@linux-sh.org>
> >>
> >> Thanks. Do you intend to merge this yourself at some point, or do you
> >> have some other preferred way to deal with this?
> >>
> > I can merge it if you like, but then obviously the ARM patches will have
> > to wait until that part is upstream. I assumed you would want them all
> > grouped together, at which point I don't mind if it goes through some
> > other tree.
> 
> [Added Simon as CC]
> 
> My personal preference would be that you (Paul) merge this patch by yourself:
> [PATCH v3 1/3] serial: sh-sci: Add OF support
> 
> I believe we can deal with the SoC bits easily afterwards. Simon may
> however prefer to deal with it differently.
> 
> Simon, how do you prefer to handle merge of DT support for the SCIF driver?

I am fairly ambivalent.

If Paul could merge this patch upstream in the v3.9-rc1~rc3 time frame
then I can queue up the SoC portions for v3.10.

Or alternatively I can queue up all three patches for v3.10.
Either way the outcome should be much the same.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Simon Horman]

On Wed, Feb 27, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
> On Wed, Feb 27, 2013 at 5:19 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Wed, Feb 27, 2013 at 05:11:34PM +0900, Magnus Damm wrote:
> >> On Wed, Feb 27, 2013 at 5:07 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> >> > On Tue, Feb 26, 2013 at 11:03:26AM -0600, Bastian Hecht wrote:
> >> >> We add the capabilty to probe Renesas SCI devices using Device Tree setup.
> >> >>
> >> >> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> >> >> ---
> >> >> v3:
> >> >> - add remaining register layouts to bindings
> >> >> - remove register set mapping sci_regtype_modes[]
> >> >> - adapt renesas,regtype probing
> >> >>
> >> >> - add enums SCBRR_ALGO_INVALID and SCBRR_NR_ALGOS
> >> >> - check renesas,scbrr-algo-id boundaries using new enums
> >> >>
> >> >>  .../bindings/tty/serial/renesas,sci-serial.txt     |   53 ++++++++
> >> >>  drivers/tty/serial/sh-sci.c                        |  126 +++++++++++++++++++-
> >> >>  include/linux/serial_sci.h                         |    4 +
> >> >>  3 files changed, 179 insertions(+), 4 deletions(-)
> >> >>  create mode 100644 Documentation/devicetree/bindings/tty/serial/renesas,sci-serial.txt
> >> >>
> >> > Looks good to me.
> >> >
> >> > Reviewed-by: Paul Mundt <lethal@linux-sh.org>
> >>
> >> Thanks. Do you intend to merge this yourself at some point, or do you
> >> have some other preferred way to deal with this?
> >>
> > I can merge it if you like, but then obviously the ARM patches will have
> > to wait until that part is upstream. I assumed you would want them all
> > grouped together, at which point I don't mind if it goes through some
> > other tree.
> 
> [Added Simon as CC]
> 
> My personal preference would be that you (Paul) merge this patch by yourself:
> [PATCH v3 1/3] serial: sh-sci: Add OF support
> 
> I believe we can deal with the SoC bits easily afterwards. Simon may
> however prefer to deal with it differently.
> 
> Simon, how do you prefer to handle merge of DT support for the SCIF driver?

I am fairly ambivalent.

If Paul could merge this patch upstream in the v3.9-rc1~rc3 time frame
then I can queue up the SoC portions for v3.10.

Or alternatively I can queue up all three patches for v3.10.
Either way the outcome should be much the same.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Paul Mundt]

On Wed, Feb 27, 2013 at 06:04:57PM +0900, Simon Horman wrote:
> On Wed, Feb 27, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
> > My personal preference would be that you (Paul) merge this patch by yourself:
> > [PATCH v3 1/3] serial: sh-sci: Add OF support
> > 
> > I believe we can deal with the SoC bits easily afterwards. Simon may
> > however prefer to deal with it differently.
> > 
> > Simon, how do you prefer to handle merge of DT support for the SCIF driver?
> 
> I am fairly ambivalent.
> 
> If Paul could merge this patch upstream in the v3.9-rc1~rc3 time frame
> then I can queue up the SoC portions for v3.10.
> 
> Or alternatively I can queue up all three patches for v3.10.
> Either way the outcome should be much the same.

Waiting an entire kernel version to throw some arbitrary dts file updates
in seems a bit absurd, but I'll let you handle it however you like. I
haven't sent out my SH updates to Linus yet, but plan to do so by -rc2
(there isn't really that much to begin with, most of it has gone through
other trees), so in light of this I will throw the sh-sci OF patch in to
my queue directly then.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Paul Mundt]

On Wed, Feb 27, 2013 at 06:04:57PM +0900, Simon Horman wrote:
> On Wed, Feb 27, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
> > My personal preference would be that you (Paul) merge this patch by yourself:
> > [PATCH v3 1/3] serial: sh-sci: Add OF support
> > 
> > I believe we can deal with the SoC bits easily afterwards. Simon may
> > however prefer to deal with it differently.
> > 
> > Simon, how do you prefer to handle merge of DT support for the SCIF driver?
> 
> I am fairly ambivalent.
> 
> If Paul could merge this patch upstream in the v3.9-rc1~rc3 time frame
> then I can queue up the SoC portions for v3.10.
> 
> Or alternatively I can queue up all three patches for v3.10.
> Either way the outcome should be much the same.

Waiting an entire kernel version to throw some arbitrary dts file updates
in seems a bit absurd, but I'll let you handle it however you like. I
haven't sent out my SH updates to Linus yet, but plan to do so by -rc2
(there isn't really that much to begin with, most of it has gone through
other trees), so in light of this I will throw the sh-sci OF patch in to
my queue directly then.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Bastian Hecht]

2013/2/27 Paul Mundt <lethal@linux-sh.org>:
> On Wed, Feb 27, 2013 at 06:04:57PM +0900, Simon Horman wrote:
>> On Wed, Feb 27, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
>> > My personal preference would be that you (Paul) merge this patch by yourself:
>> > [PATCH v3 1/3] serial: sh-sci: Add OF support
>> >
>> > I believe we can deal with the SoC bits easily afterwards. Simon may
>> > however prefer to deal with it differently.
>> >
>> > Simon, how do you prefer to handle merge of DT support for the SCIF driver?
>>
>> I am fairly ambivalent.
>>
>> If Paul could merge this patch upstream in the v3.9-rc1~rc3 time frame
>> then I can queue up the SoC portions for v3.10.
>>
>> Or alternatively I can queue up all three patches for v3.10.
>> Either way the outcome should be much the same.
>
> Waiting an entire kernel version to throw some arbitrary dts file updates
> in seems a bit absurd, but I'll let you handle it however you like. I
> haven't sent out my SH updates to Linus yet, but plan to do so by -rc2
> (there isn't really that much to begin with, most of it has gone through
> other trees), so in light of this I will throw the sh-sci OF patch in to
> my queue directly then.

Thanks to all involved getting this patch into the mainline.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Bastian Hecht]

2013/2/27 Paul Mundt <lethal@linux-sh.org>:
> On Wed, Feb 27, 2013 at 06:04:57PM +0900, Simon Horman wrote:
>> On Wed, Feb 27, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
>> > My personal preference would be that you (Paul) merge this patch by yourself:
>> > [PATCH v3 1/3] serial: sh-sci: Add OF support
>> >
>> > I believe we can deal with the SoC bits easily afterwards. Simon may
>> > however prefer to deal with it differently.
>> >
>> > Simon, how do you prefer to handle merge of DT support for the SCIF driver?
>>
>> I am fairly ambivalent.
>>
>> If Paul could merge this patch upstream in the v3.9-rc1~rc3 time frame
>> then I can queue up the SoC portions for v3.10.
>>
>> Or alternatively I can queue up all three patches for v3.10.
>> Either way the outcome should be much the same.
>
> Waiting an entire kernel version to throw some arbitrary dts file updates
> in seems a bit absurd, but I'll let you handle it however you like. I
> haven't sent out my SH updates to Linus yet, but plan to do so by -rc2
> (there isn't really that much to begin with, most of it has gone through
> other trees), so in light of this I will throw the sh-sci OF patch in to
> my queue directly then.

Thanks to all involved getting this patch into the mainline.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Simon Horman]

On Wed, Feb 27, 2013 at 06:34:40PM +0900, Paul Mundt wrote:
> On Wed, Feb 27, 2013 at 06:04:57PM +0900, Simon Horman wrote:
> > On Wed, Feb 27, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
> > > My personal preference would be that you (Paul) merge this patch by yourself:
> > > [PATCH v3 1/3] serial: sh-sci: Add OF support
> > > 
> > > I believe we can deal with the SoC bits easily afterwards. Simon may
> > > however prefer to deal with it differently.
> > > 
> > > Simon, how do you prefer to handle merge of DT support for the SCIF driver?
> > 
> > I am fairly ambivalent.
> > 
> > If Paul could merge this patch upstream in the v3.9-rc1~rc3 time frame
> > then I can queue up the SoC portions for v3.10.
> > 
> > Or alternatively I can queue up all three patches for v3.10.
> > Either way the outcome should be much the same.
> 
> Waiting an entire kernel version to throw some arbitrary dts file updates
> in seems a bit absurd, but I'll let you handle it however you like. I
> haven't sent out my SH updates to Linus yet, but plan to do so by -rc2
> (there isn't really that much to begin with, most of it has gone through
> other trees), so in light of this I will throw the sh-sci OF patch in to
> my queue directly then.

Thanks, much appreciated.

I entirely agree that my tree has longer lead-times than are desirable.

Re: [PATCH v3 1/3] serial: sh-sci: Add OF support

[Simon Horman]

On Wed, Feb 27, 2013 at 06:34:40PM +0900, Paul Mundt wrote:
> On Wed, Feb 27, 2013 at 06:04:57PM +0900, Simon Horman wrote:
> > On Wed, Feb 27, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
> > > My personal preference would be that you (Paul) merge this patch by yourself:
> > > [PATCH v3 1/3] serial: sh-sci: Add OF support
> > > 
> > > I believe we can deal with the SoC bits easily afterwards. Simon may
> > > however prefer to deal with it differently.
> > > 
> > > Simon, how do you prefer to handle merge of DT support for the SCIF driver?
> > 
> > I am fairly ambivalent.
> > 
> > If Paul could merge this patch upstream in the v3.9-rc1~rc3 time frame
> > then I can queue up the SoC portions for v3.10.
> > 
> > Or alternatively I can queue up all three patches for v3.10.
> > Either way the outcome should be much the same.
> 
> Waiting an entire kernel version to throw some arbitrary dts file updates
> in seems a bit absurd, but I'll let you handle it however you like. I
> haven't sent out my SH updates to Linus yet, but plan to do so by -rc2
> (there isn't really that much to begin with, most of it has gone through
> other trees), so in light of this I will throw the sh-sci OF patch in to
> my queue directly then.

Thanks, much appreciated.

I entirely agree that my tree has longer lead-times than are desirable.

Re: [PATCH v3 2/3] ARM: mach-shmobile: r8a7740: Add DT names to clock list

[Simon Horman]

On Tue, Feb 26, 2013 at 11:03:27AM -0600, Bastian Hecht wrote:
> This adds temporarily the alternative device names to the clock list
> that are used when booting via Device Tree setup.

Thanks, applied to the soc5 branch of the renesas tree
and thus included in its next branch and queued up for v3.10.

> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> ---
> v3:
> no changes
> 
>  arch/arm/mach-shmobile/clock-r8a7740.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
> index 71fc400..0f77823 100644
> --- a/arch/arm/mach-shmobile/clock-r8a7740.c
> +++ b/arch/arm/mach-shmobile/clock-r8a7740.c
> @@ -593,18 +593,27 @@ static struct clk_lookup lookups[] = {
>  	CLKDEV_DEV_ID("sh_mobile_ceu.1",	&mstp_clks[MSTP128]),
>  
>  	CLKDEV_DEV_ID("sh-sci.4",		&mstp_clks[MSTP200]),
> +	CLKDEV_DEV_ID("e6c80000.sci",		&mstp_clks[MSTP200]),
>  	CLKDEV_DEV_ID("sh-sci.3",		&mstp_clks[MSTP201]),
> +	CLKDEV_DEV_ID("e6c70000.sci",		&mstp_clks[MSTP201]),
>  	CLKDEV_DEV_ID("sh-sci.2",		&mstp_clks[MSTP202]),
> +	CLKDEV_DEV_ID("e6c60000.sci",		&mstp_clks[MSTP202]),
>  	CLKDEV_DEV_ID("sh-sci.1",		&mstp_clks[MSTP203]),
> +	CLKDEV_DEV_ID("e6c50000.sci",		&mstp_clks[MSTP203]),
>  	CLKDEV_DEV_ID("sh-sci.0",		&mstp_clks[MSTP204]),
> +	CLKDEV_DEV_ID("e6c40000.sci",		&mstp_clks[MSTP204]),
>  	CLKDEV_DEV_ID("sh-sci.8",		&mstp_clks[MSTP206]),
> +	CLKDEV_DEV_ID("e6c30000.sci",		&mstp_clks[MSTP206]),
>  	CLKDEV_DEV_ID("sh-sci.5",		&mstp_clks[MSTP207]),
> +	CLKDEV_DEV_ID("e6cb0000.sci",		&mstp_clks[MSTP207]),
>  	CLKDEV_DEV_ID("sh-dma-engine.3",	&mstp_clks[MSTP214]),
>  	CLKDEV_DEV_ID("sh-dma-engine.2",	&mstp_clks[MSTP216]),
>  	CLKDEV_DEV_ID("sh-dma-engine.1",	&mstp_clks[MSTP217]),
>  	CLKDEV_DEV_ID("sh-dma-engine.0",	&mstp_clks[MSTP218]),
>  	CLKDEV_DEV_ID("sh-sci.7",		&mstp_clks[MSTP222]),
> +	CLKDEV_DEV_ID("e6cd0000.sci",		&mstp_clks[MSTP222]),
>  	CLKDEV_DEV_ID("sh-sci.6",		&mstp_clks[MSTP230]),
> +	CLKDEV_DEV_ID("e6cc0000.sci",		&mstp_clks[MSTP230]),
>  
>  	CLKDEV_DEV_ID("sh_cmt.10",		&mstp_clks[MSTP329]),
>  	CLKDEV_DEV_ID("sh_fsi2",		&mstp_clks[MSTP328]),
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v3 2/3] ARM: mach-shmobile: r8a7740: Add DT names to clock list

[Simon Horman]

On Tue, Feb 26, 2013 at 11:03:27AM -0600, Bastian Hecht wrote:
> This adds temporarily the alternative device names to the clock list
> that are used when booting via Device Tree setup.

Thanks, applied to the soc5 branch of the renesas tree
and thus included in its next branch and queued up for v3.10.

> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
> ---
> v3:
> no changes
> 
>  arch/arm/mach-shmobile/clock-r8a7740.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
> index 71fc400..0f77823 100644
> --- a/arch/arm/mach-shmobile/clock-r8a7740.c
> +++ b/arch/arm/mach-shmobile/clock-r8a7740.c
> @@ -593,18 +593,27 @@ static struct clk_lookup lookups[] = {
>  	CLKDEV_DEV_ID("sh_mobile_ceu.1",	&mstp_clks[MSTP128]),
>  
>  	CLKDEV_DEV_ID("sh-sci.4",		&mstp_clks[MSTP200]),
> +	CLKDEV_DEV_ID("e6c80000.sci",		&mstp_clks[MSTP200]),
>  	CLKDEV_DEV_ID("sh-sci.3",		&mstp_clks[MSTP201]),
> +	CLKDEV_DEV_ID("e6c70000.sci",		&mstp_clks[MSTP201]),
>  	CLKDEV_DEV_ID("sh-sci.2",		&mstp_clks[MSTP202]),
> +	CLKDEV_DEV_ID("e6c60000.sci",		&mstp_clks[MSTP202]),
>  	CLKDEV_DEV_ID("sh-sci.1",		&mstp_clks[MSTP203]),
> +	CLKDEV_DEV_ID("e6c50000.sci",		&mstp_clks[MSTP203]),
>  	CLKDEV_DEV_ID("sh-sci.0",		&mstp_clks[MSTP204]),
> +	CLKDEV_DEV_ID("e6c40000.sci",		&mstp_clks[MSTP204]),
>  	CLKDEV_DEV_ID("sh-sci.8",		&mstp_clks[MSTP206]),
> +	CLKDEV_DEV_ID("e6c30000.sci",		&mstp_clks[MSTP206]),
>  	CLKDEV_DEV_ID("sh-sci.5",		&mstp_clks[MSTP207]),
> +	CLKDEV_DEV_ID("e6cb0000.sci",		&mstp_clks[MSTP207]),
>  	CLKDEV_DEV_ID("sh-dma-engine.3",	&mstp_clks[MSTP214]),
>  	CLKDEV_DEV_ID("sh-dma-engine.2",	&mstp_clks[MSTP216]),
>  	CLKDEV_DEV_ID("sh-dma-engine.1",	&mstp_clks[MSTP217]),
>  	CLKDEV_DEV_ID("sh-dma-engine.0",	&mstp_clks[MSTP218]),
>  	CLKDEV_DEV_ID("sh-sci.7",		&mstp_clks[MSTP222]),
> +	CLKDEV_DEV_ID("e6cd0000.sci",		&mstp_clks[MSTP222]),
>  	CLKDEV_DEV_ID("sh-sci.6",		&mstp_clks[MSTP230]),
> +	CLKDEV_DEV_ID("e6cc0000.sci",		&mstp_clks[MSTP230]),
>  
>  	CLKDEV_DEV_ID("sh_cmt.10",		&mstp_clks[MSTP329]),
>  	CLKDEV_DEV_ID("sh_fsi2",		&mstp_clks[MSTP328]),
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> We can now use the Device Tree for bringing up our serial devices. We
> need to add an alternative early_devices list in setup-r8a7740 without
> the serial devices and move them into the Armadillo-reference .dts config file.

Hi Bastian,

could you please refresh this patch on top of the current topic/intc-of.
In particular, it conflicts with changes made by:

ARM: shmobile: r8a7740: Do not use early devices with DT reference

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> We can now use the Device Tree for bringing up our serial devices. We
> need to add an alternative early_devices list in setup-r8a7740 without
> the serial devices and move them into the Armadillo-reference .dts config file.

Hi Bastian,

could you please refresh this patch on top of the current topic/intc-of.
In particular, it conflicts with changes made by:

ARM: shmobile: r8a7740: Do not use early devices with DT reference

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Bastian Hecht]

2013/3/1 Simon Horman <horms@verge.net.au>:
> On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>> We can now use the Device Tree for bringing up our serial devices. We
>> need to add an alternative early_devices list in setup-r8a7740 without
>> the serial devices and move them into the Armadillo-reference .dts config file.
>
> Hi Bastian,
>
> could you please refresh this patch on top of the current topic/intc-of.
> In particular, it conflicts with changes made by:
>
> ARM: shmobile: r8a7740: Do not use early devices with DT reference

Sure.

I've prepared the patch - but I start to wonder if the DT
specification for the SCIF devices should go into r8a7740.dtsi rather
than r8a7740-armadillo-reference.dts. So far it's included in
setup-r8a7740.c and not in the board code - that's a strong indication
for it, no?
I want to post a patchset for the CMT timer soon. There it's the same.

Cheers,

 Bastian

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Bastian Hecht]

2013/3/1 Simon Horman <horms@verge.net.au>:
> On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>> We can now use the Device Tree for bringing up our serial devices. We
>> need to add an alternative early_devices list in setup-r8a7740 without
>> the serial devices and move them into the Armadillo-reference .dts config file.
>
> Hi Bastian,
>
> could you please refresh this patch on top of the current topic/intc-of.
> In particular, it conflicts with changes made by:
>
> ARM: shmobile: r8a7740: Do not use early devices with DT reference

Sure.

I've prepared the patch - but I start to wonder if the DT
specification for the SCIF devices should go into r8a7740.dtsi rather
than r8a7740-armadillo-reference.dts. So far it's included in
setup-r8a7740.c and not in the board code - that's a strong indication
for it, no?
I want to post a patchset for the CMT timer soon. There it's the same.

Cheers,

 Bastian

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> 2013/3/1 Simon Horman <horms@verge.net.au>:
> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >> We can now use the Device Tree for bringing up our serial devices. We
> >> need to add an alternative early_devices list in setup-r8a7740 without
> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >
> > Hi Bastian,
> >
> > could you please refresh this patch on top of the current topic/intc-of.
> > In particular, it conflicts with changes made by:
> >
> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> 
> Sure.
> 
> I've prepared the patch - but I start to wonder if the DT
> specification for the SCIF devices should go into r8a7740.dtsi rather
> than r8a7740-armadillo-reference.dts. So far it's included in
> setup-r8a7740.c and not in the board code - that's a strong indication
> for it, no?

I forget exactly how the discussion went, but for the kzm9g the
SDHI has ended up in the dts file for the board not the sh73a0 SoC.

So I assume that r8a7740-armadillo-reference.dts is the correct place
for SDHI on the armadillo.

Magnus, can you confirm that SDHI belongs to the board not the SoC?

> I want to post a patchset for the CMT timer soon. There it's the same.

Magnus, could you also let us know if CMT should go in the board or SoC dts?

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> 2013/3/1 Simon Horman <horms@verge.net.au>:
> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >> We can now use the Device Tree for bringing up our serial devices. We
> >> need to add an alternative early_devices list in setup-r8a7740 without
> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >
> > Hi Bastian,
> >
> > could you please refresh this patch on top of the current topic/intc-of.
> > In particular, it conflicts with changes made by:
> >
> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> 
> Sure.
> 
> I've prepared the patch - but I start to wonder if the DT
> specification for the SCIF devices should go into r8a7740.dtsi rather
> than r8a7740-armadillo-reference.dts. So far it's included in
> setup-r8a7740.c and not in the board code - that's a strong indication
> for it, no?

I forget exactly how the discussion went, but for the kzm9g the
SDHI has ended up in the dts file for the board not the sh73a0 SoC.

So I assume that r8a7740-armadillo-reference.dts is the correct place
for SDHI on the armadillo.

Magnus, can you confirm that SDHI belongs to the board not the SoC?

> I want to post a patchset for the CMT timer soon. There it's the same.

Magnus, could you also let us know if CMT should go in the board or SoC dts?

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Magnus Damm]

Hi Simon,

[Added Guennadi to CC]

On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
>> 2013/3/1 Simon Horman <horms@verge.net.au>:
>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>> >> We can now use the Device Tree for bringing up our serial devices. We
>> >> need to add an alternative early_devices list in setup-r8a7740 without
>> >> the serial devices and move them into the Armadillo-reference .dts config file.
>> >
>> > Hi Bastian,
>> >
>> > could you please refresh this patch on top of the current topic/intc-of.
>> > In particular, it conflicts with changes made by:
>> >
>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
>>
>> Sure.
>>
>> I've prepared the patch - but I start to wonder if the DT
>> specification for the SCIF devices should go into r8a7740.dtsi rather
>> than r8a7740-armadillo-reference.dts. So far it's included in
>> setup-r8a7740.c and not in the board code - that's a strong indication
>> for it, no?
>
> I forget exactly how the discussion went, but for the kzm9g the
> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
>
> So I assume that r8a7740-armadillo-reference.dts is the correct place
> for SDHI on the armadillo.
>
> Magnus, can you confirm that SDHI belongs to the board not the SoC?

What does the data sheet say?

The SDHI hardware block is included in the SoC. It may however need
some board specific configuration. I believe the correct way is to
define the common parts in the SoC-specific dtsi file and add
board-specific configuration in the board-specific dts file. Perhaps
you can consult Guennadi about this, he has been tasked with SDHI and
MMCIF.

>> I want to post a patchset for the CMT timer soon. There it's the same.
>
> Magnus, could you also let us know if CMT should go in the board or SoC dts?

In the SoC. As a general rule, if there is a platform device in
setup-nnnn.c then the device does not need any board specific
configuration. Such devices should be put in the SoC-specific dtsi
file.

Thanks,

/ magnus

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Magnus Damm]

Hi Simon,

[Added Guennadi to CC]

On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
>> 2013/3/1 Simon Horman <horms@verge.net.au>:
>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>> >> We can now use the Device Tree for bringing up our serial devices. We
>> >> need to add an alternative early_devices list in setup-r8a7740 without
>> >> the serial devices and move them into the Armadillo-reference .dts config file.
>> >
>> > Hi Bastian,
>> >
>> > could you please refresh this patch on top of the current topic/intc-of.
>> > In particular, it conflicts with changes made by:
>> >
>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
>>
>> Sure.
>>
>> I've prepared the patch - but I start to wonder if the DT
>> specification for the SCIF devices should go into r8a7740.dtsi rather
>> than r8a7740-armadillo-reference.dts. So far it's included in
>> setup-r8a7740.c and not in the board code - that's a strong indication
>> for it, no?
>
> I forget exactly how the discussion went, but for the kzm9g the
> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
>
> So I assume that r8a7740-armadillo-reference.dts is the correct place
> for SDHI on the armadillo.
>
> Magnus, can you confirm that SDHI belongs to the board not the SoC?

What does the data sheet say?

The SDHI hardware block is included in the SoC. It may however need
some board specific configuration. I believe the correct way is to
define the common parts in the SoC-specific dtsi file and add
board-specific configuration in the board-specific dts file. Perhaps
you can consult Guennadi about this, he has been tasked with SDHI and
MMCIF.

>> I want to post a patchset for the CMT timer soon. There it's the same.
>
> Magnus, could you also let us know if CMT should go in the board or SoC dts?

In the SoC. As a general rule, if there is a platform device in
setup-nnnn.c then the device does not need any board specific
configuration. Such devices should be put in the SoC-specific dtsi
file.

Thanks,

/ magnus

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Guennadi Liakhovetski]

Hi

On Mon, 4 Mar 2013, Magnus Damm wrote:

> Hi Simon,
> 
> [Added Guennadi to CC]
> 
> On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> >> 2013/3/1 Simon Horman <horms@verge.net.au>:
> >> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >> >> We can now use the Device Tree for bringing up our serial devices. We
> >> >> need to add an alternative early_devices list in setup-r8a7740 without
> >> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >> >
> >> > Hi Bastian,
> >> >
> >> > could you please refresh this patch on top of the current topic/intc-of.
> >> > In particular, it conflicts with changes made by:
> >> >
> >> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> >>
> >> Sure.
> >>
> >> I've prepared the patch - but I start to wonder if the DT
> >> specification for the SCIF devices should go into r8a7740.dtsi rather
> >> than r8a7740-armadillo-reference.dts. So far it's included in
> >> setup-r8a7740.c and not in the board code - that's a strong indication
> >> for it, no?
> >
> > I forget exactly how the discussion went, but for the kzm9g the
> > SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> >
> > So I assume that r8a7740-armadillo-reference.dts is the correct place
> > for SDHI on the armadillo.
> >
> > Magnus, can you confirm that SDHI belongs to the board not the SoC?
> 
> What does the data sheet say?
> 
> The SDHI hardware block is included in the SoC. It may however need
> some board specific configuration. I believe the correct way is to
> define the common parts in the SoC-specific dtsi file and add
> board-specific configuration in the board-specific dts file. Perhaps
> you can consult Guennadi about this, he has been tasked with SDHI and
> MMCIF.

That would be the best, I agree. However, we discussed this already on the 
example of mmcif, you might remember. I asked what's the difference 
between extending a DT node (from .dtsi) with additional properties (in a 
board-specific .dts) using an "&phandle" syntax and a full path? Or are 
they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
settled with complete nodes in .dts. We do use the "&phandle" syntax for 
pinctrl function groups, for I2C devices. I used a complete path for 
CPUFreq... Mostly because other platforms did that too.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Guennadi Liakhovetski]

Hi

On Mon, 4 Mar 2013, Magnus Damm wrote:

> Hi Simon,
> 
> [Added Guennadi to CC]
> 
> On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> >> 2013/3/1 Simon Horman <horms@verge.net.au>:
> >> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >> >> We can now use the Device Tree for bringing up our serial devices. We
> >> >> need to add an alternative early_devices list in setup-r8a7740 without
> >> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >> >
> >> > Hi Bastian,
> >> >
> >> > could you please refresh this patch on top of the current topic/intc-of.
> >> > In particular, it conflicts with changes made by:
> >> >
> >> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> >>
> >> Sure.
> >>
> >> I've prepared the patch - but I start to wonder if the DT
> >> specification for the SCIF devices should go into r8a7740.dtsi rather
> >> than r8a7740-armadillo-reference.dts. So far it's included in
> >> setup-r8a7740.c and not in the board code - that's a strong indication
> >> for it, no?
> >
> > I forget exactly how the discussion went, but for the kzm9g the
> > SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> >
> > So I assume that r8a7740-armadillo-reference.dts is the correct place
> > for SDHI on the armadillo.
> >
> > Magnus, can you confirm that SDHI belongs to the board not the SoC?
> 
> What does the data sheet say?
> 
> The SDHI hardware block is included in the SoC. It may however need
> some board specific configuration. I believe the correct way is to
> define the common parts in the SoC-specific dtsi file and add
> board-specific configuration in the board-specific dts file. Perhaps
> you can consult Guennadi about this, he has been tasked with SDHI and
> MMCIF.

That would be the best, I agree. However, we discussed this already on the 
example of mmcif, you might remember. I asked what's the difference 
between extending a DT node (from .dtsi) with additional properties (in a 
board-specific .dts) using an "&phandle" syntax and a full path? Or are 
they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
settled with complete nodes in .dts. We do use the "&phandle" syntax for 
pinctrl function groups, for I2C devices. I used a complete path for 
CPUFreq... Mostly because other platforms did that too.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Bastian Hecht]

Hi Simon!

2013/3/4 Magnus Damm <magnus.damm@gmail.com>:
> Hi Simon,
>
> [Added Guennadi to CC]
>
> On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
>> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
>>> 2013/3/1 Simon Horman <horms@verge.net.au>:
>>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>>> >> We can now use the Device Tree for bringing up our serial devices. We
>>> >> need to add an alternative early_devices list in setup-r8a7740 without
>>> >> the serial devices and move them into the Armadillo-reference .dts config file.
>>> >
>>> > Hi Bastian,
>>> >
>>> > could you please refresh this patch on top of the current topic/intc-of.
>>> > In particular, it conflicts with changes made by:
>>> >
>>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
>>>
>>> Sure.
>>>
>>> I've prepared the patch - but I start to wonder if the DT
>>> specification for the SCIF devices should go into r8a7740.dtsi rather
>>> than r8a7740-armadillo-reference.dts. So far it's included in
>>> setup-r8a7740.c and not in the board code - that's a strong indication
>>> for it, no?
>>
>> I forget exactly how the discussion went, but for the kzm9g the
>> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
>>
>> So I assume that r8a7740-armadillo-reference.dts is the correct place
>> for SDHI on the armadillo.
>>
>> Magnus, can you confirm that SDHI belongs to the board not the SoC?
>
> What does the data sheet say?
>
> The SDHI hardware block is included in the SoC. It may however need
> some board specific configuration. I believe the correct way is to
> define the common parts in the SoC-specific dtsi file and add
> board-specific configuration in the board-specific dts file. Perhaps
> you can consult Guennadi about this, he has been tasked with SDHI and
> MMCIF.
>
>>> I want to post a patchset for the CMT timer soon. There it's the same.
>>
>> Magnus, could you also let us know if CMT should go in the board or SoC dts?
>
> In the SoC. As a general rule, if there is a platform device in
> setup-nnnn.c then the device does not need any board specific
> configuration. Such devices should be put in the SoC-specific dtsi
> file.

Ok I posted a v4 SCIF DT patchset putting the SCIF devices into r8a7740.dtsi.

Simon, are you aware about this in topic/intc-of? It shows up booting
the non-DT version.

Unable to handle kernel NULL pointer dereference at virtual address 00000040
pgd = c0004000
[00000040] *pgd\0000000
Internal error: Oops: 5 [#1] ARM
CPU: 0    Not tainted  (3.8.0-rc3-00205-gfb2696a #298)
PC is at __gpio_get_value+0x18/0x5c
LR is at eva_init+0x190/0x544

We should add standard bootargs in the r8a7740-armadillo800eva.dts as
well. Shall I post a small patch?

Thanks,

 Bastian


> Thanks,
>
> / magnus

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Bastian Hecht]

Hi Simon!

2013/3/4 Magnus Damm <magnus.damm@gmail.com>:
> Hi Simon,
>
> [Added Guennadi to CC]
>
> On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
>> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
>>> 2013/3/1 Simon Horman <horms@verge.net.au>:
>>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>>> >> We can now use the Device Tree for bringing up our serial devices. We
>>> >> need to add an alternative early_devices list in setup-r8a7740 without
>>> >> the serial devices and move them into the Armadillo-reference .dts config file.
>>> >
>>> > Hi Bastian,
>>> >
>>> > could you please refresh this patch on top of the current topic/intc-of.
>>> > In particular, it conflicts with changes made by:
>>> >
>>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
>>>
>>> Sure.
>>>
>>> I've prepared the patch - but I start to wonder if the DT
>>> specification for the SCIF devices should go into r8a7740.dtsi rather
>>> than r8a7740-armadillo-reference.dts. So far it's included in
>>> setup-r8a7740.c and not in the board code - that's a strong indication
>>> for it, no?
>>
>> I forget exactly how the discussion went, but for the kzm9g the
>> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
>>
>> So I assume that r8a7740-armadillo-reference.dts is the correct place
>> for SDHI on the armadillo.
>>
>> Magnus, can you confirm that SDHI belongs to the board not the SoC?
>
> What does the data sheet say?
>
> The SDHI hardware block is included in the SoC. It may however need
> some board specific configuration. I believe the correct way is to
> define the common parts in the SoC-specific dtsi file and add
> board-specific configuration in the board-specific dts file. Perhaps
> you can consult Guennadi about this, he has been tasked with SDHI and
> MMCIF.
>
>>> I want to post a patchset for the CMT timer soon. There it's the same.
>>
>> Magnus, could you also let us know if CMT should go in the board or SoC dts?
>
> In the SoC. As a general rule, if there is a platform device in
> setup-nnnn.c then the device does not need any board specific
> configuration. Such devices should be put in the SoC-specific dtsi
> file.

Ok I posted a v4 SCIF DT patchset putting the SCIF devices into r8a7740.dtsi.

Simon, are you aware about this in topic/intc-of? It shows up booting
the non-DT version.

Unable to handle kernel NULL pointer dereference at virtual address 00000040
pgd = c0004000
[00000040] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
CPU: 0    Not tainted  (3.8.0-rc3-00205-gfb2696a #298)
PC is at __gpio_get_value+0x18/0x5c
LR is at eva_init+0x190/0x544

We should add standard bootargs in the r8a7740-armadillo800eva.dts as
well. Shall I post a small patch?

Thanks,

 Bastian


> Thanks,
>
> / magnus

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:
> Hi
> 
> On Mon, 4 Mar 2013, Magnus Damm wrote:
> 
> > Hi Simon,
> > 
> > [Added Guennadi to CC]
> > 
> > On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> > > On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> > >> 2013/3/1 Simon Horman <horms@verge.net.au>:
> > >> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> > >> >> We can now use the Device Tree for bringing up our serial devices. We
> > >> >> need to add an alternative early_devices list in setup-r8a7740 without
> > >> >> the serial devices and move them into the Armadillo-reference .dts config file.
> > >> >
> > >> > Hi Bastian,
> > >> >
> > >> > could you please refresh this patch on top of the current topic/intc-of.
> > >> > In particular, it conflicts with changes made by:
> > >> >
> > >> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> > >>
> > >> Sure.
> > >>
> > >> I've prepared the patch - but I start to wonder if the DT
> > >> specification for the SCIF devices should go into r8a7740.dtsi rather
> > >> than r8a7740-armadillo-reference.dts. So far it's included in
> > >> setup-r8a7740.c and not in the board code - that's a strong indication
> > >> for it, no?
> > >
> > > I forget exactly how the discussion went, but for the kzm9g the
> > > SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> > >
> > > So I assume that r8a7740-armadillo-reference.dts is the correct place
> > > for SDHI on the armadillo.
> > >
> > > Magnus, can you confirm that SDHI belongs to the board not the SoC?
> > 
> > What does the data sheet say?
> > 
> > The SDHI hardware block is included in the SoC. It may however need
> > some board specific configuration. I believe the correct way is to
> > define the common parts in the SoC-specific dtsi file and add
> > board-specific configuration in the board-specific dts file. Perhaps
> > you can consult Guennadi about this, he has been tasked with SDHI and
> > MMCIF.
> 
> That would be the best, I agree. However, we discussed this already on the 
> example of mmcif, you might remember. I asked what's the difference 
> between extending a DT node (from .dtsi) with additional properties (in a 
> board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> pinctrl function groups, for I2C devices. I used a complete path for 
> CPUFreq... Mostly because other platforms did that too.

I am confused.

Using phandle syntax we can add a device to an soc's dtsi file and then add
extra properties in the board file.  This seems to be match the HW well.

What is your alternate suggestion?

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:
> Hi
> 
> On Mon, 4 Mar 2013, Magnus Damm wrote:
> 
> > Hi Simon,
> > 
> > [Added Guennadi to CC]
> > 
> > On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> > > On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> > >> 2013/3/1 Simon Horman <horms@verge.net.au>:
> > >> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> > >> >> We can now use the Device Tree for bringing up our serial devices. We
> > >> >> need to add an alternative early_devices list in setup-r8a7740 without
> > >> >> the serial devices and move them into the Armadillo-reference .dts config file.
> > >> >
> > >> > Hi Bastian,
> > >> >
> > >> > could you please refresh this patch on top of the current topic/intc-of.
> > >> > In particular, it conflicts with changes made by:
> > >> >
> > >> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> > >>
> > >> Sure.
> > >>
> > >> I've prepared the patch - but I start to wonder if the DT
> > >> specification for the SCIF devices should go into r8a7740.dtsi rather
> > >> than r8a7740-armadillo-reference.dts. So far it's included in
> > >> setup-r8a7740.c and not in the board code - that's a strong indication
> > >> for it, no?
> > >
> > > I forget exactly how the discussion went, but for the kzm9g the
> > > SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> > >
> > > So I assume that r8a7740-armadillo-reference.dts is the correct place
> > > for SDHI on the armadillo.
> > >
> > > Magnus, can you confirm that SDHI belongs to the board not the SoC?
> > 
> > What does the data sheet say?
> > 
> > The SDHI hardware block is included in the SoC. It may however need
> > some board specific configuration. I believe the correct way is to
> > define the common parts in the SoC-specific dtsi file and add
> > board-specific configuration in the board-specific dts file. Perhaps
> > you can consult Guennadi about this, he has been tasked with SDHI and
> > MMCIF.
> 
> That would be the best, I agree. However, we discussed this already on the 
> example of mmcif, you might remember. I asked what's the difference 
> between extending a DT node (from .dtsi) with additional properties (in a 
> board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> pinctrl function groups, for I2C devices. I used a complete path for 
> CPUFreq... Mostly because other platforms did that too.

I am confused.

Using phandle syntax we can add a device to an soc's dtsi file and then add
extra properties in the board file.  This seems to be match the HW well.

What is your alternate suggestion?

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Mon, Mar 04, 2013 at 04:44:30PM +0100, Bastian Hecht wrote:
> Hi Simon!
> 
> 2013/3/4 Magnus Damm <magnus.damm@gmail.com>:
> > Hi Simon,
> >
> > [Added Guennadi to CC]
> >
> > On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> >> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> >>> 2013/3/1 Simon Horman <horms@verge.net.au>:
> >>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >>> >> We can now use the Device Tree for bringing up our serial devices. We
> >>> >> need to add an alternative early_devices list in setup-r8a7740 without
> >>> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >>> >
> >>> > Hi Bastian,
> >>> >
> >>> > could you please refresh this patch on top of the current topic/intc-of.
> >>> > In particular, it conflicts with changes made by:
> >>> >
> >>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> >>>
> >>> Sure.
> >>>
> >>> I've prepared the patch - but I start to wonder if the DT
> >>> specification for the SCIF devices should go into r8a7740.dtsi rather
> >>> than r8a7740-armadillo-reference.dts. So far it's included in
> >>> setup-r8a7740.c and not in the board code - that's a strong indication
> >>> for it, no?
> >>
> >> I forget exactly how the discussion went, but for the kzm9g the
> >> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> >>
> >> So I assume that r8a7740-armadillo-reference.dts is the correct place
> >> for SDHI on the armadillo.
> >>
> >> Magnus, can you confirm that SDHI belongs to the board not the SoC?
> >
> > What does the data sheet say?
> >
> > The SDHI hardware block is included in the SoC. It may however need
> > some board specific configuration. I believe the correct way is to
> > define the common parts in the SoC-specific dtsi file and add
> > board-specific configuration in the board-specific dts file. Perhaps
> > you can consult Guennadi about this, he has been tasked with SDHI and
> > MMCIF.
> >
> >>> I want to post a patchset for the CMT timer soon. There it's the same.
> >>
> >> Magnus, could you also let us know if CMT should go in the board or SoC dts?
> >
> > In the SoC. As a general rule, if there is a platform device in
> > setup-nnnn.c then the device does not need any board specific
> > configuration. Such devices should be put in the SoC-specific dtsi
> > file.
> 
> Ok I posted a v4 SCIF DT patchset putting the SCIF devices into r8a7740.dtsi.
> 
> Simon, are you aware about this in topic/intc-of? It shows up booting
> the non-DT version.
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000040
> pgd = c0004000
> [00000040] *pgd\0000000
> Internal error: Oops: 5 [#1] ARM
> CPU: 0    Not tainted  (3.8.0-rc3-00205-gfb2696a #298)
> PC is at __gpio_get_value+0x18/0x5c
> LR is at eva_init+0x190/0x544

Yes, I am aware of it, it is the reason that topic/intc-of is
not included in topic/all+next at the moment.

I believe it is caused by SH pinctl DT support.

http://permalink.gmane.org/gmane.linux.ports.sh.devel/19649


> We should add standard bootargs in the r8a7740-armadillo800eva.dts as
> well. Shall I post a small patch?

I have applied a patch to do that which should be present in v3.9-rc1.

Now that v3.9-rc1 has been released I will see about rebasing my
branches on top of it.

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Mon, Mar 04, 2013 at 04:44:30PM +0100, Bastian Hecht wrote:
> Hi Simon!
> 
> 2013/3/4 Magnus Damm <magnus.damm@gmail.com>:
> > Hi Simon,
> >
> > [Added Guennadi to CC]
> >
> > On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> >> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> >>> 2013/3/1 Simon Horman <horms@verge.net.au>:
> >>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >>> >> We can now use the Device Tree for bringing up our serial devices. We
> >>> >> need to add an alternative early_devices list in setup-r8a7740 without
> >>> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >>> >
> >>> > Hi Bastian,
> >>> >
> >>> > could you please refresh this patch on top of the current topic/intc-of.
> >>> > In particular, it conflicts with changes made by:
> >>> >
> >>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> >>>
> >>> Sure.
> >>>
> >>> I've prepared the patch - but I start to wonder if the DT
> >>> specification for the SCIF devices should go into r8a7740.dtsi rather
> >>> than r8a7740-armadillo-reference.dts. So far it's included in
> >>> setup-r8a7740.c and not in the board code - that's a strong indication
> >>> for it, no?
> >>
> >> I forget exactly how the discussion went, but for the kzm9g the
> >> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> >>
> >> So I assume that r8a7740-armadillo-reference.dts is the correct place
> >> for SDHI on the armadillo.
> >>
> >> Magnus, can you confirm that SDHI belongs to the board not the SoC?
> >
> > What does the data sheet say?
> >
> > The SDHI hardware block is included in the SoC. It may however need
> > some board specific configuration. I believe the correct way is to
> > define the common parts in the SoC-specific dtsi file and add
> > board-specific configuration in the board-specific dts file. Perhaps
> > you can consult Guennadi about this, he has been tasked with SDHI and
> > MMCIF.
> >
> >>> I want to post a patchset for the CMT timer soon. There it's the same.
> >>
> >> Magnus, could you also let us know if CMT should go in the board or SoC dts?
> >
> > In the SoC. As a general rule, if there is a platform device in
> > setup-nnnn.c then the device does not need any board specific
> > configuration. Such devices should be put in the SoC-specific dtsi
> > file.
> 
> Ok I posted a v4 SCIF DT patchset putting the SCIF devices into r8a7740.dtsi.
> 
> Simon, are you aware about this in topic/intc-of? It shows up booting
> the non-DT version.
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000040
> pgd = c0004000
> [00000040] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> CPU: 0    Not tainted  (3.8.0-rc3-00205-gfb2696a #298)
> PC is at __gpio_get_value+0x18/0x5c
> LR is at eva_init+0x190/0x544

Yes, I am aware of it, it is the reason that topic/intc-of is
not included in topic/all+next at the moment.

I believe it is caused by SH pinctl DT support.

http://permalink.gmane.org/gmane.linux.ports.sh.devel/19649


> We should add standard bootargs in the r8a7740-armadillo800eva.dts as
> well. Shall I post a small patch?

I have applied a patch to do that which should be present in v3.9-rc1.

Now that v3.9-rc1 has been released I will see about rebasing my
branches on top of it.

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Guennadi Liakhovetski]

Hi Simon

On Tue, 5 Mar 2013, Simon Horman wrote:

> On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:

[snip]

> > That would be the best, I agree. However, we discussed this already on the 
> > example of mmcif, you might remember. I asked what's the difference 
> > between extending a DT node (from .dtsi) with additional properties (in a 
> > board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> > they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> > settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> > pinctrl function groups, for I2C devices. I used a complete path for 
> > CPUFreq... Mostly because other platforms did that too.
> 
> I am confused.
> 
> Using phandle syntax we can add a device to an soc's dtsi file and then add
> extra properties in the board file.  This seems to be match the HW well.
> 
> What is your alternate suggestion?

Let me give you examples. In sh73a0-reference.dtsi we define an I2C device 
#0:

	i2c0: i2c@0xe6820000 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "renesas,rmobile-iic";
		reg = <0xe6820000 0x425>;
		...
	};

Then in sh73a0-kzm9g-reference.dts I can use the phandle syntax to put 
devices on that I2C bus:

&i2c0 {
	as3711@40 {
		compatible = "ams,as3711";
		reg = <0x40>;
		...
	};
	...
};

This is one possibility. In sh73a0.dtsi we've got

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		cpu@0 {
			device_type = "cpu";
			compatible = "arm,cortex-a9";
			reg = <0>;
		};
		...
	};

Now, I can also extend this in sh73a0-kzm9g-reference.dts to add CPUFreq 
support to CPU0:

	cpus {
		cpu@0 {
			cpu0-supply = <&vdd_dvfs>;
			operating-points = <
				/* kHz  uV */
				1196000 1315000
				 598000 1175000
				 398667 1065000
			>;
			voltage-tolerance = <1>; /* 1% */
		};
	};

Which AFAICS does a similar thing (adds more properties to an existing DT 
node) but uses a different syntax. Maybe they are completely equivalent, 
the only difference being, that the former example uses a phandle and the 
latter a complete path, maybe there are differences, I don't know.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Guennadi Liakhovetski]

Hi Simon

On Tue, 5 Mar 2013, Simon Horman wrote:

> On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:

[snip]

> > That would be the best, I agree. However, we discussed this already on the 
> > example of mmcif, you might remember. I asked what's the difference 
> > between extending a DT node (from .dtsi) with additional properties (in a 
> > board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> > they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> > settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> > pinctrl function groups, for I2C devices. I used a complete path for 
> > CPUFreq... Mostly because other platforms did that too.
> 
> I am confused.
> 
> Using phandle syntax we can add a device to an soc's dtsi file and then add
> extra properties in the board file.  This seems to be match the HW well.
> 
> What is your alternate suggestion?

Let me give you examples. In sh73a0-reference.dtsi we define an I2C device 
#0:

	i2c0: i2c@0xe6820000 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "renesas,rmobile-iic";
		reg = <0xe6820000 0x425>;
		...
	};

Then in sh73a0-kzm9g-reference.dts I can use the phandle syntax to put 
devices on that I2C bus:

&i2c0 {
	as3711@40 {
		compatible = "ams,as3711";
		reg = <0x40>;
		...
	};
	...
};

This is one possibility. In sh73a0.dtsi we've got

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		cpu@0 {
			device_type = "cpu";
			compatible = "arm,cortex-a9";
			reg = <0>;
		};
		...
	};

Now, I can also extend this in sh73a0-kzm9g-reference.dts to add CPUFreq 
support to CPU0:

	cpus {
		cpu@0 {
			cpu0-supply = <&vdd_dvfs>;
			operating-points = <
				/* kHz  uV */
				1196000 1315000
				 598000 1175000
				 398667 1065000
			>;
			voltage-tolerance = <1>; /* 1% */
		};
	};

Which AFAICS does a similar thing (adds more properties to an existing DT 
node) but uses a different syntax. Maybe they are completely equivalent, 
the only difference being, that the former example uses a phandle and the 
latter a complete path, maybe there are differences, I don't know.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Tue, Mar 05, 2013 at 07:52:21AM +0100, Guennadi Liakhovetski wrote:
> Hi Simon
> 
> On Tue, 5 Mar 2013, Simon Horman wrote:
> 
> > On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:
> 
> [snip]
> 
> > > That would be the best, I agree. However, we discussed this already on the 
> > > example of mmcif, you might remember. I asked what's the difference 
> > > between extending a DT node (from .dtsi) with additional properties (in a 
> > > board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> > > they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> > > settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> > > pinctrl function groups, for I2C devices. I used a complete path for 
> > > CPUFreq... Mostly because other platforms did that too.
> > 
> > I am confused.
> > 
> > Using phandle syntax we can add a device to an soc's dtsi file and then add
> > extra properties in the board file.  This seems to be match the HW well.
> > 
> > What is your alternate suggestion?
> 
> Let me give you examples. In sh73a0-reference.dtsi we define an I2C device 
> #0:
> 
> 	i2c0: i2c@0xe6820000 {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		compatible = "renesas,rmobile-iic";
> 		reg = <0xe6820000 0x425>;
> 		...
> 	};
> 
> Then in sh73a0-kzm9g-reference.dts I can use the phandle syntax to put 
> devices on that I2C bus:
> 
> &i2c0 {
> 	as3711@40 {
> 		compatible = "ams,as3711";
> 		reg = <0x40>;
> 		...
> 	};
> 	...
> };
> 
> This is one possibility. In sh73a0.dtsi we've got
> 
> 	cpus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		cpu@0 {
> 			device_type = "cpu";
> 			compatible = "arm,cortex-a9";
> 			reg = <0>;
> 		};
> 		...
> 	};
> 
> Now, I can also extend this in sh73a0-kzm9g-reference.dts to add CPUFreq 
> support to CPU0:
> 
> 	cpus {
> 		cpu@0 {
> 			cpu0-supply = <&vdd_dvfs>;
> 			operating-points = <
> 				/* kHz  uV */
> 				1196000 1315000
> 				 598000 1175000
> 				 398667 1065000
> 			>;
> 			voltage-tolerance = <1>; /* 1% */
> 		};
> 	};
> 
> Which AFAICS does a similar thing (adds more properties to an existing DT 
> node) but uses a different syntax. Maybe they are completely equivalent, 
> the only difference being, that the former example uses a phandle and the 
> latter a complete path, maybe there are differences, I don't know.

Interesting. Thanks for the example, I now understand.

To be honest I'm not sure what the answer is.
But if they are both working then I'm not particularly fussed either way.

Re: [PATCH v3 3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

[Simon Horman]

On Tue, Mar 05, 2013 at 07:52:21AM +0100, Guennadi Liakhovetski wrote:
> Hi Simon
> 
> On Tue, 5 Mar 2013, Simon Horman wrote:
> 
> > On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:
> 
> [snip]
> 
> > > That would be the best, I agree. However, we discussed this already on the 
> > > example of mmcif, you might remember. I asked what's the difference 
> > > between extending a DT node (from .dtsi) with additional properties (in a 
> > > board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> > > they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> > > settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> > > pinctrl function groups, for I2C devices. I used a complete path for 
> > > CPUFreq... Mostly because other platforms did that too.
> > 
> > I am confused.
> > 
> > Using phandle syntax we can add a device to an soc's dtsi file and then add
> > extra properties in the board file.  This seems to be match the HW well.
> > 
> > What is your alternate suggestion?
> 
> Let me give you examples. In sh73a0-reference.dtsi we define an I2C device 
> #0:
> 
> 	i2c0: i2c@0xe6820000 {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		compatible = "renesas,rmobile-iic";
> 		reg = <0xe6820000 0x425>;
> 		...
> 	};
> 
> Then in sh73a0-kzm9g-reference.dts I can use the phandle syntax to put 
> devices on that I2C bus:
> 
> &i2c0 {
> 	as3711@40 {
> 		compatible = "ams,as3711";
> 		reg = <0x40>;
> 		...
> 	};
> 	...
> };
> 
> This is one possibility. In sh73a0.dtsi we've got
> 
> 	cpus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		cpu@0 {
> 			device_type = "cpu";
> 			compatible = "arm,cortex-a9";
> 			reg = <0>;
> 		};
> 		...
> 	};
> 
> Now, I can also extend this in sh73a0-kzm9g-reference.dts to add CPUFreq 
> support to CPU0:
> 
> 	cpus {
> 		cpu@0 {
> 			cpu0-supply = <&vdd_dvfs>;
> 			operating-points = <
> 				/* kHz  uV */
> 				1196000 1315000
> 				 598000 1175000
> 				 398667 1065000
> 			>;
> 			voltage-tolerance = <1>; /* 1% */
> 		};
> 	};
> 
> Which AFAICS does a similar thing (adds more properties to an existing DT 
> node) but uses a different syntax. Maybe they are completely equivalent, 
> the only difference being, that the former example uses a phandle and the 
> latter a complete path, maybe there are differences, I don't know.

Interesting. Thanks for the example, I now understand.

To be honest I'm not sure what the answer is.
But if they are both working then I'm not particularly fussed either way.