[PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[Sergei Shtylyov]

Hello.

   Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
week separately...

[01/13] ARM: shmobile: r8a7792: add clock index macros
[02/13] ARM: shmobile: r8a7792: add power domain index macros
[03/13] soc: renesas: rcar-sysc: add R8A7792 support
[04/13] ARM: shmobile: r8a7792: basic SoC support
[05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
[06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
[07/13] ARM: dts: r8a7792: initial SoC device tree
[08/13] ARM: dts: r8a7792: add SYS-DMAC support
[09/13] ARM: dts: r8a7792: add [H]SCIF support
[10/13] ARM dts: r8a7792: add IRQC support
[11/13] DT: arm: shmobile: document Blanche board
[12/13] ARM: dts: blanche: initial device tree
[13/13] ARM: dts: blanche: add Ethernet support

WBR, Sergei

[PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[Sergei Shtylyov]

Hello.

   Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
week separately...

[01/13] ARM: shmobile: r8a7792: add clock index macros
[02/13] ARM: shmobile: r8a7792: add power domain index macros
[03/13] soc: renesas: rcar-sysc: add R8A7792 support
[04/13] ARM: shmobile: r8a7792: basic SoC support
[05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
[06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
[07/13] ARM: dts: r8a7792: initial SoC device tree
[08/13] ARM: dts: r8a7792: add SYS-DMAC support
[09/13] ARM: dts: r8a7792: add [H]SCIF support
[10/13] ARM dts: r8a7792: add IRQC support
[11/13] DT: arm: shmobile: document Blanche board
[12/13] ARM: dts: blanche: initial device tree
[13/13] ARM: dts: blanche: add Ethernet support

WBR, Sergei

[PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Sergei Shtylyov]

Add macros usable by the device tree sources to reference the R8A7792
clocks  by index.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
===================================================================
--- /dev/null
+++ renesas/include/dt-bindings/clock/r8a7792-clock.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
+#define __DT_BINDINGS_CLOCK_R8A7792_H__
+
+/* CPG */
+#define R8A7792_CLK_MAIN		0
+#define R8A7792_CLK_PLL0		1
+#define R8A7792_CLK_PLL1		2
+#define R8A7792_CLK_PLL3		3
+#define R8A7792_CLK_LB			4
+#define R8A7792_CLK_QSPI		5
+#define R8A7792_CLK_SDH			6
+#define R8A7792_CLK_SD0			7
+#define R8A7792_CLK_SD1			8
+#define R8A7792_CLK_Z			9
+
+/* MSTP0 */
+#define R8A7792_CLK_MSIOF0		0
+
+/* MSTP1 */
+#define R8A7792_CLK_TMU1		11
+#define R8A7792_CLK_TMU3		21
+#define R8A7792_CLK_TMU2		22
+#define R8A7792_CLK_CMT0		24
+#define R8A7792_CLK_TMU0		25
+#define R8A7792_CLK_VSP1DU1		27
+#define R8A7792_CLK_VSP1DU0		28
+#define R8A7792_CLK_VSP1_SY		31
+
+/* MSTP2 */
+#define R8A7792_CLK_MSIOF1		8
+#define R8A7792_CLK_SYS_DMAC0		18
+#define R8A7792_CLK_SYS_DMAC1		19
+
+/* MSTP3 */
+#define R8A7792_CLK_TPU0		4
+#define R8A7792_CLK_SDHI0		14
+#define R8A7792_CLK_CMT1		29
+
+/* MSTP4 */
+#define R8A7792_CLK_IRQC		7
+
+/* MSTP5 */
+#define R8A7792_CLK_AUDIO_DMAC0		2
+#define R8A7792_CLK_THERMAL		22
+#define R8A7792_CLK_PWM			23
+
+/* MSTP7 */
+#define R8A7792_CLK_HSCIF1		16
+#define R8A7792_CLK_HSCIF0		17
+#define R8A7792_CLK_SCIF3		18
+#define R8A7792_CLK_SCIF2		19
+#define R8A7792_CLK_SCIF1		20
+#define R8A7792_CLK_SCIF0		21
+#define R8A7792_CLK_DU1			23
+#define R8A7792_CLK_DU0			24
+
+/* MSTP8 */
+#define R8A7792_CLK_VIN5		4
+#define R8A7792_CLK_VIN4		5
+#define R8A7792_CLK_VIN3		8
+#define R8A7792_CLK_VIN2		9
+#define R8A7792_CLK_VIN1		10
+#define R8A7792_CLK_VIN0		11
+#define R8A7792_CLK_ETHERAVB		12
+
+/* MSTP9 */
+#define R8A7792_CLK_GPIO7		4
+#define R8A7792_CLK_GPIO6		5
+#define R8A7792_CLK_GPIO5		7
+#define R8A7792_CLK_GPIO4		8
+#define R8A7792_CLK_GPIO3		9
+#define R8A7792_CLK_GPIO2		10
+#define R8A7792_CLK_GPIO1		11
+#define R8A7792_CLK_GPIO0		12
+#define R8A7792_CLK_GPIO11		13
+#define R8A7792_CLK_GPIO10		14
+#define R8A7792_CLK_CAN1		15
+#define R8A7792_CLK_CAN0		16
+#define R8A7792_CLK_QSPI_MOD		17
+#define R8A7792_CLK_GPIO9		19
+#define R8A7792_CLK_GPIO8		21
+#define R8A7792_CLK_I2C5		25
+#define R8A7792_CLK_IICDVFS		26
+#define R8A7792_CLK_I2C4		27
+#define R8A7792_CLK_I2C3		28
+#define R8A7792_CLK_I2C2		29
+#define R8A7792_CLK_I2C1		30
+#define R8A7792_CLK_I2C0		31
+
+/* MSTP10 */
+#define R8A7792_CLK_SSI_ALL		5
+#define R8A7792_CLK_SSI4		11
+#define R8A7792_CLK_SSI3		12
+
+#endif /* __DT_BINDINGS_CLOCK_R8A7792_H__ */

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Simon Horman]

On Wed, Jun 01, 2016 at 01:09:58AM +0300, Sergei Shtylyov wrote:
> Add macros usable by the device tree sources to reference the R8A7792
> clocks  by index.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> ---
>  include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
>  1 file changed, 104 insertions(+)
> 
> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
> ===================================================================
> --- /dev/null
> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (C) 2016 Cogent Embedded, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
> +#define __DT_BINDINGS_CLOCK_R8A7792_H__
> +
> +/* CPG */
> +#define R8A7792_CLK_MAIN		0
> +#define R8A7792_CLK_PLL0		1
> +#define R8A7792_CLK_PLL1		2
> +#define R8A7792_CLK_PLL3		3
> +#define R8A7792_CLK_LB			4
> +#define R8A7792_CLK_QSPI		5
> +#define R8A7792_CLK_SDH			6
> +#define R8A7792_CLK_SD0			7
> +#define R8A7792_CLK_SD1			8
> +#define R8A7792_CLK_Z			9

According to my copy of the documentation (v2.00) SDH, SD0 and SD1 do
not seem to be provided by the r8a7792 CPG.

It does, however, provide RCAN and ADSP which are supported by the CPG
driver. You may wish to add them now for completeness though from my point
of view they could also be added later when they are used.


I reviewed the values below. They appear to be complete and correct.

> +/* MSTP0 */
> +#define R8A7792_CLK_MSIOF0		0
> +
> +/* MSTP1 */
> +#define R8A7792_CLK_TMU1		11
> +#define R8A7792_CLK_TMU3		21
> +#define R8A7792_CLK_TMU2		22
> +#define R8A7792_CLK_CMT0		24
> +#define R8A7792_CLK_TMU0		25
> +#define R8A7792_CLK_VSP1DU1		27
> +#define R8A7792_CLK_VSP1DU0		28
> +#define R8A7792_CLK_VSP1_SY		31
> +/* MSTP2 */
> +#define R8A7792_CLK_MSIOF1		8
> +#define R8A7792_CLK_SYS_DMAC0		18
> +#define R8A7792_CLK_SYS_DMAC1		19

> +/* MSTP3 */
> +#define R8A7792_CLK_TPU0		4
> +#define R8A7792_CLK_SDHI0		14
> +#define R8A7792_CLK_CMT1		29
> +
> +/* MSTP4 */
> +#define R8A7792_CLK_IRQC		7
> +
> +/* MSTP5 */
> +#define R8A7792_CLK_AUDIO_DMAC0		2
> +#define R8A7792_CLK_THERMAL		22
> +#define R8A7792_CLK_PWM			23
> +
> +/* MSTP7 */
> +#define R8A7792_CLK_HSCIF1		16
> +#define R8A7792_CLK_HSCIF0		17
> +#define R8A7792_CLK_SCIF3		18
> +#define R8A7792_CLK_SCIF2		19
> +#define R8A7792_CLK_SCIF1		20
> +#define R8A7792_CLK_SCIF0		21
> +#define R8A7792_CLK_DU1			23
> +#define R8A7792_CLK_DU0			24
> +
> +/* MSTP8 */
> +#define R8A7792_CLK_VIN5		4
> +#define R8A7792_CLK_VIN4		5
> +#define R8A7792_CLK_VIN3		8
> +#define R8A7792_CLK_VIN2		9
> +#define R8A7792_CLK_VIN1		10
> +#define R8A7792_CLK_VIN0		11
> +#define R8A7792_CLK_ETHERAVB		12
> +
> +/* MSTP9 */
> +#define R8A7792_CLK_GPIO7		4
> +#define R8A7792_CLK_GPIO6		5
> +#define R8A7792_CLK_GPIO5		7
> +#define R8A7792_CLK_GPIO4		8
> +#define R8A7792_CLK_GPIO3		9
> +#define R8A7792_CLK_GPIO2		10
> +#define R8A7792_CLK_GPIO1		11
> +#define R8A7792_CLK_GPIO0		12
> +#define R8A7792_CLK_GPIO11		13
> +#define R8A7792_CLK_GPIO10		14
> +#define R8A7792_CLK_CAN1		15
> +#define R8A7792_CLK_CAN0		16
> +#define R8A7792_CLK_QSPI_MOD		17
> +#define R8A7792_CLK_GPIO9		19
> +#define R8A7792_CLK_GPIO8		21
> +#define R8A7792_CLK_I2C5		25
> +#define R8A7792_CLK_IICDVFS		26
> +#define R8A7792_CLK_I2C4		27
> +#define R8A7792_CLK_I2C3		28
> +#define R8A7792_CLK_I2C2		29
> +#define R8A7792_CLK_I2C1		30
> +#define R8A7792_CLK_I2C0		31
> +
> +/* MSTP10 */
> +#define R8A7792_CLK_SSI_ALL		5
> +#define R8A7792_CLK_SSI4		11
> +#define R8A7792_CLK_SSI3		12
> +
> +#endif /* __DT_BINDINGS_CLOCK_R8A7792_H__ */
> 

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Sergei Shtylyov]

On 06/01/2016 03:52 AM, Simon Horman wrote:

>> Add macros usable by the device tree sources to reference the R8A7792
>> clocks  by index.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>>  include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
>>  1 file changed, 104 insertions(+)
>>
>> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
>> ===================================================================
>> --- /dev/null
>> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
>> @@ -0,0 +1,104 @@
>> +/*
>> + * Copyright (C) 2016 Cogent Embedded, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
>> +#define __DT_BINDINGS_CLOCK_R8A7792_H__
>> +
>> +/* CPG */
>> +#define R8A7792_CLK_MAIN		0
>> +#define R8A7792_CLK_PLL0		1
>> +#define R8A7792_CLK_PLL1		2
>> +#define R8A7792_CLK_PLL3		3
>> +#define R8A7792_CLK_LB			4
>> +#define R8A7792_CLK_QSPI		5
>> +#define R8A7792_CLK_SDH			6
>> +#define R8A7792_CLK_SD0			7
>> +#define R8A7792_CLK_SD1			8
>> +#define R8A7792_CLK_Z			9
>
> According to my copy of the documentation (v2.00) SDH, SD0 and SD1 do
> not seem to be provided by the r8a7792 CPG.

    Right, should have checked the original patch against the manual in that 
part as well... :-/

> It does, however, provide RCAN and ADSP which are supported by the CPG
> driver. You may wish to add them now for completeness though from my point
> of view they could also be added later when they are used.

    Hm, the gen2 manual rev1.02 doesn't mention either of these clocks for V2H...
I still don't have 2.00. :-(

> I reviewed the values below. They appear to be complete and correct.

    Geert has found some bug there. :-)

MBR, Sergei

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Sergei Shtylyov]

On 06/01/2016 03:52 AM, Simon Horman wrote:

>> Add macros usable by the device tree sources to reference the R8A7792
>> clocks  by index.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>>  include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
>>  1 file changed, 104 insertions(+)
>>
>> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
>> ===================================================================
>> --- /dev/null
>> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
>> @@ -0,0 +1,104 @@
>> +/*
>> + * Copyright (C) 2016 Cogent Embedded, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
>> +#define __DT_BINDINGS_CLOCK_R8A7792_H__
>> +
>> +/* CPG */
>> +#define R8A7792_CLK_MAIN		0
>> +#define R8A7792_CLK_PLL0		1
>> +#define R8A7792_CLK_PLL1		2
>> +#define R8A7792_CLK_PLL3		3
>> +#define R8A7792_CLK_LB			4
>> +#define R8A7792_CLK_QSPI		5
>> +#define R8A7792_CLK_SDH			6
>> +#define R8A7792_CLK_SD0			7
>> +#define R8A7792_CLK_SD1			8
>> +#define R8A7792_CLK_Z			9
>
> According to my copy of the documentation (v2.00) SDH, SD0 and SD1 do
> not seem to be provided by the r8a7792 CPG.

    I've just downloaded and opened rev2.00 manual, and still, there's no
CPG registers other than FRQCRB on V2H.

> It does, however, provide RCAN and ADSP which are supported by the CPG
> driver. You may wish to add them now for completeness though from my point
> of view they could also be added later when they are used.

    My copy of the manual says there's no ADSP on V2H, and thus no ADSP clock.

MBR, Sergei

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Simon Horman]

On Wed, Jun 22, 2016 at 10:52:04PM +0300, Sergei Shtylyov wrote:
> On 06/01/2016 03:52 AM, Simon Horman wrote:
> 
> >>Add macros usable by the device tree sources to reference the R8A7792
> >>clocks  by index.
> >>
> >>Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >>
> >>---
> >> include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
> >> 1 file changed, 104 insertions(+)
> >>
> >>Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
> >>===================================================================
> >>--- /dev/null
> >>+++ renesas/include/dt-bindings/clock/r8a7792-clock.h
> >>@@ -0,0 +1,104 @@
> >>+/*
> >>+ * Copyright (C) 2016 Cogent Embedded, Inc.
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or modify
> >>+ * it under the terms of the GNU General Public License as published by
> >>+ * the Free Software Foundation; either version 2 of the License, or
> >>+ * (at your option) any later version.
> >>+ */
> >>+
> >>+#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
> >>+#define __DT_BINDINGS_CLOCK_R8A7792_H__
> >>+
> >>+/* CPG */
> >>+#define R8A7792_CLK_MAIN		0
> >>+#define R8A7792_CLK_PLL0		1
> >>+#define R8A7792_CLK_PLL1		2
> >>+#define R8A7792_CLK_PLL3		3
> >>+#define R8A7792_CLK_LB			4
> >>+#define R8A7792_CLK_QSPI		5
> >>+#define R8A7792_CLK_SDH			6
> >>+#define R8A7792_CLK_SD0			7
> >>+#define R8A7792_CLK_SD1			8
> >>+#define R8A7792_CLK_Z			9
> >
> >According to my copy of the documentation (v2.00) SDH, SD0 and SD1 do
> >not seem to be provided by the r8a7792 CPG.
> 
>    I've just downloaded and opened rev2.00 manual, and still, there's no
> CPG registers other than FRQCRB on V2H.
> 
> >It does, however, provide RCAN and ADSP which are supported by the CPG
> >driver. You may wish to add them now for completeness though from my point
> >of view they could also be added later when they are used.
> 
>    My copy of the manual says there's no ADSP on V2H, and thus no ADSP clock.

I was looking at Figure 7.1c. Perhaps it is inaccurate.

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Geert Uytterhoeven]

On Thu, Jun 23, 2016 at 12:33 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> On Wed, Jun 22, 2016 at 10:52:04PM +0300, Sergei Shtylyov wrote:
>>    I've just downloaded and opened rev2.00 manual, and still, there's no
>> CPG registers other than FRQCRB on V2H.
>>
>> >It does, however, provide RCAN and ADSP which are supported by the CPG
>> >driver. You may wish to add them now for completeness though from my point
>> >of view they could also be added later when they are used.
>>
>>    My copy of the manual says there's no ADSP on V2H, and thus no ADSP clock.
>
> I was looking at Figure 7.1c. Perhaps it is inaccurate.

Probably, the ADSP is missing for V2H in all other sections of the datasheet:
  - There's no ADSP clock in Table 7.2c,
  - ADSPCKCR does not exist according to Table 7.10,
  - There are no ADSP MSSR bits, interrupts, or micro-TLBs,
  - The audio and ADSP modules do not exist.

Of course that's the datasheet, there may still be actual hardware listening
when you try to talk to it ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Geert Uytterhoeven]

On Thu, Jun 23, 2016 at 12:33 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Jun 22, 2016 at 10:52:04PM +0300, Sergei Shtylyov wrote:
>>    I've just downloaded and opened rev2.00 manual, and still, there's no
>> CPG registers other than FRQCRB on V2H.
>>
>> >It does, however, provide RCAN and ADSP which are supported by the CPG
>> >driver. You may wish to add them now for completeness though from my point
>> >of view they could also be added later when they are used.
>>
>>    My copy of the manual says there's no ADSP on V2H, and thus no ADSP clock.
>
> I was looking at Figure 7.1c. Perhaps it is inaccurate.

Probably, the ADSP is missing for V2H in all other sections of the datasheet:
  - There's no ADSP clock in Table 7.2c,
  - ADSPCKCR does not exist according to Table 7.10,
  - There are no ADSP MSSR bits, interrupts, or micro-TLBs,
  - The audio and ADSP modules do not exist.

Of course that's the datasheet, there may still be actual hardware listening
when you try to talk to it ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Sergei Shtylyov]

On 6/23/2016 1:33 AM, Simon Horman wrote:

>>>> Add macros usable by the device tree sources to reference the R8A7792
>>>> clocks  by index.
>>>>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>>>>
>>>> ---
>>>> include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
>>>> 1 file changed, 104 insertions(+)
>>>>
>>>> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
>>>> ===================================================================
>>>> --- /dev/null
>>>> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
>>>> @@ -0,0 +1,104 @@
>>>> +/*
>>>> + * Copyright (C) 2016 Cogent Embedded, Inc.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + */
>>>> +
>>>> +#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
>>>> +#define __DT_BINDINGS_CLOCK_R8A7792_H__
>>>> +
>>>> +/* CPG */
>>>> +#define R8A7792_CLK_MAIN		0
>>>> +#define R8A7792_CLK_PLL0		1
>>>> +#define R8A7792_CLK_PLL1		2
>>>> +#define R8A7792_CLK_PLL3		3
>>>> +#define R8A7792_CLK_LB			4
>>>> +#define R8A7792_CLK_QSPI		5
>>>> +#define R8A7792_CLK_SDH			6
>>>> +#define R8A7792_CLK_SD0			7
>>>> +#define R8A7792_CLK_SD1			8
>>>> +#define R8A7792_CLK_Z			9
>>>
>>> According to my copy of the documentation (v2.00) SDH, SD0 and SD1 do
>>> not seem to be provided by the r8a7792 CPG.
>>
>>    I've just downloaded and opened rev2.00 manual, and still, there's no
>> CPG registers other than FRQCRB on V2H.
>>
>>> It does, however, provide RCAN and ADSP which are supported by the CPG
>>> driver. You may wish to add them now for completeness though from my point
>>> of view they could also be added later when they are used.
>>
>>    My copy of the manual says there's no ADSP on V2H, and thus no ADSP clock.
>
> I was looking at Figure 7.1c. Perhaps it is inaccurate.

    Indeed, it's the only place where the ADSP clock is mentioned for V2H, and 
it looks like this is in error. I guess I'll try to verify if there's writable 
ADSPCKCR and then remove the ADSP clock if not.

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Sergei Shtylyov]

On 6/23/2016 1:33 AM, Simon Horman wrote:

>>>> Add macros usable by the device tree sources to reference the R8A7792
>>>> clocks  by index.
>>>>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>>
>>>> ---
>>>> include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
>>>> 1 file changed, 104 insertions(+)
>>>>
>>>> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
>>>> ===================================================================
>>>> --- /dev/null
>>>> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
>>>> @@ -0,0 +1,104 @@
>>>> +/*
>>>> + * Copyright (C) 2016 Cogent Embedded, Inc.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + */
>>>> +
>>>> +#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
>>>> +#define __DT_BINDINGS_CLOCK_R8A7792_H__
>>>> +
>>>> +/* CPG */
>>>> +#define R8A7792_CLK_MAIN		0
>>>> +#define R8A7792_CLK_PLL0		1
>>>> +#define R8A7792_CLK_PLL1		2
>>>> +#define R8A7792_CLK_PLL3		3
>>>> +#define R8A7792_CLK_LB			4
>>>> +#define R8A7792_CLK_QSPI		5
>>>> +#define R8A7792_CLK_SDH			6
>>>> +#define R8A7792_CLK_SD0			7
>>>> +#define R8A7792_CLK_SD1			8
>>>> +#define R8A7792_CLK_Z			9
>>>
>>> According to my copy of the documentation (v2.00) SDH, SD0 and SD1 do
>>> not seem to be provided by the r8a7792 CPG.
>>
>>    I've just downloaded and opened rev2.00 manual, and still, there's no
>> CPG registers other than FRQCRB on V2H.
>>
>>> It does, however, provide RCAN and ADSP which are supported by the CPG
>>> driver. You may wish to add them now for completeness though from my point
>>> of view they could also be added later when they are used.
>>
>>    My copy of the manual says there's no ADSP on V2H, and thus no ADSP clock.
>
> I was looking at Figure 7.1c. Perhaps it is inaccurate.

    Indeed, it's the only place where the ADSP clock is mentioned for V2H, and 
it looks like this is in error. I guess I'll try to verify if there's writable 
ADSPCKCR and then remove the ADSP clock if not.

MBR, Sergei

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:09 AM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> Add macros usable by the device tree sources to reference the R8A7792
> clocks  by index.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>
> ---
>  include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
>  1 file changed, 104 insertions(+)
>
> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
> ===================================================================
> --- /dev/null
> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (C) 2016 Cogent Embedded, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
> +#define __DT_BINDINGS_CLOCK_R8A7792_H__
> +
> +/* CPG */
> +#define R8A7792_CLK_MAIN               0
> +#define R8A7792_CLK_PLL0               1
> +#define R8A7792_CLK_PLL1               2
> +#define R8A7792_CLK_PLL3               3
> +#define R8A7792_CLK_LB                 4
> +#define R8A7792_CLK_QSPI               5
> +#define R8A7792_CLK_SDH                        6
> +#define R8A7792_CLK_SD0                        7
> +#define R8A7792_CLK_SD1                        8

As Simon already pointed out, there are no ...SD* clocks on V2H.

> +#define R8A7792_CLK_Z                  9

> +/* MSTP1 */
> +#define R8A7792_CLK_TMU1               11
> +#define R8A7792_CLK_TMU3               21
> +#define R8A7792_CLK_TMU2               22
> +#define R8A7792_CLK_CMT0               24
> +#define R8A7792_CLK_TMU0               25
> +#define R8A7792_CLK_VSP1DU1            27
> +#define R8A7792_CLK_VSP1DU0            28
> +#define R8A7792_CLK_VSP1_SY            31

These are called ...VSP1_DU1, ...VSP1_DU0, and ...VSP1_S on all other
R-Car Gen2 SoCs.

> +/* MSTP2 */
> +#define R8A7792_CLK_MSIOF1             8
> +#define R8A7792_CLK_SYS_DMAC0          18

This is ...SYS_DMAC1

> +#define R8A7792_CLK_SYS_DMAC1          19

... and this is ...SYS_DMAC0

> +/* MSTP9 */
> +#define R8A7792_CLK_GPIO7              4
> +#define R8A7792_CLK_GPIO6              5
> +#define R8A7792_CLK_GPIO5              7
> +#define R8A7792_CLK_GPIO4              8
> +#define R8A7792_CLK_GPIO3              9
> +#define R8A7792_CLK_GPIO2              10
> +#define R8A7792_CLK_GPIO1              11
> +#define R8A7792_CLK_GPIO0              12
> +#define R8A7792_CLK_GPIO11             13
> +#define R8A7792_CLK_GPIO10             14
> +#define R8A7792_CLK_CAN1               15
> +#define R8A7792_CLK_CAN0               16

These are called ...RCAN1 and ...RCAR0 on all other R-Car Gen2 SoCs.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:09 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add macros usable by the device tree sources to reference the R8A7792
> clocks  by index.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
>  include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
>  1 file changed, 104 insertions(+)
>
> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
> ===================================================================
> --- /dev/null
> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (C) 2016 Cogent Embedded, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
> +#define __DT_BINDINGS_CLOCK_R8A7792_H__
> +
> +/* CPG */
> +#define R8A7792_CLK_MAIN               0
> +#define R8A7792_CLK_PLL0               1
> +#define R8A7792_CLK_PLL1               2
> +#define R8A7792_CLK_PLL3               3
> +#define R8A7792_CLK_LB                 4
> +#define R8A7792_CLK_QSPI               5
> +#define R8A7792_CLK_SDH                        6
> +#define R8A7792_CLK_SD0                        7
> +#define R8A7792_CLK_SD1                        8

As Simon already pointed out, there are no ...SD* clocks on V2H.

> +#define R8A7792_CLK_Z                  9

> +/* MSTP1 */
> +#define R8A7792_CLK_TMU1               11
> +#define R8A7792_CLK_TMU3               21
> +#define R8A7792_CLK_TMU2               22
> +#define R8A7792_CLK_CMT0               24
> +#define R8A7792_CLK_TMU0               25
> +#define R8A7792_CLK_VSP1DU1            27
> +#define R8A7792_CLK_VSP1DU0            28
> +#define R8A7792_CLK_VSP1_SY            31

These are called ...VSP1_DU1, ...VSP1_DU0, and ...VSP1_S on all other
R-Car Gen2 SoCs.

> +/* MSTP2 */
> +#define R8A7792_CLK_MSIOF1             8
> +#define R8A7792_CLK_SYS_DMAC0          18

This is ...SYS_DMAC1

> +#define R8A7792_CLK_SYS_DMAC1          19

... and this is ...SYS_DMAC0

> +/* MSTP9 */
> +#define R8A7792_CLK_GPIO7              4
> +#define R8A7792_CLK_GPIO6              5
> +#define R8A7792_CLK_GPIO5              7
> +#define R8A7792_CLK_GPIO4              8
> +#define R8A7792_CLK_GPIO3              9
> +#define R8A7792_CLK_GPIO2              10
> +#define R8A7792_CLK_GPIO1              11
> +#define R8A7792_CLK_GPIO0              12
> +#define R8A7792_CLK_GPIO11             13
> +#define R8A7792_CLK_GPIO10             14
> +#define R8A7792_CLK_CAN1               15
> +#define R8A7792_CLK_CAN0               16

These are called ...RCAN1 and ...RCAR0 on all other R-Car Gen2 SoCs.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 01/13] ARM: shmobile: r8a7792: add clock index macros

[Sergei Shtylyov]

On 06/01/2016 10:22 AM, Geert Uytterhoeven wrote:

>> Add macros usable by the device tree sources to reference the R8A7792
>> clocks  by index.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>>  include/dt-bindings/clock/r8a7792-clock.h |  104 ++++++++++++++++++++++++++++++
>>  1 file changed, 104 insertions(+)
>>
>> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
>> ===================================================================
>> --- /dev/null
>> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
>> @@ -0,0 +1,104 @@
>> +/*
>> + * Copyright (C) 2016 Cogent Embedded, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#ifndef __DT_BINDINGS_CLOCK_R8A7792_H__
>> +#define __DT_BINDINGS_CLOCK_R8A7792_H__
>> +
>> +/* CPG */
>> +#define R8A7792_CLK_MAIN               0
>> +#define R8A7792_CLK_PLL0               1
>> +#define R8A7792_CLK_PLL1               2
>> +#define R8A7792_CLK_PLL3               3
>> +#define R8A7792_CLK_LB                 4
>> +#define R8A7792_CLK_QSPI               5
>> +#define R8A7792_CLK_SDH                        6
>> +#define R8A7792_CLK_SD0                        7
>> +#define R8A7792_CLK_SD1                        8
>
> As Simon already pointed out, there are no ...SD* clocks on V2H.

    Right, looks like I shouldn't have trusted the original patch... :-/

>> +#define R8A7792_CLK_Z                  9
>
>> +/* MSTP1 */
>> +#define R8A7792_CLK_TMU1               11
>> +#define R8A7792_CLK_TMU3               21
>> +#define R8A7792_CLK_TMU2               22
>> +#define R8A7792_CLK_CMT0               24
>> +#define R8A7792_CLK_TMU0               25
>> +#define R8A7792_CLK_VSP1DU1            27
>> +#define R8A7792_CLK_VSP1DU0            28
>> +#define R8A7792_CLK_VSP1_SY            31
>
> These are called ...VSP1_DU1, ...VSP1_DU0, and ...VSP1_S on all other
> R-Car Gen2 SoCs.

    My naming comes from the 1.02 manual.

>> +/* MSTP2 */
>> +#define R8A7792_CLK_MSIOF1             8
>> +#define R8A7792_CLK_SYS_DMAC0          18
>
> This is ...SYS_DMAC1
>
>> +#define R8A7792_CLK_SYS_DMAC1          19
>
> ... and this is ...SYS_DMAC0

    Thanks for catching!

>> +/* MSTP9 */
>> +#define R8A7792_CLK_GPIO7              4
>> +#define R8A7792_CLK_GPIO6              5
>> +#define R8A7792_CLK_GPIO5              7
>> +#define R8A7792_CLK_GPIO4              8
>> +#define R8A7792_CLK_GPIO3              9
>> +#define R8A7792_CLK_GPIO2              10
>> +#define R8A7792_CLK_GPIO1              11
>> +#define R8A7792_CLK_GPIO0              12
>> +#define R8A7792_CLK_GPIO11             13
>> +#define R8A7792_CLK_GPIO10             14
>> +#define R8A7792_CLK_CAN1               15
>> +#define R8A7792_CLK_CAN0               16
>
> These are called ...RCAN1 and ...RCAR0 on all other R-Car Gen2 SoCs.

    Not in the 1.02 manual (they were called RCAN<n> in some of the earlier 
manual revs). Dunno if it makes sense to rename them in the other .dts now...

> Gr{oetje,eeting}s,
>
>                         Geert

WBR, Sergei

[PATCH 02/13] ARM: shmobile: r8a7792: add power domain index macros

[Sergei Shtylyov]

Add macros usable by the device tree sources to reference R8A7792 SYSC power
domains by index.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 include/dt-bindings/power/r8a7792-sysc.h |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

Index: renesas/include/dt-bindings/power/r8a7792-sysc.h
===================================================================
--- /dev/null
+++ renesas/include/dt-bindings/power/r8a7792-sysc.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+#ifndef __DT_BINDINGS_POWER_R8A7792_SYSC_H__
+#define __DT_BINDINGS_POWER_R8A7792_SYSC_H__
+
+/*
+ * These power domain indices match the numbers of the interrupt bits
+ * representing the power areas in the various Interrupt Registers
+ * (e.g. SYSCISR, Interrupt Status Register)
+ */
+
+#define R8A7792_PD_CA15_CPU0		0
+#define R8A7792_PD_CA15_CPU1		1
+#define R8A7792_PD_CA15_SCU		12
+#define R8A7792_PD_SGX			20
+#define R8A7792_PD_IMP			24
+
+/* Always-on power area */
+#define R8A7792_PD_ALWAYS_ON		32
+
+#endif /* __DT_BINDINGS_POWER_R8A7792_SYSC_H__ */

Re: [PATCH 02/13] ARM: shmobile: r8a7792: add power domain index macros

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:11 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add macros usable by the device tree sources to reference R8A7792 SYSC power
> domains by index.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 03/13] soc: renesas: rcar-sysc: add R8A7792 support

[Sergei Shtylyov]

Add support for R-Car V2H (R8A7792) SoC power areas to the SYSC driver.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 drivers/soc/renesas/Makefile       |    1 +
 drivers/soc/renesas/r8a7792-sysc.c |   34 ++++++++++++++++++++++++++++++++++
 drivers/soc/renesas/rcar-sysc.c    |    3 +++
 drivers/soc/renesas/rcar-sysc.h    |    1 +
 4 files changed, 39 insertions(+)

Index: renesas/drivers/soc/renesas/Makefile
===================================================================
--- renesas.orig/drivers/soc/renesas/Makefile
+++ renesas/drivers/soc/renesas/Makefile
@@ -1,6 +1,7 @@
 obj-$(CONFIG_ARCH_R8A7779)	+= rcar-sysc.o r8a7779-sysc.o
 obj-$(CONFIG_ARCH_R8A7790)	+= rcar-sysc.o r8a7790-sysc.o
 obj-$(CONFIG_ARCH_R8A7791)	+= rcar-sysc.o r8a7791-sysc.o
+obj-$(CONFIG_ARCH_R8A7792)	+= rcar-sysc.o r8a7792-sysc.o
 # R-Car M2-N is identical to R-Car M2-W w.r.t. power domains.
 obj-$(CONFIG_ARCH_R8A7793)	+= rcar-sysc.o r8a7791-sysc.o
 obj-$(CONFIG_ARCH_R8A7794)	+= rcar-sysc.o r8a7794-sysc.o
Index: renesas/drivers/soc/renesas/r8a7792-sysc.c
===================================================================
--- /dev/null
+++ renesas/drivers/soc/renesas/r8a7792-sysc.c
@@ -0,0 +1,34 @@
+/*
+ * Renesas R-Car V2H (R8A7792) System Controller
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include <linux/bug.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+
+#include <dt-bindings/power/r8a7792-sysc.h>
+
+#include "rcar-sysc.h"
+
+static const struct rcar_sysc_area r8a7792_areas[] __initconst = {
+	{ "always-on",	    0, 0, R8A7792_PD_ALWAYS_ON,	-1, PD_ALWAYS_ON },
+	{ "ca15-scu",	0x180, 0, R8A7792_PD_CA15_SCU,	R8A7792_PD_ALWAYS_ON,
+	  PD_SCU },
+	{ "ca15-cpu0",	 0x40, 0, R8A7792_PD_CA15_CPU0,	R8A7792_PD_CA15_SCU,
+	  PD_CPU_NOCR },
+	{ "ca15-cpu1",	 0x40, 1, R8A7792_PD_CA15_CPU1,	R8A7792_PD_CA15_SCU,
+	  PD_CPU_NOCR },
+	{ "sgx",	 0xc0, 0, R8A7792_PD_SGX,	R8A7792_PD_ALWAYS_ON },
+	{ "imp",	0x140, 0, R8A7792_PD_IMP,	R8A7792_PD_ALWAYS_ON },
+};
+
+const struct rcar_sysc_info r8a7792_sysc_info __initconst = {
+	.areas = r8a7792_areas,
+	.num_areas = ARRAY_SIZE(r8a7792_areas),
+};
Index: renesas/drivers/soc/renesas/rcar-sysc.c
===================================================================
--- renesas.orig/drivers/soc/renesas/rcar-sysc.c
+++ renesas/drivers/soc/renesas/rcar-sysc.c
@@ -293,6 +293,9 @@ static const struct of_device_id rcar_sy
 #ifdef CONFIG_ARCH_R8A7791
 	{ .compatible = "renesas,r8a7791-sysc", .data = &r8a7791_sysc_info },
 #endif
+#ifdef CONFIG_ARCH_R8A7792
+	{ .compatible = "renesas,r8a7792-sysc", .data = &r8a7792_sysc_info },
+#endif
 #ifdef CONFIG_ARCH_R8A7793
 	/* R-Car M2-N is identical to R-Car M2-W w.r.t. power domains. */
 	{ .compatible = "renesas,r8a7793-sysc", .data = &r8a7791_sysc_info },
Index: renesas/drivers/soc/renesas/rcar-sysc.h
===================================================================
--- renesas.orig/drivers/soc/renesas/rcar-sysc.h
+++ renesas/drivers/soc/renesas/rcar-sysc.h
@@ -53,6 +53,7 @@ struct rcar_sysc_info {
 extern const struct rcar_sysc_info r8a7779_sysc_info;
 extern const struct rcar_sysc_info r8a7790_sysc_info;
 extern const struct rcar_sysc_info r8a7791_sysc_info;
+extern const struct rcar_sysc_info r8a7792_sysc_info;
 extern const struct rcar_sysc_info r8a7794_sysc_info;
 extern const struct rcar_sysc_info r8a7795_sysc_info;
 #endif /* __SOC_RENESAS_RCAR_SYSC_H__ */

Re: [PATCH 03/13] soc: renesas: rcar-sysc: add R8A7792 support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:15 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add support for R-Car V2H (R8A7792) SoC power areas to the SYSC driver.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Sergei Shtylyov]

Add minimal support for the R-Car V2H (R8A7792) SoC.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/mach-shmobile/Kconfig         |    5 ++++
 arch/arm/mach-shmobile/Makefile        |    1 
 arch/arm/mach-shmobile/setup-r8a7792.c |   34 +++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -86,6 +86,11 @@ config ARCH_R8A7791
 	select ARCH_RCAR_GEN2
 	select I2C
 
+config ARCH_R8A7792
+	bool "R-Car V2H (R8A77920)"
+	select ARCH_RCAR_GEN2
+	select I2C
+
 config ARCH_R8A7793
 	bool "R-Car M2-N (R8A7793)"
 	select ARCH_RCAR_GEN2
Index: renesas/arch/arm/mach-shmobile/Makefile
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Makefile
+++ renesas/arch/arm/mach-shmobile/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7
 obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o pm-r8a7779.o
 obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o
 obj-$(CONFIG_ARCH_R8A7791)	+= setup-r8a7791.o
+obj-$(CONFIG_ARCH_R8A7792)	+= setup-r8a7792.o
 obj-$(CONFIG_ARCH_R8A7793)	+= setup-r8a7793.o
 obj-$(CONFIG_ARCH_R8A7794)	+= setup-r8a7794.o
 obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o
Index: renesas/arch/arm/mach-shmobile/setup-r8a7792.c
===================================================================
--- /dev/null
+++ renesas/arch/arm/mach-shmobile/setup-r8a7792.c
@@ -0,0 +1,34 @@
+/*
+ * r8a7792 processor support
+ *
+ * Copyright (C) 2014  Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/of_platform.h>
+
+#include <asm/mach/arch.h>
+
+#include "common.h"
+#include "rcar-gen2.h"
+
+static const char * const r8a7792_boards_compat_dt[] __initconst = {
+	"renesas,r8a7792",
+	NULL,
+};
+
+DT_MACHINE_START(R8A7792_DT, "Generic R8A7792 (Flattened Device Tree)")
+	.init_early	= shmobile_init_delay,
+	.init_late	= shmobile_init_late,
+	.init_time	= rcar_gen2_timer_init,
+	.reserve	= rcar_gen2_reserve,
+	.dt_compat	= r8a7792_boards_compat_dt,
+MACHINE_END

[PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Sergei Shtylyov]

Add minimal support for the R-Car V2H (R8A7792) SoC.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/mach-shmobile/Kconfig         |    5 ++++
 arch/arm/mach-shmobile/Makefile        |    1 
 arch/arm/mach-shmobile/setup-r8a7792.c |   34 +++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+)

Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -86,6 +86,11 @@ config ARCH_R8A7791
 	select ARCH_RCAR_GEN2
 	select I2C
 
+config ARCH_R8A7792
+	bool "R-Car V2H (R8A77920)"
+	select ARCH_RCAR_GEN2
+	select I2C
+
 config ARCH_R8A7793
 	bool "R-Car M2-N (R8A7793)"
 	select ARCH_RCAR_GEN2
Index: renesas/arch/arm/mach-shmobile/Makefile
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Makefile
+++ renesas/arch/arm/mach-shmobile/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7
 obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o pm-r8a7779.o
 obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o
 obj-$(CONFIG_ARCH_R8A7791)	+= setup-r8a7791.o
+obj-$(CONFIG_ARCH_R8A7792)	+= setup-r8a7792.o
 obj-$(CONFIG_ARCH_R8A7793)	+= setup-r8a7793.o
 obj-$(CONFIG_ARCH_R8A7794)	+= setup-r8a7794.o
 obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o
Index: renesas/arch/arm/mach-shmobile/setup-r8a7792.c
===================================================================
--- /dev/null
+++ renesas/arch/arm/mach-shmobile/setup-r8a7792.c
@@ -0,0 +1,34 @@
+/*
+ * r8a7792 processor support
+ *
+ * Copyright (C) 2014  Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/of_platform.h>
+
+#include <asm/mach/arch.h>
+
+#include "common.h"
+#include "rcar-gen2.h"
+
+static const char * const r8a7792_boards_compat_dt[] __initconst = {
+	"renesas,r8a7792",
+	NULL,
+};
+
+DT_MACHINE_START(R8A7792_DT, "Generic R8A7792 (Flattened Device Tree)")
+	.init_early	= shmobile_init_delay,
+	.init_late	= shmobile_init_late,
+	.init_time	= rcar_gen2_timer_init,
+	.reserve	= rcar_gen2_reserve,
+	.dt_compat	= r8a7792_boards_compat_dt,
+MACHINE_END

Re: [PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:18:22AM +0300, Sergei Shtylyov wrote:
> Add minimal support for the R-Car V2H (R8A7792) SoC.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

[PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:18:22AM +0300, Sergei Shtylyov wrote:
> Add minimal support for the R-Car V2H (R8A7792) SoC.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

Re: [PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:18 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> --- renesas.orig/arch/arm/mach-shmobile/Kconfig
> +++ renesas/arch/arm/mach-shmobile/Kconfig
> @@ -86,6 +86,11 @@ config ARCH_R8A7791
>         select ARCH_RCAR_GEN2
>         select I2C
>
> +config ARCH_R8A7792
> +       bool "R-Car V2H (R8A77920)"
> +       select ARCH_RCAR_GEN2
> +       select I2C

I2c is selected for the other SoCs because of regulator-quirk-rcar-gen2.
I do not have schematics for Blanche, so I don't know if it has DA9063 and
DA9210 regulators sharing the same interrupt.
If yes, you should make sure regulator-quirk-rcar-gen2 is updated for Blanche,
and built.
If no, you should drop the select.

If the above is clarified:

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:18 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> --- renesas.orig/arch/arm/mach-shmobile/Kconfig
> +++ renesas/arch/arm/mach-shmobile/Kconfig
> @@ -86,6 +86,11 @@ config ARCH_R8A7791
>         select ARCH_RCAR_GEN2
>         select I2C
>
> +config ARCH_R8A7792
> +       bool "R-Car V2H (R8A77920)"
> +       select ARCH_RCAR_GEN2
> +       select I2C

I2c is selected for the other SoCs because of regulator-quirk-rcar-gen2.
I do not have schematics for Blanche, so I don't know if it has DA9063 and
DA9210 regulators sharing the same interrupt.
If yes, you should make sure regulator-quirk-rcar-gen2 is updated for Blanche,
and built.
If no, you should drop the select.

If the above is clarified:

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Sergei Shtylyov]

On 06/01/2016 10:47 AM, Geert Uytterhoeven wrote:

>> --- renesas.orig/arch/arm/mach-shmobile/Kconfig
>> +++ renesas/arch/arm/mach-shmobile/Kconfig
>> @@ -86,6 +86,11 @@ config ARCH_R8A7791
>>         select ARCH_RCAR_GEN2
>>         select I2C
>>
>> +config ARCH_R8A7792
>> +       bool "R-Car V2H (R8A77920)"
>> +       select ARCH_RCAR_GEN2
>> +       select I2C
>
> I2c is selected for the other SoCs because of regulator-quirk-rcar-gen2.
> I do not have schematics for Blanche, so I don't know if it has DA9063 and
> DA9210 regulators sharing the same interrupt.

    No, it only has DA9063.

> If yes, you should make sure regulator-quirk-rcar-gen2 is updated for Blanche,
> and built.
> If no, you should drop the select.

    Thanks for noticing!

> If the above is clarified:

> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

    Thank you, adding...

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Sergei Shtylyov]

On 06/01/2016 10:47 AM, Geert Uytterhoeven wrote:

>> --- renesas.orig/arch/arm/mach-shmobile/Kconfig
>> +++ renesas/arch/arm/mach-shmobile/Kconfig
>> @@ -86,6 +86,11 @@ config ARCH_R8A7791
>>         select ARCH_RCAR_GEN2
>>         select I2C
>>
>> +config ARCH_R8A7792
>> +       bool "R-Car V2H (R8A77920)"
>> +       select ARCH_RCAR_GEN2
>> +       select I2C
>
> I2c is selected for the other SoCs because of regulator-quirk-rcar-gen2.
> I do not have schematics for Blanche, so I don't know if it has DA9063 and
> DA9210 regulators sharing the same interrupt.

    No, it only has DA9063.

> If yes, you should make sure regulator-quirk-rcar-gen2 is updated for Blanche,
> and built.
> If no, you should drop the select.

    Thanks for noticing!

> If the above is clarified:

> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

    Thank you, adding...

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

Re: [PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Sergei Shtylyov]

Hello.

On 06/01/2016 01:18 AM, Sergei Shtylyov wrote:

> Add minimal support for the R-Car V2H (R8A7792) SoC.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
[...]

> Index: renesas/arch/arm/mach-shmobile/setup-r8a7792.c
> ===================================================================
> --- /dev/null
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7792.c
> @@ -0,0 +1,34 @@
> +/*
> + * r8a7792 processor support
> + *
> + * Copyright (C) 2014  Renesas Electronics Corporation

    Hm, I thought I'd stamped Cogent's copyright here... Please hold on with 
merging this patch.

[...]

MBR, Sergei

[PATCH 04/13] ARM: shmobile: r8a7792: basic SoC support

[Sergei Shtylyov]

Hello.

On 06/01/2016 01:18 AM, Sergei Shtylyov wrote:

> Add minimal support for the R-Car V2H (R8A7792) SoC.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
[...]

> Index: renesas/arch/arm/mach-shmobile/setup-r8a7792.c
> ===================================================================
> --- /dev/null
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7792.c
> @@ -0,0 +1,34 @@
> +/*
> + * r8a7792 processor support
> + *
> + * Copyright (C) 2014  Renesas Electronics Corporation

    Hm, I thought I'd stamped Cogent's copyright here... Please hold on with 
merging this patch.

[...]

MBR, Sergei

[PATCH 05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support

[Sergei Shtylyov]

Renesas R8A7792 SoC is a member of the R-Car gen2 family and so has CPG...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt |    1 +
 1 file changed, 1 insertion(+)

Index: renesas/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
===================================================================
--- renesas.orig/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
+++ renesas/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
@@ -10,6 +10,7 @@ Required Properties:
   - compatible: Must be one of
     - "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
     - "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
+    - "renesas,r8a7792-cpg-clocks" for the r8a7792 CPG
     - "renesas,r8a7793-cpg-clocks" for the r8a7793 CPG
     - "renesas,r8a7794-cpg-clocks" for the r8a7794 CPG
     and "renesas,rcar-gen2-cpg-clocks" as a fallback.

Re: [PATCH 05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support

[Simon Horman]

[Cc: Geert]

On Wed, Jun 01, 2016 at 01:20:11AM +0300, Sergei Shtylyov wrote:
> Renesas R8A7792 SoC is a member of the R-Car gen2 family and so has CPG...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Hi Sergei,

I think the prefix of this patch should be "clk: shmobile: rcar-gen2: "

Hi Geert,

I apologise if I have missed a discussion of this topic or if my analysis
is wrong for some reason but I am curious to know what the intended way
is for the rcar-gen2 CPG driver to handle differences in the availability
of clocks across different SoCs.

My possibly naïve expectation is that the implementation would use compat
strings. But as it stands it appears that all clocks supported by the
driver are available for all SoCs. This does not seem to reflect the
documentation (v2.00).

FWIW my quick analysis of clocks supported by the driver present in
renesas-drivers-2016-05-31-v4.7-rc1 but not present on one or more SoCs
is as follows:

Not present on V2H: sdh, sd0
Not present on V2H or E2: sd1
Not present on H2, M2-W, M2-N, E2: rcan

> 
> ---
>  Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt |    1 +
>  1 file changed, 1 insertion(+)
> 
> Index: renesas/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> ===================================================================
> --- renesas.orig/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> +++ renesas/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> @@ -10,6 +10,7 @@ Required Properties:
>    - compatible: Must be one of
>      - "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
>      - "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
> +    - "renesas,r8a7792-cpg-clocks" for the r8a7792 CPG
>      - "renesas,r8a7793-cpg-clocks" for the r8a7793 CPG
>      - "renesas,r8a7794-cpg-clocks" for the r8a7794 CPG
>      and "renesas,rcar-gen2-cpg-clocks" as a fallback.
> 

Re: [PATCH 05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support

[Simon Horman]

On Wed, Jun 01, 2016 at 09:25:35AM +0900, Simon Horman wrote:
> [Cc: Geert]
> 
> On Wed, Jun 01, 2016 at 01:20:11AM +0300, Sergei Shtylyov wrote:
> > Renesas R8A7792 SoC is a member of the R-Car gen2 family and so has CPG...
> > 
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> Hi Sergei,
> 
> I think the prefix of this patch should be "clk: shmobile: rcar-gen2: "
> 
> Hi Geert,
> 
> I apologise if I have missed a discussion of this topic or if my analysis
> is wrong for some reason but I am curious to know what the intended way
> is for the rcar-gen2 CPG driver to handle differences in the availability
> of clocks across different SoCs.
> 
> My possibly naïve expectation is that the implementation would use compat
> strings. But as it stands it appears that all clocks supported by the
> driver are available for all SoCs. This does not seem to reflect the
> documentation (v2.00).
> 
> FWIW my quick analysis of clocks supported by the driver present in
> renesas-drivers-2016-05-31-v4.7-rc1 but not present on one or more SoCs
> is as follows:
> 
> Not present on V2H: sdh, sd0
> Not present on V2H or E2: sd1
> Not present on H2, M2-W, M2-N, E2: rcan

Thinking about a little more, which I obviously should have done
before hitting send:

There does not seem to be any conflict in the implementation of individual
clocks between SoCs at least so far as clocks supported by the driver goes.
Its just that some of them aren't present on all SoCs. But in that case
they shouldn't be used in DT: the DT describes the HW. So I think I'm ok
with this patch. Sorry for the noise!

Acked-by: Simon Horman <horms+renesas@verge.net.au>

> > ---
> >  Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > Index: renesas/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> > ===================================================================
> > --- renesas.orig/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> > +++ renesas/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> > @@ -10,6 +10,7 @@ Required Properties:
> >    - compatible: Must be one of
> >      - "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
> >      - "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
> > +    - "renesas,r8a7792-cpg-clocks" for the r8a7792 CPG
> >      - "renesas,r8a7793-cpg-clocks" for the r8a7793 CPG
> >      - "renesas,r8a7794-cpg-clocks" for the r8a7794 CPG
> >      and "renesas,rcar-gen2-cpg-clocks" as a fallback.
> > 
> 

Re: [PATCH 05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support

[Geert Uytterhoeven]

Hi Simon,

On Wed, Jun 1, 2016 at 2:25 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Jun 01, 2016 at 01:20:11AM +0300, Sergei Shtylyov wrote:
>> Renesas R8A7792 SoC is a member of the R-Car gen2 family and so has CPG...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> I think the prefix of this patch should be "clk: shmobile: rcar-gen2: "

Almost, "clk: renesas: rcar-gen: " ;-)

> I apologise if I have missed a discussion of this topic or if my analysis
> is wrong for some reason but I am curious to know what the intended way
> is for the rcar-gen2 CPG driver to handle differences in the availability
> of clocks across different SoCs.
>
> My possibly naïve expectation is that the implementation would use compat
> strings. But as it stands it appears that all clocks supported by the
> driver are available for all SoCs. This does not seem to reflect the
> documentation (v2.00).

Differentiaton is not done using compat strings, but using clock-output-names.
The driver only instantiates the clocks that are listed there.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:20 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Renesas R8A7792 SoC is a member of the R-Car gen2 family and so has CPG...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support

[Rob Herring]

On Wed, Jun 01, 2016 at 01:20:11AM +0300, Sergei Shtylyov wrote:
> Renesas R8A7792 SoC is a member of the R-Car gen2 family and so has CPG...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> ---
>  Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt |    1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh@kernel.org>

[PATCH 06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support

[Sergei Shtylyov]

Renesas R8A7792 SoC also has the CPG MSTP clocks...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt |    1 +
 1 file changed, 1 insertion(+)

Index: renesas/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
===================================================================
--- renesas.orig/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
+++ renesas/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
@@ -17,6 +17,7 @@ Required Properties:
     - "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks
     - "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks
     - "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2-W) MSTP gate clocks
+    - "renesas,r8a7792-mstp-clocks" for R8A7792 (R-Car V2H) MSTP gate clocks
     - "renesas,r8a7793-mstp-clocks" for R8A7793 (R-Car M2-N) MSTP gate clocks
     - "renesas,r8a7794-mstp-clocks" for R8A7794 (R-Car E2) MSTP gate clocks
     - "renesas,sh73a0-mstp-clocks" for SH73A0 (SH-MobileAG5) MSTP gate clocks

Re: [PATCH 06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:21:26AM +0300, Sergei Shtylyov wrote:
> Renesas R8A7792 SoC also has the CPG MSTP clocks...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

I think the prefix of this patch should be "clk: shmobile: mstp: "

With that change feel free to add:

Acked-by: Simon Horman <horms+renesas@verge.net.au>

> ---
>  Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt |    1 +
>  1 file changed, 1 insertion(+)
> 
> Index: renesas/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
> ===================================================================
> --- renesas.orig/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
> +++ renesas/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
> @@ -17,6 +17,7 @@ Required Properties:
>      - "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks
>      - "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks
>      - "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2-W) MSTP gate clocks
> +    - "renesas,r8a7792-mstp-clocks" for R8A7792 (R-Car V2H) MSTP gate clocks
>      - "renesas,r8a7793-mstp-clocks" for R8A7793 (R-Car M2-N) MSTP gate clocks
>      - "renesas,r8a7794-mstp-clocks" for R8A7794 (R-Car E2) MSTP gate clocks
>      - "renesas,sh73a0-mstp-clocks" for SH73A0 (SH-MobileAG5) MSTP gate clocks
> 

Re: [PATCH 06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:21 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Renesas R8A7792 SoC also has the CPG MSTP clocks...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

If you use "clk: renesas: smtp: ..."

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support

[Rob Herring]

On Wed, Jun 01, 2016 at 01:21:26AM +0300, Sergei Shtylyov wrote:
> Renesas R8A7792 SoC also has the CPG MSTP clocks...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> ---
>  Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt |    1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh@kernel.org>

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
and the required  clock descriptions.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792.dtsi |  423 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 423 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -0,0 +1,423 @@
+/*
+ * Device Tree Source for the r8a7792 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/clock/r8a7792-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/power/r8a7792-sysc.h>
+
+/ {
+	compatible = "renesas,r8a7792";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+			clock-frequency = <1000000000>;
+			clocks = <&cpg_clocks R8A7792_CLK_Z>;
+			power-domains = <&sysc R8A7792_PD_CA15_CPU0>;
+			next-level-cache = <&L2_CA15>;
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <1>;
+			clock-frequency = <1000000000>;
+			power-domains = <&sysc R8A7792_PD_CA15_CPU1>;
+			next-level-cache = <&L2_CA15>;
+		};
+
+		L2_CA15: cache-controller@0 {
+			compatible = "cache";
+			reg = <0>;
+			cache-unified;
+			cache-level = <2>;
+			power-domains = <&sysc R8A7792_PD_CA15_SCU>;
+		};
+	};
+
+	gic: interrupt-controller@f1001000 {
+		compatible = "arm,gic-400";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0 0xf1001000 0 0x1000>,
+		      <0 0xf1002000 0 0x1000>,
+		      <0 0xf1004000 0 0x2000>,
+		      <0 0xf1006000 0 0x2000>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
+			      IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <GIC_PPI 13
+			      (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14
+			      (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11
+			      (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10
+			      (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	sysc: system-controller@e6180000 {
+		compatible = "renesas,r8a7792-sysc";
+		reg = <0 0xe6180000 0 0x0200>;
+		#power-domain-cells = <1>;
+	};
+
+	clocks {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/* External root clock */
+		extal_clk: extal {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+		};
+
+		/* External PCIe clock - can be overridden by the board */
+		pcie_bus_clk: pcie_bus {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+		};
+
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+		};
+
+		/*
+		 * The external audio clocks are configured as 0 Hz fixed
+		 * frequency clocks by default.  Boards that provide audio
+		 * clocks should override them.
+		 */
+		audio_clka: audio_clka {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+		};
+		audio_clkb: audio_clkb {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+		};
+		audio_clkc: audio_clkc {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+		};
+
+		/* Special CPG clocks */
+		cpg_clocks: cpg_clocks@e6150000 {
+			compatible = "renesas,r8a7792-cpg-clocks",
+				     "renesas,rcar-gen2-cpg-clocks";
+			reg = <0 0xe6150000 0 0x1000>;
+			clocks = <&extal_clk>;
+			#clock-cells = <1>;
+			clock-output-names = "main", "pll0", "pll1", "pll3",
+					     "lb", "qspi", "sdh", "sd0", "sd1",
+					     "z";
+			#power-domain-cells = <0>;
+		};
+
+		/* Fixed factor clocks */
+		pll1_div2_clk: pll1_div2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
+		z2_clk: z2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
+		zg_clk: zg {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <3>;
+			clock-mult = <1>;
+		};
+		zx_clk: zx {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <3>;
+			clock-mult = <1>;
+		};
+		zs_clk: zs {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <6>;
+			clock-mult = <1>;
+		};
+		hp_clk: hp {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <12>;
+			clock-mult = <1>;
+		};
+		i_clk: i {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
+		b_clk: b {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <12>;
+			clock-mult = <1>;
+		};
+		p_clk: p {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <24>;
+			clock-mult = <1>;
+		};
+		cl_clk: cl {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <48>;
+			clock-mult = <1>;
+		};
+		m2_clk: m2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+		rclk_clk: rclk {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <(48 * 1024)>;
+			clock-mult = <1>;
+		};
+		oscclk_clk: oscclk {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <(12 * 1024)>;
+			clock-mult = <1>;
+		};
+		zb3_clk: zb3 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL3>;
+			#clock-cells = <0>;
+			clock-div = <4>;
+			clock-mult = <1>;
+		};
+		zb3d2_clk: zb3d2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL3>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+		ddr_clk: ddr {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL3>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+		mp_clk: mp {
+			compatible = "fixed-factor-clock";
+			clocks = <&pll1_div2_clk>;
+			#clock-cells = <0>;
+			clock-div = <15>;
+			clock-mult = <1>;
+		};
+		cp_clk: cp {
+			compatible = "fixed-factor-clock";
+			clocks = <&extal_clk>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
+
+		/* Gate clocks */
+		mstp0_clks: mstp0_clks@e6150130 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150130 0 4>, <0 0xe6150030 0 4>;
+			clocks = <&mp_clk>;
+			#clock-cells = <1>;
+			clock-indices = <R8A7792_CLK_MSIOF0>;
+			clock-output-names = "msiof0";
+		};
+		mstp1_clks: mstp1_clks@e6150134 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150134 0 4>, <0 0xe6150038 0 4>;
+			clocks = <&p_clk>, <&p_clk>, <&p_clk>, <&rclk_clk>,
+				 <&cp_clk>, <&zs_clk>, <&zs_clk>, <&zs_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_TMU1 R8A7792_CLK_TMU3
+				R8A7792_CLK_TMU2 R8A7792_CLK_CMT0
+				R8A7792_CLK_TMU0 R8A7792_CLK_VSP1DU1
+				R8A7792_CLK_VSP1DU0 R8A7792_CLK_VSP1_SY
+			>;
+			clock-output-names = "tmu1", "tmu3", "tmu2", "cmt0",
+					     "tmu0", "vsp1du1", "vsp1du0",
+					     "vsp1-sy";
+		};
+		mstp2_clks: mstp2_clks@e6150138 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150138 0 4>, <0 0xe6150040 0 4>;
+			clocks = <&mp_clk>, <&zs_clk>, <&zs_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_MSIOF1
+				R8A7792_CLK_SYS_DMAC0 R8A7792_CLK_SYS_DMAC1
+			>;
+			clock-output-names = "msiof1", "sys-dmac0", "sys-dmac1";
+		};
+		mstp3_clks: mstp3_clks@e615013c {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>;
+			clocks = <&cp_clk>, <&cpg_clocks R8A7792_CLK_SD0>,
+				 <&rclk_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_TPU0 R8A7792_CLK_SDHI0
+				R8A7792_CLK_CMT1
+			>;
+			clock-output-names = "tpu0", "sdhi0", "cmt1";
+		};
+		mstp4_clks: mstp4_clks@e6150140 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150140 0 4>, <0 0xe615004c 0 4>;
+			clocks = <&cp_clk>;
+			#clock-cells = <1>;
+			clock-indices = <R8A7792_CLK_IRQC>;
+			clock-output-names = "irqc";
+		};
+		mstp5_clks: mstp5_clks@e6150144 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>;
+			clocks = <&hp_clk>, <&extal_clk>, <&p_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_AUDIO_DMAC0
+				R8A7792_CLK_THERMAL R8A7792_CLK_PWM
+			>;
+			clock-output-names = "thermal", "pwm", "audmac0";
+		};
+		mstp7_clks: mstp7_clks@e615014c {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>;
+			clocks = <&zs_clk>, <&zs_clk>, <&p_clk>, <&p_clk>,
+				 <&p_clk>, <&p_clk>, <&zx_clk>, <&zx_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_HSCIF1 R8A7792_CLK_HSCIF0
+				R8A7792_CLK_SCIF3 R8A7792_CLK_SCIF2
+				R8A7792_CLK_SCIF1 R8A7792_CLK_SCIF0
+				R8A7792_CLK_DU1 R8A7792_CLK_DU0
+			>;
+			clock-output-names = "hscif1", "hscif0", "scif3",
+					     "scif2", "scif1", "scif0",
+					     "du1", "du0";
+		};
+		mstp8_clks: mstp8_clks@e6150990 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
+			clocks = <&zg_clk>, <&zg_clk>, <&zg_clk>, <&zg_clk>,
+				 <&zg_clk>, <&zg_clk>, <&hp_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_VIN5 R8A7792_CLK_VIN4
+				R8A7792_CLK_VIN3 R8A7792_CLK_VIN2
+				R8A7792_CLK_VIN1 R8A7792_CLK_VIN0
+				R8A7792_CLK_ETHERAVB
+			>;
+			clock-output-names = "vin5", "vin4", "vin3", "vin2",
+					     "vin1", "vin0", "etheravb";
+		};
+		mstp9_clks: mstp9_clks@e6150994 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>;
+			clocks = <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
+				 <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
+				 <&cp_clk>, <&cp_clk>, <&p_clk>, <&p_clk>,
+				 <&cpg_clocks R8A7792_CLK_QSPI>, <&cp_clk>,
+				 <&cp_clk>, <&hp_clk>, <&cp_clk>, <&hp_clk>,
+				 <&hp_clk>, <&hp_clk>, <&hp_clk>, <&hp_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_GPIO7 R8A7792_CLK_GPIO6
+				R8A7792_CLK_GPIO5 R8A7792_CLK_GPIO4
+				R8A7792_CLK_GPIO3 R8A7792_CLK_GPIO2
+				R8A7792_CLK_GPIO1 R8A7792_CLK_GPIO0
+				R8A7792_CLK_GPIO11 R8A7792_CLK_GPIO10
+				R8A7792_CLK_CAN1 R8A7792_CLK_CAN0
+				R8A7792_CLK_QSPI_MOD R8A7792_CLK_GPIO9
+				R8A7792_CLK_GPIO8 R8A7792_CLK_I2C5
+				R8A7792_CLK_IICDVFS R8A7792_CLK_I2C4
+				R8A7792_CLK_I2C3 R8A7792_CLK_I2C2
+				R8A7792_CLK_I2C1 R8A7792_CLK_I2C0
+			>;
+			clock-output-names = "gpio7", "gpio6", "gpio5", "gpio4",
+					     "gpio3", "gpio2", "gpio1", "gpio0",
+					     "gpio11", "gpio10", "can1", "can0",
+					     "qspi_mod", "gpio9", "gpio8",
+					     "i2c5", "iic3", "i2c4", "i2c3",
+					     "i2c2", "i2c1", "i2c0";
+		};
+		mstp10_clks: mstp10_clks@e6150998 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
+			clocks = <&p_clk>, <&p_clk>, <&p_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_SSI_ALL
+				R8A7792_CLK_SSI4 R8A7792_CLK_SSI3
+			>;
+			clock-output-names = "ssi", "ssi4", "ssi3";
+		};
+	};
+};

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
and the required  clock descriptions.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792.dtsi |  423 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 423 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -0,0 +1,423 @@
+/*
+ * Device Tree Source for the r8a7792 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/clock/r8a7792-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/power/r8a7792-sysc.h>
+
+/ {
+	compatible = "renesas,r8a7792";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+			clock-frequency = <1000000000>;
+			clocks = <&cpg_clocks R8A7792_CLK_Z>;
+			power-domains = <&sysc R8A7792_PD_CA15_CPU0>;
+			next-level-cache = <&L2_CA15>;
+		};
+
+		cpu1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <1>;
+			clock-frequency = <1000000000>;
+			power-domains = <&sysc R8A7792_PD_CA15_CPU1>;
+			next-level-cache = <&L2_CA15>;
+		};
+
+		L2_CA15: cache-controller at 0 {
+			compatible = "cache";
+			reg = <0>;
+			cache-unified;
+			cache-level = <2>;
+			power-domains = <&sysc R8A7792_PD_CA15_SCU>;
+		};
+	};
+
+	gic: interrupt-controller at f1001000 {
+		compatible = "arm,gic-400";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0 0xf1001000 0 0x1000>,
+		      <0 0xf1002000 0 0x1000>,
+		      <0 0xf1004000 0 0x2000>,
+		      <0 0xf1006000 0 0x2000>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
+			      IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <GIC_PPI 13
+			      (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14
+			      (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11
+			      (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10
+			      (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	sysc: system-controller at e6180000 {
+		compatible = "renesas,r8a7792-sysc";
+		reg = <0 0xe6180000 0 0x0200>;
+		#power-domain-cells = <1>;
+	};
+
+	clocks {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/* External root clock */
+		extal_clk: extal {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+		};
+
+		/* External PCIe clock - can be overridden by the board */
+		pcie_bus_clk: pcie_bus {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+		};
+
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+		};
+
+		/*
+		 * The external audio clocks are configured as 0 Hz fixed
+		 * frequency clocks by default.  Boards that provide audio
+		 * clocks should override them.
+		 */
+		audio_clka: audio_clka {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+		};
+		audio_clkb: audio_clkb {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+		};
+		audio_clkc: audio_clkc {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+		};
+
+		/* Special CPG clocks */
+		cpg_clocks: cpg_clocks at e6150000 {
+			compatible = "renesas,r8a7792-cpg-clocks",
+				     "renesas,rcar-gen2-cpg-clocks";
+			reg = <0 0xe6150000 0 0x1000>;
+			clocks = <&extal_clk>;
+			#clock-cells = <1>;
+			clock-output-names = "main", "pll0", "pll1", "pll3",
+					     "lb", "qspi", "sdh", "sd0", "sd1",
+					     "z";
+			#power-domain-cells = <0>;
+		};
+
+		/* Fixed factor clocks */
+		pll1_div2_clk: pll1_div2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
+		z2_clk: z2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
+		zg_clk: zg {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <3>;
+			clock-mult = <1>;
+		};
+		zx_clk: zx {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <3>;
+			clock-mult = <1>;
+		};
+		zs_clk: zs {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <6>;
+			clock-mult = <1>;
+		};
+		hp_clk: hp {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <12>;
+			clock-mult = <1>;
+		};
+		i_clk: i {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
+		b_clk: b {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <12>;
+			clock-mult = <1>;
+		};
+		p_clk: p {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <24>;
+			clock-mult = <1>;
+		};
+		cl_clk: cl {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <48>;
+			clock-mult = <1>;
+		};
+		m2_clk: m2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+		rclk_clk: rclk {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <(48 * 1024)>;
+			clock-mult = <1>;
+		};
+		oscclk_clk: oscclk {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <(12 * 1024)>;
+			clock-mult = <1>;
+		};
+		zb3_clk: zb3 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL3>;
+			#clock-cells = <0>;
+			clock-div = <4>;
+			clock-mult = <1>;
+		};
+		zb3d2_clk: zb3d2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL3>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+		ddr_clk: ddr {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL3>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+		mp_clk: mp {
+			compatible = "fixed-factor-clock";
+			clocks = <&pll1_div2_clk>;
+			#clock-cells = <0>;
+			clock-div = <15>;
+			clock-mult = <1>;
+		};
+		cp_clk: cp {
+			compatible = "fixed-factor-clock";
+			clocks = <&extal_clk>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
+
+		/* Gate clocks */
+		mstp0_clks: mstp0_clks at e6150130 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150130 0 4>, <0 0xe6150030 0 4>;
+			clocks = <&mp_clk>;
+			#clock-cells = <1>;
+			clock-indices = <R8A7792_CLK_MSIOF0>;
+			clock-output-names = "msiof0";
+		};
+		mstp1_clks: mstp1_clks at e6150134 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150134 0 4>, <0 0xe6150038 0 4>;
+			clocks = <&p_clk>, <&p_clk>, <&p_clk>, <&rclk_clk>,
+				 <&cp_clk>, <&zs_clk>, <&zs_clk>, <&zs_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_TMU1 R8A7792_CLK_TMU3
+				R8A7792_CLK_TMU2 R8A7792_CLK_CMT0
+				R8A7792_CLK_TMU0 R8A7792_CLK_VSP1DU1
+				R8A7792_CLK_VSP1DU0 R8A7792_CLK_VSP1_SY
+			>;
+			clock-output-names = "tmu1", "tmu3", "tmu2", "cmt0",
+					     "tmu0", "vsp1du1", "vsp1du0",
+					     "vsp1-sy";
+		};
+		mstp2_clks: mstp2_clks at e6150138 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150138 0 4>, <0 0xe6150040 0 4>;
+			clocks = <&mp_clk>, <&zs_clk>, <&zs_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_MSIOF1
+				R8A7792_CLK_SYS_DMAC0 R8A7792_CLK_SYS_DMAC1
+			>;
+			clock-output-names = "msiof1", "sys-dmac0", "sys-dmac1";
+		};
+		mstp3_clks: mstp3_clks at e615013c {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>;
+			clocks = <&cp_clk>, <&cpg_clocks R8A7792_CLK_SD0>,
+				 <&rclk_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_TPU0 R8A7792_CLK_SDHI0
+				R8A7792_CLK_CMT1
+			>;
+			clock-output-names = "tpu0", "sdhi0", "cmt1";
+		};
+		mstp4_clks: mstp4_clks at e6150140 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150140 0 4>, <0 0xe615004c 0 4>;
+			clocks = <&cp_clk>;
+			#clock-cells = <1>;
+			clock-indices = <R8A7792_CLK_IRQC>;
+			clock-output-names = "irqc";
+		};
+		mstp5_clks: mstp5_clks at e6150144 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>;
+			clocks = <&hp_clk>, <&extal_clk>, <&p_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_AUDIO_DMAC0
+				R8A7792_CLK_THERMAL R8A7792_CLK_PWM
+			>;
+			clock-output-names = "thermal", "pwm", "audmac0";
+		};
+		mstp7_clks: mstp7_clks at e615014c {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>;
+			clocks = <&zs_clk>, <&zs_clk>, <&p_clk>, <&p_clk>,
+				 <&p_clk>, <&p_clk>, <&zx_clk>, <&zx_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_HSCIF1 R8A7792_CLK_HSCIF0
+				R8A7792_CLK_SCIF3 R8A7792_CLK_SCIF2
+				R8A7792_CLK_SCIF1 R8A7792_CLK_SCIF0
+				R8A7792_CLK_DU1 R8A7792_CLK_DU0
+			>;
+			clock-output-names = "hscif1", "hscif0", "scif3",
+					     "scif2", "scif1", "scif0",
+					     "du1", "du0";
+		};
+		mstp8_clks: mstp8_clks at e6150990 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
+			clocks = <&zg_clk>, <&zg_clk>, <&zg_clk>, <&zg_clk>,
+				 <&zg_clk>, <&zg_clk>, <&hp_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_VIN5 R8A7792_CLK_VIN4
+				R8A7792_CLK_VIN3 R8A7792_CLK_VIN2
+				R8A7792_CLK_VIN1 R8A7792_CLK_VIN0
+				R8A7792_CLK_ETHERAVB
+			>;
+			clock-output-names = "vin5", "vin4", "vin3", "vin2",
+					     "vin1", "vin0", "etheravb";
+		};
+		mstp9_clks: mstp9_clks at e6150994 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>;
+			clocks = <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
+				 <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
+				 <&cp_clk>, <&cp_clk>, <&p_clk>, <&p_clk>,
+				 <&cpg_clocks R8A7792_CLK_QSPI>, <&cp_clk>,
+				 <&cp_clk>, <&hp_clk>, <&cp_clk>, <&hp_clk>,
+				 <&hp_clk>, <&hp_clk>, <&hp_clk>, <&hp_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_GPIO7 R8A7792_CLK_GPIO6
+				R8A7792_CLK_GPIO5 R8A7792_CLK_GPIO4
+				R8A7792_CLK_GPIO3 R8A7792_CLK_GPIO2
+				R8A7792_CLK_GPIO1 R8A7792_CLK_GPIO0
+				R8A7792_CLK_GPIO11 R8A7792_CLK_GPIO10
+				R8A7792_CLK_CAN1 R8A7792_CLK_CAN0
+				R8A7792_CLK_QSPI_MOD R8A7792_CLK_GPIO9
+				R8A7792_CLK_GPIO8 R8A7792_CLK_I2C5
+				R8A7792_CLK_IICDVFS R8A7792_CLK_I2C4
+				R8A7792_CLK_I2C3 R8A7792_CLK_I2C2
+				R8A7792_CLK_I2C1 R8A7792_CLK_I2C0
+			>;
+			clock-output-names = "gpio7", "gpio6", "gpio5", "gpio4",
+					     "gpio3", "gpio2", "gpio1", "gpio0",
+					     "gpio11", "gpio10", "can1", "can0",
+					     "qspi_mod", "gpio9", "gpio8",
+					     "i2c5", "iic3", "i2c4", "i2c3",
+					     "i2c2", "i2c1", "i2c0";
+		};
+		mstp10_clks: mstp10_clks at e6150998 {
+			compatible = "renesas,r8a7792-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
+			clocks = <&p_clk>, <&p_clk>, <&p_clk>;
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7792_CLK_SSI_ALL
+				R8A7792_CLK_SSI4 R8A7792_CLK_SSI3
+			>;
+			clock-output-names = "ssi", "ssi4", "ssi3";
+		};
+	};
+};

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Wed, Jun 01, 2016 at 01:24:21AM +0300, Sergei Shtylyov wrote:
> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
> and the required  clock descriptions.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

This is rather large for an initial DTSI. Did you give any consideration
to splitting it up: e.g. only providing what is needed to get to a serial
console?

With regards to SMP. Have you checked to make sure CPU hotplug works
on all CPUs? And that the system behaves sanely on suspend/resume.
If it is not possible to verify this at this stage then I would recommend
only enabling one CPU at this stage.

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Wed, Jun 01, 2016 at 01:24:21AM +0300, Sergei Shtylyov wrote:
> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
> and the required  clock descriptions.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

This is rather large for an initial DTSI. Did you give any consideration
to splitting it up: e.g. only providing what is needed to get to a serial
console?

With regards to SMP. Have you checked to make sure CPU hotplug works
on all CPUs? And that the system behaves sanely on suspend/resume.
If it is not possible to verify this at this stage then I would recommend
only enabling one CPU at this stage.

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/01/2016 03:57 AM, Simon Horman wrote:

>> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
>> and the required  clock descriptions.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> This is rather large for an initial DTSI. Did you give any consideration
> to splitting it up: e.g. only providing what is needed to get to a serial
> console?

    You mean dropping the majority of clocks, right?

> With regards to SMP. Have you checked to make sure CPU hotplug works
> on all CPUs? And that the system behaves sanely on suspend/resume.
> If it is not possible to verify this at this stage then I would recommend
> only enabling one CPU at this stage.

    No, the SMP support isn't ready yet.
    And I'll have to enable SMP on R8A7794 as well...

MBR, Sergei

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/01/2016 03:57 AM, Simon Horman wrote:

>> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
>> and the required  clock descriptions.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> This is rather large for an initial DTSI. Did you give any consideration
> to splitting it up: e.g. only providing what is needed to get to a serial
> console?

    You mean dropping the majority of clocks, right?

> With regards to SMP. Have you checked to make sure CPU hotplug works
> on all CPUs? And that the system behaves sanely on suspend/resume.
> If it is not possible to verify this at this stage then I would recommend
> only enabling one CPU at this stage.

    No, the SMP support isn't ready yet.
    And I'll have to enable SMP on R8A7794 as well...

MBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

Hello.

On 06/01/2016 03:57 AM, Simon Horman wrote:

>> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
>> and the required  clock descriptions.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> This is rather large for an initial DTSI. Did you give any consideration
> to splitting it up: e.g. only providing what is needed to get to a serial
> console?

    Was done in the v2 patchset...

> With regards to SMP. Have you checked to make sure CPU hotplug works
> on all CPUs?

    How to test the CPU hotplug? I've now added the SMP support and made sure 
both CPUs are online and serve IRQs...

> And that the system behaves sanely on suspend/resume.

    I'd be thankful if you told me how to test that. :-)

> If it is not possible to verify this at this stage then I would recommend
> only enabling one CPU at this stage.

    Had a hard time debugging SMP until I realized I'd removed CPU1 from the 
device tree. :-)

MBR, Sergei

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

Hello.

On 06/01/2016 03:57 AM, Simon Horman wrote:

>> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
>> and the required  clock descriptions.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> This is rather large for an initial DTSI. Did you give any consideration
> to splitting it up: e.g. only providing what is needed to get to a serial
> console?

    Was done in the v2 patchset...

> With regards to SMP. Have you checked to make sure CPU hotplug works
> on all CPUs?

    How to test the CPU hotplug? I've now added the SMP support and made sure 
both CPUs are online and serve IRQs...

> And that the system behaves sanely on suspend/resume.

    I'd be thankful if you told me how to test that. :-)

> If it is not possible to verify this at this stage then I would recommend
> only enabling one CPU at this stage.

    Had a hard time debugging SMP until I realized I'd removed CPU1 from the 
device tree. :-)

MBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Tue, Jun 7, 2016 at 12:26 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>> With regards to SMP. Have you checked to make sure CPU hotplug works
>> on all CPUs?
>
>    How to test the CPU hotplug? I've now added the SMP support and made sure
> both CPUs are online and serve IRQs...

Off/online all CPUs:

    for i in /sys/*/*/cpu/cpu[0-9]*; do echo 0 > $i/online; echo 1 >
$i/online; done

Offline all CPUs:

    for i in /sys/*/*/cpu/cpu[0-9]*; do echo 0 > $i/online; done; cat
/proc/cpuinfo

Online all CPUs:

   for i in /sys/*/*/cpu/cpu[0-9]*; do echo 1 > $i/online; done; cat
/proc/cpuinfo

>> And that the system behaves sanely on suspend/resume.
>
>    I'd be thankful if you told me how to test that. :-)

System suspend:

    echo mem > /sys/power/state

System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
Serial should work too, echo "enabled" to the corresponding wakeup
file in /sys first.

In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".

Good luck!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Tue, Jun 7, 2016 at 12:26 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>> With regards to SMP. Have you checked to make sure CPU hotplug works
>> on all CPUs?
>
>    How to test the CPU hotplug? I've now added the SMP support and made sure
> both CPUs are online and serve IRQs...

Off/online all CPUs:

    for i in /sys/*/*/cpu/cpu[0-9]*; do echo 0 > $i/online; echo 1 >
$i/online; done

Offline all CPUs:

    for i in /sys/*/*/cpu/cpu[0-9]*; do echo 0 > $i/online; done; cat
/proc/cpuinfo

Online all CPUs:

   for i in /sys/*/*/cpu/cpu[0-9]*; do echo 1 > $i/online; done; cat
/proc/cpuinfo

>> And that the system behaves sanely on suspend/resume.
>
>    I'd be thankful if you told me how to test that. :-)

System suspend:

    echo mem > /sys/power/state

System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
Serial should work too, echo "enabled" to the corresponding wakeup
file in /sys first.

In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".

Good luck!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/07/2016 10:13 AM, Geert Uytterhoeven wrote:

[...]

>>> And that the system behaves sanely on suspend/resume.
>>
>>    I'd be thankful if you told me how to test that. :-)
>
> System suspend:
>
>     echo mem > /sys/power/state

    Oh. I know that one! :-)

> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> Serial should work too, echo "enabled" to the corresponding wakeup
> file in /sys first.

    I'm afraid I couldn't find that file. All I saw were RPM controls...

> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".

    There's no problems suspending, it's the resuming that's a problem for me.

> Good luck!

    As usual, there was no luck. :-)

WBR, Sergei

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/07/2016 10:13 AM, Geert Uytterhoeven wrote:

[...]

>>> And that the system behaves sanely on suspend/resume.
>>
>>    I'd be thankful if you told me how to test that. :-)
>
> System suspend:
>
>     echo mem > /sys/power/state

    Oh. I know that one! :-)

> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> Serial should work too, echo "enabled" to the corresponding wakeup
> file in /sys first.

    I'm afraid I couldn't find that file. All I saw were RPM controls...

> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".

    There's no problems suspending, it's the resuming that's a problem for me.

> Good luck!

    As usual, there was no luck. :-)

WBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Tue, Jun 07, 2016 at 11:58:45PM +0300, Sergei Shtylyov wrote:
> On 06/07/2016 10:13 AM, Geert Uytterhoeven wrote:
> 
> [...]
> 
> >>>And that the system behaves sanely on suspend/resume.
> >>
> >>   I'd be thankful if you told me how to test that. :-)
> >
> >System suspend:
> >
> >    echo mem > /sys/power/state
> 
>    Oh. I know that one! :-)
> 
> >System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> >Serial should work too, echo "enabled" to the corresponding wakeup
> >file in /sys first.
> 
>    I'm afraid I couldn't find that file. All I saw were RPM controls...
> 
> >In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
> 
>    There's no problems suspending, it's the resuming that's a problem for me.
> 
> >Good luck!
> 
>    As usual, there was no luck. :-)
> 
> WBR, Sergei

Does resume work for UP (i.e. without SMP)?

How did testing CPU hotplug go? Did it work for all CPUs?

If things work less well for SMP than UP I am inclined to ask
you to defer adding SMP support.

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Tue, Jun 07, 2016 at 11:58:45PM +0300, Sergei Shtylyov wrote:
> On 06/07/2016 10:13 AM, Geert Uytterhoeven wrote:
> 
> [...]
> 
> >>>And that the system behaves sanely on suspend/resume.
> >>
> >>   I'd be thankful if you told me how to test that. :-)
> >
> >System suspend:
> >
> >    echo mem > /sys/power/state
> 
>    Oh. I know that one! :-)
> 
> >System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> >Serial should work too, echo "enabled" to the corresponding wakeup
> >file in /sys first.
> 
>    I'm afraid I couldn't find that file. All I saw were RPM controls...
> 
> >In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
> 
>    There's no problems suspending, it's the resuming that's a problem for me.
> 
> >Good luck!
> 
>    As usual, there was no luck. :-)
> 
> WBR, Sergei

Does resume work for UP (i.e. without SMP)?

How did testing CPU hotplug go? Did it work for all CPUs?

If things work less well for SMP than UP I am inclined to ask
you to defer adding SMP support.

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/10/2016 04:02 AM, Simon Horman wrote:

>> [...]
>>
>>>>> And that the system behaves sanely on suspend/resume.
>>>>
>>>>   I'd be thankful if you told me how to test that. :-)
>>>
>>> System suspend:
>>>
>>>    echo mem > /sys/power/state
>>
>>    Oh. I know that one! :-)
>>
>>> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
>>> Serial should work too, echo "enabled" to the corresponding wakeup
>>> file in /sys first.
>>
>>    I'm afraid I couldn't find that file. All I saw were RPM controls...
>>
>>> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
>>
>>    There's no problems suspending, it's the resuming that's a problem for me.
>>
>>> Good luck!
>>
>>    As usual, there was no luck. :-)
>>
>> WBR, Sergei
>
> Does resume work for UP (i.e. without SMP)?

    No. My problem with resume is I can't wake up the remote system. I don't 
see the needed 'wakeup' file in /sys/devices/platform/soc/e6e60000.serial/...
     However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do

$ echo -n core /sys/.power/pm_test

the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.

> How did testing CPU hotplug go? Did it work for all CPUs?

    Sure!
    The only problem I'm seeing (again) is the RCAN clock failing to register:

rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)

    I was going to look at it yesterday but (wrongly) thought it somehow cured 
itself... I'll look at it now.

MBR, Sergei

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/10/2016 04:02 AM, Simon Horman wrote:

>> [...]
>>
>>>>> And that the system behaves sanely on suspend/resume.
>>>>
>>>>   I'd be thankful if you told me how to test that. :-)
>>>
>>> System suspend:
>>>
>>>    echo mem > /sys/power/state
>>
>>    Oh. I know that one! :-)
>>
>>> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
>>> Serial should work too, echo "enabled" to the corresponding wakeup
>>> file in /sys first.
>>
>>    I'm afraid I couldn't find that file. All I saw were RPM controls...
>>
>>> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
>>
>>    There's no problems suspending, it's the resuming that's a problem for me.
>>
>>> Good luck!
>>
>>    As usual, there was no luck. :-)
>>
>> WBR, Sergei
>
> Does resume work for UP (i.e. without SMP)?

    No. My problem with resume is I can't wake up the remote system. I don't 
see the needed 'wakeup' file in /sys/devices/platform/soc/e6e60000.serial/...
     However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do

$ echo -n core /sys/.power/pm_test

the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.

> How did testing CPU hotplug go? Did it work for all CPUs?

    Sure!
    The only problem I'm seeing (again) is the RCAN clock failing to register:

rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)

    I was going to look at it yesterday but (wrongly) thought it somehow cured 
itself... I'll look at it now.

MBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Fri, Jun 10, 2016 at 9:29 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>    The only problem I'm seeing (again) is the RCAN clock failing to
> register:
>
> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>
>    I was going to look at it yesterday but (wrongly) thought it somehow
> cured itself... I'll look at it now.

The RCAN parent is the second clock in the CPG node's "clocks" property,
which you didn't provide.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Fri, Jun 10, 2016 at 9:29 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>    The only problem I'm seeing (again) is the RCAN clock failing to
> register:
>
> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>
>    I was going to look at it yesterday but (wrongly) thought it somehow
> cured itself... I'll look at it now.

The RCAN parent is the second clock in the CPG node's "clocks" property,
which you didn't provide.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/10/2016 11:42 PM, Geert Uytterhoeven wrote:

>>    The only problem I'm seeing (again) is the RCAN clock failing to
>> register:
>>
>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>
>>    I was going to look at it yesterday but (wrongly) thought it somehow
>> cured itself... I'll look at it now.
>
> The RCAN parent is the second clock in the CPG node's "clocks" property,
> which you didn't provide.

    Actually, the things are more complex. The figure 7.1c suggests that the 
RCAN clock has different parent on R8A7792 than on the other SoCs -- namely 
PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this SoC 
(it doesn't seem to support any USB IPs). Which means the 'clk-rcar-gen2' 
driver can't work with the RCAN clock in its current form.

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 06/10/2016 11:42 PM, Geert Uytterhoeven wrote:

>>    The only problem I'm seeing (again) is the RCAN clock failing to
>> register:
>>
>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>
>>    I was going to look at it yesterday but (wrongly) thought it somehow
>> cured itself... I'll look at it now.
>
> The RCAN parent is the second clock in the CPG node's "clocks" property,
> which you didn't provide.

    Actually, the things are more complex. The figure 7.1c suggests that the 
RCAN clock has different parent on R8A7792 than on the other SoCs -- namely 
PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this SoC 
(it doesn't seem to support any USB IPs). Which means the 'clk-rcar-gen2' 
driver can't work with the RCAN clock in its current form.

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Fri, Jun 10, 2016 at 10:50 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 06/10/2016 11:42 PM, Geert Uytterhoeven wrote:
>>>    The only problem I'm seeing (again) is the RCAN clock failing to
>>> register:
>>>
>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>>
>>>    I was going to look at it yesterday but (wrongly) thought it somehow
>>> cured itself... I'll look at it now.
>>
>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>> which you didn't provide.
>
>    Actually, the things are more complex. The figure 7.1c suggests that the
> RCAN clock has different parent on R8A7792 than on the other SoCs -- namely
> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
> SoC (it doesn't seem to support any USB IPs). Which means the
> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form.

Right, I had forgotten about that.
Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)

it seems the RCAN clock can just be modeled as a fixed clock. However,
its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
using an integer divider. Morimoto-san, can you please ask for clarification?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Fri, Jun 10, 2016 at 10:50 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 06/10/2016 11:42 PM, Geert Uytterhoeven wrote:
>>>    The only problem I'm seeing (again) is the RCAN clock failing to
>>> register:
>>>
>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>>
>>>    I was going to look at it yesterday but (wrongly) thought it somehow
>>> cured itself... I'll look at it now.
>>
>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>> which you didn't provide.
>
>    Actually, the things are more complex. The figure 7.1c suggests that the
> RCAN clock has different parent on R8A7792 than on the other SoCs -- namely
> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
> SoC (it doesn't seem to support any USB IPs). Which means the
> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form.

Right, I had forgotten about that.
Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)

it seems the RCAN clock can just be modeled as a fixed clock. However,
its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
using an integer divider. Morimoto-san, can you please ask for clarification?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 6/13/2016 10:12 AM, Geert Uytterhoeven wrote:

>>>>    The only problem I'm seeing (again) is the RCAN clock failing to
>>>> register:
>>>>
>>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>>>
>>>>    I was going to look at it yesterday but (wrongly) thought it somehow
>>>> cured itself... I'll look at it now.
>>>
>>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>>> which you didn't provide.
>>
>>    Actually, the things are more complex. The figure 7.1c suggests that the
>> RCAN clock has different parent on R8A7792 than on the other SoCs -- namely
>> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
>> SoC (it doesn't seem to support any USB IPs). Which means the
>> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form.
>
> Right, I had forgotten about that.
> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)

    What do you mean?

> it seems the RCAN clock can just be modeled as a fixed clock. However,
> its divider value isn't clear to me,

    IIRC, the fixed RCAN divisor was equal to 6.

[...]

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

On 6/13/2016 10:12 AM, Geert Uytterhoeven wrote:

>>>>    The only problem I'm seeing (again) is the RCAN clock failing to
>>>> register:
>>>>
>>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>>>
>>>>    I was going to look at it yesterday but (wrongly) thought it somehow
>>>> cured itself... I'll look at it now.
>>>
>>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>>> which you didn't provide.
>>
>>    Actually, the things are more complex. The figure 7.1c suggests that the
>> RCAN clock has different parent on R8A7792 than on the other SoCs -- namely
>> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
>> SoC (it doesn't seem to support any USB IPs). Which means the
>> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form.
>
> Right, I had forgotten about that.
> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)

    What do you mean?

> it seems the RCAN clock can just be modeled as a fixed clock. However,
> its divider value isn't clear to me,

    IIRC, the fixed RCAN divisor was equal to 6.

[...]

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Mon, Jun 13, 2016 at 1:24 PM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> On 6/13/2016 10:12 AM, Geert Uytterhoeven wrote:
>>>>>    The only problem I'm seeing (again) is the RCAN clock failing to
>>>>> register:
>>>>>
>>>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock
>>>>> (-12)
>>>>>
>>>>>    I was going to look at it yesterday but (wrongly) thought it somehow
>>>>> cured itself... I'll look at it now.
>>>>
>>>>
>>>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>>>> which you didn't provide.
>>>
>>>
>>>    Actually, the things are more complex. The figure 7.1c suggests that
>>> the
>>> RCAN clock has different parent on R8A7792 than on the other SoCs --
>>> namely
>>> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
>>> SoC (it doesn't seem to support any USB IPs). Which means the
>>> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current
>>> form.
>>
>> Right, I had forgotten about that.
>> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case
>> ;-)
>
>    What do you mean?

I mean that it failed due to the missing parent clock, instead of continuing
silently with a wrong clock rate.

>> it seems the RCAN clock can just be modeled as a fixed clock. However,
>> its divider value isn't clear to me,
>
>    IIRC, the fixed RCAN divisor was equal to 6.

1560 / 6 != 15.9.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Mon, Jun 13, 2016 at 1:24 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 6/13/2016 10:12 AM, Geert Uytterhoeven wrote:
>>>>>    The only problem I'm seeing (again) is the RCAN clock failing to
>>>>> register:
>>>>>
>>>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock
>>>>> (-12)
>>>>>
>>>>>    I was going to look at it yesterday but (wrongly) thought it somehow
>>>>> cured itself... I'll look at it now.
>>>>
>>>>
>>>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>>>> which you didn't provide.
>>>
>>>
>>>    Actually, the things are more complex. The figure 7.1c suggests that
>>> the
>>> RCAN clock has different parent on R8A7792 than on the other SoCs --
>>> namely
>>> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
>>> SoC (it doesn't seem to support any USB IPs). Which means the
>>> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current
>>> form.
>>
>> Right, I had forgotten about that.
>> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case
>> ;-)
>
>    What do you mean?

I mean that it failed due to the missing parent clock, instead of continuing
silently with a wrong clock rate.

>> it seems the RCAN clock can just be modeled as a fixed clock. However,
>> its divider value isn't clear to me,
>
>    IIRC, the fixed RCAN divisor was equal to 6.

1560 / 6 != 15.9.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Sergei,

On Mon, Jun 13, 2016 at 1:24 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 6/13/2016 10:12 AM, Geert Uytterhoeven wrote:
>>>>>    The only problem I'm seeing (again) is the RCAN clock failing to
>>>>> register:
>>>>>
>>>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock
>>>>> (-12)
>>>>>
>>>>>    I was going to look at it yesterday but (wrongly) thought it somehow
>>>>> cured itself... I'll look at it now.
>>>>
>>>>
>>>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>>>> which you didn't provide.
>>>
>>>
>>>    Actually, the things are more complex. The figure 7.1c suggests that
>>> the
>>> RCAN clock has different parent on R8A7792 than on the other SoCs --
>>> namely
>>> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
>>> SoC (it doesn't seem to support any USB IPs). Which means the
>>> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current
>>> form.
>>
>> Right, I had forgotten about that.
>> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case
>> ;-)
>
>    What do you mean?

I mean that it failed due to the missing parent clock, instead of continuing
silently with a wrong clock rate.

>> it seems the RCAN clock can just be modeled as a fixed clock. However,
>> its divider value isn't clear to me,
>
>    IIRC, the fixed RCAN divisor was equal to 6.

1560 / 6 != 15.9.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Kuninori Morimoto]

Hi Geert

> Right, I had forgotten about that.
> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)
> 
> it seems the RCAN clock can just be modeled as a fixed clock. However,
> its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
> using an integer divider. Morimoto-san, can you please ask for clarification?

OK.
Now, I asked to HW team about that.
Please wait.

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Kuninori Morimoto]

Hi Geert

> Right, I had forgotten about that.
> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)
> 
> it seems the RCAN clock can just be modeled as a fixed clock. However,
> its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
> using an integer divider. Morimoto-san, can you please ask for clarification?

OK.
Now, I asked to HW team about that.
Please wait.

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Kuninori Morimoto]

Hi Geert

> > Right, I had forgotten about that.
> > Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)
> > 
> > it seems the RCAN clock can just be modeled as a fixed clock. However,
> > its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
> > using an integer divider. Morimoto-san, can you please ask for clarification?
> 
> OK.
> Now, I asked to HW team about that.
> Please wait.

RCAN divider is fixed for 1/49

PLL1 (= 1560MHz) 
  -> 1/2 (= 780MHz)
    -> RCAN divider 1/49 (= 15.9183..MHz)

Is this clear for you ?

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Kuninori Morimoto]

Hi Geert

> > Right, I had forgotten about that.
> > Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)
> > 
> > it seems the RCAN clock can just be modeled as a fixed clock. However,
> > its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
> > using an integer divider. Morimoto-san, can you please ask for clarification?
> 
> OK.
> Now, I asked to HW team about that.
> Please wait.

RCAN divider is fixed for 1/49

PLL1 (= 1560MHz) 
  -> 1/2 (= 780MHz)
    -> RCAN divider 1/49 (= 15.9183..MHz)

Is this clear for you ?

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Morimoto-san,

On Fri, Jun 17, 2016 at 4:14 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>> > Right, I had forgotten about that.
>> > Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)
>> >
>> > it seems the RCAN clock can just be modeled as a fixed clock. However,
>> > its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
>> > using an integer divider. Morimoto-san, can you please ask for clarification?
>>
>> OK.
>> Now, I asked to HW team about that.
>> Please wait.
>
> RCAN divider is fixed for 1/49
>
> PLL1 (= 1560MHz)
>   -> 1/2 (= 780MHz)
>     -> RCAN divider 1/49 (= 15.9183..MHz)
>
> Is this clear for you ?

Thanks, that's exactly what we need to know.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

Hi Morimoto-san,

On Fri, Jun 17, 2016 at 4:14 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>> > Right, I had forgotten about that.
>> > Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)
>> >
>> > it seems the RCAN clock can just be modeled as a fixed clock. However,
>> > its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
>> > using an integer divider. Morimoto-san, can you please ask for clarification?
>>
>> OK.
>> Now, I asked to HW team about that.
>> Please wait.
>
> RCAN divider is fixed for 1/49
>
> PLL1 (= 1560MHz)
>   -> 1/2 (= 780MHz)
>     -> RCAN divider 1/49 (= 15.9183..MHz)
>
> Is this clear for you ?

Thanks, that's exactly what we need to know.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Fri, Jun 10, 2016 at 10:29:17PM +0300, Sergei Shtylyov wrote:
> On 06/10/2016 04:02 AM, Simon Horman wrote:
> 
> >>[...]
> >>
> >>>>>And that the system behaves sanely on suspend/resume.
> >>>>
> >>>>  I'd be thankful if you told me how to test that. :-)
> >>>
> >>>System suspend:
> >>>
> >>>   echo mem > /sys/power/state
> >>
> >>   Oh. I know that one! :-)
> >>
> >>>System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> >>>Serial should work too, echo "enabled" to the corresponding wakeup
> >>>file in /sys first.
> >>
> >>   I'm afraid I couldn't find that file. All I saw were RPM controls...
> >>
> >>>In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
> >>
> >>   There's no problems suspending, it's the resuming that's a problem for me.
> >>
> >>>Good luck!
> >>
> >>   As usual, there was no luck. :-)
> >>
> >>WBR, Sergei
> >
> >Does resume work for UP (i.e. without SMP)?
> 
>    No. My problem with resume is I can't wake up the remote system. I don't
> see the needed 'wakeup' file in
> /sys/devices/platform/soc/e6e60000.serial/...
>     However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do
> 
> $ echo -n core /sys/.power/pm_test
> 
> the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.

That seems promising but it seems curious that there is no wakeup file.

On Lager the following procedure works for me using
renesas-devel-20160613-v4.7-rc3 and shmobile defconfig.

0. Add wakeup-source property to serial@e6ce0000 node in DT
1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup
2. echo mem > /sys/power/state
3. Provide input on serial console

* Success! *

> >How did testing CPU hotplug go? Did it work for all CPUs?
> 
>    Sure!

Great!

>    The only problem I'm seeing (again) is the RCAN clock failing to register:
> 
> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
> 
>    I was going to look at it yesterday but (wrongly) thought it somehow
> cured itself... I'll look at it now.

Is this resolved? If not perhaps you could consider removing the node
in question for now.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Fri, Jun 10, 2016 at 10:29:17PM +0300, Sergei Shtylyov wrote:
> On 06/10/2016 04:02 AM, Simon Horman wrote:
> 
> >>[...]
> >>
> >>>>>And that the system behaves sanely on suspend/resume.
> >>>>
> >>>>  I'd be thankful if you told me how to test that. :-)
> >>>
> >>>System suspend:
> >>>
> >>>   echo mem > /sys/power/state
> >>
> >>   Oh. I know that one! :-)
> >>
> >>>System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> >>>Serial should work too, echo "enabled" to the corresponding wakeup
> >>>file in /sys first.
> >>
> >>   I'm afraid I couldn't find that file. All I saw were RPM controls...
> >>
> >>>In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
> >>
> >>   There's no problems suspending, it's the resuming that's a problem for me.
> >>
> >>>Good luck!
> >>
> >>   As usual, there was no luck. :-)
> >>
> >>WBR, Sergei
> >
> >Does resume work for UP (i.e. without SMP)?
> 
>    No. My problem with resume is I can't wake up the remote system. I don't
> see the needed 'wakeup' file in
> /sys/devices/platform/soc/e6e60000.serial/...
>     However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do
> 
> $ echo -n core /sys/.power/pm_test
> 
> the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.

That seems promising but it seems curious that there is no wakeup file.

On Lager the following procedure works for me using
renesas-devel-20160613-v4.7-rc3 and shmobile defconfig.

0. Add wakeup-source property to serial at e6ce0000 node in DT
1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup
2. echo mem > /sys/power/state
3. Provide input on serial console

* Success! *

> >How did testing CPU hotplug go? Did it work for all CPUs?
> 
>    Sure!

Great!

>    The only problem I'm seeing (again) is the RCAN clock failing to register:
> 
> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
> 
>    I was going to look at it yesterday but (wrongly) thought it somehow
> cured itself... I'll look at it now.

Is this resolved? If not perhaps you could consider removing the node
in question for now.

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Fri, Jun 10, 2016 at 10:29:17PM +0300, Sergei Shtylyov wrote:
> On 06/10/2016 04:02 AM, Simon Horman wrote:
> 
> >>[...]
> >>
> >>>>>And that the system behaves sanely on suspend/resume.
> >>>>
> >>>>  I'd be thankful if you told me how to test that. :-)
> >>>
> >>>System suspend:
> >>>
> >>>   echo mem > /sys/power/state
> >>
> >>   Oh. I know that one! :-)
> >>
> >>>System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> >>>Serial should work too, echo "enabled" to the corresponding wakeup
> >>>file in /sys first.
> >>
> >>   I'm afraid I couldn't find that file. All I saw were RPM controls...
> >>
> >>>In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
> >>
> >>   There's no problems suspending, it's the resuming that's a problem for me.
> >>
> >>>Good luck!
> >>
> >>   As usual, there was no luck. :-)
> >>
> >>WBR, Sergei
> >
> >Does resume work for UP (i.e. without SMP)?
> 
>    No. My problem with resume is I can't wake up the remote system. I don't
> see the needed 'wakeup' file in
> /sys/devices/platform/soc/e6e60000.serial/...
>     However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do
> 
> $ echo -n core /sys/.power/pm_test
> 
> the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.

That seems promising but it seems curious that there is no wakeup file.

On Lager the following procedure works for me using
renesas-devel-20160613-v4.7-rc3 and shmobile defconfig.

0. Add wakeup-source property to serial@e6ce0000 node in DT
1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup
2. echo mem > /sys/power/state
3. Provide input on serial console

* Success! *

> >How did testing CPU hotplug go? Did it work for all CPUs?
> 
>    Sure!

Great!

>    The only problem I'm seeing (again) is the RCAN clock failing to register:
> 
> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
> 
>    I was going to look at it yesterday but (wrongly) thought it somehow
> cured itself... I'll look at it now.

Is this resolved? If not perhaps you could consider removing the node
in question for now.

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

Hello.

On 06/14/2016 03:43 AM, Simon Horman wrote:

>>>> [...]
>>>>
>>>>>>> And that the system behaves sanely on suspend/resume.
>>>>>>
>>>>>>  I'd be thankful if you told me how to test that. :-)
>>>>>
>>>>> System suspend:
>>>>>
>>>>>   echo mem > /sys/power/state
>>>>
>>>>   Oh. I know that one! :-)
>>>>
>>>>> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
>>>>> Serial should work too, echo "enabled" to the corresponding wakeup
>>>>> file in /sys first.
>>>>
>>>>   I'm afraid I couldn't find that file. All I saw were RPM controls...
>>>>
>>>>> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
>>>>
>>>>   There's no problems suspending, it's the resuming that's a problem for me.
>>>>
>>>>> Good luck!
>>>>
>>>>   As usual, there was no luck. :-)
>>>>
>>>> WBR, Sergei
>>>
>>> Does resume work for UP (i.e. without SMP)?
>>
>>    No. My problem with resume is I can't wake up the remote system. I don't
>> see the needed 'wakeup' file in
>> /sys/devices/platform/soc/e6e60000.serial/...
>>     However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do
>>
>> $ echo -n core /sys/.power/pm_test
>>
>> the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.
>
> That seems promising but it seems curious that there is no wakeup file.
>
> On Lager the following procedure works for me using
> renesas-devel-20160613-v4.7-rc3 and shmobile defconfig.
>
> 0. Add wakeup-source property to serial@e6ce0000 node in DT

    Ah, stupid me, it was the piece that I'd overlooked!

> 1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup
> 2. echo mem > /sys/power/state
> 3. Provide input on serial console
>
> * Success! *

    Yeah, works now!
    Sorry, I had no previous experience with the PM. Was unsupported feature 
back in MontaVista... :-)

>>> How did testing CPU hotplug go? Did it work for all CPUs?
>>
>>    Sure!
>
> Great!
>
>>    The only problem I'm seeing (again) is the RCAN clock failing to register:
>>
>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>
>>    I was going to look at it yesterday but (wrongly) thought it somehow
>> cured itself... I'll look at it now.
>
> Is this resolved? If not perhaps you could consider removing the node
> in question for now.

    That's what I did in v5, i.e. removed the RCAN CPG clock (not the whole 
node)...

MBR, Sergei

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Sergei Shtylyov]

Hello.

On 06/14/2016 03:43 AM, Simon Horman wrote:

>>>> [...]
>>>>
>>>>>>> And that the system behaves sanely on suspend/resume.
>>>>>>
>>>>>>  I'd be thankful if you told me how to test that. :-)
>>>>>
>>>>> System suspend:
>>>>>
>>>>>   echo mem > /sys/power/state
>>>>
>>>>   Oh. I know that one! :-)
>>>>
>>>>> System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
>>>>> Serial should work too, echo "enabled" to the corresponding wakeup
>>>>> file in /sys first.
>>>>
>>>>   I'm afraid I couldn't find that file. All I saw were RPM controls...
>>>>
>>>>> In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
>>>>
>>>>   There's no problems suspending, it's the resuming that's a problem for me.
>>>>
>>>>> Good luck!
>>>>
>>>>   As usual, there was no luck. :-)
>>>>
>>>> WBR, Sergei
>>>
>>> Does resume work for UP (i.e. without SMP)?
>>
>>    No. My problem with resume is I can't wake up the remote system. I don't
>> see the needed 'wakeup' file in
>> /sys/devices/platform/soc/e6e60000.serial/...
>>     However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do
>>
>> $ echo -n core /sys/.power/pm_test
>>
>> the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.
>
> That seems promising but it seems curious that there is no wakeup file.
>
> On Lager the following procedure works for me using
> renesas-devel-20160613-v4.7-rc3 and shmobile defconfig.
>
> 0. Add wakeup-source property to serial at e6ce0000 node in DT

    Ah, stupid me, it was the piece that I'd overlooked!

> 1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup
> 2. echo mem > /sys/power/state
> 3. Provide input on serial console
>
> * Success! *

    Yeah, works now!
    Sorry, I had no previous experience with the PM. Was unsupported feature 
back in MontaVista... :-)

>>> How did testing CPU hotplug go? Did it work for all CPUs?
>>
>>    Sure!
>
> Great!
>
>>    The only problem I'm seeing (again) is the RCAN clock failing to register:
>>
>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>
>>    I was going to look at it yesterday but (wrongly) thought it somehow
>> cured itself... I'll look at it now.
>
> Is this resolved? If not perhaps you could consider removing the node
> in question for now.

    That's what I did in v5, i.e. removed the RCAN CPG clock (not the whole 
node)...

MBR, Sergei

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Wed, Jun 15, 2016 at 12:08:21AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 06/14/2016 03:43 AM, Simon Horman wrote:
> 
> >>>>[...]
> >>>>
> >>>>>>>And that the system behaves sanely on suspend/resume.
> >>>>>>
> >>>>>> I'd be thankful if you told me how to test that. :-)
> >>>>>
> >>>>>System suspend:
> >>>>>
> >>>>>  echo mem > /sys/power/state
> >>>>
> >>>>  Oh. I know that one! :-)
> >>>>
> >>>>>System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> >>>>>Serial should work too, echo "enabled" to the corresponding wakeup
> >>>>>file in /sys first.
> >>>>
> >>>>  I'm afraid I couldn't find that file. All I saw were RPM controls...
> >>>>
> >>>>>In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
> >>>>
> >>>>  There's no problems suspending, it's the resuming that's a problem for me.
> >>>>
> >>>>>Good luck!
> >>>>
> >>>>  As usual, there was no luck. :-)
> >>>>
> >>>>WBR, Sergei
> >>>
> >>>Does resume work for UP (i.e. without SMP)?
> >>
> >>   No. My problem with resume is I can't wake up the remote system. I don't
> >>see the needed 'wakeup' file in
> >>/sys/devices/platform/soc/e6e60000.serial/...
> >>    However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do
> >>
> >>$ echo -n core /sys/.power/pm_test
> >>
> >>the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.
> >
> >That seems promising but it seems curious that there is no wakeup file.
> >
> >On Lager the following procedure works for me using
> >renesas-devel-20160613-v4.7-rc3 and shmobile defconfig.
> >
> >0. Add wakeup-source property to serial@e6ce0000 node in DT
> 
>    Ah, stupid me, it was the piece that I'd overlooked!
> 
> >1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup
> >2. echo mem > /sys/power/state
> >3. Provide input on serial console
> >
> >* Success! *
> 
>    Yeah, works now!
>    Sorry, I had no previous experience with the PM. Was unsupported feature
> back in MontaVista... :-)

Great, thanks for your persistence.

FWIW, I always have to refer to some notes in order to exercise PM.

> >>>How did testing CPU hotplug go? Did it work for all CPUs?
> >>
> >>   Sure!
> >
> >Great!
> >
> >>   The only problem I'm seeing (again) is the RCAN clock failing to register:
> >>
> >>rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
> >>
> >>   I was going to look at it yesterday but (wrongly) thought it somehow
> >>cured itself... I'll look at it now.
> >
> >Is this resolved? If not perhaps you could consider removing the node
> >in question for now.
> 
>    That's what I did in v5, i.e. removed the RCAN CPG clock (not the whole
> node)...

Great.

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Simon Horman]

On Wed, Jun 15, 2016 at 12:08:21AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 06/14/2016 03:43 AM, Simon Horman wrote:
> 
> >>>>[...]
> >>>>
> >>>>>>>And that the system behaves sanely on suspend/resume.
> >>>>>>
> >>>>>> I'd be thankful if you told me how to test that. :-)
> >>>>>
> >>>>>System suspend:
> >>>>>
> >>>>>  echo mem > /sys/power/state
> >>>>
> >>>>  Oh. I know that one! :-)
> >>>>
> >>>>>System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
> >>>>>Serial should work too, echo "enabled" to the corresponding wakeup
> >>>>>file in /sys first.
> >>>>
> >>>>  I'm afraid I couldn't find that file. All I saw were RPM controls...
> >>>>
> >>>>>In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
> >>>>
> >>>>  There's no problems suspending, it's the resuming that's a problem for me.
> >>>>
> >>>>>Good luck!
> >>>>
> >>>>  As usual, there was no luck. :-)
> >>>>
> >>>>WBR, Sergei
> >>>
> >>>Does resume work for UP (i.e. without SMP)?
> >>
> >>   No. My problem with resume is I can't wake up the remote system. I don't
> >>see the needed 'wakeup' file in
> >>/sys/devices/platform/soc/e6e60000.serial/...
> >>    However, if I enable CONFIG_PM_[ADVANCED_]DEBUG and do
> >>
> >>$ echo -n core /sys/.power/pm_test
> >>
> >>the system happily wakes up after a small delay (5 s), w/either SMP or UP kernel.
> >
> >That seems promising but it seems curious that there is no wakeup file.
> >
> >On Lager the following procedure works for me using
> >renesas-devel-20160613-v4.7-rc3 and shmobile defconfig.
> >
> >0. Add wakeup-source property to serial at e6ce0000 node in DT
> 
>    Ah, stupid me, it was the piece that I'd overlooked!
> 
> >1. echo enabled > /sys/devices/platform/e6e60000.serial/tty/ttySC0/power/wakeup
> >2. echo mem > /sys/power/state
> >3. Provide input on serial console
> >
> >* Success! *
> 
>    Yeah, works now!
>    Sorry, I had no previous experience with the PM. Was unsupported feature
> back in MontaVista... :-)

Great, thanks for your persistence.

FWIW, I always have to refer to some notes in order to exercise PM.

> >>>How did testing CPU hotplug go? Did it work for all CPUs?
> >>
> >>   Sure!
> >
> >Great!
> >
> >>   The only problem I'm seeing (again) is the RCAN clock failing to register:
> >>
> >>rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
> >>
> >>   I was going to look at it yesterday but (wrongly) thought it somehow
> >>cured itself... I'll look at it now.
> >
> >Is this resolved? If not perhaps you could consider removing the node
> >in question for now.
> 
>    That's what I did in v5, i.e. removed the RCAN CPG clock (not the whole
> node)...

Great.

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:24 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
> and the required  clock descriptions.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
>  arch/arm/boot/dts/r8a7792.dtsi |  423 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 423 insertions(+)
>
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===================================================================
> --- /dev/null
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -0,0 +1,423 @@
> +/*
> + * Device Tree Source for the r8a7792 SoC
> + *
> + * Copyright (C) 2016 Cogent Embedded Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <dt-bindings/clock/r8a7792-clock.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>

#include <dt-bindings/interrupt-controller/irq.h> is included
implicitly by the above.

> +#include <dt-bindings/power/r8a7792-sysc.h>
> +
> +/ {
> +       compatible = "renesas,r8a7792";
> +       interrupt-parent = <&gic>;
> +       #address-cells = <2>;
> +       #size-cells = <2>;
> +
> +       cpus {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               cpu0: cpu@0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a15";
> +                       reg = <0>;
> +                       clock-frequency = <1000000000>;
> +                       clocks = <&cpg_clocks R8A7792_CLK_Z>;
> +                       power-domains = <&sysc R8A7792_PD_CA15_CPU0>;
> +                       next-level-cache = <&L2_CA15>;
> +               };
> +
> +               cpu1: cpu@1 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a15";
> +                       reg = <1>;
> +                       clock-frequency = <1000000000>;
> +                       power-domains = <&sysc R8A7792_PD_CA15_CPU1>;
> +                       next-level-cache = <&L2_CA15>;
> +               };
> +
> +               L2_CA15: cache-controller@0 {
> +                       compatible = "cache";
> +                       reg = <0>;
> +                       cache-unified;
> +                       cache-level = <2>;
> +                       power-domains = <&sysc R8A7792_PD_CA15_SCU>;
> +               };
> +       };
> +
> +       gic: interrupt-controller@f1001000 {

It would be good to group all on-SoC devices under an "soc" node, like we
started doing for r8a7795.

> +       clocks {
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +               ranges;
> +
> +               /* External root clock */
> +               extal_clk: extal {
> +                       compatible = "fixed-clock";
> +                       #clock-cells = <0>;
> +                       /* This value must be overridden by the board. */
> +                       clock-frequency = <0>;
> +               };

The fixed clocks should be at the root level these days.

> +               /* Special CPG clocks */
> +               cpg_clocks: cpg_clocks@e6150000 {
> +                       compatible = "renesas,r8a7792-cpg-clocks",
> +                                    "renesas,rcar-gen2-cpg-clocks";
> +                       reg = <0 0xe6150000 0 0x1000>;
> +                       clocks = <&extal_clk>;
> +                       #clock-cells = <1>;
> +                       clock-output-names = "main", "pll0", "pll1", "pll3",
> +                                            "lb", "qspi", "sdh", "sd0", "sd1",
> +                                            "z";

"sdh", "sd0", and "sd1" do not exist. Please remove them.

> +               z2_clk: z2 {
> +                       compatible = "fixed-factor-clock";
> +                       clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
> +                       #clock-cells = <0>;
> +                       clock-div = <2>;
> +                       clock-mult = <1>;
> +               };

V2H doesn't have Z2.

> +               i_clk: i {
> +                       compatible = "fixed-factor-clock";
> +                       clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
> +                       #clock-cells = <0>;
> +                       clock-div = <2>;
> +                       clock-mult = <1>;
> +               };

clock-div = <3>;

> +               cp_clk: cp {
> +                       compatible = "fixed-factor-clock";
> +                       clocks = <&extal_clk>;
> +                       #clock-cells = <0>;
> +                       clock-div = <2>;
> +                       clock-mult = <1>;
> +               };

On V2H, CP is derived from PLL1, cfr. CL.
The clock derived from EXTAL is called CPEX.

> +               mstp1_clks: mstp1_clks@e6150134 {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe6150134 0 4>, <0 0xe6150038 0 4>;
> +                       clocks = <&p_clk>, <&p_clk>, <&p_clk>, <&rclk_clk>,
> +                                <&cp_clk>, <&zs_clk>, <&zs_clk>, <&zs_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_TMU1 R8A7792_CLK_TMU3
> +                               R8A7792_CLK_TMU2 R8A7792_CLK_CMT0
> +                               R8A7792_CLK_TMU0 R8A7792_CLK_VSP1DU1
> +                               R8A7792_CLK_VSP1DU0 R8A7792_CLK_VSP1_SY
> +                       >;
> +                       clock-output-names = "tmu1", "tmu3", "tmu2", "cmt0",
> +                                            "tmu0", "vsp1du1", "vsp1du0",

These are called "vsp1-du1", "vsp1-du0" in all other R-Car Gen2 dtsis.

> +                                            "vsp1-sy";
> +               };
> +               mstp2_clks: mstp2_clks@e6150138 {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe6150138 0 4>, <0 0xe6150040 0 4>;
> +                       clocks = <&mp_clk>, <&zs_clk>, <&zs_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_MSIOF1
> +                               R8A7792_CLK_SYS_DMAC0 R8A7792_CLK_SYS_DMAC1

Wrong order of the DMACs.

> +                       >;
> +                       clock-output-names = "msiof1", "sys-dmac0", "sys-dmac1";

Wrong order of the DMACs.

> +               };
> +               mstp3_clks: mstp3_clks@e615013c {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>;
> +                       clocks = <&cp_clk>, <&cpg_clocks R8A7792_CLK_SD0>,

As there's no SD0, this can't be correct.

> +                                <&rclk_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_TPU0 R8A7792_CLK_SDHI0
> +                               R8A7792_CLK_CMT1
> +                       >;
> +                       clock-output-names = "tpu0", "sdhi0", "cmt1";
> +               };

> +               mstp5_clks: mstp5_clks@e6150144 {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>;
> +                       clocks = <&hp_clk>, <&extal_clk>, <&p_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_AUDIO_DMAC0
> +                               R8A7792_CLK_THERMAL R8A7792_CLK_PWM
> +                       >;
> +                       clock-output-names = "thermal", "pwm", "audmac0";

clock-output-names = "audmac0", "thermal", "pwm";

> +               };


> +               mstp9_clks: mstp9_clks@e6150994 {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>;
> +                       clocks = <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
> +                                <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
> +                                <&cp_clk>, <&cp_clk>, <&p_clk>, <&p_clk>,
> +                                <&cpg_clocks R8A7792_CLK_QSPI>, <&cp_clk>,
> +                                <&cp_clk>, <&hp_clk>, <&cp_clk>, <&hp_clk>,
> +                                <&hp_clk>, <&hp_clk>, <&hp_clk>, <&hp_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_GPIO7 R8A7792_CLK_GPIO6
> +                               R8A7792_CLK_GPIO5 R8A7792_CLK_GPIO4
> +                               R8A7792_CLK_GPIO3 R8A7792_CLK_GPIO2
> +                               R8A7792_CLK_GPIO1 R8A7792_CLK_GPIO0
> +                               R8A7792_CLK_GPIO11 R8A7792_CLK_GPIO10
> +                               R8A7792_CLK_CAN1 R8A7792_CLK_CAN0
> +                               R8A7792_CLK_QSPI_MOD R8A7792_CLK_GPIO9
> +                               R8A7792_CLK_GPIO8 R8A7792_CLK_I2C5
> +                               R8A7792_CLK_IICDVFS R8A7792_CLK_I2C4
> +                               R8A7792_CLK_I2C3 R8A7792_CLK_I2C2
> +                               R8A7792_CLK_I2C1 R8A7792_CLK_I2C0
> +                       >;
> +                       clock-output-names = "gpio7", "gpio6", "gpio5", "gpio4",
> +                                            "gpio3", "gpio2", "gpio1", "gpio0",
> +                                            "gpio11", "gpio10", "can1", "can0",

These are called "rcan1", "rcan0" in other dtsis.

> +                                            "qspi_mod", "gpio9", "gpio8",
> +                                            "i2c5", "iic3", "i2c4", "i2c3",
> +                                            "i2c2", "i2c1", "i2c0";
> +               };

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:24 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> The initial R8A7792 SoC device tree including 2 CPU cores, GIC, timer, SYSC,
> and the required  clock descriptions.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
>  arch/arm/boot/dts/r8a7792.dtsi |  423 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 423 insertions(+)
>
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===================================================================
> --- /dev/null
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -0,0 +1,423 @@
> +/*
> + * Device Tree Source for the r8a7792 SoC
> + *
> + * Copyright (C) 2016 Cogent Embedded Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <dt-bindings/clock/r8a7792-clock.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>

#include <dt-bindings/interrupt-controller/irq.h> is included
implicitly by the above.

> +#include <dt-bindings/power/r8a7792-sysc.h>
> +
> +/ {
> +       compatible = "renesas,r8a7792";
> +       interrupt-parent = <&gic>;
> +       #address-cells = <2>;
> +       #size-cells = <2>;
> +
> +       cpus {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               cpu0: cpu at 0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a15";
> +                       reg = <0>;
> +                       clock-frequency = <1000000000>;
> +                       clocks = <&cpg_clocks R8A7792_CLK_Z>;
> +                       power-domains = <&sysc R8A7792_PD_CA15_CPU0>;
> +                       next-level-cache = <&L2_CA15>;
> +               };
> +
> +               cpu1: cpu at 1 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a15";
> +                       reg = <1>;
> +                       clock-frequency = <1000000000>;
> +                       power-domains = <&sysc R8A7792_PD_CA15_CPU1>;
> +                       next-level-cache = <&L2_CA15>;
> +               };
> +
> +               L2_CA15: cache-controller at 0 {
> +                       compatible = "cache";
> +                       reg = <0>;
> +                       cache-unified;
> +                       cache-level = <2>;
> +                       power-domains = <&sysc R8A7792_PD_CA15_SCU>;
> +               };
> +       };
> +
> +       gic: interrupt-controller at f1001000 {

It would be good to group all on-SoC devices under an "soc" node, like we
started doing for r8a7795.

> +       clocks {
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +               ranges;
> +
> +               /* External root clock */
> +               extal_clk: extal {
> +                       compatible = "fixed-clock";
> +                       #clock-cells = <0>;
> +                       /* This value must be overridden by the board. */
> +                       clock-frequency = <0>;
> +               };

The fixed clocks should be at the root level these days.

> +               /* Special CPG clocks */
> +               cpg_clocks: cpg_clocks at e6150000 {
> +                       compatible = "renesas,r8a7792-cpg-clocks",
> +                                    "renesas,rcar-gen2-cpg-clocks";
> +                       reg = <0 0xe6150000 0 0x1000>;
> +                       clocks = <&extal_clk>;
> +                       #clock-cells = <1>;
> +                       clock-output-names = "main", "pll0", "pll1", "pll3",
> +                                            "lb", "qspi", "sdh", "sd0", "sd1",
> +                                            "z";

"sdh", "sd0", and "sd1" do not exist. Please remove them.

> +               z2_clk: z2 {
> +                       compatible = "fixed-factor-clock";
> +                       clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
> +                       #clock-cells = <0>;
> +                       clock-div = <2>;
> +                       clock-mult = <1>;
> +               };

V2H doesn't have Z2.

> +               i_clk: i {
> +                       compatible = "fixed-factor-clock";
> +                       clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
> +                       #clock-cells = <0>;
> +                       clock-div = <2>;
> +                       clock-mult = <1>;
> +               };

clock-div = <3>;

> +               cp_clk: cp {
> +                       compatible = "fixed-factor-clock";
> +                       clocks = <&extal_clk>;
> +                       #clock-cells = <0>;
> +                       clock-div = <2>;
> +                       clock-mult = <1>;
> +               };

On V2H, CP is derived from PLL1, cfr. CL.
The clock derived from EXTAL is called CPEX.

> +               mstp1_clks: mstp1_clks at e6150134 {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe6150134 0 4>, <0 0xe6150038 0 4>;
> +                       clocks = <&p_clk>, <&p_clk>, <&p_clk>, <&rclk_clk>,
> +                                <&cp_clk>, <&zs_clk>, <&zs_clk>, <&zs_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_TMU1 R8A7792_CLK_TMU3
> +                               R8A7792_CLK_TMU2 R8A7792_CLK_CMT0
> +                               R8A7792_CLK_TMU0 R8A7792_CLK_VSP1DU1
> +                               R8A7792_CLK_VSP1DU0 R8A7792_CLK_VSP1_SY
> +                       >;
> +                       clock-output-names = "tmu1", "tmu3", "tmu2", "cmt0",
> +                                            "tmu0", "vsp1du1", "vsp1du0",

These are called "vsp1-du1", "vsp1-du0" in all other R-Car Gen2 dtsis.

> +                                            "vsp1-sy";
> +               };
> +               mstp2_clks: mstp2_clks at e6150138 {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe6150138 0 4>, <0 0xe6150040 0 4>;
> +                       clocks = <&mp_clk>, <&zs_clk>, <&zs_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_MSIOF1
> +                               R8A7792_CLK_SYS_DMAC0 R8A7792_CLK_SYS_DMAC1

Wrong order of the DMACs.

> +                       >;
> +                       clock-output-names = "msiof1", "sys-dmac0", "sys-dmac1";

Wrong order of the DMACs.

> +               };
> +               mstp3_clks: mstp3_clks at e615013c {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>;
> +                       clocks = <&cp_clk>, <&cpg_clocks R8A7792_CLK_SD0>,

As there's no SD0, this can't be correct.

> +                                <&rclk_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_TPU0 R8A7792_CLK_SDHI0
> +                               R8A7792_CLK_CMT1
> +                       >;
> +                       clock-output-names = "tpu0", "sdhi0", "cmt1";
> +               };

> +               mstp5_clks: mstp5_clks at e6150144 {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>;
> +                       clocks = <&hp_clk>, <&extal_clk>, <&p_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_AUDIO_DMAC0
> +                               R8A7792_CLK_THERMAL R8A7792_CLK_PWM
> +                       >;
> +                       clock-output-names = "thermal", "pwm", "audmac0";

clock-output-names = "audmac0", "thermal", "pwm";

> +               };


> +               mstp9_clks: mstp9_clks at e6150994 {
> +                       compatible = "renesas,r8a7792-mstp-clocks",
> +                                    "renesas,cpg-mstp-clocks";
> +                       reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>;
> +                       clocks = <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
> +                                <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
> +                                <&cp_clk>, <&cp_clk>, <&p_clk>, <&p_clk>,
> +                                <&cpg_clocks R8A7792_CLK_QSPI>, <&cp_clk>,
> +                                <&cp_clk>, <&hp_clk>, <&cp_clk>, <&hp_clk>,
> +                                <&hp_clk>, <&hp_clk>, <&hp_clk>, <&hp_clk>;
> +                       #clock-cells = <1>;
> +                       clock-indices = <
> +                               R8A7792_CLK_GPIO7 R8A7792_CLK_GPIO6
> +                               R8A7792_CLK_GPIO5 R8A7792_CLK_GPIO4
> +                               R8A7792_CLK_GPIO3 R8A7792_CLK_GPIO2
> +                               R8A7792_CLK_GPIO1 R8A7792_CLK_GPIO0
> +                               R8A7792_CLK_GPIO11 R8A7792_CLK_GPIO10
> +                               R8A7792_CLK_CAN1 R8A7792_CLK_CAN0
> +                               R8A7792_CLK_QSPI_MOD R8A7792_CLK_GPIO9
> +                               R8A7792_CLK_GPIO8 R8A7792_CLK_I2C5
> +                               R8A7792_CLK_IICDVFS R8A7792_CLK_I2C4
> +                               R8A7792_CLK_I2C3 R8A7792_CLK_I2C2
> +                               R8A7792_CLK_I2C1 R8A7792_CLK_I2C0
> +                       >;
> +                       clock-output-names = "gpio7", "gpio6", "gpio5", "gpio4",
> +                                            "gpio3", "gpio2", "gpio1", "gpio0",
> +                                            "gpio11", "gpio10", "can1", "can0",

These are called "rcan1", "rcan0" in other dtsis.

> +                                            "qspi_mod", "gpio9", "gpio8",
> +                                            "i2c5", "iic3", "i2c4", "i2c3",
> +                                            "i2c2", "i2c1", "i2c0";
> +               };

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 08/13] ARM: dts: r8a7792: add SYS-DMAC support

[Sergei Shtylyov]

Describe SYS-DMAC0/1 in the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792.dtsi |   60 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -80,6 +80,66 @@
 		#power-domain-cells = <1>;
 	};
 
+	dmac0: dma-controller@e6700000 {
+		compatible = "renesas,dmac-r8a7792", "renesas,rcar-dmac";
+		reg = <0 0xe6700000 0 0x20000>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				  "ch0", "ch1", "ch2", "ch3", "ch4", "ch5",
+				  "ch6", "ch7", "ch8", "ch9", "ch10", "ch11",
+				  "ch12", "ch13", "ch14";
+		clocks = <&mstp2_clks R8A7792_CLK_SYS_DMAC0>;
+		clock-names = "fck";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		#dma-cells = <1>;
+		dma-channels = <15>;
+	};
+
+	dmac1: dma-controller@e6720000 {
+		compatible = "renesas,dmac-r8a7792", "renesas,rcar-dmac";
+		reg = <0 0xe6720000 0 0x20000>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				  "ch0", "ch1", "ch2", "ch3", "ch4", "ch5",
+				  "ch6", "ch7",	"ch8", "ch9", "ch10", "ch11",
+				  "ch12", "ch13", "ch14";
+		clocks = <&mstp2_clks R8A7792_CLK_SYS_DMAC1>;
+		clock-names = "fck";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		#dma-cells = <1>;
+		dma-channels = <15>;
+	};
+
 	clocks {
 		#address-cells = <2>;
 		#size-cells = <2>;

[PATCH 08/13] ARM: dts: r8a7792: add SYS-DMAC support

[Sergei Shtylyov]

Describe SYS-DMAC0/1 in the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792.dtsi |   60 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -80,6 +80,66 @@
 		#power-domain-cells = <1>;
 	};
 
+	dmac0: dma-controller at e6700000 {
+		compatible = "renesas,dmac-r8a7792", "renesas,rcar-dmac";
+		reg = <0 0xe6700000 0 0x20000>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				  "ch0", "ch1", "ch2", "ch3", "ch4", "ch5",
+				  "ch6", "ch7", "ch8", "ch9", "ch10", "ch11",
+				  "ch12", "ch13", "ch14";
+		clocks = <&mstp2_clks R8A7792_CLK_SYS_DMAC0>;
+		clock-names = "fck";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		#dma-cells = <1>;
+		dma-channels = <15>;
+	};
+
+	dmac1: dma-controller at e6720000 {
+		compatible = "renesas,dmac-r8a7792", "renesas,rcar-dmac";
+		reg = <0 0xe6720000 0 0x20000>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				  "ch0", "ch1", "ch2", "ch3", "ch4", "ch5",
+				  "ch6", "ch7",	"ch8", "ch9", "ch10", "ch11",
+				  "ch12", "ch13", "ch14";
+		clocks = <&mstp2_clks R8A7792_CLK_SYS_DMAC1>;
+		clock-names = "fck";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		#dma-cells = <1>;
+		dma-channels = <15>;
+	};
+
 	clocks {
 		#address-cells = <2>;
 		#size-cells = <2>;

Re: [PATCH 08/13] ARM: dts: r8a7792: add SYS-DMAC support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:25:24AM +0300, Sergei Shtylyov wrote:
> Describe SYS-DMAC0/1 in the R8A7792 device tree.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

[PATCH 08/13] ARM: dts: r8a7792: add SYS-DMAC support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:25:24AM +0300, Sergei Shtylyov wrote:
> Describe SYS-DMAC0/1 in the R8A7792 device tree.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

Re: [PATCH 08/13] ARM: dts: r8a7792: add SYS-DMAC support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:25 AM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> Describe SYS-DMAC0/1 in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/13] ARM: dts: r8a7792: add SYS-DMAC support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:25 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe SYS-DMAC0/1 in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 08/13] ARM: dts: r8a7792: add SYS-DMAC support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:25 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe SYS-DMAC0/1 in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Sergei Shtylyov]

Describe [H]SCIFs in the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792.dtsi |   90 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -140,6 +140,96 @@
 		dma-channels = <15>;
 	};
 
+	scif0: serial@e6e60000 {
+		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
+		reg = <0 0xe6e60000 0 64>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
+		       <&dmac1 0x29>, <&dmac1 0x2a>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	scif1: serial@e6e68000 {
+		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
+		reg = <0 0xe6e68000 0 64>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
+		       <&dmac1 0x2d>, <&dmac1 0x2e>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	scif2: serial@e6e58000 {
+		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
+		reg = <0 0xe6e58000 0 64>;
+		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
+		       <&dmac1 0x2b>, <&dmac1 0x2c>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	scif3: serial@e6ea8000 {
+		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
+		reg = <0 0xe6ea8000 0 64>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
+		       <&dmac1 0x2f>, <&dmac1 0x30>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	hscif0: serial@e62c0000 {
+		compatible = "renesas,hscif-r8a7792", "renesas,rcar-gen2-hscif",
+			     "renesas,hscif";
+		reg = <0 0xe62c0000 0 96>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
+		       <&dmac1 0x39>, <&dmac1 0x3a>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	hscif1: serial@e62c8000 {
+		compatible = "renesas,hscif-r8a7792", "renesas,rcar-gen2-hscif",
+			     "renesas,hscif";
+		reg = <0 0xe62c8000 0 96>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
+		       <&dmac1 0x4d>, <&dmac1 0x4e>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
 	clocks {
 		#address-cells = <2>;
 		#size-cells = <2>;

[PATCH 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Sergei Shtylyov]

Describe [H]SCIFs in the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792.dtsi |   90 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -140,6 +140,96 @@
 		dma-channels = <15>;
 	};
 
+	scif0: serial at e6e60000 {
+		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
+		reg = <0 0xe6e60000 0 64>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
+		       <&dmac1 0x29>, <&dmac1 0x2a>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	scif1: serial at e6e68000 {
+		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
+		reg = <0 0xe6e68000 0 64>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
+		       <&dmac1 0x2d>, <&dmac1 0x2e>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	scif2: serial at e6e58000 {
+		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
+		reg = <0 0xe6e58000 0 64>;
+		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
+		       <&dmac1 0x2b>, <&dmac1 0x2c>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	scif3: serial at e6ea8000 {
+		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
+		reg = <0 0xe6ea8000 0 64>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
+		       <&dmac1 0x2f>, <&dmac1 0x30>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	hscif0: serial at e62c0000 {
+		compatible = "renesas,hscif-r8a7792", "renesas,rcar-gen2-hscif",
+			     "renesas,hscif";
+		reg = <0 0xe62c0000 0 96>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
+		       <&dmac1 0x39>, <&dmac1 0x3a>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
+	hscif1: serial at e62c8000 {
+		compatible = "renesas,hscif-r8a7792", "renesas,rcar-gen2-hscif",
+			     "renesas,hscif";
+		reg = <0 0xe62c8000 0 96>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp7_clks R8A7792_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
+		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
+		       <&dmac1 0x4d>, <&dmac1 0x4e>;
+		dma-names = "tx", "rx", "tx", "rx";
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+		status = "disabled";
+	};
+
 	clocks {
 		#address-cells = <2>;
 		#size-cells = <2>;

Re: [PATCH 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:26:56AM +0300, Sergei Shtylyov wrote:
> Describe [H]SCIFs in the R8A7792 device tree.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

This looks correct to me.

I am wondering if you have been able to confirm DMA operation of the
devices enabled later on in the series.

> 
> ---
>  arch/arm/boot/dts/r8a7792.dtsi |   90 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
> 
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -140,6 +140,96 @@
>  		dma-channels = <15>;
>  	};
>  
> +	scif0: serial@e6e60000 {
> +		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
> +			     "renesas,scif";
> +		reg = <0 0xe6e60000 0 64>;
> +		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_SCIF0>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
> +		       <&dmac1 0x29>, <&dmac1 0x2a>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	scif1: serial@e6e68000 {
> +		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
> +			     "renesas,scif";
> +		reg = <0 0xe6e68000 0 64>;
> +		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_SCIF1>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
> +		       <&dmac1 0x2d>, <&dmac1 0x2e>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	scif2: serial@e6e58000 {
> +		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
> +			     "renesas,scif";
> +		reg = <0 0xe6e58000 0 64>;
> +		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_SCIF2>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
> +		       <&dmac1 0x2b>, <&dmac1 0x2c>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	scif3: serial@e6ea8000 {
> +		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
> +			     "renesas,scif";
> +		reg = <0 0xe6ea8000 0 64>;
> +		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_SCIF3>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
> +		       <&dmac1 0x2f>, <&dmac1 0x30>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	hscif0: serial@e62c0000 {
> +		compatible = "renesas,hscif-r8a7792", "renesas,rcar-gen2-hscif",
> +			     "renesas,hscif";
> +		reg = <0 0xe62c0000 0 96>;
> +		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_HSCIF0>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
> +		       <&dmac1 0x39>, <&dmac1 0x3a>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	hscif1: serial@e62c8000 {
> +		compatible = "renesas,hscif-r8a7792", "renesas,rcar-gen2-hscif",
> +			     "renesas,hscif";
> +		reg = <0 0xe62c8000 0 96>;
> +		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_HSCIF1>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
> +		       <&dmac1 0x4d>, <&dmac1 0x4e>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
>  	clocks {
>  		#address-cells = <2>;
>  		#size-cells = <2>;
> 

[PATCH 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:26:56AM +0300, Sergei Shtylyov wrote:
> Describe [H]SCIFs in the R8A7792 device tree.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

This looks correct to me.

I am wondering if you have been able to confirm DMA operation of the
devices enabled later on in the series.

> 
> ---
>  arch/arm/boot/dts/r8a7792.dtsi |   90 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
> 
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -140,6 +140,96 @@
>  		dma-channels = <15>;
>  	};
>  
> +	scif0: serial at e6e60000 {
> +		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
> +			     "renesas,scif";
> +		reg = <0 0xe6e60000 0 64>;
> +		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_SCIF0>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
> +		       <&dmac1 0x29>, <&dmac1 0x2a>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	scif1: serial at e6e68000 {
> +		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
> +			     "renesas,scif";
> +		reg = <0 0xe6e68000 0 64>;
> +		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_SCIF1>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
> +		       <&dmac1 0x2d>, <&dmac1 0x2e>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	scif2: serial at e6e58000 {
> +		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
> +			     "renesas,scif";
> +		reg = <0 0xe6e58000 0 64>;
> +		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_SCIF2>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
> +		       <&dmac1 0x2b>, <&dmac1 0x2c>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	scif3: serial at e6ea8000 {
> +		compatible = "renesas,scif-r8a7792", "renesas,rcar-gen2-scif",
> +			     "renesas,scif";
> +		reg = <0 0xe6ea8000 0 64>;
> +		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_SCIF3>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
> +		       <&dmac1 0x2f>, <&dmac1 0x30>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	hscif0: serial at e62c0000 {
> +		compatible = "renesas,hscif-r8a7792", "renesas,rcar-gen2-hscif",
> +			     "renesas,hscif";
> +		reg = <0 0xe62c0000 0 96>;
> +		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_HSCIF0>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
> +		       <&dmac1 0x39>, <&dmac1 0x3a>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
> +	hscif1: serial at e62c8000 {
> +		compatible = "renesas,hscif-r8a7792", "renesas,rcar-gen2-hscif",
> +			     "renesas,hscif";
> +		reg = <0 0xe62c8000 0 96>;
> +		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp7_clks R8A7792_CLK_HSCIF1>, <&zs_clk>,
> +			 <&scif_clk>;
> +		clock-names = "fck", "brg_int", "scif_clk";
> +		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
> +		       <&dmac1 0x4d>, <&dmac1 0x4e>;
> +		dma-names = "tx", "rx", "tx", "rx";
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +		status = "disabled";
> +	};
> +
>  	clocks {
>  		#address-cells = <2>;
>  		#size-cells = <2>;
> 

Re: [PATCH 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Sergei Shtylyov]

On 06/01/2016 04:13 AM, Simon Horman wrote:

>> Describe [H]SCIFs in the R8A7792 device tree.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> This looks correct to me.
>
> I am wondering if you have been able to confirm DMA operation of the
> devices enabled later on in the series.

    The SCIF DMA seems to work now that enabled it in the driver. Not sure 
what you meant by "the devices enabled later in the seties"...

MBR, Sergei

[PATCH 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Sergei Shtylyov]

On 06/01/2016 04:13 AM, Simon Horman wrote:

>> Describe [H]SCIFs in the R8A7792 device tree.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> This looks correct to me.
>
> I am wondering if you have been able to confirm DMA operation of the
> devices enabled later on in the series.

    The SCIF DMA seems to work now that enabled it in the driver. Not sure 
what you meant by "the devices enabled later in the seties"...

MBR, Sergei

Re: [PATCH 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:26 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe [H]SCIFs in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 09/13] ARM: dts: r8a7792: add [H]SCIF support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:26 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe [H]SCIFs in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Sergei Shtylyov]

Describe the IRQC interrupt controller in the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792.dtsi |   13 +++++++++++++
 1 file changed, 13 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -62,6 +62,19 @@
 			      IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
+	irqc: interrupt-controller@e61c0000 {
+		compatible = "renesas,irqc-r8a7792", "renesas,irqc";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0 0xe61c0000 0 0x200>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp4_clks R8A7792_CLK_IRQC>;
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		interrupts = <GIC_PPI 13

[PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Sergei Shtylyov]

Describe the IRQC interrupt controller in the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792.dtsi |   13 +++++++++++++
 1 file changed, 13 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -62,6 +62,19 @@
 			      IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
+	irqc: interrupt-controller at e61c0000 {
+		compatible = "renesas,irqc-r8a7792", "renesas,irqc";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0 0xe61c0000 0 0x200>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp4_clks R8A7792_CLK_IRQC>;
+		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		interrupts = <GIC_PPI 13

Re: [PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:29:05AM +0300, Sergei Shtylyov wrote:
> Describe the IRQC interrupt controller in the R8A7792 device tree.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> ---
>  arch/arm/boot/dts/r8a7792.dtsi |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -62,6 +62,19 @@
>  			      IRQ_TYPE_LEVEL_HIGH)>;
>  	};
>  
> +	irqc: interrupt-controller@e61c0000 {

Could you consider using irqc0 as the node name for consistency with the
DT of other R-Car Gen2 SoCs?

What follows looks correct to me.

> +		compatible = "renesas,irqc-r8a7792", "renesas,irqc";
> +		#interrupt-cells = <2>;
> +		interrupt-controller;
> +		reg = <0 0xe61c0000 0 0x200>;
> +		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp4_clks R8A7792_CLK_IRQC>;
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +	};
> +
>  	timer {
>  		compatible = "arm,armv7-timer";
>  		interrupts = <GIC_PPI 13
> 

[PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:29:05AM +0300, Sergei Shtylyov wrote:
> Describe the IRQC interrupt controller in the R8A7792 device tree.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> ---
>  arch/arm/boot/dts/r8a7792.dtsi |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -62,6 +62,19 @@
>  			      IRQ_TYPE_LEVEL_HIGH)>;
>  	};
>  
> +	irqc: interrupt-controller at e61c0000 {

Could you consider using irqc0 as the node name for consistency with the
DT of other R-Car Gen2 SoCs?

What follows looks correct to me.

> +		compatible = "renesas,irqc-r8a7792", "renesas,irqc";
> +		#interrupt-cells = <2>;
> +		interrupt-controller;
> +		reg = <0 0xe61c0000 0 0x200>;
> +		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&mstp4_clks R8A7792_CLK_IRQC>;
> +		power-domains = <&sysc R8A7792_PD_ALWAYS_ON>;
> +	};
> +
>  	timer {
>  		compatible = "arm,armv7-timer";
>  		interrupts = <GIC_PPI 13
> 

Re: [PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Sergei Shtylyov]

On 06/01/2016 04:18 AM, Simon Horman wrote:

>> Describe the IRQC interrupt controller in the R8A7792 device tree.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>>  arch/arm/boot/dts/r8a7792.dtsi |   13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
>> ===================================================================
>> --- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
>> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
>> @@ -62,6 +62,19 @@
>>  			      IRQ_TYPE_LEVEL_HIGH)>;
>>  	};
>>
>> +	irqc: interrupt-controller@e61c0000 {
>
> Could you consider using irqc0 as the node name for consistency with the
> DT of other R-Car Gen2 SoCs?

    Frankly speaking I didn't get that name indexing thing at all. Could you 
share the reasoning behind it?

> What follows looks correct to me.

    Thank you. :-)

MBR, Sergei

[PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Sergei Shtylyov]

On 06/01/2016 04:18 AM, Simon Horman wrote:

>> Describe the IRQC interrupt controller in the R8A7792 device tree.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>>  arch/arm/boot/dts/r8a7792.dtsi |   13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
>> ===================================================================
>> --- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
>> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
>> @@ -62,6 +62,19 @@
>>  			      IRQ_TYPE_LEVEL_HIGH)>;
>>  	};
>>
>> +	irqc: interrupt-controller at e61c0000 {
>
> Could you consider using irqc0 as the node name for consistency with the
> DT of other R-Car Gen2 SoCs?

    Frankly speaking I didn't get that name indexing thing at all. Could you 
share the reasoning behind it?

> What follows looks correct to me.

    Thank you. :-)

MBR, Sergei

Re: [PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:29 AM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> Describe the IRQC interrupt controller in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:29 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe the IRQC interrupt controller in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 10/13] ARM: dts: r8a7792: add IRQC support

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:29 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe the IRQC interrupt controller in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 11/13] DT: arm: shmobile: document Blanche board

[Sergei Shtylyov]

Document the Blanche device tree bindings, listing it as a supported board.

This allows to use checkpatch.pl to validate .dts files referring to the
Blanche board.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 Documentation/devicetree/bindings/arm/shmobile.txt |    2 ++
 1 file changed, 2 insertions(+)

Index: renesas/Documentation/devicetree/bindings/arm/shmobile.txt
===================================================================
--- renesas.orig/Documentation/devicetree/bindings/arm/shmobile.txt
+++ renesas/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -39,6 +39,8 @@ Boards:
     compatible = "renesas,ape6evm", "renesas,r8a73a4"
   - Atmark Techno Armadillo-800 EVA
     compatible = "renesas,armadillo800eva"
+  - Blanche (RTP0RC7792SEB00010S)
+    compatible = "renesas,blanche", "renesas,r8a7792"
   - BOCK-W
     compatible = "renesas,bockw", "renesas,r8a7778"
   - Genmai (RTK772100BC00000BR)

Re: [PATCH 11/13] DT: arm: shmobile: document Blanche board

[Simon Horman]

On Wed, Jun 01, 2016 at 01:30:39AM +0300, Sergei Shtylyov wrote:
> Document the Blanche device tree bindings, listing it as a supported board.
> 
> This allows to use checkpatch.pl to validate .dts files referring to the
> Blanche board.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

I think the prefix for patch 11 should be: "ARM: dts: blanche: "
It also looks like it could be squashed into patch 12 but I don't
feel strongly about that.

> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: renesas/Documentation/devicetree/bindings/arm/shmobile.txt
> ===================================================================
> --- renesas.orig/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ renesas/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -39,6 +39,8 @@ Boards:
>      compatible = "renesas,ape6evm", "renesas,r8a73a4"
>    - Atmark Techno Armadillo-800 EVA
>      compatible = "renesas,armadillo800eva"
> +  - Blanche (RTP0RC7792SEB00010S)
> +    compatible = "renesas,blanche", "renesas,r8a7792"
>    - BOCK-W
>      compatible = "renesas,bockw", "renesas,r8a7778"
>    - Genmai (RTK772100BC00000BR)
> 

Re: [PATCH 11/13] DT: arm: shmobile: document Blanche board

[Sergei Shtylyov]

Hello.

On 06/01/2016 02:51 AM, Simon Horman wrote:

>> Document the Blanche device tree bindings, listing it as a supported board.
>>
>> This allows to use checkpatch.pl to validate .dts files referring to the
>> Blanche board.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>
> I think the prefix for patch 11 should be: "ARM: dts: blanche: "

     Hm... why?

> It also looks like it could be squashed into patch 12 but I don't
> feel strongly about that.

    I'd prefer not to merge them.

[...]

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/13] DT: arm: shmobile: document Blanche board

[Sergei Shtylyov]

Hello.

On 06/01/2016 02:51 AM, Simon Horman wrote:

>> Document the Blanche device tree bindings, listing it as a supported board.
>>
>> This allows to use checkpatch.pl to validate .dts files referring to the
>> Blanche board.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> I think the prefix for patch 11 should be: "ARM: dts: blanche: "

     Hm... why?

> It also looks like it could be squashed into patch 12 but I don't
> feel strongly about that.

    I'd prefer not to merge them.

[...]

MBR, Sergei

Re: [PATCH 11/13] DT: arm: shmobile: document Blanche board

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:30 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Document the Blanche device tree bindings, listing it as a supported board.
>
> This allows to use checkpatch.pl to validate .dts files referring to the
> Blanche board.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

I can't verify the correctness of the board product ID, though.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 11/13] DT: arm: shmobile: document Blanche board

[Rob Herring]

On Wed, Jun 01, 2016 at 01:30:39AM +0300, Sergei Shtylyov wrote:
> Document the Blanche device tree bindings, listing it as a supported board.
> 
> This allows to use checkpatch.pl to validate .dts files referring to the
> Blanche board.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Acked-by: Rob Herring <robh@kernel.org>

[PATCH 12/13] ARM: dts: blanche: initial device tree

[Sergei Shtylyov]

Add the initial device  tree for the R8A7792 SoC based Blanche board.
The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
them,  so that  the serial console  can  work.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/Makefile            |    1 
 arch/arm/boot/dts/r8a7792-blanche.dts |   44 ++++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+)

Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -638,6 +638,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
 	r8a7790-lager.dtb \
 	r8a7791-koelsch.dtb \
 	r8a7791-porter.dtb \
+	r8a7792-blanche.dtb \
 	r8a7793-gose.dtb \
 	r8a7794-alt.dtb \
 	r8a7794-silk.dtb \
Index: renesas/arch/arm/boot/dts/r8a7792-blanche.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the Blanche board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7792.dtsi"
+
+/ {
+	model = "Blanche";
+	compatible = "renesas,blanche", "renesas,r8a7792";
+
+	aliases {
+		serial0 = &scif0;
+		serial1 = &scif3;
+	};
+
+	chosen {
+		bootargs = "ignore_loglevel";
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0 0x40000000 0 0x40000000>;
+	};
+};
+
+&extal_clk {
+	clock-frequency = <20000000>;
+};
+
+&scif0 {
+	status = "okay";
+};
+
+&scif3 {
+	status = "okay";
+};

[PATCH 12/13] ARM: dts: blanche: initial device tree

[Sergei Shtylyov]

Add the initial device  tree for the R8A7792 SoC based Blanche board.
The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
them,  so that  the serial console  can  work.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/Makefile            |    1 
 arch/arm/boot/dts/r8a7792-blanche.dts |   44 ++++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+)

Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -638,6 +638,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
 	r8a7790-lager.dtb \
 	r8a7791-koelsch.dtb \
 	r8a7791-porter.dtb \
+	r8a7792-blanche.dtb \
 	r8a7793-gose.dtb \
 	r8a7794-alt.dtb \
 	r8a7794-silk.dtb \
Index: renesas/arch/arm/boot/dts/r8a7792-blanche.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the Blanche board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7792.dtsi"
+
+/ {
+	model = "Blanche";
+	compatible = "renesas,blanche", "renesas,r8a7792";
+
+	aliases {
+		serial0 = &scif0;
+		serial1 = &scif3;
+	};
+
+	chosen {
+		bootargs = "ignore_loglevel";
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		reg = <0 0x40000000 0 0x40000000>;
+	};
+};
+
+&extal_clk {
+	clock-frequency = <20000000>;
+};
+
+&scif0 {
+	status = "okay";
+};
+
+&scif3 {
+	status = "okay";
+};

Re: [PATCH 12/13] ARM: dts: blanche: initial device tree

[Simon Horman]

On Wed, Jun 01, 2016 at 01:32:35AM +0300, Sergei Shtylyov wrote:
> Add the initial device  tree for the R8A7792 SoC based Blanche board.
> The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
> them,  so that  the serial console  can  work.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

At this time I do not have access to documentation or hardware for this
board. So I am relying on you to test this and make sure it complies
with the spec.

What you have looks reasonable to me:

Acked-by: Simon Horman <horms+renesas@verge.net.au>

[PATCH 12/13] ARM: dts: blanche: initial device tree

[Simon Horman]

On Wed, Jun 01, 2016 at 01:32:35AM +0300, Sergei Shtylyov wrote:
> Add the initial device  tree for the R8A7792 SoC based Blanche board.
> The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
> them,  so that  the serial console  can  work.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

At this time I do not have access to documentation or hardware for this
board. So I am relying on you to test this and make sure it complies
with the spec.

What you have looks reasonable to me:

Acked-by: Simon Horman <horms+renesas@verge.net.au>

Re: [PATCH 12/13] ARM: dts: blanche: initial device tree

[Sergei Shtylyov]

On 06/01/2016 04:21 AM, Simon Horman wrote:

>> Add the initial device  tree for the R8A7792 SoC based Blanche board.
>> The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
>> them,  so that  the serial console  can  work.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> At this time I do not have access to documentation or hardware for this
> board. So I am relying on you to test this and make sure it complies
> with the spec.

    Don't worry, the patches have been tested on the real hardware.

> What you have looks reasonable to me:
>
> Acked-by: Simon Horman <horms+renesas@verge.net.au>

    Thank you. :-)

MBR, Sergei

[PATCH 12/13] ARM: dts: blanche: initial device tree

[Sergei Shtylyov]

On 06/01/2016 04:21 AM, Simon Horman wrote:

>> Add the initial device  tree for the R8A7792 SoC based Blanche board.
>> The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
>> them,  so that  the serial console  can  work.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> At this time I do not have access to documentation or hardware for this
> board. So I am relying on you to test this and make sure it complies
> with the spec.

    Don't worry, the patches have been tested on the real hardware.

> What you have looks reasonable to me:
>
> Acked-by: Simon Horman <horms+renesas@verge.net.au>

    Thank you. :-)

MBR, Sergei

Re: [PATCH 12/13] ARM: dts: blanche: initial device tree

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:32 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add the initial device  tree for the R8A7792 SoC based Blanche board.
> The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
> them,  so that  the serial console  can  work.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 12/13] ARM: dts: blanche: initial device tree

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:32 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add the initial device  tree for the R8A7792 SoC based Blanche board.
> The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
> them,  so that  the serial console  can  work.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 12/13] ARM: dts: blanche: initial device tree

[Geert Uytterhoeven]

On Wed, Jun 1, 2016 at 12:32 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add the initial device  tree for the R8A7792 SoC based Blanche board.
> The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
> them,  so that  the serial console  can  work.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Sergei Shtylyov]

R8A7792  SoC  doesn't have the EtherMAC core, so SMSC  LAN89218  Ethernet
chip was used instead on the Blanche board; this chip  is compatible with
SMSC LAN9115  for  which there's a (device tree aware) driver. Describe
the  chip in  the  Blanche device tree;  enable DHCP and NFS root in the
kernel command line for the kernel booting.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792-blanche.dts |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/boot/dts/r8a7792-blanche.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
+++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -21,7 +21,7 @@
 	};
 
 	chosen {
-		bootargs = "ignore_loglevel";
+		bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
 		stdout-path = "serial0:115200n8";
 	};
 
@@ -29,6 +29,27 @@
 		device_type = "memory";
 		reg = <0 0x40000000 0 0x40000000>;
 	};
+
+	d3_3v: regulator-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "D3.3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+	ethernet@18000000 {
+		compatible = "smsc,lan89218", "smsc,lan9115";
+		reg = <0 0x18000000 0 0x100>;
+		phy-mode = "mii";
+		interrupt-parent = <&irqc>;
+		interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+		smsc,irq-push-pull;
+		reg-io-width = <4>;
+		vddvario-supply = <&d3_3v>;
+		vdd33a-supply = <&d3_3v>;
+	};
 };
 
 &extal_clk {

[PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Sergei Shtylyov]

R8A7792  SoC  doesn't have the EtherMAC core, so SMSC  LAN89218  Ethernet
chip was used instead on the Blanche board; this chip  is compatible with
SMSC LAN9115  for  which there's a (device tree aware) driver. Describe
the  chip in  the  Blanche device tree;  enable DHCP and NFS root in the
kernel command line for the kernel booting.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/r8a7792-blanche.dts |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/boot/dts/r8a7792-blanche.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
+++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -21,7 +21,7 @@
 	};
 
 	chosen {
-		bootargs = "ignore_loglevel";
+		bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
 		stdout-path = "serial0:115200n8";
 	};
 
@@ -29,6 +29,27 @@
 		device_type = "memory";
 		reg = <0 0x40000000 0 0x40000000>;
 	};
+
+	d3_3v: regulator-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "D3.3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+	ethernet at 18000000 {
+		compatible = "smsc,lan89218", "smsc,lan9115";
+		reg = <0 0x18000000 0 0x100>;
+		phy-mode = "mii";
+		interrupt-parent = <&irqc>;
+		interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+		smsc,irq-push-pull;
+		reg-io-width = <4>;
+		vddvario-supply = <&d3_3v>;
+		vdd33a-supply = <&d3_3v>;
+	};
 };
 
 &extal_clk {

Re: [PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:33:49AM +0300, Sergei Shtylyov wrote:
> R8A7792  SoC  doesn't have the EtherMAC core, so SMSC  LAN89218  Ethernet
> chip was used instead on the Blanche board; this chip  is compatible with
> SMSC LAN9115  for  which there's a (device tree aware) driver. Describe
> the  chip in  the  Blanche device tree;  enable DHCP and NFS root in the
> kernel command line for the kernel booting.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

At this time I do not have access to documentation or hardware for this
board. So I am relying on you to test this and make sure it complies
with the spec.

What you have looks reasonable to me:

Acked-by: Simon Horman <horms+renesas@verge.net.au>

[PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Simon Horman]

On Wed, Jun 01, 2016 at 01:33:49AM +0300, Sergei Shtylyov wrote:
> R8A7792  SoC  doesn't have the EtherMAC core, so SMSC  LAN89218  Ethernet
> chip was used instead on the Blanche board; this chip  is compatible with
> SMSC LAN9115  for  which there's a (device tree aware) driver. Describe
> the  chip in  the  Blanche device tree;  enable DHCP and NFS root in the
> kernel command line for the kernel booting.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

At this time I do not have access to documentation or hardware for this
board. So I am relying on you to test this and make sure it complies
with the spec.

What you have looks reasonable to me:

Acked-by: Simon Horman <horms+renesas@verge.net.au>

Re: [PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:33 AM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts

> +       ethernet@18000000 {
> +               compatible = "smsc,lan89218", "smsc,lan9115";

The "smsc,lan89218" needs to be documented in the device tree bindings.
Google couldn't find any evidence you submitted a patch for that.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:33 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts

> +       ethernet at 18000000 {
> +               compatible = "smsc,lan89218", "smsc,lan9115";

The "smsc,lan89218" needs to be documented in the device tree bindings.
Google couldn't find any evidence you submitted a patch for that.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:33 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts

> +       ethernet@18000000 {
> +               compatible = "smsc,lan89218", "smsc,lan9115";

The "smsc,lan89218" needs to be documented in the device tree bindings.
Google couldn't find any evidence you submitted a patch for that.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Sergei Shtylyov]

Hello.

On 6/1/2016 11:22 AM, Geert Uytterhoeven wrote:

>> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
>> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
>
>> +       ethernet@18000000 {
>> +               compatible = "smsc,lan89218", "smsc,lan9115";
>
> The "smsc,lan89218" needs to be documented in the device tree bindings.

    Have you looked at those bindings?

> Google couldn't find any evidence you submitted a patch for that.

    Because the bindings document *any* LAN9115 compatible chip already.

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Sergei Shtylyov]

Hello.

On 6/1/2016 11:22 AM, Geert Uytterhoeven wrote:

>> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
>> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
>
>> +       ethernet at 18000000 {
>> +               compatible = "smsc,lan89218", "smsc,lan9115";
>
> The "smsc,lan89218" needs to be documented in the device tree bindings.

    Have you looked at those bindings?

> Google couldn't find any evidence you submitted a patch for that.

    Because the bindings document *any* LAN9115 compatible chip already.

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

Re: [PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 2:16 PM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> On 6/1/2016 11:22 AM, Geert Uytterhoeven wrote:
>>> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
>>> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
>>
>>> +       ethernet@18000000 {
>>> +               compatible = "smsc,lan89218", "smsc,lan9115";
>>
>>
>> The "smsc,lan89218" needs to be documented in the device tree bindings.
>
>    Have you looked at those bindings?

Now I did.

>> Google couldn't find any evidence you submitted a patch for that.
>
>    Because the bindings document *any* LAN9115 compatible chip already.

Ah, generic wildcard, not listing valid values. Hence checkpatch complained...

Google predict-while-you-type suggests "lan89218aq"? Should you use that?
BTW, that's why we always want to document all valid values...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 2:16 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 6/1/2016 11:22 AM, Geert Uytterhoeven wrote:
>>> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
>>> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
>>
>>> +       ethernet at 18000000 {
>>> +               compatible = "smsc,lan89218", "smsc,lan9115";
>>
>>
>> The "smsc,lan89218" needs to be documented in the device tree bindings.
>
>    Have you looked at those bindings?

Now I did.

>> Google couldn't find any evidence you submitted a patch for that.
>
>    Because the bindings document *any* LAN9115 compatible chip already.

Ah, generic wildcard, not listing valid values. Hence checkpatch complained...

Google predict-while-you-type suggests "lan89218aq"? Should you use that?
BTW, that's why we always want to document all valid values...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 2:16 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 6/1/2016 11:22 AM, Geert Uytterhoeven wrote:
>>> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
>>> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
>>
>>> +       ethernet@18000000 {
>>> +               compatible = "smsc,lan89218", "smsc,lan9115";
>>
>>
>> The "smsc,lan89218" needs to be documented in the device tree bindings.
>
>    Have you looked at those bindings?

Now I did.

>> Google couldn't find any evidence you submitted a patch for that.
>
>    Because the bindings document *any* LAN9115 compatible chip already.

Ah, generic wildcard, not listing valid values. Hence checkpatch complained...

Google predict-while-you-type suggests "lan89218aq"? Should you use that?
BTW, that's why we always want to document all valid values...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Sergei Shtylyov]

On 06/01/2016 03:27 PM, Geert Uytterhoeven wrote:

>>>> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
>>>> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
>>>
>>>> +       ethernet@18000000 {
>>>> +               compatible = "smsc,lan89218", "smsc,lan9115";
>>>
>>>
>>> The "smsc,lan89218" needs to be documented in the device tree bindings.
>>
>>    Have you looked at those bindings?
>
> Now I did.
>
>>> Google couldn't find any evidence you submitted a patch for that.
>>
>>    Because the bindings document *any* LAN9115 compatible chip already.
>
> Ah, generic wildcard, not listing valid values. Hence checkpatch complained...

    Note that it doesn't complain about "smsc,lan9220" though that is only 
mentioned in the example.

> Google predict-while-you-type suggests "lan89218aq"? Should you use that?

    No, my googling shows that the suffix can be different, and the Microchip 
(the new owner?) has it without the suffix on their site.

> BTW, that's why we always want to document all valid values...

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH 13/13] ARM: dts: blanche: add Ethernet support

[Sergei Shtylyov]

On 06/01/2016 03:27 PM, Geert Uytterhoeven wrote:

>>>> --- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
>>>> +++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
>>>
>>>> +       ethernet at 18000000 {
>>>> +               compatible = "smsc,lan89218", "smsc,lan9115";
>>>
>>>
>>> The "smsc,lan89218" needs to be documented in the device tree bindings.
>>
>>    Have you looked at those bindings?
>
> Now I did.
>
>>> Google couldn't find any evidence you submitted a patch for that.
>>
>>    Because the bindings document *any* LAN9115 compatible chip already.
>
> Ah, generic wildcard, not listing valid values. Hence checkpatch complained...

    Note that it doesn't complain about "smsc,lan9220" though that is only 
mentioned in the example.

> Google predict-while-you-type suggests "lan89218aq"? Should you use that?

    No, my googling shows that the suffix can be different, and the Microchip 
(the new owner?) has it without the suffix on their site.

> BTW, that's why we always want to document all valid values...

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

Re: [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:06 AM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
>    Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
> 'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
> the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
> week separately...
>
> [01/13] ARM: shmobile: r8a7792: add clock index macros
> [02/13] ARM: shmobile: r8a7792: add power domain index macros
> [03/13] soc: renesas: rcar-sysc: add R8A7792 support
> [04/13] ARM: shmobile: r8a7792: basic SoC support
> [05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
> [06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
> [07/13] ARM: dts: r8a7792: initial SoC device tree
> [08/13] ARM: dts: r8a7792: add SYS-DMAC support
> [09/13] ARM: dts: r8a7792: add [H]SCIF support
> [10/13] ARM dts: r8a7792: add IRQC support
> [11/13] DT: arm: shmobile: document Blanche board
> [12/13] ARM: dts: blanche: initial device tree
> [13/13] ARM: dts: blanche: add Ethernet support

Thanks for your series!

The subject doesn't seem to cover the contents, though:
> [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:06 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>    Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
> 'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
> the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
> week separately...
>
> [01/13] ARM: shmobile: r8a7792: add clock index macros
> [02/13] ARM: shmobile: r8a7792: add power domain index macros
> [03/13] soc: renesas: rcar-sysc: add R8A7792 support
> [04/13] ARM: shmobile: r8a7792: basic SoC support
> [05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
> [06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
> [07/13] ARM: dts: r8a7792: initial SoC device tree
> [08/13] ARM: dts: r8a7792: add SYS-DMAC support
> [09/13] ARM: dts: r8a7792: add [H]SCIF support
> [10/13] ARM dts: r8a7792: add IRQC support
> [11/13] DT: arm: shmobile: document Blanche board
> [12/13] ARM: dts: blanche: initial device tree
> [13/13] ARM: dts: blanche: add Ethernet support

Thanks for your series!

The subject doesn't seem to cover the contents, though:
> [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Jun 1, 2016 at 12:06 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>    Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
> 'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
> the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
> week separately...
>
> [01/13] ARM: shmobile: r8a7792: add clock index macros
> [02/13] ARM: shmobile: r8a7792: add power domain index macros
> [03/13] soc: renesas: rcar-sysc: add R8A7792 support
> [04/13] ARM: shmobile: r8a7792: basic SoC support
> [05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
> [06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
> [07/13] ARM: dts: r8a7792: initial SoC device tree
> [08/13] ARM: dts: r8a7792: add SYS-DMAC support
> [09/13] ARM: dts: r8a7792: add [H]SCIF support
> [10/13] ARM dts: r8a7792: add IRQC support
> [11/13] DT: arm: shmobile: document Blanche board
> [12/13] ARM: dts: blanche: initial device tree
> [13/13] ARM: dts: blanche: add Ethernet support

Thanks for your series!

The subject doesn't seem to cover the contents, though:
> [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[Sergei Shtylyov]

Hello.

On 6/1/2016 10:04 AM, Geert Uytterhoeven wrote:

>>    Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
>> 'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
>> the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
>> week separately...
>>
>> [01/13] ARM: shmobile: r8a7792: add clock index macros
>> [02/13] ARM: shmobile: r8a7792: add power domain index macros
>> [03/13] soc: renesas: rcar-sysc: add R8A7792 support
>> [04/13] ARM: shmobile: r8a7792: basic SoC support
>> [05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
>> [06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
>> [07/13] ARM: dts: r8a7792: initial SoC device tree
>> [08/13] ARM: dts: r8a7792: add SYS-DMAC support
>> [09/13] ARM: dts: r8a7792: add [H]SCIF support
>> [10/13] ARM dts: r8a7792: add IRQC support
>> [11/13] DT: arm: shmobile: document Blanche board
>> [12/13] ARM: dts: blanche: initial device tree
>> [13/13] ARM: dts: blanche: add Ethernet support
>
> Thanks for your series!
>
> The subject doesn't seem to cover the contents, though:
>> [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

    Oops. :-(
    Sorry about that...

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH 00/13] Add R8A7794/SILK board eMMC DT support

[Sergei Shtylyov]

Hello.

On 6/1/2016 10:04 AM, Geert Uytterhoeven wrote:

>>    Here's the set of 13 patches against Simon Horman's 'renesas.git' repo,
>> 'renesas-devel-20160530-v4.7-rc1' tag. We add the device tree support for
>> the R8A7792-based Blanche board. The R-Car 'clk' driver patch was posted last
>> week separately...
>>
>> [01/13] ARM: shmobile: r8a7792: add clock index macros
>> [02/13] ARM: shmobile: r8a7792: add power domain index macros
>> [03/13] soc: renesas: rcar-sysc: add R8A7792 support
>> [04/13] ARM: shmobile: r8a7792: basic SoC support
>> [05/13] DT: clock: rcar-gen2-cpg-clocks: document R8A7792 support
>> [06/13] DT: clock: cpg-mstp-clocks: document-R8A7792-support
>> [07/13] ARM: dts: r8a7792: initial SoC device tree
>> [08/13] ARM: dts: r8a7792: add SYS-DMAC support
>> [09/13] ARM: dts: r8a7792: add [H]SCIF support
>> [10/13] ARM dts: r8a7792: add IRQC support
>> [11/13] DT: arm: shmobile: document Blanche board
>> [12/13] ARM: dts: blanche: initial device tree
>> [13/13] ARM: dts: blanche: add Ethernet support
>
> Thanks for your series!
>
> The subject doesn't seem to cover the contents, though:
>> [PATCH 00/13] Add R8A7794/SILK board eMMC DT support

    Oops. :-(
    Sorry about that...

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH v2 1/2] ip6_gre: Fix MTU setting for ip6gretap

[Haishuang Yan]

When creat an ip6gretap interface with an unreachable route,
the MTU is about 14 bytes larger than what was needed.

If the remote address is reachable:
ping6 2001:0:130::1 -c 2
PING 2001:0:130::1(2001:0:130::1) 56 data bytes
64 bytes from 2001:0:130::1: icmp_seq=1 ttl=64 time=1.46 ms
64 bytes from 2001:0:130::1: icmp_seq=2 ttl=64 time=81.1 ms

--- 2001:0:130::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.465/41.316/81.167/39.851 ms

ip link add ip6gretap1 type ip6gretap\
 local 2001:0:130::2 remote 2001:0:130::1
ip link show ip6gretap1
11: ip6gretap1@NONE: <BROADCAST,MULTICAST> mtu 1434 ...
    link/ether c2:f3:f8:c1:2c:bf brd ff:ff:ff:ff:ff:ff

The MTU value 1434 is right. But if we delete the direct route:
ip -6 route del 2001:0:130::/64
ping6 2001:0:130::1 -c 2
connect: Network is unreachable
ip link add ip6gretap1 type ip6gretap\
 local 2001:0:130::2 remote 2001:0:130::1
ip link show ip6gretap1
12: ip6gretap1@NONE: <BROADCAST,MULTICAST> mtu 1448 ...
    link/ether 7e:e1:d2:c4:06:5e brd ff:ff:ff:ff:ff:ff

Now, the MTU value 1448 is larger than what was needed.

The reason is that if there is a reachable route, when
run following code in ip6gre_tnl_link_config:

	if (p->flags & IP6_TNL_F_CAP_XMIT) {
		int strict = (ipv6_addr_type(&p->raddr) &
			      (IPV6_ADDR_MULTICAST|IPV6_ADDR_LINKLOCAL));

		struct rt6_info *rt = rt6_lookup(t->net,
						 &p->raddr, &p->laddr,
						 p->link, strict);

		if (!rt)
			return;

		if (rt->dst.dev) {
			dev->hard_header_len = rt->dst.dev->hard_header_len +
					       t_hlen;

			if (set_mtu) {
				dev->mtu = rt->dst.dev->mtu - t_hlen;
				if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
					dev->mtu -= 8;
				if (dev->type == ARPHRD_ETHER)
					dev->mtu -= ETH_HLEN;

				if (dev->mtu < IPV6_MIN_MTU)
					dev->mtu = IPV6_MIN_MTU;
			}
		}
		ip6_rt_put(rt);
	}

Because rt is not NULL here, so dev->mtu will subtract the ethernet
header length later. But when rt is NULL, it just simply return, so
dev->mtu doesn't update correctly in this situation.

This patch first verify the dev->type is ARPHRD_ETHER for ip6gretap
interface, and then decrease the mtu as early as possible.

Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
Changes in v2:
  - Make the commit message more clearer.
---
 net/ipv6/ip6_gre.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 4541fa5..8ea5a4d 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1029,6 +1029,8 @@ static int ip6gre_tunnel_init_common(struct net_device *dev)
 
 	dev->hard_header_len = LL_MAX_HEADER + t_hlen;
 	dev->mtu = ETH_DATA_LEN - t_hlen;
+	if (dev->type == ARPHRD_ETHER)
+		dev->mtu -= ETH_HLEN;
 	if (!(tunnel->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
 		dev->mtu -= 8;
 
-- 
1.8.3.1

[PATCH v2 2/2] ip6_gre: Set flowi6_proto as IPPROTO_GRE in xmit path.

[Haishuang Yan]

In gre6 xmit path, we are sending a GRE packet, so set fl6 proto
to IPPROTO_GRE properly.

Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
Changes in v2:
  - Initialize the flow protocol in ip6gre_tnl_link_config
---
 net/ipv6/ip6_gre.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 8ea5a4d..e706621 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -712,6 +712,7 @@ static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
 	fl6->daddr = p->raddr;
 	fl6->flowi6_oif = p->link;
 	fl6->flowlabel = 0;
+	fl6->flowi6_proto = IPPROTO_GRE;
 
 	if (!(p->flags&IP6_TNL_F_USE_ORIG_TCLASS))
 		fl6->flowlabel |= IPV6_TCLASS_MASK & p->flowinfo;
-- 
1.8.3.1

Re: [PATCH v2 2/2] ip6_gre: Set flowi6_proto as IPPROTO_GRE in xmit path.

[David Miller]

From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Sat, 21 May 2016 18:17:35 +0800

> In gre6 xmit path, we are sending a GRE packet, so set fl6 proto
> to IPPROTO_GRE properly.
> 
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>

Applied.

Re: [PATCH v2 2/2] ip6_gre: Set flowi6_proto as IPPROTO_GRE in xmit path., Re: [PATCH] ARM: shmobile: rcar-gen2: Use ICRAM1 for jump stub on all SoCs, [PATCH 12/13] ARM: dts: blanche: initial device tree

[David Miller, Simon Horman, Sergei Shtylyov]

From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Sat, 21 May 2016 18:17:35 +0800

> In gre6 xmit path, we are sending a GRE packet, so set fl6 proto
> to IPPROTO_GRE properly.
> 
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>

Applied.

On Tue, May 17, 2016 at 05:15:33PM +0200, Geert Uytterhoeven wrote:
> Currently the different SoCs in the R-Car Gen2 family use different
> types of on-chip RAM for the jump stub:
>   - R-Car H2 uses Media RAM,
>   - R-Car M2-W uses another type of optional On-chip RAM, as it doesn't
>     have Media RAM,
>   - R-Car M2-N uses Inter Connect RAM in Magnus Damm's "ARM: shmobile:
>     r8a7793 boot address update".
> 
> As all R-Car Gen2 SoCs have 4 KiB of Inter Connect RAM, consolidate the
> code by always using that.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Tested on r8a7790/lager and r8a7791/koelsch.
> ---
>  arch/arm/mach-shmobile/pm-rcar-gen2.c | 13 ++++---------
>  1 file changed, 4 insertions(+), 9 deletions(-)

Thanks, I have queued this up.

Add the initial device  tree for the R8A7792 SoC based Blanche board.
The board has 2 debug serial ports: SCIF0 and SCIF3; include support for
them,  so that  the serial console  can  work.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
 arch/arm/boot/dts/Makefile            |    1 
 arch/arm/boot/dts/r8a7792-blanche.dts |   44 ++++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+)

Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -638,6 +638,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
 	r8a7790-lager.dtb \
 	r8a7791-koelsch.dtb \
 	r8a7791-porter.dtb \
+	r8a7792-blanche.dtb \
 	r8a7793-gose.dtb \
 	r8a7794-alt.dtb \
 	r8a7794-silk.dtb \
Index: renesas/arch/arm/boot/dts/r8a7792-blanche.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the Blanche board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7792.dtsi"
+
+/ {
+	model = "Blanche";
+	compatible = "renesas,blanche", "renesas,r8a7792";
+
+	aliases {
+		serial0 = &scif0;
+		serial1 = &scif3;
+	};
+
+	chosen {
+		bootargs = "ignore_loglevel";
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0 0x40000000 0 0x40000000>;
+	};
+};
+
+&extal_clk {
+	clock-frequency = <20000000>;
+};
+
+&scif0 {
+	status = "okay";
+};
+
+&scif3 {
+	status = "okay";
+};

Re: [PATCH v2 1/2] ip6_gre: Fix MTU setting for ip6gretap

[David Miller]

From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Sat, 21 May 2016 18:17:34 +0800

> When creat an ip6gretap interface with an unreachable route,
> the MTU is about 14 bytes larger than what was needed.
 ...
> Because rt is not NULL here, so dev->mtu will subtract the ethernet
> header length later. But when rt is NULL, it just simply return, so
> dev->mtu doesn't update correctly in this situation.
> 
> This patch first verify the dev->type is ARPHRD_ETHER for ip6gretap
> interface, and then decrease the mtu as early as possible.
> 
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>

Applied.

[PATCH] ARM: shmobile: rcar-gen2: Use ICRAM1 for jump stub on all SoCs

[Geert Uytterhoeven]

Currently the different SoCs in the R-Car Gen2 family use different
types of on-chip RAM for the jump stub:
  - R-Car H2 uses Media RAM,
  - R-Car M2-W uses another type of optional On-chip RAM, as it doesn't
    have Media RAM,
  - R-Car M2-N uses Inter Connect RAM in Magnus Damm's "ARM: shmobile:
    r8a7793 boot address update".

As all R-Car Gen2 SoCs have 4 KiB of Inter Connect RAM, consolidate the
code by always using that.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Tested on r8a7790/lager and r8a7791/koelsch.
---
 arch/arm/mach-shmobile/pm-rcar-gen2.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/pm-rcar-gen2.c b/arch/arm/mach-shmobile/pm-rcar-gen2.c
index 691ac166a277c03f..61361dac6068210a 100644
--- a/arch/arm/mach-shmobile/pm-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/pm-rcar-gen2.c
@@ -26,8 +26,7 @@
 #define CA7RESCNT	0x0044
 
 /* On-chip RAM */
-#define MERAM		0xe8080000
-#define RAM		0xe6300000
+#define ICRAM1		0xe63c0000	/* Inter Connect RAM1 (4 KiB) */
 
 /* SYSC */
 #define SYSCIER 0x0c
@@ -58,7 +57,7 @@ void __init rcar_gen2_pm_init(void)
 	struct device_node *np, *cpus;
 	bool has_a7 = false;
 	bool has_a15 = false;
-	phys_addr_t boot_vector_addr = 0;
+	phys_addr_t boot_vector_addr = ICRAM1;
 	u32 syscier = 0;
 
 	if (once++)
@@ -75,14 +74,10 @@ void __init rcar_gen2_pm_init(void)
 			has_a7 = true;
 	}
 
-	if (of_machine_is_compatible("renesas,r8a7790")) {
-		boot_vector_addr = MERAM;
+	if (of_machine_is_compatible("renesas,r8a7790"))
 		syscier = 0x013111ef;
-
-	} else if (of_machine_is_compatible("renesas,r8a7791")) {
-		boot_vector_addr = RAM;
+	else if (of_machine_is_compatible("renesas,r8a7791"))
 		syscier = 0x00111003;
-	}
 
 	/* RAM for jump stub, because BAR requires 256KB aligned address */
 	p = ioremap_nocache(boot_vector_addr, shmobile_boot_size);
-- 
1.9.1

[PATCH] ARM: shmobile: rcar-gen2: Use ICRAM1 for jump stub on all SoCs

[Geert Uytterhoeven]

Currently the different SoCs in the R-Car Gen2 family use different
types of on-chip RAM for the jump stub:
  - R-Car H2 uses Media RAM,
  - R-Car M2-W uses another type of optional On-chip RAM, as it doesn't
    have Media RAM,
  - R-Car M2-N uses Inter Connect RAM in Magnus Damm's "ARM: shmobile:
    r8a7793 boot address update".

As all R-Car Gen2 SoCs have 4 KiB of Inter Connect RAM, consolidate the
code by always using that.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Tested on r8a7790/lager and r8a7791/koelsch.
---
 arch/arm/mach-shmobile/pm-rcar-gen2.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/pm-rcar-gen2.c b/arch/arm/mach-shmobile/pm-rcar-gen2.c
index 691ac166a277c03f..61361dac6068210a 100644
--- a/arch/arm/mach-shmobile/pm-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/pm-rcar-gen2.c
@@ -26,8 +26,7 @@
 #define CA7RESCNT	0x0044
 
 /* On-chip RAM */
-#define MERAM		0xe8080000
-#define RAM		0xe6300000
+#define ICRAM1		0xe63c0000	/* Inter Connect RAM1 (4 KiB) */
 
 /* SYSC */
 #define SYSCIER 0x0c
@@ -58,7 +57,7 @@ void __init rcar_gen2_pm_init(void)
 	struct device_node *np, *cpus;
 	bool has_a7 = false;
 	bool has_a15 = false;
-	phys_addr_t boot_vector_addr = 0;
+	phys_addr_t boot_vector_addr = ICRAM1;
 	u32 syscier = 0;
 
 	if (once++)
@@ -75,14 +74,10 @@ void __init rcar_gen2_pm_init(void)
 			has_a7 = true;
 	}
 
-	if (of_machine_is_compatible("renesas,r8a7790")) {
-		boot_vector_addr = MERAM;
+	if (of_machine_is_compatible("renesas,r8a7790"))
 		syscier = 0x013111ef;
-
-	} else if (of_machine_is_compatible("renesas,r8a7791")) {
-		boot_vector_addr = RAM;
+	else if (of_machine_is_compatible("renesas,r8a7791"))
 		syscier = 0x00111003;
-	}
 
 	/* RAM for jump stub, because BAR requires 256KB aligned address */
 	p = ioremap_nocache(boot_vector_addr, shmobile_boot_size);
-- 
1.9.1

Re: [PATCH] ARM: shmobile: rcar-gen2: Use ICRAM1 for jump stub on all SoCs

[Simon Horman]

On Tue, May 17, 2016 at 05:15:33PM +0200, Geert Uytterhoeven wrote:
> Currently the different SoCs in the R-Car Gen2 family use different
> types of on-chip RAM for the jump stub:
>   - R-Car H2 uses Media RAM,
>   - R-Car M2-W uses another type of optional On-chip RAM, as it doesn't
>     have Media RAM,
>   - R-Car M2-N uses Inter Connect RAM in Magnus Damm's "ARM: shmobile:
>     r8a7793 boot address update".
> 
> As all R-Car Gen2 SoCs have 4 KiB of Inter Connect RAM, consolidate the
> code by always using that.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Tested on r8a7790/lager and r8a7791/koelsch.
> ---
>  arch/arm/mach-shmobile/pm-rcar-gen2.c | 13 ++++---------
>  1 file changed, 4 insertions(+), 9 deletions(-)

Thanks, I have queued this up.

[PATCH] ARM: shmobile: rcar-gen2: Use ICRAM1 for jump stub on all SoCs

[Simon Horman]

On Tue, May 17, 2016 at 05:15:33PM +0200, Geert Uytterhoeven wrote:
> Currently the different SoCs in the R-Car Gen2 family use different
> types of on-chip RAM for the jump stub:
>   - R-Car H2 uses Media RAM,
>   - R-Car M2-W uses another type of optional On-chip RAM, as it doesn't
>     have Media RAM,
>   - R-Car M2-N uses Inter Connect RAM in Magnus Damm's "ARM: shmobile:
>     r8a7793 boot address update".
> 
> As all R-Car Gen2 SoCs have 4 KiB of Inter Connect RAM, consolidate the
> code by always using that.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Tested on r8a7790/lager and r8a7791/koelsch.
> ---
>  arch/arm/mach-shmobile/pm-rcar-gen2.c | 13 ++++---------
>  1 file changed, 4 insertions(+), 9 deletions(-)

Thanks, I have queued this up.