[PATCH] ASoC: rsnd: avoid duplicate free_irq()

2017-08-08 Thread Kuninori Morimoto

From: Kuninori Morimoto 

commit 1f8754d4daea5f ("ASoC: rsnd: don't call free_irq() on
Parent SSI") fixed Parent SSI duplicate free_irq().
But on Renesas Sound, not only Parent SSI but also Multi SSI
have same issue.
This patch avoid duplicate free_irq() if it was not pure SSI.

Fixes: 1f8754d4daea5f ("ASoC: rsnd: don't call free_irq() on Parent SSI")
Signed-off-by: Kuninori Morimoto 
---
 sound/soc/sh/rcar/ssi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 25c351f..0309de5 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -846,10 +846,10 @@ static int rsnd_ssi_dma_remove(struct rsnd_mod *mod,
   struct rsnd_priv *priv)
 {
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
-   struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
+   struct rsnd_mod *pure_ssi_mod = rsnd_io_to_mod_ssi(io);
 
-   /* Do nothing for SSI parent mod */
-   if (ssi_parent_mod == mod)
+   /* Do nothing if non SSI (= SSI parent, multi SSI) mod */
+   if (pure_ssi_mod != mod)
return 0;
 
/* PIO will request IRQ again */
-- 
1.9.1



[PATCH] ASoC: rsnd: remove 16ch support for now

2017-08-08 Thread Kuninori Morimoto

From: Kuninori Morimoto 

R-Car Gen3 sound device can use TDM 16ch, but its usage is very
limited. It is not yet supported.
Let's remove unexpected/unsupported channel settings for now.
This patch makes xx_ADINR register settings sanity without
runtime check.

R-Car Gen3 datasheet

40.4.7 Note on Usage of the SSIU Module
When an SSIU module is used in "TDM-16ch mode",
only the transfer with the external memory is available.

Reported-by: Nguyen Viet Dung 
Signed-off-by: Kuninori Morimoto 
---
 sound/soc/sh/rcar/core.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 4117b56..cd8db39 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -726,7 +726,6 @@ static int rsnd_soc_set_dai_tdm_slot(struct snd_soc_dai 
*dai,
case 2:
case 6:
case 8:
-   case 16:
/* TDM Extend Mode */
rsnd_rdai_channels_set(rdai, slots);
rsnd_rdai_ssi_lane_set(rdai, 1);
@@ -740,7 +739,7 @@ static int rsnd_soc_set_dai_tdm_slot(struct snd_soc_dai 
*dai,
 }
 
 static unsigned int rsnd_soc_hw_channels_list[] = {
-   2, 6, 8, 16,
+   2, 6, 8,
 };
 
 static unsigned int rsnd_soc_hw_rate_list[] = {
@@ -1025,7 +1024,7 @@ static void __rsnd_dai_probe(struct rsnd_priv *priv,
drv->playback.rates = RSND_RATES;
drv->playback.formats   = RSND_FMTS;
drv->playback.channels_min  = 2;
-   drv->playback.channels_max  = 16;
+   drv->playback.channels_max  = 8;
drv->playback.stream_name   = rdai->playback.name;
 
snprintf(rdai->capture.name, RSND_DAI_NAME_SIZE,
@@ -1033,7 +1032,7 @@ static void __rsnd_dai_probe(struct rsnd_priv *priv,
drv->capture.rates  = RSND_RATES;
drv->capture.formats= RSND_FMTS;
drv->capture.channels_min   = 2;
-   drv->capture.channels_max   = 16;
+   drv->capture.channels_max   = 8;
drv->capture.stream_name= rdai->capture.name;
 
rdai->playback.rdai = rdai;
-- 
1.9.1



Re: [RFT] arm64: dts: renesas: salvator-common: enable SDR104 for SD cards

2017-08-08 Thread Wolfram Sang

> As it is an "RFT" I'm happy to apply it if you repost
> it or otherwise indicate that is what you would like to happen.

As discussed in a chat, I tried SDR104 with my SDIO WiFi cards:

H3:
- one slot worked flawlessly
- one slot could load FW but failed to read status
(with SDR50: both slots work)

M3-W:
- both slots could not load the firmware
(with SDR50: one slot works, one fails to load FW)

The cards, however, were correctly identified as SDR104 and there were
no tuning errors and no other SDHI related warnings.

Changing TDSEL in the PFC did not change anything.

The manual of the WiFi card (u-blox EMMY-W1) mentions a maximum line
length of 100mm. Measuring a direct line from the SoC to the slots,
I'd think we are very much on the edge of that. And given the length
of the SDIO adapter, we are surely exceeding that :(

Maybe we should do more tests with more boards? On the other hand, it
seems the WiFi card is running out of the specs.

So much for now. I'll sleep over it and try to get more data tomorrow.

Regards,

   Wolfram



signature.asc
Description: PGP signature


Re: [PATCH 01/15] ARM: assembler: introduce adr_l, ldr_l and str_l macros

2017-08-08 Thread Nicolas Pitre
On Tue, 8 Aug 2017, Ard Biesheuvel wrote:

> On 8 August 2017 at 16:10, Nicolas Pitre  wrote:
> > On Sat, 5 Aug 2017, Ard Biesheuvel wrote:
> >
> >> Like arm64, ARM supports position independent code sequences that
> >> produce symbol references with a greater reach than the ordinary
> >> adr/ldr instructions.
> >>
> >> Currently, we use open coded instruction sequences involving literals
> >> and arithmetic operations. Instead, we can use movw/movt pairs on v7
> >> CPUs, circumventing the D-cache entirely. For older CPUs, we can emit
> >> the literal into a subsection, allowing it to be emitted out of line
> >> while retaining the ability to perform arithmetic on label offsets.
> >>
> >> E.g., on pre-v7 CPUs, we can emit a PC-relative reference as follows:
> >>
> >>ldr  , 222f
> >>   111: add  , , pc
> >>.subsection  1
> >>   222: .long - (111b + 8)
> >>.previous
> >>
> >> This is allowed by the assembler because, unlike ordinary sections,
> >> subsections are combined into a single section into the object file,
> >> and so the label references are not true cross-section references that
> >> are visible as relocations. Note that we could even do something like
> >>
> >>add  , pc, #(222f - 111f) & ~0xfff
> >>ldr  , [, #(222f - 111f) & 0xfff]
> >>   111: add  , , pc
> >>.subsection  1
> >>   222: .long - (111b + 8)
> >>.previous
> >>
> >> if it turns out that the 4 KB range of the ldr instruction is insufficient
> >> to reach the literal in the subsection, although this is currently not a
> >> problem (of the 98 objects built from .S files in a multi_v7_defconfig
> >> build, only 11 have .text sections that are over 1 KB, and the largest one
> >> [entry-armv.o] is 3308 bytes)
> >>
> >> Subsections have been available in binutils since 2004 at least, so
> >> they should not cause any issues with older toolchains.
> >>
> >> So use the above to implement the macros mov_l, adr_l, adrm_l (using ldm
> >> to load multiple literals at once), ldr_l and str_l, all of which will
> >> use movw/movt pairs on v7 and later CPUs, and use PC-relative literals
> >> otherwise.
> >
> > There is no adrm_l definition in this patch.
> >
> 
> Ah yes, I played around with it but it becomes a bit clunky so I removed it:
> 
> adrl , 222f
> ldm  , {, }
>111: add  , , pc
> add  , , pc
> .subsection  1
>222: .long - (111b + 8)
> .long - (111b + 12)
> .previous
> 
> The adrl pseudo op always assembles to two instructions, so you need 5
> instructions while using adr_l twice uses only 4. I am not sure if
> eliminating one of the loads would make a huge difference, given that
> there are no use cases for adrm_l on hot paths, at least not in this
> series.

I'd suggest you keep it to a minimum.  Using adr_l twice is clear and 
obvious.

> > Also, might it be better to change mov_l to movl? Tthis looks similar to
> > the ARM64 movl pseudo-instruction, and unlike all the other _l variants,
> > this is not producing a pc relative result.
> >
> 
> On arm64, we have mov_q for a 64-bit absolute load, and I thought
> mov_l was less confusing than mov_w. In general, I like the underscore
> in the middle because on the one hand, it looks like a ordinary
> mnemonic but on the other hand, it is obvious that it is not a true
> instruction. mov_abs perhaps?
> 
> > Talking about the _l suffix: I wonder if this could be more meaningful,
> > like _rel maybe? At least in the adr_l case, this could easily be
> > confused with adrl.
> >
> 
> On arm64, we have ldr_l, str_l and adr_l as well, and I usually try to
> align between ARM and arm64 if I can.

OK. I'm much less versed into ARM64 assembly so I'll defer to your 
judgment.  It's good if this mnemonic scheme already exists there with 
a similar meaning.


Nicolas


Re: [PATCH 01/15] ARM: assembler: introduce adr_l, ldr_l and str_l macros

2017-08-08 Thread Ard Biesheuvel
On 8 August 2017 at 16:10, Nicolas Pitre  wrote:
> On Sat, 5 Aug 2017, Ard Biesheuvel wrote:
>
>> Like arm64, ARM supports position independent code sequences that
>> produce symbol references with a greater reach than the ordinary
>> adr/ldr instructions.
>>
>> Currently, we use open coded instruction sequences involving literals
>> and arithmetic operations. Instead, we can use movw/movt pairs on v7
>> CPUs, circumventing the D-cache entirely. For older CPUs, we can emit
>> the literal into a subsection, allowing it to be emitted out of line
>> while retaining the ability to perform arithmetic on label offsets.
>>
>> E.g., on pre-v7 CPUs, we can emit a PC-relative reference as follows:
>>
>>ldr  , 222f
>>   111: add  , , pc
>>.subsection  1
>>   222: .long - (111b + 8)
>>.previous
>>
>> This is allowed by the assembler because, unlike ordinary sections,
>> subsections are combined into a single section into the object file,
>> and so the label references are not true cross-section references that
>> are visible as relocations. Note that we could even do something like
>>
>>add  , pc, #(222f - 111f) & ~0xfff
>>ldr  , [, #(222f - 111f) & 0xfff]
>>   111: add  , , pc
>>.subsection  1
>>   222: .long - (111b + 8)
>>.previous
>>
>> if it turns out that the 4 KB range of the ldr instruction is insufficient
>> to reach the literal in the subsection, although this is currently not a
>> problem (of the 98 objects built from .S files in a multi_v7_defconfig
>> build, only 11 have .text sections that are over 1 KB, and the largest one
>> [entry-armv.o] is 3308 bytes)
>>
>> Subsections have been available in binutils since 2004 at least, so
>> they should not cause any issues with older toolchains.
>>
>> So use the above to implement the macros mov_l, adr_l, adrm_l (using ldm
>> to load multiple literals at once), ldr_l and str_l, all of which will
>> use movw/movt pairs on v7 and later CPUs, and use PC-relative literals
>> otherwise.
>
> There is no adrm_l definition in this patch.
>

Ah yes, I played around with it but it becomes a bit clunky so I removed it:

adrl , 222f
ldm  , {, }
   111: add  , , pc
add  , , pc
.subsection  1
   222: .long - (111b + 8)
.long - (111b + 12)
.previous

The adrl pseudo op always assembles to two instructions, so you need 5
instructions while using adr_l twice uses only 4. I am not sure if
eliminating one of the loads would make a huge difference, given that
there are no use cases for adrm_l on hot paths, at least not in this
series.

> Also, might it be better to change mov_l to movl? Tthis looks similar to
> the ARM64 movl pseudo-instruction, and unlike all the other _l variants,
> this is not producing a pc relative result.
>

On arm64, we have mov_q for a 64-bit absolute load, and I thought
mov_l was less confusing than mov_w. In general, I like the underscore
in the middle because on the one hand, it looks like a ordinary
mnemonic but on the other hand, it is obvious that it is not a true
instruction. mov_abs perhaps?

> Talking about the _l suffix: I wonder if this could be more meaningful,
> like _rel maybe? At least in the adr_l case, this could easily be
> confused with adrl.
>

On arm64, we have ldr_l, str_l and adr_l as well, and I usually try to
align between ARM and arm64 if I can.

> Otherwise I like it pretty much.
>

Thanks!


Re: [PATCH 01/15] ARM: assembler: introduce adr_l, ldr_l and str_l macros

2017-08-08 Thread Nicolas Pitre
On Sat, 5 Aug 2017, Ard Biesheuvel wrote:

> Like arm64, ARM supports position independent code sequences that
> produce symbol references with a greater reach than the ordinary
> adr/ldr instructions.
> 
> Currently, we use open coded instruction sequences involving literals
> and arithmetic operations. Instead, we can use movw/movt pairs on v7
> CPUs, circumventing the D-cache entirely. For older CPUs, we can emit
> the literal into a subsection, allowing it to be emitted out of line
> while retaining the ability to perform arithmetic on label offsets.
> 
> E.g., on pre-v7 CPUs, we can emit a PC-relative reference as follows:
> 
>ldr  , 222f
>   111: add  , , pc
>.subsection  1
>   222: .long - (111b + 8)
>.previous
> 
> This is allowed by the assembler because, unlike ordinary sections,
> subsections are combined into a single section into the object file,
> and so the label references are not true cross-section references that
> are visible as relocations. Note that we could even do something like
> 
>add  , pc, #(222f - 111f) & ~0xfff
>ldr  , [, #(222f - 111f) & 0xfff]
>   111: add  , , pc
>.subsection  1
>   222: .long - (111b + 8)
>.previous
> 
> if it turns out that the 4 KB range of the ldr instruction is insufficient
> to reach the literal in the subsection, although this is currently not a
> problem (of the 98 objects built from .S files in a multi_v7_defconfig
> build, only 11 have .text sections that are over 1 KB, and the largest one
> [entry-armv.o] is 3308 bytes)
> 
> Subsections have been available in binutils since 2004 at least, so
> they should not cause any issues with older toolchains.
> 
> So use the above to implement the macros mov_l, adr_l, adrm_l (using ldm
> to load multiple literals at once), ldr_l and str_l, all of which will
> use movw/movt pairs on v7 and later CPUs, and use PC-relative literals
> otherwise.

There is no adrm_l definition in this patch.

Also, might it be better to change mov_l to movl? Tthis looks similar to 
the ARM64 movl pseudo-instruction, and unlike all the other _l variants, 
this is not producing a pc relative result.

Talking about the _l suffix: I wonder if this could be more meaningful, 
like _rel maybe? At least in the adr_l case, this could easily be 
confused with adrl.

Otherwise I like it pretty much.


> Signed-off-by: Ard Biesheuvel 
> ---
>  arch/arm/include/asm/assembler.h | 70 
>  1 file changed, 70 insertions(+)
> 
> diff --git a/arch/arm/include/asm/assembler.h 
> b/arch/arm/include/asm/assembler.h
> index ad301f107dd2..cedf59a7f853 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -518,4 +518,74 @@ THUMB(   orr \reg , \reg , #PSR_T_BIT)
>  #endif
>   .endm
>  
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define  ARM_PC_BIAS 4
> +#else
> +#define  ARM_PC_BIAS 8
> +#endif
> +
> + .macro  __adldst_l, op, reg, sym, tmp
> + .if __LINUX_ARM_ARCH__ < 7
> + ldr \tmp, 111f
> + .subsection 1
> + .align  2
> +111: .long   \sym - (222f + ARM_PC_BIAS)
> + .previous
> + .else
> + movw\tmp, #:lower16:\sym - (222f + ARM_PC_BIAS)
> + movt\tmp, #:upper16:\sym - (222f + ARM_PC_BIAS)
> + .endif
> +222:;.ifc\op, add
> + add \reg, \tmp, pc
> + .elseif CONFIG_THUMB2_KERNEL == 1
> + add \tmp, \tmp, pc
> + \op \reg, [\tmp]
> + .else
> + \op \reg, [pc, \tmp]
> + .endif
> + .endm
> +
> + /*
> +  * mov_l - move a constant value or [relocated] address into a register
> +  */
> + .macro  mov_l, dst:req, imm:req
> + .if __LINUX_ARM_ARCH__ < 7
> + ldr \dst, =\imm
> + .else
> + movw\dst, #:lower16:\imm
> + movt\dst, #:upper16:\imm
> + .endif
> + .endm
> +
> + /*
> +  * adr_l - adr pseudo-op with unlimited range
> +  *
> +  * @dst: destination register
> +  * @sym: name of the symbol
> +  */
> + .macro  adr_l, dst:req, sym:req
> + __adldst_l  add, \dst, \sym, \dst
> + .endm
> +
> + /*
> +  * ldr_l - ldr  pseudo-op with unlimited range
> +  *
> +  * @dst: destination register
> +  * @sym: name of the symbol
> +  */
> + .macro  ldr_l, dst:req, sym:req
> + __adldst_l  ldr, \dst, \sym, \dst
> + .endm
> +
> + /*
> +  * str_l - str  pseudo-op with unlimited range
> +  *
> +  * @src: source register
> +  * @sym: name of the symbol
> +  * @tmp: mandatory scratch register
> +  */
> + .macro  str_l, src:req, sym:req, tmp:req
> + __adldst_l  str, \src, \sym, \tmp
> + .endm
> +
> 

RE: [PATCH 2/2] ARM: shmobile: document iW-RainboW-G22D SODIMM SOM Development Platform

2017-08-08 Thread Chris Paterson
+ linux-renesas-soc

> From: Fabrizio Castro [mailto:fabrizio.cas...@bp.renesas.com]
> Sent: 08 August 2017 13:28
> 
> Document the iW-RainboW-G22D device tree bindings.
> It is just a placeholder for the time being, the actual implementation is not
> available yet.
> 
> Signed-off-by: Fabrizio Castro 
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
> b/Documentation/devicetree/bindings/arm/shmobile.txt
> index 64e7f63..ae75cb3 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -68,6 +68,8 @@ Boards:
>  compatible = "renesas,h3ulcb", "renesas,r8a7795";
>- Henninger
>  compatible = "renesas,henninger", "renesas,r8a7791"
> +  - iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-
> RainboW-G22D)
> +compatible = "iwave,g22d", "iwave,g22m", "renesas,r8a7745"
>- iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-
> SM)
>  compatible = "iwave,g22m", "renesas,r8a7745"
>- iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-
> Qseven)
> --
> 1.9.1



RE: [PATCH 0/2] ARM: shmobile: document iWave's iW-RainboW-G22D-SODIMM RZ/G1E SODIMM development platform

2017-08-08 Thread Chris Paterson
+ linux-renesas-soc

> From: Fabrizio Castro [mailto:fabrizio.cas...@bp.renesas.com]
> Sent: 08 August 2017 13:28
> To: robh...@kernel.org; mark.rutl...@arm.com
> 
> Hello,
> 
> This series aims to add the documentation for the device tree bindings of the
> iWave iW-RainboW-G22D-SODIMM RZ/G1E SODIMM development kit:
> http://www.iwavesystems.com/product/development-platform/sodimm-
> evaluation-boards/rz-g1e-sodimm-development-kit-28/rz-g1e-sodimm-
> development-kit.html
> 
> which consists of a System on Module (iW-RainboW-G22M-SM) and a carrier
> card (iW-RainboW-G22D).
> 
> Regards,
> 
> Fabrizio Castro (2):
>   ARM: shmobile: document iW-RainboW-G22M-SM SODIMM System on
> Module
>   ARM: shmobile: document iW-RainboW-G22D SODIMM SOM Development
> Platform
> 
>  Documentation/devicetree/bindings/arm/shmobile.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> --
> 1.9.1



[PATCH 0/2] Add BQ32000 RTC support for iWave RZ/G1M board

2017-08-08 Thread Biju Das
This series aims to add BQ32000 RTC support for iWave RZ/G1M board.

This series has been tested against Linux-next tag 20170727 and renesas-dev 
branch.
This patch series depends on 
https://www.spinics.net/lists/arm-kernel/msg599220.html

Biju Das (2):
  ARM: dts: iwg20d-q7: Add RTC support
  ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig

 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 18 ++
 arch/arm/configs/shmobile_defconfig |  1 +
 2 files changed, 19 insertions(+)

-- 
1.9.1



[PATCH 1/2] ARM: dts: iwg20d-q7: Add RTC support

2017-08-08 Thread Biju Das
Define the iWave RainboW-G20D-Qseven board dependent part of the
RTC device node.

Signed-off-by: Biju Das 
---
 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts 
b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index 081af01..b3a1efa 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -31,6 +31,11 @@
groups = "avb_mdio", "avb_gmii";
function = "avb";
};
+
+   i2c2_pins: i2c2 {
+   groups = "i2c2";
+   function = "i2c2";
+   };
 };
 
  {
@@ -54,3 +59,16 @@
micrel,led-mode = <1>;
};
 };
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+   clock-frequency = <40>;
+
+   rtc@68 {
+   compatible = "bq32000";
+   reg = <0x68>;
+   };
+};
-- 
1.9.1



[PATCH 2/2] ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig

2017-08-08 Thread Biju Das
The iWave RZ/G1M Q7 SOM supports RTC (TI BQ32000).
To increase hardware support enable the driver in the
shmobile_defconfig multiplatform configuration.

Signed-off-by: Biju Das 
---
 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 18886c5..7b4fc01 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -193,6 +193,7 @@ CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_RS5C372=y
+CONFIG_RTC_DRV_BQ32K=y
 CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_RX8581=y
 CONFIG_RTC_DRV_DA9063=y
-- 
1.9.1



[PATCH 2/2] ARM: dts: r8a7743: Add IIC cores to dtsi

2017-08-08 Thread Biju Das
Signed-off-by: Biju Das 
---
This patch has been tested against Linux-next tag 20170727 and renesas-dev 
branch.
This patch depends on https://www.spinics.net/lists/arm-kernel/msg599220.html

 arch/arm/boot/dts/r8a7743.dtsi | 55 ++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 14222c72..5c2b140 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -25,6 +25,9 @@
i2c3 = 
i2c4 = 
i2c5 = 
+   i2c6 = 
+   i2c7 = 
+   i2c8 = 
};
 
cpus {
@@ -436,6 +439,58 @@
status = "disabled";
};
 
+   i2c6: i2c@e60b {
+   /* doesn't need pinmux */
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,iic-r8a7743",
+"renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
+   reg = <0 0xe60b 0 0x425>;
+   interrupts = ;
+   clocks = < CPG_MOD 926>;
+   dmas = < 0x77>, < 0x78>,
+  < 0x77>, < 0x78>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < CPG_MOD 926>;
+   status = "disabled";
+   };
+
+   i2c7: i2c@e650 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,iic-r8a7743",
+"renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
+   reg = <0 0xe650 0 0x425>;
+   interrupts = ;
+   clocks = < CPG_MOD 318>;
+   dmas = < 0x61>, < 0x62>,
+  < 0x61>, < 0x62>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 318>;
+   status = "disabled";
+   };
+
+   i2c8: i2c@e651 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,iic-r8a7743",
+"renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
+   reg = <0 0xe651 0 0x425>;
+   interrupts = ;
+   clocks = < CPG_MOD 323>;
+   dmas = < 0x65>, < 0x66>,
+  < 0x65>, < 0x66>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 323>;
+   status = "disabled";
+   };
+
scifa0: serial@e6c4 {
compatible = "renesas,scifa-r8a7743",
 "renesas,rcar-gen2-scifa", "renesas,scifa";
-- 
1.9.1



[PATCH 1/2] dt-bindings: i2c: sh_mobile: Document r8a7743/5 support

2017-08-08 Thread Biju Das
Document i2c Device Tree support for RZ/G1[ME]
(also known as r8a774[35]) SoCs. They are compatible with
R-Car Gen2 SoC family. No driver change is required as the
initialisation sequence is currently the same as for the
R-Car Gen2 fallback binding.

Signed-off-by: Biju Das 
---
 Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt 
b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
index ae9c2a7..2243909 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
@@ -4,6 +4,8 @@ Required properties:
 - compatible  :
- "renesas,iic-r8a73a4" (R-Mobile APE6)
- "renesas,iic-r8a7740" (R-Mobile A1)
+   - "renesas,iic-r8a7743" (RZ/G1M)
+   - "renesas,iic-r8a7745" (RZ/G1E)
- "renesas,iic-r8a7790" (R-Car H2)
- "renesas,iic-r8a7791" (R-Car M2-W)
- "renesas,iic-r8a7792" (R-Car V2H)
@@ -12,7 +14,8 @@ Required properties:
- "renesas,iic-r8a7795" (R-Car H3)
- "renesas,iic-r8a7796" (R-Car M3-W)
- "renesas,iic-sh73a0" (SH-Mobile AG5)
-   - "renesas,rcar-gen2-iic" (generic R-Car Gen2 
compatible device)
+   - "renesas,rcar-gen2-iic" (generic R-Car Gen2 or RZ/G1
+   compatible device)
- "renesas,rcar-gen3-iic" (generic R-Car Gen3 
compatible device)
- "renesas,rmobile-iic" (generic device)
 
-- 
1.9.1



Re: [PATCH 1/2] dt-bindings: i2c: Document r8a7743/5 support

2017-08-08 Thread Wolfram Sang
On Tue, Aug 08, 2017 at 12:20:31PM +0100, Biju Das wrote:
> Document i2c Device Tree support for RZ/G1[ME]
> (also known as r8aA774[35]) SoCs. They are compatible with
> R-Car Gen2 SoC family.
> 
> Signed-off-by: Biju Das 

Looks good to me, yet I'd like an ack from Simon who is currently
working on the generic fallback compatibles.

> ---
>  Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> index 2b8bd33..cad39ae 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> @@ -2,6 +2,8 @@ I2C for R-Car platforms
>  
>  Required properties:
>  - compatible:
> + "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC.
> + "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC.
>   "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
>   "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
>   "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
> @@ -12,7 +14,8 @@ Required properties:
>   "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
>   "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
>   "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
> - "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
> + "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible
> + device.
>   "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
>   "renesas,i2c-rcar" (deprecated)
>  
> -- 
> 1.9.1
> 


signature.asc
Description: PGP signature


[PATCH 2/2] ARM: dts: r8a7743: Add I2C DT support

2017-08-08 Thread Biju Das
Add the I2C[0-5] devices to the r8a7743 device tree.

Signed-off-by: Biju Das 
---
This patch has been tested against Linux-next tag 20170727 and renesas-dev 
branch.
This patch depends on 
https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg17008.html

 arch/arm/boot/dts/r8a7743.dtsi | 97 ++
 1 file changed, 97 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 8c46f62..14222c72 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -18,6 +18,15 @@
#address-cells = <2>;
#size-cells = <2>;
 
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   i2c5 = 
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -339,6 +348,94 @@
dma-channels = <15>;
};
 
+   /* The memory map in the User's Manual maps the cores to bus
+*  numbers
+*/
+   i2c0: i2c@e6508000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7743",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe6508000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 931>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 931>;
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@e6518000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7743",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe6518000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 930>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 930>;
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@e653 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7743",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe653 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 929>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 929>;
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@e654 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7743",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe654 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 928>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 928>;
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c4: i2c@e652 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7743",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe652 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 927>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 927>;
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c5: i2c@e6528000 {
+   /* doesn't need pinmux */
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7743",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe6528000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 925>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 925>;
+   i2c-scl-internal-delay-ns = <110>;
+   status = "disabled";
+   };
+
scifa0: serial@e6c4 {
compatible = 

[PATCH 1/2] dt-bindings: i2c: Document r8a7743/5 support

2017-08-08 Thread Biju Das
Document i2c Device Tree support for RZ/G1[ME]
(also known as r8aA774[35]) SoCs. They are compatible with
R-Car Gen2 SoC family.

Signed-off-by: Biju Das 
---
 Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt 
b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 2b8bd33..cad39ae 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -2,6 +2,8 @@ I2C for R-Car platforms
 
 Required properties:
 - compatible:
+   "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC.
+   "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC.
"renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
"renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
"renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
@@ -12,7 +14,8 @@ Required properties:
"renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
"renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
"renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
-   "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
+   "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible
+   device.
"renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
"renesas,i2c-rcar" (deprecated)
 
-- 
1.9.1



[PATCH 2/3] ARM: dts: r8a7743: Add APMU node and second CPU core

2017-08-08 Thread Biju Das
Add DT nodes for the Advanced Power Management Unit (APMU) and the
second CPU core.  Use the enable-method to point out that the APMU
should be used for SMP support.

Signed-off-by: Biju Das 
---
 arch/arm/boot/dts/r8a7743.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index f62e858..77da319 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -21,6 +21,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "renesas,apmu";
 
cpu0: cpu@0 {
device_type = "cpu";
@@ -32,6 +33,15 @@
next-level-cache = <_CA15>;
};
 
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <1>;
+   clock-frequency = <15>;
+   power-domains = < R8A7743_PD_CA15_CPU1>;
+   next-level-cache = <_CA15>;
+   };
+
L2_CA15: cache-controller-0 {
compatible = "cache";
cache-unified;
@@ -48,6 +58,12 @@
#size-cells = <2>;
ranges;
 
+   apmu@e6152000 {
+   compatible = "renesas,r8a7743-apmu", "renesas,apmu";
+   reg = <0 0xe6152000 0 0x188>;
+   cpus = < >;
+   };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
1.9.1



[PATCH 0/3] Add SMP support

2017-08-08 Thread Biju Das
This series aims to add SMP support for r8a7743 SoC.

This series has been tested against Linux-next tag 20170727
and renesas-dev branch.

Biju Das (3):
  dt-bindings: apmu: Document r8a7743 support
  ARM: dts: r8a7743: Add APMU node and second CPU core
  ARM: dts: r8a7743: Add OPP table for frequency scaling

 .../devicetree/bindings/power/renesas,apmu.txt |  3 ++-
 arch/arm/boot/dts/r8a7743.dtsi | 25 ++
 2 files changed, 27 insertions(+), 1 deletion(-)

-- 
1.9.1



[PATCH 1/3] dt-bindings: apmu: Document r8a7743 support

2017-08-08 Thread Biju Das
Document APMU and SMP enable method for RZ/G1M
(also known as r8a7743) SoC.

Signed-off-by: Biju Das 
---
 Documentation/devicetree/bindings/power/renesas,apmu.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.txt 
b/Documentation/devicetree/bindings/power/renesas,apmu.txt
index 84404c9..af21502 100644
--- a/Documentation/devicetree/bindings/power/renesas,apmu.txt
+++ b/Documentation/devicetree/bindings/power/renesas,apmu.txt
@@ -1,12 +1,13 @@
 DT bindings for the Renesas Advanced Power Management Unit
 
-Renesas R-Car line of SoCs utilize one or more APMU hardware units
+Renesas R-Car and RZ/G1 SoCs utilize one or more APMU hardware units
 for CPU core power domain control including SMP boot and CPU Hotplug.
 
 Required properties:
 
 - compatible: Should be "renesas,-apmu", "renesas,apmu" as fallback.
  Examples with soctypes are:
+   - "renesas,r8a7743-apmu" (RZ/G1M)
- "renesas,r8a7790-apmu" (R-Car H2)
- "renesas,r8a7791-apmu" (R-Car M2-W)
- "renesas,r8a7792-apmu" (R-Car V2H)
-- 
1.9.1



[PATCH 3/3] ARM: dts: r8a7743: Add OPP table for frequency scaling

2017-08-08 Thread Biju Das
Add needed information inside CPU0 for the generic cpufreq-cpu0 driver.

- clock-latency = 300 us
Approximate worst-case latency to do clock transition for every
OPPs. Using an arbitrary safe value similar to r8a7791(R-Car M2) Soc.

- operating-points = < kHz - uV >
List of 6 operating points. All of them are using the same voltage
since DVS is not supported in RZ/G1 Soc.

Note:This also fixes the below errors seen on kernel logs
[0.876877] cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19)
[0.883727] cpu cpu1: cpufreq_init: failed to get clk: -2

Signed-off-by: Biju Das 
---
 arch/arm/boot/dts/r8a7743.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 77da319..8c46f62 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -29,8 +29,17 @@
reg = <0>;
clock-frequency = <15>;
clocks = < CPG_CORE R8A7743_CLK_Z>;
+   clock-latency = <30>; /* 300 us */
power-domains = < R8A7743_PD_CA15_CPU0>;
next-level-cache = <_CA15>;
+
+   /* kHz - uV - OPPs unknown yet */
+   operating-points = <150 100>,
+  <1312500 100>,
+  <1125000 100>,
+  < 937500 100>,
+  < 75 100>,
+  < 375000 100>;
};
 
cpu1: cpu@1 {
-- 
1.9.1



Applied "ASoC: rsnd: move rsnd_ssi_config_init() execute condition into it." to the asoc tree

2017-08-08 Thread Mark Brown
The patch

   ASoC: rsnd: move rsnd_ssi_config_init() execute condition into it.

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From bf23c6a3813aac96e0af01565aba012b25c8bae5 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Tue, 8 Aug 2017 01:32:08 +
Subject: [PATCH] ASoC: rsnd: move rsnd_ssi_config_init() execute condition
 into it.

Make it the same style as other functions

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/sh/rcar/ssi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 49cdc5e007b3..3ee7b2de7dea 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -335,6 +335,9 @@ static void rsnd_ssi_config_init(struct rsnd_mod *mod,
u32 wsr;
int is_tdm;
 
+   if (rsnd_ssi_is_parent(mod, io))
+   return;
+
is_tdm = rsnd_runtime_is_ssi_tdm(io);
 
/*
@@ -472,8 +475,7 @@ static int rsnd_ssi_init(struct rsnd_mod *mod,
if (ret < 0)
return ret;
 
-   if (!rsnd_ssi_is_parent(mod, io))
-   rsnd_ssi_config_init(mod, io);
+   rsnd_ssi_config_init(mod, io);
 
rsnd_ssi_register_setup(mod);
 
-- 
2.13.2



Applied "ASoC: rsnd: control SSICR::EN correctly" to the asoc tree

2017-08-08 Thread Mark Brown
The patch

   ASoC: rsnd: control SSICR::EN correctly

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 597b046f0d99b0b0123a715f8c8b1ea881d2bec6 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Tue, 8 Aug 2017 01:31:39 +
Subject: [PATCH] ASoC: rsnd: control SSICR::EN correctly

In case of SSI0 playback, SSI1 capture, SSI0 might be shared for
clock output if clock master mode.

Current rsnd driver had been assumed that SSI clock contiguous
output which is needed for SSI parent needs SSICR::EN (SSI module
enable) bit.
But, this bit controls data input/output, not for clock.
Clock contiguous output needs SSICR : FORCE, SCKD, SWSD,
and SSIWSR : CONT. Not SSICR : EN.

Because of this wrong assumption, and insufficient control, on current
code, for example, if it starts SSI0(playback) -> SSI1(capture) order,
SSI0 SSICR::EN bit will temporarily be 0.
It causes playback side underrun error. This is bug.
We can reproduce this issue with SSI+SRC (without DVC), and capture
during playback operation.

This patch fixup current (wrong) assumption, and control SSICR::EN bit
correctly.

Reported-by: Hiroyuki Yokoyama 
Signed-off-by: Kuninori Morimoto 
Tested-by: Hiroyuki Yokoyama 
Signed-off-by: Mark Brown 
---
 sound/soc/sh/rcar/ssi.c | 40 +++-
 1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 46feddd78ee2..c5d5c64152e9 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -72,6 +72,7 @@ struct rsnd_ssi {
u32 cr_own;
u32 cr_clk;
u32 cr_mode;
+   u32 cr_en;
u32 wsr;
int chan;
int rate;
@@ -291,6 +292,16 @@ static int rsnd_ssi_master_clk_start(struct rsnd_mod *mod,
if (ret < 0)
return ret;
 
+   /*
+* SSI clock will be output contiguously
+* by below settings.
+* This means, rsnd_ssi_master_clk_start()
+* and rsnd_ssi_register_setup() are necessary
+* for SSI parent
+*
+* SSICR  : FORCE, SCKD, SWSD
+* SSIWSR : CONT
+*/
ssi->cr_clk = FORCE | SWL_32 | SCKD | SWSD | CKDV(idx);
ssi->wsr = CONT;
ssi->rate = rate;
@@ -393,7 +404,8 @@ static void rsnd_ssi_register_setup(struct rsnd_mod *mod)
rsnd_mod_write(mod, SSIWSR, ssi->wsr);
rsnd_mod_write(mod, SSICR,  ssi->cr_own |
ssi->cr_clk |
-   ssi->cr_mode); /* without EN */
+   ssi->cr_mode|
+   ssi->cr_en);
 }
 
 static void rsnd_ssi_pointer_init(struct rsnd_mod *mod,
@@ -544,6 +556,8 @@ static int rsnd_ssi_start(struct rsnd_mod *mod,
  struct rsnd_dai_stream *io,
  struct rsnd_priv *priv)
 {
+   struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
+
if (!rsnd_ssi_is_run_mods(mod, io))
return 0;
 
@@ -554,7 +568,19 @@ static int rsnd_ssi_start(struct rsnd_mod *mod,
if (rsnd_ssi_multi_slaves_runtime(io))
return 0;
 
-   rsnd_mod_bset(mod, SSICR, EN, EN);
+   /*
+* EN is for data output.
+* SSI parent EN is not needed.
+*/
+   if (rsnd_ssi_is_parent(mod, io))
+   return 0;
+
+   ssi->cr_en = EN;
+
+   rsnd_mod_write(mod, SSICR,  ssi->cr_own |
+   ssi->cr_clk |
+   ssi->cr_mode|
+   ssi->cr_en);
 
return 0;
 }
@@ -569,13 +595,7 @@ static int rsnd_ssi_stop(struct rsnd_mod *mod,
if (!rsnd_ssi_is_run_mods(mod, io))
return 0;
 
-   /*
-* don't stop if not last user
-* see also
-*  rsnd_ssi_start
-*  rsnd_ssi_interrupt
-*/
-   if (ssi->usrcnt > 1)
+   if (rsnd_ssi_is_parent(mod, 

Applied "ASoC: rsnd: rsnd_ssi_can_output_clk() macro" to the asoc tree

2017-08-08 Thread Mark Brown
The patch

   ASoC: rsnd: rsnd_ssi_can_output_clk() macro

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From bb002f925ae18c0c9d72d87b74b311a5209d7178 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Tue, 8 Aug 2017 01:32:42 +
Subject: [PATCH] ASoC: rsnd: rsnd_ssi_can_output_clk() macro

For example SSI0/SSI1 case, SSI1 can share pin with SSI0.
And then, SSI1 needs SSI0's clock.
This clock controlling is very picky and difficult to understand
in current code.

This patch adds new rsnd_ssi_can_output_clk() macro,
the code will be more understandable.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/sh/rcar/ssi.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 3ee7b2de7dea..434996d4054a 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -106,6 +106,7 @@ struct rsnd_ssi {
(rsnd_ssi_multi_slaves(io) & (1 << rsnd_mod_id(mod)))
 #define rsnd_ssi_is_run_mods(mod, io) \
(rsnd_ssi_run_mods(io) & (1 << rsnd_mod_id(mod)))
+#define rsnd_ssi_can_output_clk(mod) (!__rsnd_ssi_is_pin_sharing(mod))
 
 int rsnd_ssi_hdmi_port(struct rsnd_dai_stream *io)
 {
@@ -255,7 +256,6 @@ static int rsnd_ssi_master_clk_start(struct rsnd_mod *mod,
struct device *dev = rsnd_priv_to_dev(priv);
struct rsnd_dai *rdai = rsnd_io_to_rdai(io);
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
-   struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
int chan = rsnd_runtime_channel_for_ssi(io);
int idx, ret;
unsigned int main_rate;
@@ -266,7 +266,7 @@ static int rsnd_ssi_master_clk_start(struct rsnd_mod *mod,
if (!rsnd_rdai_is_clk_master(rdai))
return 0;
 
-   if (ssi_parent_mod && !rsnd_ssi_is_parent(mod, io))
+   if (!rsnd_ssi_can_output_clk(mod))
return 0;
 
if (rsnd_ssi_is_multi_slave(mod, io))
@@ -307,12 +307,11 @@ static void rsnd_ssi_master_clk_stop(struct rsnd_mod *mod,
 {
struct rsnd_dai *rdai = rsnd_io_to_rdai(io);
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
-   struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
 
if (!rsnd_rdai_is_clk_master(rdai))
return;
 
-   if (ssi_parent_mod && !rsnd_ssi_is_parent(mod, io))
+   if (!rsnd_ssi_can_output_clk(mod))
return;
 
if (ssi->usrcnt > 1)
-- 
2.13.2



Re: [PATCH 00/10] ARM, arm64: dts: renesas: Use R-Car GPIO Gen[123] fallback compat strings

2017-08-08 Thread Magnus Damm
Hi Simon,

On Tue, Aug 8, 2017 at 5:39 PM, Simon Horman  wrote:
> Use newly added R-Car GPIO Gen 1, 2 and 3 fallback compat strings in place
> of now deprecated non-generation specific R-Car GPIO fallback compat string
> in the DT of Renesas ARM and arm64 based SoCs.
>
> This should have no run-time effect as the driver matches against the
> per-SoC compat string before considering the fallback compat string.

Thanks for your efforts.I have no issue with your series (apart from
the GPIO and SATA mistake), but at the same time I believe the GPIO
hardware itself is backwards compatible between various generations.

In the nitpick department I would like to point out that the level of
hardware difference between say R-Car Gen1 GPIO and R-Car Gen2 GPIO is
similar to say good old uarts like 8250 and 16450 hardware. Basically
a couple of registers were added to the hardware in a
backwards-compatible way if I recall correctly.

So if we are going to use "compatible" to point out if hardware is
compatible or not then I would do this instead:

--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -214,7 +214,7 @@

gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a7796",
+"renesas,rcar-gen3-gpio";
 "renesas,gpio-rcar";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;

At the same time I'm not sure if I care _that_ much. =)

Thanks,

/ magnus


Re: [PATCH 3/3] arm64: dts: r8a7795: Use R-Car GPIO Gen3 fallback compat string

2017-08-08 Thread Magnus Damm
Hi Simon,

On Tue, Aug 8, 2017 at 5:54 PM, Simon Horman  wrote:
> Use newly added R-Car GPIO Gen3 fallback compat string
> in the DT of the r8a7795 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before the fallback compat string is considered.
>
> Signed-off-by: Simon Horman 
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index a87ae76880ab..c9f2b87e7ee3 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -1451,7 +1451,8 @@
> };
>
> sata: sata@ee30 {
> -   compatible = "renesas,sata-r8a7795";
> +   compatible = "renesas,sata-r8a7795",
> +"renesas,rcar-gen3-sata";
> reg = <0 0xee30 0 0x20>;
> interrupts = ;
> clocks = < CPG_MOD 815>;
> --
> 2.1.4

This patch looks odd. The subject and patch description says GPIO but
the hunk above modifies SATA...?

Cheers,

/ magnus


Re: [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

2017-08-08 Thread Vincent ABRIOU


On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
> 
> Signed-off-by: Daniel Vetter 

[...]

>   drivers/gpu/drm/sti/sti_cursor.c|  1 -
>   drivers/gpu/drm/sti/sti_gdp.c   |  1 -
>   drivers/gpu/drm/sti/sti_hqvdp.c |  1 -

Acked-by: Vincent Abriou 

BR
Vincent

[PATCH 3/3] arm64: dts: r8a7795: Use R-Car GPIO Gen3 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen3 fallback compat string
in the DT of the r8a7795 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before the fallback compat string is considered.

Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a87ae76880ab..c9f2b87e7ee3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1451,7 +1451,8 @@
};
 
sata: sata@ee30 {
-   compatible = "renesas,sata-r8a7795";
+   compatible = "renesas,sata-r8a7795",
+"renesas,rcar-gen3-sata";
reg = <0 0xee30 0 0x20>;
interrupts = ;
clocks = < CPG_MOD 815>;
-- 
2.1.4



[PATCH 2/3] ARM: dts: r8a7791: Use R-Car GPIO Gen2 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen2 fallback compat string
in the DT of the r8a7791 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before the fallback compat string is considered.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7791.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index ea4a8147d995..f1d1a9772153 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -933,7 +933,7 @@
};
 
sata0: sata@ee30 {
-   compatible = "renesas,sata-r8a7791";
+   compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata";
reg = <0 0xee30 0 0x2000>;
interrupts = ;
clocks = <_clks R8A7791_CLK_SATA0>;
@@ -942,7 +942,7 @@
};
 
sata1: sata@ee50 {
-   compatible = "renesas,sata-r8a7791";
+   compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata";
reg = <0 0xee50 0 0x2000>;
interrupts = ;
clocks = <_clks R8A7791_CLK_SATA1>;
-- 
2.1.4



[PATCH 0/3] ARM, arm64: dts: renesas: Use R-Car SATA Gen[23] fallback compat strings

2017-08-08 Thread Simon Horman
Use newly added R-Car SATA Gen 2 and 3 fallback compat strings.

This should have no run-time effect as the driver matches against the
per-SoC compat string before considering the fallback compat string.

Based on renesas-devel-20170807-v4.13-rc4

Simon Horman (3):
  ARM: dts: r8a7790: Use R-Car GPIO Gen2 fallback compat string
  ARM: dts: r8a7791: Use R-Car GPIO Gen2 fallback compat string
  arm64: dts: r8a7795: Use R-Car GPIO Gen3 fallback compat string

 arch/arm/boot/dts/r8a7790.dtsi   | 4 ++--
 arch/arm/boot/dts/r8a7791.dtsi   | 4 ++--
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
 3 files changed, 6 insertions(+), 5 deletions(-)

-- 
2.1.4



[PATCH 1/3] ARM: dts: r8a7790: Use R-Car GPIO Gen2 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen2 fallback compat string
in the DT of the r8a7790 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before the fallback compat string is considered.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7790.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 167fd57aea68..16358bf8d1db 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -873,7 +873,7 @@
};
 
sata0: sata@ee30 {
-   compatible = "renesas,sata-r8a7790";
+   compatible = "renesas,sata-r8a7790", "renesas,rcar-gen2-sata";
reg = <0 0xee30 0 0x2000>;
interrupts = ;
clocks = <_clks R8A7790_CLK_SATA0>;
@@ -882,7 +882,7 @@
};
 
sata1: sata@ee50 {
-   compatible = "renesas,sata-r8a7790";
+   compatible = "renesas,sata-r8a7790", "renesas,rcar-gen2-sata";
reg = <0 0xee50 0 0x2000>;
interrupts = ;
clocks = <_clks R8A7790_CLK_SATA1>;
-- 
2.1.4



[PATCH 09/10] arm64: dts: r8a7795: Use R-Car GPIO Gen3 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen3 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in the DT of the r8a7795 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a87ae76880ab..79d611db142a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -220,7 +220,7 @@
 
gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a7795",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -235,7 +235,7 @@
 
gpio1: gpio@e6051000 {
compatible = "renesas,gpio-r8a7795",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -250,7 +250,7 @@
 
gpio2: gpio@e6052000 {
compatible = "renesas,gpio-r8a7795",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -265,7 +265,7 @@
 
gpio3: gpio@e6053000 {
compatible = "renesas,gpio-r8a7795",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -280,7 +280,7 @@
 
gpio4: gpio@e6054000 {
compatible = "renesas,gpio-r8a7795",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -295,7 +295,7 @@
 
gpio5: gpio@e6055000 {
compatible = "renesas,gpio-r8a7795",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -310,7 +310,7 @@
 
gpio6: gpio@e6055400 {
compatible = "renesas,gpio-r8a7795",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -325,7 +325,7 @@
 
gpio7: gpio@e6055800 {
compatible = "renesas,gpio-r8a7795",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6055800 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
-- 
2.1.4



[PATCH 08/10] ARM: dts: r8a7794: Use R-Car GPIO Gen2 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen2 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in the DT of the r8a7794 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7794.dtsi | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 26535414203a..294bb1a697a6 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -81,7 +81,7 @@
};
 
gpio0: gpio@e605 {
-   compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7794", "renesas,rcar-gen2-gpio";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -94,7 +94,7 @@
};
 
gpio1: gpio@e6051000 {
-   compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7794", "renesas,rcar-gen2-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -107,7 +107,7 @@
};
 
gpio2: gpio@e6052000 {
-   compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7794", "renesas,rcar-gen2-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -120,7 +120,7 @@
};
 
gpio3: gpio@e6053000 {
-   compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7794", "renesas,rcar-gen2-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -133,7 +133,7 @@
};
 
gpio4: gpio@e6054000 {
-   compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7794", "renesas,rcar-gen2-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -146,7 +146,7 @@
};
 
gpio5: gpio@e6055000 {
-   compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7794", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -159,7 +159,7 @@
};
 
gpio6: gpio@e6055400 {
-   compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7794", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
-- 
2.1.4



[PATCH 07/10] ARM: dts: r8a7793: Use R-Car GPIO Gen2 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen2 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in the DT of the r8a7793 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7793.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 497716b6fbe2..8f905dacb10c 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -114,7 +114,7 @@
};
 
gpio0: gpio@e605 {
-   compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7793", "renesas,rcar-gen2-gpio";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -127,7 +127,7 @@
};
 
gpio1: gpio@e6051000 {
-   compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7793", "renesas,rcar-gen2-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -140,7 +140,7 @@
};
 
gpio2: gpio@e6052000 {
-   compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7793", "renesas,rcar-gen2-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -153,7 +153,7 @@
};
 
gpio3: gpio@e6053000 {
-   compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7793", "renesas,rcar-gen2-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -166,7 +166,7 @@
};
 
gpio4: gpio@e6054000 {
-   compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7793", "renesas,rcar-gen2-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -179,7 +179,7 @@
};
 
gpio5: gpio@e6055000 {
-   compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7793", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -192,7 +192,7 @@
};
 
gpio6: gpio@e6055400 {
-   compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7793", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -205,7 +205,7 @@
};
 
gpio7: gpio@e6055800 {
-   compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7793", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055800 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
-- 
2.1.4



[PATCH 10/10] arm64: dts: r8a7796: Use R-Car GPIO Gen3 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen3 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in the DT of the r8a7796 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index ef1120f4e561..1f945720f761 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -214,7 +214,7 @@
 
gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a7796",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -229,7 +229,7 @@
 
gpio1: gpio@e6051000 {
compatible = "renesas,gpio-r8a7796",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -244,7 +244,7 @@
 
gpio2: gpio@e6052000 {
compatible = "renesas,gpio-r8a7796",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -259,7 +259,7 @@
 
gpio3: gpio@e6053000 {
compatible = "renesas,gpio-r8a7796",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -274,7 +274,7 @@
 
gpio4: gpio@e6054000 {
compatible = "renesas,gpio-r8a7796",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -289,7 +289,7 @@
 
gpio5: gpio@e6055000 {
compatible = "renesas,gpio-r8a7796",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -304,7 +304,7 @@
 
gpio6: gpio@e6055400 {
compatible = "renesas,gpio-r8a7796",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -319,7 +319,7 @@
 
gpio7: gpio@e6055800 {
compatible = "renesas,gpio-r8a7796",
-"renesas,gpio-rcar";
+"renesas,rcar-gen3-gpio";
reg = <0 0xe6055800 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
-- 
2.1.4



[PATCH 03/10] ARM: dts: r8a7743: Use R-Car GPIO Gen2 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen2 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in the DT of the r8a7743 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7743.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index f62e8587f1a8..e4c0c9d1bfad 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -67,7 +67,7 @@
 
gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a7743",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -82,7 +82,7 @@
 
gpio1: gpio@e6051000 {
compatible = "renesas,gpio-r8a7743",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -97,7 +97,7 @@
 
gpio2: gpio@e6052000 {
compatible = "renesas,gpio-r8a7743",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -112,7 +112,7 @@
 
gpio3: gpio@e6053000 {
compatible = "renesas,gpio-r8a7743",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -127,7 +127,7 @@
 
gpio4: gpio@e6054000 {
compatible = "renesas,gpio-r8a7743",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -142,7 +142,7 @@
 
gpio5: gpio@e6055000 {
compatible = "renesas,gpio-r8a7743",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -157,7 +157,7 @@
 
gpio6: gpio@e6055400 {
compatible = "renesas,gpio-r8a7743",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -172,7 +172,7 @@
 
gpio7: gpio@e6055800 {
compatible = "renesas,gpio-r8a7743",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055800 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
-- 
2.1.4



[PATCH 02/10] ARM: dts: r8a7779: Use R-Car GPIO Gen1 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen1 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in DT of r8a7779 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7779.dtsi | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 8ee0b2ca5d39..ccef2cfab6e0 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -76,7 +76,7 @@
};
 
gpio0: gpio@ffc4 {
-   compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
reg = <0xffc4 0x2c>;
interrupts = ;
#gpio-cells = <2>;
@@ -87,7 +87,7 @@
};
 
gpio1: gpio@ffc41000 {
-   compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
reg = <0xffc41000 0x2c>;
interrupts = ;
#gpio-cells = <2>;
@@ -98,7 +98,7 @@
};
 
gpio2: gpio@ffc42000 {
-   compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
reg = <0xffc42000 0x2c>;
interrupts = ;
#gpio-cells = <2>;
@@ -109,7 +109,7 @@
};
 
gpio3: gpio@ffc43000 {
-   compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
reg = <0xffc43000 0x2c>;
interrupts = ;
#gpio-cells = <2>;
@@ -120,7 +120,7 @@
};
 
gpio4: gpio@ffc44000 {
-   compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
reg = <0xffc44000 0x2c>;
interrupts = ;
#gpio-cells = <2>;
@@ -131,7 +131,7 @@
};
 
gpio5: gpio@ffc45000 {
-   compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
reg = <0xffc45000 0x2c>;
interrupts = ;
#gpio-cells = <2>;
@@ -142,7 +142,7 @@
};
 
gpio6: gpio@ffc46000 {
-   compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
reg = <0xffc46000 0x2c>;
interrupts = ;
#gpio-cells = <2>;
-- 
2.1.4



[PATCH 00/10] ARM, arm64: dts: renesas: Use R-Car GPIO Gen[123] fallback compat strings

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen 1, 2 and 3 fallback compat strings in place
of now deprecated non-generation specific R-Car GPIO fallback compat string
in the DT of Renesas ARM and arm64 based SoCs.

This should have no run-time effect as the driver matches against the
per-SoC compat string before considering the fallback compat string.

Based on renesas-devel-20170807-v4.13-rc4

Simon Horman (10):
  ARM: dts: r8a7778: Use R-Car GPIO Gen1 fallback compat string
  ARM: dts: r8a7779: Use R-Car GPIO Gen1 fallback compat string
  ARM: dts: r8a7743: Use R-Car GPIO Gen2 fallback compat string
  ARM: dts: r8a7790: Use R-Car GPIO Gen2 fallback compat string
  ARM: dts: r8a7791: Use R-Car GPIO Gen2 fallback compat string
  ARM: dts: r8a7792: Use R-Car GPIO Gen2 fallback compat string
  ARM: dts: r8a7793: Use R-Car GPIO Gen2 fallback compat string
  ARM: dts: r8a7794: Use R-Car GPIO Gen2 fallback compat string
  arm64: dts: r8a7795: Use R-Car GPIO Gen3 fallback compat string
  arm64: dts: r8a7796: Use R-Car GPIO Gen3 fallback compat string

 arch/arm/boot/dts/r8a7743.dtsi   | 16 
 arch/arm/boot/dts/r8a7778.dtsi   | 10 +-
 arch/arm/boot/dts/r8a7779.dtsi   | 14 +++---
 arch/arm/boot/dts/r8a7790.dtsi   | 12 ++--
 arch/arm/boot/dts/r8a7791.dtsi   | 16 
 arch/arm/boot/dts/r8a7792.dtsi   | 24 
 arch/arm/boot/dts/r8a7793.dtsi   | 16 
 arch/arm/boot/dts/r8a7794.dtsi   | 14 +++---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 16 
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 16 
 10 files changed, 77 insertions(+), 77 deletions(-)

-- 
2.1.4



[PATCH 06/10] ARM: dts: r8a7792: Use R-Car GPIO Gen2 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen2 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in the DT of the r8a7792 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7792.dtsi | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 2623f39bed2b..7fa5d835dbe9 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -145,7 +145,7 @@
 
gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -159,7 +159,7 @@
 
gpio1: gpio@e6051000 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -173,7 +173,7 @@
 
gpio2: gpio@e6052000 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -187,7 +187,7 @@
 
gpio3: gpio@e6053000 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -201,7 +201,7 @@
 
gpio4: gpio@e6054000 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -215,7 +215,7 @@
 
gpio5: gpio@e6055000 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -229,7 +229,7 @@
 
gpio6: gpio@e6055100 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055100 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -243,7 +243,7 @@
 
gpio7: gpio@e6055200 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055200 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -257,7 +257,7 @@
 
gpio8: gpio@e6055300 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055300 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -271,7 +271,7 @@
 
gpio9: gpio@e6055400 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -285,7 +285,7 @@
 
gpio10: gpio@e6055500 {
compatible = "renesas,gpio-r8a7792",
-"renesas,gpio-rcar";
+"renesas,rcar-gen2-gpio";
reg = <0 0xe6055500 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -299,7 +299,7 @@
 
gpio11: gpio@e6055600 {
compatible = "renesas,gpio-r8a7792",
-

[PATCH 04/10] ARM: dts: r8a7790: Use R-Car GPIO Gen2 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen2 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in the DT of the r8a7790 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7790.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 167fd57aea68..34cc293ac087 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -191,7 +191,7 @@
};
 
gpio0: gpio@e605 {
-   compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7790", "renesas,rcar-gen2-gpio";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -204,7 +204,7 @@
};
 
gpio1: gpio@e6051000 {
-   compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7790", "renesas,rcar-gen2-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -217,7 +217,7 @@
};
 
gpio2: gpio@e6052000 {
-   compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7790", "renesas,rcar-gen2-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -230,7 +230,7 @@
};
 
gpio3: gpio@e6053000 {
-   compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7790", "renesas,rcar-gen2-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -243,7 +243,7 @@
};
 
gpio4: gpio@e6054000 {
-   compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7790", "renesas,rcar-gen2-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -256,7 +256,7 @@
};
 
gpio5: gpio@e6055000 {
-   compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7790", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
-- 
2.1.4



[PATCH 05/10] ARM: dts: r8a7791: Use R-Car GPIO Gen2 fallback compat string

2017-08-08 Thread Simon Horman
Use newly added R-Car GPIO Gen2 fallback compat string
in place of now deprecated non-generation specific
R-Car GPIO fallback compat string in the DT of the r8a7791 SoC.

This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7791.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index ea4a8147d995..4bef05f186df 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -123,7 +123,7 @@
};
 
gpio0: gpio@e605 {
-   compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7791", "renesas,rcar-gen2-gpio";
reg = <0 0xe605 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -136,7 +136,7 @@
};
 
gpio1: gpio@e6051000 {
-   compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7791", "renesas,rcar-gen2-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -149,7 +149,7 @@
};
 
gpio2: gpio@e6052000 {
-   compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7791", "renesas,rcar-gen2-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -162,7 +162,7 @@
};
 
gpio3: gpio@e6053000 {
-   compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7791", "renesas,rcar-gen2-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -175,7 +175,7 @@
};
 
gpio4: gpio@e6054000 {
-   compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7791", "renesas,rcar-gen2-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -188,7 +188,7 @@
};
 
gpio5: gpio@e6055000 {
-   compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7791", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -201,7 +201,7 @@
};
 
gpio6: gpio@e6055400 {
-   compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7791", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
@@ -214,7 +214,7 @@
};
 
gpio7: gpio@e6055800 {
-   compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
+   compatible = "renesas,gpio-r8a7791", "renesas,rcar-gen2-gpio";
reg = <0 0xe6055800 0 0x50>;
interrupts = ;
#gpio-cells = <2>;
-- 
2.1.4



Re: [PATCH 27/31] arm64: dts: renesas: r8a7795: Add usb companion property in EHCI

2017-08-08 Thread Simon Horman
On Wed, Aug 02, 2017 at 02:20:59PM +0200, Simon Horman wrote:
> On Mon, Jul 31, 2017 at 07:40:23PM +0300, Sergei Shtylyov wrote:
> > On 07/31/2017 06:03 PM, Simon Horman wrote:
> > 
> > >From: Kazuya Mizuguchi 
> > >
> > >This patch adds the "companion" property in the EHCI ch0, ch1 and
> > >ch2 nodes to wait for the usb companion controller startup at resume.
> > >
> > >Signed-off-by: Kazuya Mizuguchi 
> > >Signed-off-by: Takeshi Kihara 
> > >[remove ch3 node and revise the commit log]
> > >Signed-off-by: Yoshihiro Shimoda 
> > >
> > >Signed-off-by: Simon Horman 
> > >---
> > >  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > >diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> > >b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > >index d73d986039c8..7246e689b619 100644
> > >--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > >+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > >@@ -1583,6 +1583,7 @@
> > >   clocks = < CPG_MOD 703>;
> > >   phys = <_phy0>;
> > >   phy-names = "usb";
> > >+  companion= <>;
> > >   power-domains = < R8A7795_PD_ALWAYS_ON>;
> > >   resets = < 703>;
> > >   status = "disabled";
> > >@@ -1595,6 +1596,7 @@
> > >   clocks = < CPG_MOD 702>;
> > >   phys = <_phy1>;
> > >   phy-names = "usb";
> > >+  companion= <>;
> > >   power-domains = < R8A7795_PD_ALWAYS_ON>;
> > >   resets = < 702>;
> > >   status = "disabled";
> > >@@ -1607,6 +1609,7 @@
> > >   clocks = < CPG_MOD 701>;
> > >   phys = <_phy2>;
> > >   phy-names = "usb";
> > >+  companion= <>;
> > >   power-domains = < R8A7795_PD_ALWAYS_ON>;
> > >   resets = < 701>;
> > >   status = "disabled";
> > 
> >Looks like a space before = is missing in all 3 cases.
> 
> Thanks.
> 
> I'll post a follow-up patch for that. I don't think it warrants respinning
> this pull request at this point.

Follow-up sent as
[PATCH] arm64: dts: renesas: r8a7795: correct whitespace of companion property


[PATCH] arm64: dts: renesas: r8a7795: correct whitespace of companion property

2017-08-08 Thread Simon Horman
Fixes: 4dad6dcdae7b ("arm64: dts: renesas: r8a7795: add usb2.0 host ch3 device 
nodes")
Fixes: 1c422b4c501e ("arm64: dts: renesas: r8a7795: Add usb companion property 
in EHCI")
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

 Based on renesas-devel-20170807-v4.13-rc4

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a87ae76880ab..efe2cb2b9951 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1623,7 +1623,7 @@
clocks = < CPG_MOD 703>;
phys = <_phy0>;
phy-names = "usb";
-   companion= <>;
+   companion = <>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 703>;
status = "disabled";
@@ -1636,7 +1636,7 @@
clocks = < CPG_MOD 702>;
phys = <_phy1>;
phy-names = "usb";
-   companion= <>;
+   companion = <>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 702>;
status = "disabled";
@@ -1649,7 +1649,7 @@
clocks = < CPG_MOD 701>;
phys = <_phy2>;
phy-names = "usb";
-   companion= <>;
+   companion = <>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 701>;
status = "disabled";
@@ -1662,7 +1662,7 @@
clocks = < CPG_MOD 700>;
phys = <_phy3>;
phy-names = "usb";
-   companion= <>;
+   companion = <>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 700>;
status = "disabled";
-- 
2.1.4