[PATCH v2] pinctrl: sh-pfc: r8a77970: fix pin I/O voltage control support

[Sergei Shtylyov]

I've included the pin I/O voltage control into the R8A77970 PFC driver but
it was incomplete because:
- SH_PFC_PIN_CFG_IO_VOLTAGE pin flags weren't set properly;
- sh_pfc_soc_info::ioctrl_regs wasn't set at all...

Fixes: b92ac66a1819 ("pinctrl: sh-pfc: Add R8A77970 PFC support")
Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'sh-pfc' branch of Geert's 'renesas-drivers.git' repo.

Changes in version 2:
- fixed the commit SHA1 in the "Fixes:" tag.

 drivers/pinctrl/sh-pfc/pfc-r8a77970.c |   34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)

Index: renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
===
--- renesas-drivers.orig/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
+++ renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
@@ -21,13 +21,15 @@
 #include "core.h"
 #include "sh_pfc.h"
 
+#define CFG_FLAGS SH_PFC_PIN_CFG_DRIVE_STRENGTH
+
 #define CPU_ALL_PORT(fn, sfx)  \
-   PORT_GP_CFG_22(0, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),  \
-   PORT_GP_CFG_28(1, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),  \
-   PORT_GP_CFG_17(2, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),  \
-   PORT_GP_CFG_17(3, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),  \
-   PORT_GP_CFG_6(4, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),   \
-   PORT_GP_CFG_15(5, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH)
+   PORT_GP_CFG_22(0, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
+   PORT_GP_CFG_28(1, fn, sfx, CFG_FLAGS),  \
+   PORT_GP_CFG_17(2, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
+   PORT_GP_CFG_17(3, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
+   PORT_GP_CFG_6(4,  fn, sfx, CFG_FLAGS),  \
+   PORT_GP_CFG_15(5, fn, sfx, CFG_FLAGS)
 /*
  * F_() : just information
  * FM() : macro for FN_xxx / xxx_MARK
@@ -2382,18 +2384,33 @@ static const struct pinmux_cfg_reg pinmu
{ },
 };
 
+enum ioctrl_regs {
+   IOCTRL30,
+   IOCTRL31,
+   IOCTRL32,
+   IOCTRL40,
+};
+
+static const struct pinmux_ioctrl_reg pinmux_ioctrl_regs[] = {
+   [IOCTRL30] = { 0xe6060380 },
+   [IOCTRL31] = { 0xe6060384 },
+   [IOCTRL32] = { 0xe6060388 },
+   [IOCTRL40] = { 0xe60603c0 },
+   { /* sentinel */ },
+};
+
 static int r8a77970_pin_to_pocctrl(struct sh_pfc *pfc, unsigned int pin,
   u32 *pocctrl)
 {
int bit = pin & 0x1f;
 
-   *pocctrl = 0xe6060380;
+   *pocctrl = pinmux_ioctrl_regs[IOCTRL30].reg;
if (pin >= RCAR_GP_PIN(0, 0) && pin <= RCAR_GP_PIN(0, 21))
return bit;
if (pin >= RCAR_GP_PIN(2, 0) && pin <= RCAR_GP_PIN(2, 9))
return bit + 22;
 
-   *pocctrl += 4;
+   *pocctrl = pinmux_ioctrl_regs[IOCTRL31].reg;
if (pin >= RCAR_GP_PIN(2, 10) && pin <= RCAR_GP_PIN(2, 16))
return bit - 10;
if (pin >= RCAR_GP_PIN(3, 0) && pin <= RCAR_GP_PIN(3, 16))
@@ -2421,6 +2438,7 @@ const struct sh_pfc_soc_info r8a77970_pi
.nr_functions = ARRAY_SIZE(pinmux_functions),
 
.cfg_regs = pinmux_config_regs,
+   .ioctrl_regs = pinmux_ioctrl_regs,
 
.pinmux_data = pinmux_data,
.pinmux_data_size = ARRAY_SIZE(pinmux_data),

Re: [PATCH] pinctrl: sh-pfc: r8a77970: fix pin I/O voltage control support

[Sergei Shtylyov]

On 04/18/2018 11:06 PM, Sergei Shtylyov wrote:

> I've included the pin I/O voltage control into the R8A77970 PFC driver but
> it was incomplete because:
> - SH_PFC_PIN_CFG_IO_VOLTAGE pin flags weren't set properly;
> - sh_pfc_soc_info::ioctrl_regs wasn't set at all...
> 
> Fixes: b92ac66a181 ("pinctrl: sh-pfc: Add R8A77970 PFC support")

   Oops, only 11 digits... will repost!

> Signed-off-by: Sergei Shtylyov 
[...]

MBR, Sergei

[PATCH 5/5] arm64: dts: renesas: r8a77970: sort subnodes of the soc node

[Yoshihiro Kaneko]

Sort subnodes of the soc node.
- The primary key is the bus address.
- The secondary key is the IP block.
- The tertiary key is the node name.

This is part of an ongoing effort to provide consistent node
order in the DT of Renesas SoCs to improve maintainability.

This should not have any run-time effect.

Signed-off-by: Yoshihiro Kaneko 
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 378 +++---
 1 file changed, 189 insertions(+), 189 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 71f466d..d8f6808 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -83,23 +83,6 @@
#size-cells = <2>;
ranges;
 
-   gic: interrupt-controller@f101 {
-   compatible = "arm,gic-400";
-   #interrupt-cells = <3>;
-   #address-cells = <0>;
-   interrupt-controller;
-   reg = <0 0xf101 0 0x1000>,
- <0 0xf102 0 0x2>,
- <0 0xf104 0 0x2>,
- <0 0xf106 0 0x2>;
-   interrupts = ;
-   clocks = < CPG_MOD 408>;
-   clock-names = "clk";
-   power-domains = < R8A77970_PD_ALWAYS_ON>;
-   resets = < 408>;
-   };
-
rwdt: watchdog@e602 {
compatible = "renesas,r8a77970-wdt",
 "renesas,rcar-gen3-wdt";
@@ -110,75 +93,6 @@
status = "disabled";
};
 
-   cpg: clock-controller@e615 {
-   compatible = "renesas,r8a77970-cpg-mssr";
-   reg = <0 0xe615 0 0x1000>;
-   clocks = <_clk>, <_clk>;
-   clock-names = "extal", "extalr";
-   #clock-cells = <2>;
-   #power-domain-cells = <0>;
-   #reset-cells = <1>;
-   };
-
-   rst: reset-controller@e616 {
-   compatible = "renesas,r8a77970-rst";
-   reg = <0 0xe616 0 0x200>;
-   };
-
-   sysc: system-controller@e618 {
-   compatible = "renesas,r8a77970-sysc";
-   reg = <0 0xe618 0 0x440>;
-   #power-domain-cells = <1>;
-   };
-
-   ipmmu_vi0: mmu@febd {
-   compatible = "renesas,ipmmu-r8a77970";
-   reg = <0 0xfebd 0 0x1000>;
-   renesas,ipmmu-main = <_mm 9>;
-   power-domains = < R8A77970_PD_ALWAYS_ON>;
-   #iommu-cells = <1>;
-   status = "disabled";
-   };
-
-   ipmmu_ir: mmu@ff8b {
-   compatible = "renesas,ipmmu-r8a77970";
-   reg = <0 0xff8b 0 0x1000>;
-   renesas,ipmmu-main = <_mm 3>;
-   power-domains = < R8A77970_PD_A3IR>;
-   #iommu-cells = <1>;
-   status = "disabled";
-   };
-
-   ipmmu_rt: mmu@ffc8 {
-   compatible = "renesas,ipmmu-r8a77970";
-   reg = <0 0xffc8 0 0x1000>;
-   renesas,ipmmu-main = <_mm 7>;
-   power-domains = < R8A77970_PD_ALWAYS_ON>;
-   #iommu-cells = <1>;
-   };
-
-   ipmmu_ds1: mmu@e774 {
-   compatible = "renesas,ipmmu-r8a77970";
-   reg = <0 0xe774 0 0x1000>;
-   renesas,ipmmu-main = <_mm 0>;
-   power-domains = < R8A77970_PD_ALWAYS_ON>;
-   #iommu-cells = <1>;
-   };
-
-   ipmmu_mm: mmu@e67b {
-   compatible = "renesas,ipmmu-r8a77970";
-   reg = <0 0xe67b 0 0x1000>;
-   interrupts = ,
-;
-   power-domains = < R8A77970_PD_ALWAYS_ON>;
-   #iommu-cells = <1>;
-   };
-
-   pfc: pin-controller@e606 {
-   compatible = "renesas,pfc-r8a77970";
-   reg = <0 0xe606 0 0x504>;
-   };
-
gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a77970",
 "renesas,rcar-gen3-gpio";
@@ -269,6 +183,32 @@
resets = < 907>;
};
 
+   pfc: pin-controller@e606 {
+   compatible = 

[PATCH 3/5] arm64: dts: renesas: r8a77965: sort subnodes of the root node

[Yoshihiro Kaneko]

Sort subnodes of the root node alphanumerically.

This is part of an ongoing effort to provide consistent node
order in the DT of Renesas SoCs to improve maintainability.

This should not have any run-time effect.

Signed-off-by: Yoshihiro Kaneko 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 120 +++---
 1 file changed, 60 insertions(+), 60 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index a41f916..d110382 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -22,9 +22,34 @@
i2c7 = _dvfs;
};
 
-   psci {
-   compatible = "arm,psci-1.0", "arm,psci-0.2";
-   method = "smc";
+   /*
+* The external audio clocks are configured as 0 Hz fixed frequency
+* clocks by default.
+* Boards that provide audio clocks should override them.
+*/
+   audio_clk_a: audio_clk_a {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   audio_clk_b: audio_clk_b {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   audio_clk_c: audio_clk_c {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   /* External CAN clock - to be overridden by boards that provide it */
+   can_clk: can {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
};
 
cpus {
@@ -71,34 +96,24 @@
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_clk_a: audio_clk_a {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
-   audio_clk_b: audio_clk_b {
+   /* External PCIe clock - can be overridden by the board */
+   pcie_bus_clk: pcie_bus {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <0>;
};
 
-   audio_clk_c: audio_clk_c {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
+   pmu_a57 {
+   compatible = "arm,cortex-a57-pmu";
+   interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-affinity = <_0>,
+<_1>;
};
 
-   /* External CAN clock - to be overridden by boards that provide it */
-   can_clk: can {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
+   psci {
+   compatible = "arm,psci-1.0", "arm,psci-0.2";
+   method = "smc";
};
 
/* External SCIF clock - to be overridden by boards that provide it */
@@ -108,42 +123,6 @@
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 USB clocks - can be overridden by the board */
-   usb3s0_clk: usb3s0 {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
-   usb_extal_clk: usb_extal {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
-   timer {
-   compatible = "arm,armv8-timer";
-   interrupts-extended = < 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)>;
-   };
-
-   pmu_a57 {
-   compatible = "arm,cortex-a57-pmu";
-   interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
- < GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
-   interrupt-affinity = <_0>,
-<_1>;
-   };
-
soc {
compatible = "simple-bus";
interrupt-parent = <>;
@@ -1073,4 +1052,25 @@
/* placeholder */
   

[PATCH 4/5] arm64: dts: renesas: r8a77965: sort subnodes of the soc node

[Yoshihiro Kaneko]

Sort subnodes of the soc node.
- The primary key is the bus address.
- The secondary key is the IP block.
- The tertiary key is the node name.

This is part of an ongoing effort to provide consistent node
order in the DT of Renesas SoCs to improve maintainability.

This should not have any run-time effect.

Signed-off-by: Yoshihiro Kaneko 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 912 +++---
 1 file changed, 456 insertions(+), 456 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index d110382..b12f417 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -130,52 +130,9 @@
#size-cells = <2>;
ranges;
 
-   gic: interrupt-controller@f101 {
-   compatible = "arm,gic-400";
-   #interrupt-cells = <3>;
-   #address-cells = <0>;
-   interrupt-controller;
-   reg = <0x0 0xf101 0 0x1000>,
- <0x0 0xf102 0 0x2>,
- <0x0 0xf104 0 0x2>,
- <0x0 0xf106 0 0x2>;
-   interrupts = ;
-   clocks = < CPG_MOD 408>;
-   clock-names = "clk";
-   power-domains = < 32>;
-   resets = < 408>;
-   };
-
-   pfc: pin-controller@e606 {
-   compatible = "renesas,pfc-r8a77965";
-   reg = <0 0xe606 0 0x50c>;
-   };
-
-   cpg: clock-controller@e615 {
-   compatible = "renesas,r8a77965-cpg-mssr";
-   reg = <0 0xe615 0 0x1000>;
-   clocks = <_clk>, <_clk>;
-   clock-names = "extal", "extalr";
-   #clock-cells = <2>;
-   #power-domain-cells = <0>;
-   #reset-cells = <1>;
-   };
-
-   rst: reset-controller@e616 {
-   compatible = "renesas,r8a77965-rst";
-   reg = <0 0xe616 0 0x0200>;
-   };
-
-   prr: chipid@fff00044 {
-   compatible = "renesas,prr";
-   reg = <0 0xfff00044 0 4>;
-   };
-
-   sysc: system-controller@e618 {
-   compatible = "renesas,r8a77965-sysc";
-   reg = <0 0xe618 0 0x0400>;
-   #power-domain-cells = <1>;
+   wdt0: watchdog@e602 {
+   reg = <0 0xe602 0 0x0c>;
+   /* placeholder */
};
 
gpio0: gpio@e605 {
@@ -298,6 +255,32 @@
resets = < 905>;
};
 
+   pfc: pin-controller@e606 {
+   compatible = "renesas,pfc-r8a77965";
+   reg = <0 0xe606 0 0x50c>;
+   };
+
+   cpg: clock-controller@e615 {
+   compatible = "renesas,r8a77965-cpg-mssr";
+   reg = <0 0xe615 0 0x1000>;
+   clocks = <_clk>, <_clk>;
+   clock-names = "extal", "extalr";
+   #clock-cells = <2>;
+   #power-domain-cells = <0>;
+   #reset-cells = <1>;
+   };
+
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a77965-rst";
+   reg = <0 0xe616 0 0x0200>;
+   };
+
+   sysc: system-controller@e618 {
+   compatible = "renesas,r8a77965-sysc";
+   reg = <0 0xe618 0 0x0400>;
+   #power-domain-cells = <1>;
+   };
+
intc_ex: interrupt-controller@e61c {
compatible = "renesas,intc-ex-r8a77965", "renesas,irqc";
#interrupt-cells = <2>;
@@ -314,6 +297,121 @@
resets = < 407>;
};
 
+   i2c0: i2c@e650 {
+   reg = <0 0xe650 0 0x40>;
+   /* placeholder */
+   };
+
+   i2c1: i2c@e6508000 {
+   reg = <0 0xe6508000 0 0x40>;
+   /* placeholder */
+   };
+
+   i2c2: i2c@e651 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <0 0xe651 0 0x40>;
+   /* placeholder */
+   };
+
+   i2c3: i2c@e66d {
+   reg = <0 0xe66d 0 0x40>;
+   /* placeholder */
+  

[PATCH 2/5] arm64: dts: renesas: r8a77995: sort subnodes of the soc node

[Yoshihiro Kaneko]

Sort subnodes of the soc node.
- The primary key is the bus address.
- The secondary key is the IP block.
- The tertiary key is the node name.

This is part of an ongoing effort to provide consistent node
order in the DT of Renesas SoCs to improve maintainability.

This should not have any run-time effect.

Signed-off-by: Yoshihiro Kaneko 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 697 +++---
 1 file changed, 348 insertions(+), 349 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index cf47655..a978305 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -76,23 +76,6 @@
#size-cells = <2>;
ranges;
 
-   gic: interrupt-controller@f101 {
-   compatible = "arm,gic-400";
-   #interrupt-cells = <3>;
-   #address-cells = <0>;
-   interrupt-controller;
-   reg = <0x0 0xf101 0 0x1000>,
- <0x0 0xf102 0 0x2>,
- <0x0 0xf104 0 0x2>,
- <0x0 0xf106 0 0x2>;
-   interrupts = ;
-   clocks = < CPG_MOD 408>;
-   clock-names = "clk";
-   power-domains = < R8A77995_PD_ALWAYS_ON>;
-   resets = < 408>;
-   };
-
rwdt: watchdog@e602 {
compatible = "renesas,r8a77995-wdt",
 "renesas,rcar-gen3-wdt";
@@ -103,88 +86,123 @@
status = "disabled";
};
 
-   ipmmu_vi0: mmu@febd {
-   compatible = "renesas,ipmmu-r8a77995";
-   reg = <0 0xfebd 0 0x1000>;
-   renesas,ipmmu-main = <_mm 14>;
-   #iommu-cells = <1>;
-   status = "disabled";
-   };
-
-   ipmmu_vp0: mmu@fe99 {
-   compatible = "renesas,ipmmu-r8a77995";
-   reg = <0 0xfe99 0 0x1000>;
-   renesas,ipmmu-main = <_mm 16>;
-   #iommu-cells = <1>;
-   status = "disabled";
-   };
-
-   ipmmu_vc0: mmu@fe6b {
-   compatible = "renesas,ipmmu-r8a77995";
-   reg = <0 0xfe6b 0 0x1000>;
-   renesas,ipmmu-main = <_mm 12>;
-   #iommu-cells = <1>;
-   status = "disabled";
+   gpio0: gpio@e605 {
+   compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+"renesas,gpio-rcar";
+   reg = <0 0xe605 0 0x50>;
+   interrupts = ;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-ranges = < 0 0 9>;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   clocks = < CPG_MOD 912>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 912>;
};
 
-   ipmmu_pv0: mmu@fd80 {
-   compatible = "renesas,ipmmu-r8a77995";
-   reg = <0 0xfd80 0 0x1000>;
-   renesas,ipmmu-main = <_mm 6>;
-   #iommu-cells = <1>;
-   status = "disabled";
+   gpio1: gpio@e6051000 {
+   compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+"renesas,gpio-rcar";
+   reg = <0 0xe6051000 0 0x50>;
+   interrupts = ;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-ranges = < 0 32 32>;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   clocks = < CPG_MOD 911>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 911>;
};
 
-   ipmmu_hc: mmu@e657 {
-   compatible = "renesas,ipmmu-r8a77995";
-   reg = <0 0xe657 0 0x1000>;
-   renesas,ipmmu-main = <_mm 2>;
-   #iommu-cells = <1>;
-   status = "disabled";
+   gpio2: gpio@e6052000 {
+   compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+

[PATCH 0/5] arm64: dts: renesas: r8a779xx: sort nodes

[Yoshihiro Kaneko]

Sort nodes of the R-Car M3-N (r8a77965), V3M (r8a77970) and D3 (r8a77995) DTs.

This is part of an ongoing effort to provide consistent node
order in the DT of Renesas SoCs to improve maintainability.

This should not have any run-time effect.

Based on the devel branch of Simon Horman's renesas tree.

Yoshihiro Kaneko (5):
  arm64: dts: renesas: r8a77995: sort subnodes of the root node
  arm64: dts: renesas: r8a77995: sort subnodes of the soc node
  arm64: dts: renesas: r8a77965: sort subnodes of the root node
  arm64: dts: renesas: r8a77965: sort subnodes of the soc node
  arm64: dts: renesas: r8a77970: sort subnodes of the soc node

 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1160 ++---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi |  378 +-
 arch/arm64/boot/dts/renesas/r8a77995.dtsi |  717 +-
 3 files changed, 1127 insertions(+), 1128 deletions(-)

-- 
1.9.1

[PATCH 1/5] arm64: dts: renesas: r8a77995: sort subnodes of the root node

[Yoshihiro Kaneko]

Sort subnodes of the root node alphanumerically.

This is part of an ongoing effort to provide consistent node
order in the DT of Renesas SoCs to improve maintainability.

This should not have any run-time effect.

Signed-off-by: Yoshihiro Kaneko 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 82aed7e..cf47655 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -18,9 +18,11 @@
#address-cells = <2>;
#size-cells = <2>;
 
-   psci {
-   compatible = "arm,psci-1.0", "arm,psci-0.2";
-   method = "smc";
+   /* External CAN clock - to be overridden by boards that provide it */
+   can_clk: can {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
};
 
cpus {
@@ -51,18 +53,16 @@
clock-frequency = <0>;
};
 
-   /* External CAN clock - to be overridden by boards that provide it */
-   can_clk: can {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
pmu_a53 {
compatible = "arm,cortex-a53-pmu";
interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
};
 
+   psci {
+   compatible = "arm,psci-1.0", "arm,psci-0.2";
+   method = "smc";
+   };
+
scif_clk: scif {
compatible = "fixed-clock";
#clock-cells = <0>;
-- 
1.9.1

[PATCH] pinctrl: sh-pfc: r8a77970: fix pin I/O voltage control support

[Sergei Shtylyov]

I've included the pin I/O voltage control into the R8A77970 PFC driver but
it was incomplete because:
- SH_PFC_PIN_CFG_IO_VOLTAGE pin flags weren't set properly;
- sh_pfc_soc_info::ioctrl_regs wasn't set at all...

Fixes: b92ac66a181 ("pinctrl: sh-pfc: Add R8A77970 PFC support")
Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'sh-pfc' branch of Geert's 'renesas-drivers.git' repo.

 drivers/pinctrl/sh-pfc/pfc-r8a77970.c |   34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)

Index: renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
===
--- renesas-drivers.orig/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
+++ renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
@@ -21,13 +21,15 @@
 #include "core.h"
 #include "sh_pfc.h"
 
+#define CFG_FLAGS SH_PFC_PIN_CFG_DRIVE_STRENGTH
+
 #define CPU_ALL_PORT(fn, sfx)  \
-   PORT_GP_CFG_22(0, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),  \
-   PORT_GP_CFG_28(1, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),  \
-   PORT_GP_CFG_17(2, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),  \
-   PORT_GP_CFG_17(3, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),  \
-   PORT_GP_CFG_6(4, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH),   \
-   PORT_GP_CFG_15(5, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH)
+   PORT_GP_CFG_22(0, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
+   PORT_GP_CFG_28(1, fn, sfx, CFG_FLAGS),  \
+   PORT_GP_CFG_17(2, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
+   PORT_GP_CFG_17(3, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
+   PORT_GP_CFG_6(4,  fn, sfx, CFG_FLAGS),  \
+   PORT_GP_CFG_15(5, fn, sfx, CFG_FLAGS)
 /*
  * F_() : just information
  * FM() : macro for FN_xxx / xxx_MARK
@@ -2382,18 +2384,33 @@ static const struct pinmux_cfg_reg pinmu
{ },
 };
 
+enum ioctrl_regs {
+   IOCTRL30,
+   IOCTRL31,
+   IOCTRL32,
+   IOCTRL40,
+};
+
+static const struct pinmux_ioctrl_reg pinmux_ioctrl_regs[] = {
+   [IOCTRL30] = { 0xe6060380 },
+   [IOCTRL31] = { 0xe6060384 },
+   [IOCTRL32] = { 0xe6060388 },
+   [IOCTRL40] = { 0xe60603c0 },
+   { /* sentinel */ },
+};
+
 static int r8a77970_pin_to_pocctrl(struct sh_pfc *pfc, unsigned int pin,
   u32 *pocctrl)
 {
int bit = pin & 0x1f;
 
-   *pocctrl = 0xe6060380;
+   *pocctrl = pinmux_ioctrl_regs[IOCTRL30].reg;
if (pin >= RCAR_GP_PIN(0, 0) && pin <= RCAR_GP_PIN(0, 21))
return bit;
if (pin >= RCAR_GP_PIN(2, 0) && pin <= RCAR_GP_PIN(2, 9))
return bit + 22;
 
-   *pocctrl += 4;
+   *pocctrl = pinmux_ioctrl_regs[IOCTRL31].reg;
if (pin >= RCAR_GP_PIN(2, 10) && pin <= RCAR_GP_PIN(2, 16))
return bit - 10;
if (pin >= RCAR_GP_PIN(3, 0) && pin <= RCAR_GP_PIN(3, 16))
@@ -2421,6 +2438,7 @@ const struct sh_pfc_soc_info r8a77970_pi
.nr_functions = ARRAY_SIZE(pinmux_functions),
 
.cfg_regs = pinmux_config_regs,
+   .ioctrl_regs = pinmux_ioctrl_regs,
 
.pinmux_data = pinmux_data,
.pinmux_data_size = ARRAY_SIZE(pinmux_data),

[PATCH v3 3/5] mmc: renesas_sdhi: Fix alignment check of sg buffer

[Wolfram Sang]

From: Masaharu Hayakawa 

Sometimes sg->offset is not used for buffer addresses allocated by
dma_map_sg(), so alignment checks should be done on the allocated buffer
addresses. Delete the alignment check for sg->offset that is done before
dma_map_sg(). Instead, it performs the alignment check for
sg->dma_address after dma_map_sg().

Signed-off-by: Masaharu Hayakawa 
[Niklas: broke this commit in two and tidied small style issue]
Signed-off-by: Niklas Söderlund 
[rebased to mmc/next]
Signed-off-by: Wolfram Sang 
Reviewed-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 6a86619d3f85..b36e174a4b0c 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -157,14 +157,20 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
 {
struct scatterlist *sg = host->sg_ptr;
u32 dtran_mode = DTRAN_MODE_BUS_WID_TH | DTRAN_MODE_ADDR_MODE;
-   int ret;
 
/* This DMAC cannot handle if sg_len is not 1 */
WARN_ON(host->sg_len > 1);
 
+   if (!dma_map_sg(>pdev->dev, sg, host->sg_len,
+   mmc_get_dma_dir(data)))
+   goto force_pio;
+
/* This DMAC cannot handle if buffer is not 8-bytes alignment */
-   if (!IS_ALIGNED(sg->offset, 8))
+   if (!IS_ALIGNED(sg_dma_address(sg), 8)) {
+   dma_unmap_sg(>pdev->dev, sg, host->sg_len,
+mmc_get_dma_dir(data));
goto force_pio;
+   }
 
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
@@ -175,11 +181,6 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
}
 
-   ret = dma_map_sg(>pdev->dev, sg, host->sg_len,
-mmc_get_dma_dir(data));
-   if (ret == 0)
-   goto force_pio;
-
renesas_sdhi_internal_dmac_enable_dma(host, true);
 
/* set dma parameters */
-- 
2.11.0

[PATCH v3 5/5] mmc: renesas_sdhi_internal_dmac: remove superfluous WARN

[Wolfram Sang]

The WARN can never trigger because we limited the max_seg number in
renesas_sdhi_of_data already. Remove it and update the comment.

Signed-off-by: Wolfram Sang 
Reviewed-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 240e8a168aa1..2935dd9315d3 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -91,7 +91,7 @@ static const struct renesas_sdhi_of_data 
of_rcar_gen3_compatible = {
.scc_offset = 0x1000,
.taps   = rcar_gen3_scc_taps,
.taps_num   = ARRAY_SIZE(rcar_gen3_scc_taps),
-   /* Gen3 SDHI DMAC can handle 0x blk count, but seg = 1 */
+   /* DMAC can handle 0x blk count but only 1 segment */
.max_blk_count  = 0x,
.max_segs   = 1,
 };
@@ -158,9 +158,6 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
struct scatterlist *sg = host->sg_ptr;
u32 dtran_mode = DTRAN_MODE_BUS_WID_TH | DTRAN_MODE_ADDR_MODE;
 
-   /* This DMAC cannot handle if sg_len is not 1 */
-   WARN_ON(host->sg_len > 1);
-
if (!dma_map_sg(>pdev->dev, sg, host->sg_len,
mmc_get_dma_dir(data)))
goto force_pio;
-- 
2.11.0

[PATCH v3 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

[Wolfram Sang]

Early revisions of certain SoCs cannot do multiple DMA RX streams in
parallel. To avoid data corruption, only allow one DMA RX channel and
fall back to PIO, if needed.

Signed-off-by: Wolfram Sang 
Reviewed-by: Yoshihiro Shimoda 
Tested-by: Nguyen Viet Dung 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 39 ++-
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 8e0acd197c43..6af946d16d24 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -62,6 +63,17 @@
  *   need a custom accessor.
  */
 
+static unsigned long global_flags;
+/*
+ * Workaround for avoiding to use RX DMAC by multiple channels.
+ * On R-Car H3 ES1.* and M3-W ES1.0, when multiple SDHI channels use
+ * RX DMAC simultaneously, sometimes hundreds of bytes data are not
+ * stored into the system memory even if the DMAC interrupt happened.
+ * So, this driver then uses one RX DMAC channel only.
+ */
+#define SDHI_INTERNAL_DMAC_ONE_RX_ONLY 0
+#define SDHI_INTERNAL_DMAC_RX_IN_USE   1
+
 /* Definitions for sampling clocks */
 static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
{
@@ -126,6 +138,9 @@ renesas_sdhi_internal_dmac_abort_dma(struct tmio_mmc_host 
*host) {
renesas_sdhi_internal_dmac_dm_write(host, DM_CM_RST,
RST_RESERVED_BITS | val);
 
+   if (host->data && host->data->flags & MMC_DATA_READ)
+   clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
+
renesas_sdhi_internal_dmac_enable_dma(host, true);
 }
 
@@ -155,6 +170,9 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
dir = DMA_FROM_DEVICE;
+   if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
+   test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, 
_flags))
+   goto force_pio;
} else {
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
dir = DMA_TO_DEVICE;
@@ -208,6 +226,9 @@ static void 
renesas_sdhi_internal_dmac_complete_tasklet_fn(unsigned long arg)
renesas_sdhi_internal_dmac_enable_dma(host, false);
dma_unmap_sg(>pdev->dev, host->sg_ptr, host->sg_len, dir);
 
+   if (dir == DMA_FROM_DEVICE)
+   clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
+
tmio_mmc_do_data_irq(host);
 out:
spin_unlock_irq(>lock);
@@ -251,18 +272,24 @@ static const struct tmio_mmc_dma_ops 
renesas_sdhi_internal_dmac_dma_ops = {
  * implementation as others may use a different implementation.
  */
 static const struct soc_device_attribute gen3_soc_whitelist[] = {
-{ .soc_id = "r8a7795", .revision = "ES1.*" },
-{ .soc_id = "r8a7795", .revision = "ES2.0" },
-{ .soc_id = "r8a7796", .revision = "ES1.0" },
-{ .soc_id = "r8a77995", .revision = "ES1.0" },
-{ /* sentinel */ }
+   { .soc_id = "r8a7795", .revision = "ES1.*",
+ .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
+   { .soc_id = "r8a7795", .revision = "ES2.0" },
+   { .soc_id = "r8a7796", .revision = "ES1.0",
+ .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
+   { .soc_id = "r8a77995", .revision = "ES1.0" },
+   { /* sentinel */ }
 };
 
 static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
 {
-   if (!soc_device_match(gen3_soc_whitelist))
+   const struct soc_device_attribute *soc = 
soc_device_match(gen3_soc_whitelist);
+
+   if (!soc)
return -ENODEV;
 
+   global_flags |= (unsigned long)soc->data;
+
return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
 }
 
-- 
2.11.0

[PATCH v3 2/5] mmc: renesas_sdhi: use helpers to access struct scatterlist members

[Wolfram Sang]

From: Niklas Söderlund 

Instead of directly accessing the members of struct scatterlist use the
helpers mmc_get_dma_dir() and sg_dma_address() in
renesas_sdhi_internal_dmac_start_dma(). Based on previous work by
Masaharu Hayakawa.

Signed-off-by: Niklas Söderlund 
[rebased to mmc/next]
Signed-off-by: Wolfram Sang 
Reviewed-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 6af946d16d24..6a86619d3f85 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -157,7 +157,6 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
 {
struct scatterlist *sg = host->sg_ptr;
u32 dtran_mode = DTRAN_MODE_BUS_WID_TH | DTRAN_MODE_ADDR_MODE;
-   enum dma_data_direction dir;
int ret;
 
/* This DMAC cannot handle if sg_len is not 1 */
@@ -169,16 +168,15 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
 
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
-   dir = DMA_FROM_DEVICE;
if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, 
_flags))
goto force_pio;
} else {
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
-   dir = DMA_TO_DEVICE;
}
 
-   ret = dma_map_sg(>pdev->dev, sg, host->sg_len, dir);
+   ret = dma_map_sg(>pdev->dev, sg, host->sg_len,
+mmc_get_dma_dir(data));
if (ret == 0)
goto force_pio;
 
@@ -188,7 +186,7 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
renesas_sdhi_internal_dmac_dm_write(host, DM_CM_DTRAN_MODE,
dtran_mode);
renesas_sdhi_internal_dmac_dm_write(host, DM_DTRAN_ADDR,
-   sg->dma_address);
+   sg_dma_address(sg));
 
return;
 
-- 
2.11.0

[PATCH v3 4/5] mmc: renesas_sdhi_internal_dmac: use more generic whitelisting

[Wolfram Sang]

Whitelisting every ES version does not scale. So, we whitelist whole
SoCs independent of ES version. If we need specific handling for an ES
version, we put it to the front, so it will be matched first.

Signed-off-by: Wolfram Sang 
Reviewed-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
Tested-by: Nguyen Viet Dung 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index b36e174a4b0c..240e8a168aa1 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -271,12 +271,15 @@ static const struct tmio_mmc_dma_ops 
renesas_sdhi_internal_dmac_dma_ops = {
  * implementation as others may use a different implementation.
  */
 static const struct soc_device_attribute gen3_soc_whitelist[] = {
+   /* specific ones */
{ .soc_id = "r8a7795", .revision = "ES1.*",
  .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
-   { .soc_id = "r8a7795", .revision = "ES2.0" },
{ .soc_id = "r8a7796", .revision = "ES1.0",
  .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
-   { .soc_id = "r8a77995", .revision = "ES1.0" },
+   /* generic ones */
+   { .soc_id = "r8a7795" },
+   { .soc_id = "r8a7796" },
+   { .soc_id = "r8a77995" },
{ /* sentinel */ }
 };
 
-- 
2.11.0

[PATCH v3 0/5] mmc: renesas_sdhi_internal_dmac: DMA handling fixes

[Wolfram Sang]

I have collected the patches floating around for renesas_sdhi_internal_dmac and
grouped them to avoid dependency issues.

Regarding stable: I think patch 1 is clearly for stable. Patch 3 maybe, but it
needs patch 2 which is not. Not sure if it is worth the hazzle. Patches 4 & 5
are not for stable.

Changes since v2:
* fixed checkpatch issues (Thanks Sergei!)
* rebased to mmc/next

Changes since v1:
* patch 1: drop superfluous NULL check on soc->date
   (Thanks Geert!)
* patches 2,3,5: added Simon's tag

Kind regards,

   Wolfram


Masaharu Hayakawa (1):
  mmc: renesas_sdhi: Fix alignment check of sg buffer

Niklas Söderlund (1):
  mmc: renesas_sdhi: use helpers to access struct scatterlist members

Wolfram Sang (3):
  mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs
  mmc: renesas_sdhi_internal_dmac: use more generic whitelisting
  mmc: renesas_sdhi_internal_dmac: remove superfluous WARN

 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 64 +++
 1 file changed, 45 insertions(+), 19 deletions(-)

-- 
2.11.0

[PATCH] soc: renesas: r8a77995-sysc: Cleanups

[Geert Uytterhoeven]

Minor cleanup of artefacts caused by deriving from r8a7795-sysc.c:
  - Remove unused inclusion of ,
  - Make r8a77995_areas[] const.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/soc/renesas/r8a77995-sysc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/soc/renesas/r8a77995-sysc.c 
b/drivers/soc/renesas/r8a77995-sysc.c
index f718429cab02393d..1b2ef415bbe1cbf7 100644
--- a/drivers/soc/renesas/r8a77995-sysc.c
+++ b/drivers/soc/renesas/r8a77995-sysc.c
@@ -10,13 +10,12 @@
 
 #include 
 #include 
-#include 
 
 #include 
 
 #include "rcar-sysc.h"
 
-static struct rcar_sysc_area r8a77995_areas[] __initdata = {
+static const struct rcar_sysc_area r8a77995_areas[] __initconst = {
{ "always-on", 0, 0, R8A77995_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
{ "ca53-scu",  0x140, 0, R8A77995_PD_CA53_SCU,  R8A77995_PD_ALWAYS_ON,
  PD_SCU },
-- 
2.7.4

[PATCH v9 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..37f0c04
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,60 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two LVDS input streams and up to two digital CMOS/TTL outputs.
+
+Single or dual operation mode, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
+  PPL and digital circuitry
+
+Optional properties:
+- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
+- oe-gpios: Output enable GPIO signal, pin name "OE". Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- port@0: First LVDS input port
+- port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- port@1: Second LVDS input port
+- port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   powerdown-gpios = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
2.7.4

[PATCH v9 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Jacopo Mondi]

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/Kconfig|   6 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c | 206 ++
 3 files changed, 213 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3aa65bd..42c9c2d 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -93,6 +93,12 @@ config DRM_SII9234
  It is an I2C driver, that detects connection of MHL bridge
  and starts encapsulation of HDMI signal.
 
+config DRM_THINE_THC63LVD1024
+   tristate "Thine THC63LVD1024 LVDS decoder bridge"
+   depends on OF
+   ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..c8b9edd
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+enum thc63_ports {
+   THC63_LVDS_IN0,
+   THC63_LVDS_IN1,
+   THC63_RGB_OUT0,
+   THC63_RGB_OUT1,
+};
+
+struct thc63_dev {
+   struct device *dev;
+
+   struct regulator *vcc;
+
+   struct gpio_desc *pdwn;
+   struct gpio_desc *oe;
+
+   struct drm_bridge bridge;
+   struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+
+   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   int ret;
+
+   ret = regulator_enable(thc63->vcc);
+   if (ret) {
+   dev_err(thc63->dev,
+   "Failed to enable regulator \"vcc\": %d\n", ret);
+   return;
+   }
+
+   gpiod_set_value(thc63->pdwn, 0);
+   gpiod_set_value(thc63->oe, 1);
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   int ret;
+
+   gpiod_set_value(thc63->oe, 0);
+   gpiod_set_value(thc63->pdwn, 1);
+
+   ret = regulator_disable(thc63->vcc);
+   if (ret)
+   dev_err(thc63->dev,
+   "Failed to disable regulator \"vcc\": %d\n", ret);
+}
+
+static const struct drm_bridge_funcs thc63_bridge_func = {
+   .attach = thc63_attach,
+   .enable = thc63_enable,
+   .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+   struct device_node *thc63_out;
+   struct device_node *remote;
+
+   thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_RGB_OUT0, -1);
+   if (!thc63_out) {
+   dev_err(thc63->dev, "Missing endpoint in port@%u\n",
+   THC63_RGB_OUT0);
+   return -ENODEV;
+   }
+
+   remote = of_graph_get_remote_port_parent(thc63_out);
+   of_node_put(thc63_out);
+   if (!remote) {
+   dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
+   THC63_RGB_OUT0);
+   return -ENODEV;
+   }
+
+   if (!of_device_is_available(remote)) {
+   dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
+   THC63_RGB_OUT0);
+   of_node_put(remote);
+   return -ENODEV;
+   }
+
+   thc63->next = of_drm_find_bridge(remote);
+   of_node_put(remote);
+   if (!thc63->next)
+   

[PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

[Jacopo Mondi]

As I have another series which is based on this one + Eagle board display
support, I'm re-sending this one to fix the small issue I pointed out in my
reply to v8.

Simon: no changes to Eagle DTS series, so the last one sent is still the good
one.

DRM: I have collected several reviewed-by tags both on driver and bindings.
Can I send out incremental patches on this series and consider this one to
be ready to be collected?

Thanks
   j

v8 -> v9:
- Put 'remote' OF node after usage not just in error path during device
  tree parsing routine
- Add Rob's Reviewed-by tag to the device tree bindings documentation

v7 -> b8:
- Make 'vcc' supply mandatory
- Use 'oe' property name to describe "OE" pin
- Minor fixes as suggested by Laurent on bindings and driver

v6 -> v7:
- Use semi-standard names for powerdown and output enable GPIOs as suggested
  by Rob and Vladimir
- Use 'regulator_get()' not the optional version, and list only 'vcc' as
  requested supply
- Addressed Laurent's review comments and removed Eagle display enablement patch
  to be sent separately

v5 -> v6:
- Drop check for CONFIG_OF as it is a Kconfig dependency
- Add Niklas Reviewed-by tags
- List [3/3] depenencies below commit message to ease integration

v4 -> v5:
- Fix punctuation in bindings documentation
- Add small statement to bindings document to clarify the chip has no
  control bus
- Print regulator name in enable/disable routines error path
- Add Andrzej Reviewed-by tag

v3 -> v4:
- Rename permutations of "pdwn" to just "pdwn" everywhere in the series
- Improve power enable/disable routines as suggested by Andrzej and Sergei
- Change "pdwn" gpio initialization to use the logical output level
- Change Kconfig description

v2 -> v3:
- Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific
-- Rework bindings to describe multiple input/output ports
-- Rename driver and remove "lvds-decoder" references
-- Rework Eagle DTS to use new bindings

v1 -> v2:
- Drop support for THC63LVD1024

Jacopo Mondi (2):
  dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
  drm: bridge: Add thc63lvd1024 LVDS decoder driver

 .../bindings/display/bridge/thine,thc63lvd1024.txt |  60 ++
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c  | 205 +
 4 files changed, 272 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

--
2.7.4

Re: [PATCH/RFC 0/2] regulator: bd9571mwv: Add support for toggle power switches

[Mark Brown]

On Wed, Apr 18, 2018 at 03:29:36PM +0200, Geert Uytterhoeven wrote:

> Any comments/suggestions?

> In case you lost the patches from the thread:
> https://www.spinics.net/lists/linux-renesas-soc/msg24955.html

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, though there are some other maintainers who like them - if in
doubt look at how patches for the subsystem are normally handled.


signature.asc
Description: PGP signature

Re: [PATCH 0/3] Add R8A77980/Condor PCIe support

[Simon Horman]

On Fri, Apr 06, 2018 at 11:11:38PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> Here's the set of 3 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180330-v4.16-rc7' tag. We're adding the R8A77980 PCIe related
> device nodes and then enable PCIe on the Condor board. These patches depend on
> the R8A77980 PCIe PHY and PCIEC driver support in order to work properly...

Thanks, I have marked these as deferred.

Please ping me once the dependencies have been accepted.

Re: [PATCH] arm64: dts: r8a77965: Add R-Car Gen3 thermal support

[Geert Uytterhoeven]

Hi Niklas,

On Tue, Apr 17, 2018 at 11:03 PM, Niklas Söderlund
 wrote:
> From: Niklas Söderlund 
>
> Based on previous work by Ryo Kataoka .
>
> Signed-off-by: Niklas Söderlund 
> ---
>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 59 +++
>  1 file changed, 59 insertions(+)
>
> Hi Simon,
>
> This patch depends on '[PATCH 0/2] thermal: rcar_gen3_thermal: add
> r8a77965 support'. So it's probably best you hold back applying it to

Does it? Just on the (trivial) addition of a new compatible value, right?

> such time it's dependency are accepted. I post it in any case to get
> review comments and keep it ready for future integration in
> renesas-drivers branches.

So I don't think the above is a blocker, but...

> It also uses numerical values for the power-doamains propery as the
> defines where not yet available for me. This shall of course be updated
> before they are accepted.

They're in v4.17-rc1, so you can update the patch now?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 0/2] arm64: dts: renesas: r8a779{5,6}: decrease temperature

[Simon Horman]

On Tue, Apr 17, 2018 at 10:54:26PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund 
> 
> Hi Simon,
> 
> This series decrease the hysteresis from 2C to 1C for the two boards we 
> have described upstream. They have no dependencies and are ready to be 
> accepted if the review is in favor of them.

Thanks Niklas,

applied.

Re: [PATCH] arm64: dts: r8a77965: Add R-Car Gen3 thermal support

[Simon Horman]

On Tue, Apr 17, 2018 at 11:03:42PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund 
> 
> Based on previous work by Ryo Kataoka .
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 59 +++
>  1 file changed, 59 insertions(+)
> 
> Hi Simon,
> 
> This patch depends on '[PATCH 0/2] thermal: rcar_gen3_thermal: add 
> r8a77965 support'. So it's probably best you hold back applying it to 
> such time it's dependency are accepted. I post it in any case to get 
> review comments and keep it ready for future integration in 
> renesas-drivers branches.
> 
> It also uses numerical values for the power-doamains propery as the 
> defines where not yet available for me. This shall of course be updated 
> before they are accepted.

Thanks,  I will mark this as deferred. Please repost or ping me once
the dependency is accepted.

Re: [PATCH v6 11/11] ARM: shmobile: Convert file to use cntvoff

[Simon Horman]

On Wed, Apr 18, 2018 at 12:03:27PM +0200, Mylène Josserand wrote:
> Hello,
> 
> On Wed, 18 Apr 2018 11:36:27 +0200
> Geert Uytterhoeven  wrote:
> 
> > Hi Mylène,
> > 
> > On Mon, Apr 16, 2018 at 11:50 PM, Mylène Josserand
> >  wrote:
> > > Now that a common function is available for CNTVOFF's
> > > initialization, let's convert shmobile-apmu code to use
> > > this function.  
> > 
> > Thanks for your patch, works fine on Renesas ALT with R-Car E2,
> > which suffers from lack of CNTVOFF initialization.
> 
> Great to know that it works on this board.
> 
> > 
> > > Signed-off-by: Mylène Josserand   
> > 
> > Reviewed-by: Geert Uytterhoeven 
> > Tested-by: Geert Uytterhoeven 
> > 
> > Gr{oetje,eeting}s,
> > 
> > Geert
> > 
> 
> Thank you again for testing it :)

What is the plan for merging this patch/series?

I'd be happy to take this patch through the renesas tree once any
dependencies are in place.

Re: [PATCH 0/3] arm64: dts: renesas: Rename EtherAVB "mdc" pin group to "mdio"

[Geert Uytterhoeven]

Hi Simon,

On Fri, Mar 16, 2018 at 9:39 AM, Simon Horman  wrote:
> On Tue, Mar 13, 2018 at 08:23:05PM +0100, Geert Uytterhoeven wrote:
>> On Tue, Mar 13, 2018 at 7:49 PM, Simon Horman  wrote:
>> > On Mon, Mar 12, 2018 at 04:11:57PM +0100, Geert Uytterhoeven wrote:
>> >> On Renesas R-Car Gen2 SoCs, the pin group for the MDIO bus is named
>> >> "mdio".
>> >>
>> >> When initial support was added for R-Car H3, the MDIO pin was forgotten,
>> >> and the MDC pin got its own group named "mdc".  During the addition of
>> >> support for R-Car M3-W, this mistake was noticed.  But as R-Car H3 and
>> >> M3-W are pin compatible, and can be mounted on the same boards, the
>> >> decision was made to just add the MDIO pin to the existing "mdc" group.
>> >> Later this was extended to R-Car H3 ES2.0, and M3-N, because of pin
>> >> compatibility, and to R-Car D3, in the name of consistency among R-Car
>> >> Gen3 SoCs.
>> >>
>> >> However, this decision keeps on being questioned when adding new SoC
>> >> support.  Hence bite the bullet and admit our mistake, and rename the
>> >> pin group from "mdc" to "mdio", like on R-Car Gen2 SoCs.
>> >>
>> >> This series is the DTS part, and depends on the series '[PATCH 0/6]
>> >> pinctrl: sh-pfc: rcar-gen3: Rename EtherAVB "mdc" pin group to "mdio"'.
>> >
>> > could you comment on the forwards/backwards compatibility considerations
>> > of this series?
>>
>> Old and new kernels work with old DT (tested on Salvator-X(S).
>> New DT requires a new kernel, hence the dependency of the DTS part on the
>> driver part.
>
> Thanks, that is fine by me.
>
> I have marked these patches as deferred. Please repost or ping me
> once the dependency is available in an RC release.

Now in v4.17-rc1.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v5 00/26] Fix watchdog on Renesas R-Car Gen2 and RZ/G1

[Geert Uytterhoeven]

Hi Simon,

On Tue, Mar 13, 2018 at 9:05 PM, Simon Horman  wrote:
> I understand that the watchdog driver has been accepted and that as things
> currently stand if it is enabled in the build it will be enabled in DT and
> a crash will result. From my POV that is a regression so I have decided
> to adopt the alternate plan proposed by Geert above: in short drop DT
> patches (to avoid enabling broken driver) and enqueue mach-shmobile
> patches (which don't make things any worse.
>
> Patch-by-patch things are as follows.
>
> Dropped from "[PATCH v5 00/26] Fix watchdog on Renesas R-Car Gen2 and RZ/G1":
>
> 979d28f29742 ARM: dts: r8a7743: Adjust SMP routine size
> 0b205f679f5d ARM: dts: r8a7745: Adjust SMP routine size
> 2ad21a1d78b3 ARM: dts: r8a7790: Adjust SMP routine size
> 82c978459c77 ARM: dts: r8a7791: Adjust SMP routine size
> d303698e6ff3 ARM: dts: r8a7792: Adjust SMP routine size
> d8b8b9a1e295 ARM: dts: r8a7793: Adjust SMP routine size
> 70b3ab369773 ARM: dts: r8a7794: Adjust SMP routine size
>
> ebf26cf1b1de ARM: dts: r8a7743: Add watchdog support to SoC dtsi
> 5a4566ab3777 ARM: dts: r8a7745: Add watchdog support to SoC dtsi
> acd58e2bb1e5 ARM: dts: r8a7790: Add watchdog support to SoC dtsi
> e3f89168e72f ARM: dts: r8a7791: Add watchdog support to SoC dtsi
> e76a6a69a1fc ARM: dts: r8a7794: Add watchdog support to SoC dtsi
> 242cc1ab7f7c ARM: dts: iwg20m: Add watchdog support to SoM dtsi
> 748ed07f6c7c ARM: dts: iwg22m: Add watchdog support to SoM dtsi
>
>
> Dropped from "[PATCH/RFC 00/11] ARM: dts: rcar-gen2: Enable watchdog support":
>
> c257202482e2 ARM: dts: r8a7792: Add RWDT node
> 01ec04dec8eb ARM: dts: r8a7793: Add RWDT node
> 8e6ebe4f2f94 ARM: dts: lager: Enable watchdog support
> f223ad0198f6 ARM: dts: koelsch: Enable watchdog support
> 1d14d2bb700d ARM: dts: porter: Enable watchdog support
> bf71652fc955 ARM: dts: blanche: Enable watchdog support
> 13a0b10aeea4 ARM: dts: wheat: Enable watchdog support
> 4e247bf110b8 ARM: dts: gose: Enable watchdog support
> 2dcbd24bbf5e ARM: dts: alt: Enable watchdog support
> 7f6844c900b4 ARM: dts: silk: Enable watchdog support
>
> And applied:
>
> [v5] ARM: shmobile: rcar-gen2: Add watchdog support
> [v5] ARM: shmobile: Add watchdog support
>
> In the case of the last patch above I removed the #ifdef from the header file.

I guess the time is ripe to apply the DTS patches again, in the following order:
  1. SMP routine size adjustments,
  2. Watchdog support additions to dtsi,
  3. Watchdog enablement for dts?

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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/RFC 0/2] regulator: bd9571mwv: Add support for toggle power switches

[Geert Uytterhoeven]

Hi all,

On Wed, Mar 14, 2018 at 12:26 PM, Geert Uytterhoeven
 wrote:
> The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
> development boards supports DDR Backup Power, which means that the DDR
> power rails can be kept powered while the main SoC is powered down.
>
> This patch series extends the support for DDR backup mode[1] to systems
> with toggle instead of momentary power switches.
>
> With a toggle power switch (or level signal), the following steps must
> be followed exactly:
>1. Configure PMIC for backup mode, which changes the role of the
>   power switch to a wake-up switch,
>2. Switch accessory power switch off, to prepare for system suspend,
>   which is a manual step not controlled by software,
>3. Suspend system,
>4. Switch accessory power switch on, to resume.
>
> Unlike on systems with a momentary toggle switch, an additional step 2
> must be performed in between step 1 and step 3.  Hence step 1 can no
> longer be handled in the PMIC's suspend callback.
>
> This patch series proposes a new callback for wake-up change
> notification, which allows performing step 1 when the user writes
> "enabled" to the PMIC's "wakeup" virtual file in sysfs, e.g.
>
> echo enabled > 
> /sys/devices/platform/soc/e60b.i2c/i2c-7/7-0030/bd9571mwv-regulator.2.auto/power/wakeup
>
> Conversely, writing "disabled" reverts the role of the accessory switch
> to a power switch.
> Note that unlike with momentary switches, backup mode is not enabled by
> default, as enabling it prevents the board from being powered off using
> the power switch, which may confuse the user.
>
> This has been tested on M3ULCB (thanks Jacopo!), and on Salvator-X(S).
>
> For testing, driver and DTS patches are available in the
> topic/bd9571-ddr-backup-mode-driver-v2 and
> topic/bd9571-ddr-backup-mode-dt-v2 branches of my renesas-drivers git
> repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>
> Thanks for your comments!
>
> [1] https://lkml.org/lkml/2018/3/14/302
>
> Geert Uytterhoeven (2):
>   PM / wakeup: Add callback for wake-up change notification
>   regulator: bd9571mwv: Add support for toggle power switches
>
>  drivers/base/power/wakeup.c |  4 
>  drivers/regulator/bd9571mwv-regulator.c | 24 
>  include/linux/pm.h  |  1 +
>  3 files changed, 29 insertions(+)

Any comments/suggestions?

In case you lost the patches from the thread:
https://www.spinics.net/lists/linux-renesas-soc/msg24955.html

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v3 3/4] mfd: bd9571mwv: Allow DDR Backup Power register access

[Geert Uytterhoeven]

Enable read/write access to the BD9571MWV_BKUP_MODE_CNT register, which
is amongst others used to configure DDR Backup Power.

Signed-off-by: Geert Uytterhoeven 
---
Acked-for-MFD-by: Lee Jones 

v3:
  - No changes,

v2:
  - Expand "a.o.",
  - Add Acked-for-MFD-by.
---
 drivers/mfd/bd9571mwv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 64e088dfe7b05b5b..503979c81dae11bb 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -29,6 +29,7 @@ static const struct mfd_cell bd9571mwv_cells[] = {
 
 static const struct regmap_range bd9571mwv_readable_yes_ranges[] = {
regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION),
+   regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
regmap_reg_range(BD9571MWV_AVS_SET_MONI, BD9571MWV_AVS_DVFS_VID(3)),
regmap_reg_range(BD9571MWV_VD18_VID, BD9571MWV_VD33_VID),
regmap_reg_range(BD9571MWV_DVFS_VINIT, BD9571MWV_DVFS_VINIT),
@@ -44,6 +45,7 @@ static const struct regmap_access_table 
bd9571mwv_readable_table = {
 };
 
 static const struct regmap_range bd9571mwv_writable_yes_ranges[] = {
+   regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
regmap_reg_range(BD9571MWV_AVS_VD09_VID(0), BD9571MWV_AVS_VD09_VID(3)),
regmap_reg_range(BD9571MWV_DVFS_SETVID, BD9571MWV_DVFS_SETVID),
regmap_reg_range(BD9571MWV_GPIO_DIR, BD9571MWV_GPIO_OUT),
-- 
2.7.4

[PATCH v3 2/4] mfd: bd9571mwv: Add DDR Backup Power register bit definitions

[Geert Uytterhoeven]

Add definitions for the KEEPON_* bits in the "BKUP Mode Cnt" register,
which control the DDR rails to be kept powered when backup mode is
enabled.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Lee Jones 
---
v3:
  - No changes,

v2:
  - Add Acked-by.
---
 include/linux/mfd/bd9571mwv.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mfd/bd9571mwv.h b/include/linux/mfd/bd9571mwv.h
index f0708ba4cbbae2dc..eb05569f752bb089 100644
--- a/include/linux/mfd/bd9571mwv.h
+++ b/include/linux/mfd/bd9571mwv.h
@@ -33,6 +33,11 @@
 #define BD9571MWV_I2C_MD2_E1_BIT_2 0x12
 
 #define BD9571MWV_BKUP_MODE_CNT0x20
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_MASKGENMASK(3, 0)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR0BIT(0)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR1BIT(1)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR0C   BIT(2)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR1C   BIT(3)
 #define BD9571MWV_BKUP_MODE_STATUS 0x21
 #define BD9571MWV_BKUP_RECOVERY_CNT0x22
 #define BD9571MWV_BKUP_CTRL_TIM_CNT0x23
-- 
2.7.4

[PATCH v3 4/4] regulator: bd9571mwv: Add support for backup mode

[Geert Uytterhoeven]

The BD9571MWV PMIC supports backup mode, which keeps one or more DDR
rails powered while the main SoC is powered down.

Which DDR rails are to be kept powered is board-specific, and controlled
using the optional "rohm,ddr-backup-power" DT property.  In the absence
of this property, backup mode is not available.

Backup mode can be enabled or disabled by the user using the standard
"wakeup" virtual file in sysfs, e.g. to enable:

echo enabled > 
/sys/devices/platform/soc/e60b.i2c/i2c-7/7-0030/bd9571mwv-regulator.2.auto/power/wakeup

When the PMIC is configured for backup mode, the role of the accessory
power switch changes from a power switch to a wake-up switch.
Two types of switches (or signals) can be used:
  A. With a momentary power switch (or pulse signal), the PMIC is
 configured for backup mode in the PMIC driver's suspend callback,
 during system suspend.
 Backup mode is enabled by default, as there is no further impact
 during normal system operation.

  B. With a toggle power switch (or level signal), the following steps
 must be followed exactly:
   1. Configure PMIC for backup mode,
   2. Switch accessory power switch off, to prepare for system
  suspend, which is a manual step not controlled by software,
   3. Suspend system.
 This mode is not yet supported by the driver.

As the switch type is board-specific, and cannot be determined
automatically, it is obtained from the presence of one of the
"rohm,rstbmode-*" properties in DT.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - No changes,

v2:
  - Use normal "wakeup" sysfs virtual file instead of adding our own
"backup_mode" file,
  - Differentiate between momentary and toggle power switches:
  - Support for momentary switches is enabled automatically,
  - Toggle switches are not yet supported (but still work when
backup mode is enabled using i2set from userspace).
---
 drivers/regulator/bd9571mwv-regulator.c | 127 +++-
 1 file changed, 126 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/bd9571mwv-regulator.c 
b/drivers/regulator/bd9571mwv-regulator.c
index c67a83d53c4cb76b..be574eb444ebda97 100644
--- a/drivers/regulator/bd9571mwv-regulator.c
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -24,6 +24,18 @@
 
 #include 
 
+struct bd9571mwv_reg {
+   struct bd9571mwv *bd;
+
+   /* DDR Backup Power */
+   u8 bkup_mode_cnt_keepon;/* from "rohm,ddr-backup-power" */
+   u8 bkup_mode_cnt_saved;
+
+   /* Power switch type */
+   bool rstbmode_level;
+   bool rstbmode_pulse;
+};
+
 enum bd9571mwv_regulators { VD09, VD18, VD25, VD33, DVFS };
 
 #define BD9571MWV_REG(_name, _of, _id, _ops, _vr, _vm, _nv, _min, _step, 
_lmin)\
@@ -131,14 +143,99 @@ static struct regulator_desc regulators[] = {
  0x80, 60, 1, 0x3c),
 };
 
+#ifdef CONFIG_PM_SLEEP
+static int bd9571mwv_bkup_mode_read(struct bd9571mwv *bd, unsigned int *mode)
+{
+   int ret;
+
+   ret = regmap_read(bd->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
+   if (ret) {
+   dev_err(bd->dev, "failed to read backup mode (%d)\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int bd9571mwv_bkup_mode_write(struct bd9571mwv *bd, unsigned int mode)
+{
+   int ret;
+
+   ret = regmap_write(bd->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
+   if (ret) {
+   dev_err(bd->dev, "failed to configure backup mode 0x%x (%d)\n",
+   mode, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int bd9571mwv_suspend(struct device *dev)
+{
+   struct bd9571mwv_reg *bdreg = dev_get_drvdata(dev);
+   unsigned int mode;
+   int ret;
+
+   if (!device_may_wakeup(dev))
+   return 0;
+
+   /* Save DDR Backup Mode */
+   ret = bd9571mwv_bkup_mode_read(bdreg->bd, );
+   if (ret)
+   return ret;
+
+   bdreg->bkup_mode_cnt_saved = mode;
+
+   if (!bdreg->rstbmode_pulse)
+   return 0;
+
+   /* Enable DDR Backup Mode */
+   mode &= ~BD9571MWV_BKUP_MODE_CNT_KEEPON_MASK;
+   mode |= bdreg->bkup_mode_cnt_keepon;
+
+   if (mode != bdreg->bkup_mode_cnt_saved)
+   return bd9571mwv_bkup_mode_write(bdreg->bd, mode);
+
+   return 0;
+}
+
+static int bd9571mwv_resume(struct device *dev)
+{
+   struct bd9571mwv_reg *bdreg = dev_get_drvdata(dev);
+
+   if (!device_may_wakeup(dev))
+   return 0;
+
+   /* Restore DDR Backup Mode */
+   return bd9571mwv_bkup_mode_write(bdreg->bd, bdreg->bkup_mode_cnt_saved);
+}
+
+static const struct dev_pm_ops bd9571mwv_pm  = {
+   SET_SYSTEM_SLEEP_PM_OPS(bd9571mwv_suspend, bd9571mwv_resume)
+};
+
+#define DEV_PM_OPS _pm
+#else
+#define DEV_PM_OPS NULL
+#endif /* CONFIG_PM_SLEEP */
+
 static int bd9571mwv_regulator_probe(struct platform_device *pdev)
 {

[PATCH v3 1/4] dt-bindings: mfd: bd9571mwv: Document DDR Backup Mode properties

[Geert Uytterhoeven]

Document the new optional properties related to DDR Backup Mode and
toggle/momentary power switches.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Rob Herring 
---
Acked-for-MFD-by: Lee Jones 

v3:
  - Add Reviewed-by, Acked-for-MFD-by (for Lee's own reference),
  - Use a hex value for the bit mask,

v2:
  - Improve property description,
  - Add properties for power switch type.
---
 Documentation/devicetree/bindings/mfd/bd9571mwv.txt | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt 
b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
index 9ab216a851d5619b..25d1f697eb25c67d 100644
--- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
+++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
@@ -25,6 +25,25 @@ Required properties:
Each child node is defined using the standard
binding for regulators.
 
+Optional properties:
+  - rohm,ddr-backup-power : Value to use for DDR-Backup Power (default 0).
+   This is a bitmask that specifies which DDR power
+   rails need to be kept powered when backup mode is
+   entered, for system suspend:
+ - bit 0: DDR0
+ - bit 1: DDR1
+ - bit 2: DDR0C
+ - bit 3: DDR1C
+   These bits match the KEEPON_DDR* bits in the
+   documentation for the "BKUP Mode Cnt" register.
+  - rohm,rstbmode-level: The RSTB signal is configured for level mode, to
+accommodate a toggle power switch (the RSTBMODE pin is
+strapped low).
+  - rohm,rstbmode-pulse: The RSTB signal is configured for pulse mode, to
+accommodate a momentary power switch (the RSTBMODE pin
+is strapped high).
+The two properties above are mutually exclusive.
+
 Example:
 
pmic: pmic@30 {
@@ -36,6 +55,8 @@ Example:
#interrupt-cells = <2>;
gpio-controller;
#gpio-cells = <2>;
+   rohm,ddr-backup-power = <0xf>;
+   rohm,rstbmode-pulse;
 
regulators {
dvfs: dvfs {
-- 
2.7.4

[PATCH v3 0/4] regulator: bd9571mwv: Add support for DDR backup mode

[Geert Uytterhoeven]

Hi all,

The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
development boards supports DDR Backup Power, which means that the DDR
power rails can be kept powered while the main SoC is powered down.

Currently performing a system suspend/resume cycle involves several
manual steps:
  1. Configure the PMIC for Backup Mode, using
 "i2cset -f -y 7 0x30 0x20 0x0f", which changes the role of the
 power switch to a wake-up switch,
  2. Switch off SW23 (the ACC toggle switch) to prepare for suspend
 (only on Salvator-X(S)),
  3. Suspend to RAM, using "echo mem > /sys/power/state",
  4. Switch on SW23 (on Salvator-X(S)) or push momentary switch SW8 (on
 ULCB) to resume.
Note the need for step 2 on systems equipped with a toggle instead of
momentary power switch.

Especially the first and second steps are cumbersome, as they rely on
  1. Intimate knowledge about the PMIC and actual board design,
  2. Direct i2c access,
  3. Having the i2cset utility available,
  4. A manual toggle switch operation (on Salvator-X(S)).
In addition, all of this has to be redone after system resume.

This patch series integrates Backup Mode configuration into the PMIC
driver, using the "wakeup" sysfs virtual file.  I.e. it can be enabled
or disabled by writing "enabled" or "disabled" to e.g.


/sys/devices/platform/soc/e60b.i2c/i2c-7/7-0030/bd9571mwv-regulator.2.auto/power/wakeup

Which DDR rails are to be kept powered is board-specific, and controlled
using the optional "rohm,ddr-backup-power" property in the board DTS
file.

As the power switch type is board-specific, and cannot be determined
automatically, it is obtained from the presence of one of the
"rohm,rstbmode-{pulse,level}" properties in DT.

For now only momentary power switches are supported, and wake-up is
enabled by default, as it doesn't have any run-time side-effects.
Support for toggle switches is added in a follow-up series ("[PATCH/RFC
0/2] regulator: bd9571mwv: Add support for toggle power switches",
https://lkml.org/lkml/2018/3/14/324).

Changes compared to v2:
  - Add Reviewed-by, Acked-for-MFD-by (for Lee's own reference),
  - Use a hex value for the bit mask.

Changes compared to v1:
  - Improve DT property description,
  - Add DT properties for power switch type,
  - Add Acked-by,
  - Use normal "wakeup" sysfs virtual file instead of adding our own
"backup_mode" file,
  - Differentiate between momentary and toggle power switches:
  - Support for momentary switches is enabled automatically,
  - Toggle switches are not yet supported (but still work when
backup mode is enabled using i2set from userspace).
  - Split off DTS part into its own series.

This has been tested on M3ULCB (thanks Jacopo!), and on Salvator-X(S)
(still using i2set from userspace).

For testing, driver and DTS patches are available in the
topic/bd9571-ddr-backup-mode-driver-v3 and
topic/bd9571-ddr-backup-mode-dt-v3 branches of my renesas-drivers git
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.

Thanks for applying!

Geert Uytterhoeven (4):
  dt-bindings: mfd: bd9571mwv: Document DDR Backup Mode properties
  mfd: bd9571mwv: Add DDR Backup Power register bit definitions
  mfd: bd9571mwv: Allow DDR Backup Power register access
  regulator: bd9571mwv: Add support for backup mode

 .../devicetree/bindings/mfd/bd9571mwv.txt  |  21 
 drivers/mfd/bd9571mwv.c|   2 +
 drivers/regulator/bd9571mwv-regulator.c| 127 -
 include/linux/mfd/bd9571mwv.h  |   5 +
 4 files changed, 154 insertions(+), 1 deletion(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] sh: mm: Fix unprotected access to struct device

[jacopo mondi]

Hi Christoph,

On Wed, Apr 18, 2018 at 03:47:03AM -0700, Christoph Hellwig wrote:
> On Tue, Apr 17, 2018 at 03:35:23PM +0200, Jacopo Mondi wrote:
> > With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
> > operations observe dev->dma_pfn_offset") the generic DMA allocation
> > function on which the SH 'dma_alloc_coherent()' function relies on,
> > access the 'dma_pfn_offset' field of struct device.
> >
> > Unfortunately the 'dma_generic_alloc_coherent()' function is called from
> > several places with a NULL struct device argument, halting the CPU
> > during the boot process.
> >
> > This patch fixes the issue protecting access to dev->dma_pfn_offset,
> > with a trivial check for validity. It also passes a valid 'struct device'
> > in the 'platform_resource_setup_memory' function which is the main user
> > of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
> > (and existing) bogus users of this function they're should provide a valid
> > 'struct device' whenever possible.
>
> Please fix those callers to not pass a NULL pointer instead.

As long as it goes for arch/sh, the only user of dma_alloc_coherent()
is platform_resource_setup_memory(), and it has been fixed by this
patch.

Unfortunately, as Thomas pointed out, there are drivers which calls
into this with the wrong 'struct device' as the sh_eth one he had fixed.

I would then say that as long as it goes for the NULL case, we should be
fine now.

Thanks
   j


signature.asc
Description: PGP signature

[renesas:topic/hs400-mmc-v4 3/4] drivers/mmc/host/tmio_mmc_core.c:1103:5: sparse: symbol 'tmio_mmc_prepare_hs400_tuning' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/hs400-mmc-v4
head:   bad50f922dfffd9bc1a54e1512852e45d25b4ac7
commit: 485c8281e412190ab902c62868cfebf7dc783189 [3/4] mmc: tmio: add eMMC 
HS400 mode support
reproduce:
# apt-get install sparse
git checkout 485c8281e412190ab902c62868cfebf7dc783189
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/mmc/host/tmio_mmc_core.c:1103:5: sparse: symbol 
>> 'tmio_mmc_prepare_hs400_tuning' was not declared. Should it be static?
>> drivers/mmc/host/tmio_mmc_core.c:1113:6: sparse: symbol 
>> 'tmio_mmc_prepare_hs400_tuning_downgrade' was not declared. Should it be 
>> static?
>> drivers/mmc/host/tmio_mmc_core.c:1122:6: sparse: symbol 
>> 'tmio_mmc_complete_hs400_tuning' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[RFC PATCH renesas] mmc: tmio: tmio_mmc_prepare_hs400_tuning() can be static

[kbuild test robot]

Fixes: 485c8281e412 ("mmc: tmio: add eMMC HS400 mode support")
Signed-off-by: Fengguang Wu 
---
 tmio_mmc_core.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 4a83320..cd7afa9 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1100,7 +1100,7 @@ static int tmio_multi_io_quirk(struct mmc_card *card,
return blk_size;
 }
 
-int tmio_mmc_prepare_hs400_tuning(struct mmc_host *mmc, struct mmc_ios *ios)
+static int tmio_mmc_prepare_hs400_tuning(struct mmc_host *mmc, struct mmc_ios 
*ios)
 {
struct tmio_mmc_host *host = mmc_priv(mmc);
 
@@ -1110,8 +1110,8 @@ int tmio_mmc_prepare_hs400_tuning(struct mmc_host *mmc, 
struct mmc_ios *ios)
return 0;
 }
 
-void tmio_mmc_prepare_hs400_tuning_downgrade(struct mmc_host *mmc,
-struct mmc_ios *ios)
+static void tmio_mmc_prepare_hs400_tuning_downgrade(struct mmc_host *mmc,
+   struct mmc_ios *ios)
 {
struct tmio_mmc_host *host = mmc_priv(mmc);
 
@@ -1119,8 +1119,8 @@ void tmio_mmc_prepare_hs400_tuning_downgrade(struct 
mmc_host *mmc,
host->prepare_hs400_tuning_downgrade(host, ios);
 }
 
-void tmio_mmc_complete_hs400_tuning(struct mmc_host *mmc,
-   struct mmc_ios *ios)
+static void tmio_mmc_complete_hs400_tuning(struct mmc_host *mmc,
+  struct mmc_ios *ios)
 {
struct tmio_mmc_host *host = mmc_priv(mmc);
 

Re: [PATCH] sh: mm: Fix unprotected access to struct device

[Christoph Hellwig]

On Tue, Apr 17, 2018 at 03:35:23PM +0200, Jacopo Mondi wrote:
> With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
> operations observe dev->dma_pfn_offset") the generic DMA allocation
> function on which the SH 'dma_alloc_coherent()' function relies on,
> access the 'dma_pfn_offset' field of struct device.
> 
> Unfortunately the 'dma_generic_alloc_coherent()' function is called from
> several places with a NULL struct device argument, halting the CPU
> during the boot process.
> 
> This patch fixes the issue protecting access to dev->dma_pfn_offset,
> with a trivial check for validity. It also passes a valid 'struct device'
> in the 'platform_resource_setup_memory' function which is the main user
> of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
> (and existing) bogus users of this function they're should provide a valid
> 'struct device' whenever possible.

Please fix those callers to not pass a NULL pointer instead.

Re: [PATCH v6 01/11] ARM: sunxi: smp: Move assembly code into a file

[Chen-Yu Tsai]

On Wed, Apr 18, 2018 at 4:45 PM, Maxime Ripard
 wrote:
> On Tue, Apr 17, 2018 at 07:25:15PM +0800, Chen-Yu Tsai wrote:
>> On Tue, Apr 17, 2018 at 7:17 PM, Maxime Ripard
>>  wrote:
>> > On Tue, Apr 17, 2018 at 11:12:41AM +0800, Chen-Yu Tsai wrote:
>> >> On Tue, Apr 17, 2018 at 5:50 AM, Mylène Josserand
>> >>  wrote:
>> >> > Move the assembly code for cluster cache enabling and resuming
>> >> > into an assembly file instead of having it directly in C code.
>> >> >
>> >> > Remove the CFLAGS because we are using the ARM directive "arch"
>> >> > instead.
>> >> >
>> >> > Signed-off-by: Mylène Josserand 
>> >> > ---
>> >> >  arch/arm/mach-sunxi/Makefile  |  4 +--
>> >> >  arch/arm/mach-sunxi/headsmp.S | 80 
>> >> > +
>> >> >  arch/arm/mach-sunxi/mc_smp.c  | 82 
>> >> > +++
>> >> >  3 files changed, 85 insertions(+), 81 deletions(-)
>> >> >  create mode 100644 arch/arm/mach-sunxi/headsmp.S
>> >>
>> >> I'm still not convinced about this whole "move ASM to separate
>> >> file" thing, especially now that you aren't actually adding any
>> >> sunxi-specific ASM code beyond a simple function call.
>> >>
>> >> Could you drop this for now?
>> >
>> > I'd really like to have this merged actually. There's a significant
>> > readibility improvement, so even if there's no particular functional
>> > improvement, I'd still call it a win.
>>
>> What parts do you consider hard to read? The extra quotes? Trailing
>> newline? Or perhaps the __stringify bits?
>
> All of this, plus the clobbers and operands.

Ok. Lets move it then.

The kbuild reports indicate this still needs some work though.

ChenYu

Re: [PATCH v6 11/11] ARM: shmobile: Convert file to use cntvoff

[Mylène Josserand]

Hello,

On Wed, 18 Apr 2018 11:36:27 +0200
Geert Uytterhoeven  wrote:

> Hi Mylène,
> 
> On Mon, Apr 16, 2018 at 11:50 PM, Mylène Josserand
>  wrote:
> > Now that a common function is available for CNTVOFF's
> > initialization, let's convert shmobile-apmu code to use
> > this function.  
> 
> Thanks for your patch, works fine on Renesas ALT with R-Car E2,
> which suffers from lack of CNTVOFF initialization.

Great to know that it works on this board.

> 
> > Signed-off-by: Mylène Josserand   
> 
> Reviewed-by: Geert Uytterhoeven 
> Tested-by: Geert Uytterhoeven 
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 

Thank you again for testing it :)

Best regards,

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH v6 05/11] ARM: smp: Add initialization of CNTVOFF

[Mylène Josserand]

Hello Geert,

On Wed, 18 Apr 2018 11:30:47 +0200
Geert Uytterhoeven  wrote:

> Allo Mylène,
> 
> On Mon, Apr 16, 2018 at 11:50 PM, Mylène Josserand
>  wrote:
> > The CNTVOFF register from arch timer is uninitialized.
> > It should be done by the bootloader but it is currently not the case,
> > even for boot CPU because this SoC is booting in secure mode.
> > It leads to an random offset value meaning that each CPU will have a
> > different time, which isn't working very well.
> >
> > Add assembly code used for boot CPU and secondary CPU cores to make
> > sure that the CNTVOFF register is initialized. Because this code can
> > be used by different platforms, add this assembly file in ARM's common
> > folder.  
> 
> Thanks for your patch!
> 
> > Signed-off-by: Mylène Josserand   
> 
> Reviewed-by: Geert Uytterhoeven 
> Tested-by: Geert Uytterhoeven 
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 

Great, thank you very much for your test!

Best regards,

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[PATCH v4 1/4] mmc: core: select HS400 from HS200 tuning function

[Simon Horman]

Call mmc_select_hs400() from mmc_hs200_tuning().

This should have no run-time effect as the existing call to
mmc_select_hs400() is right after a call to mmc_hs200_tuning() in
mmc_init_card() and that is the only caller of mmc_hs200_tuning().

This is in preparation for adding a new mmc_host_opp to be called
after tuning and selecting HS400 - or in other words,
after mmc_execute_tuning() and mmc_select_hs400().

Signed-off-by: Simon Horman 
---
v4
- New patch
---
 drivers/mmc/core/mmc.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 6f8ebd6caa4c..099b327e10ca 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1508,6 +1508,7 @@ static int mmc_select_timing(struct mmc_card *card)
 static int mmc_hs200_tuning(struct mmc_card *card)
 {
struct mmc_host *host = card->host;
+   int err;
 
/*
 * Timing should be adjusted to the HS400 target
@@ -1518,7 +1519,11 @@ static int mmc_hs200_tuning(struct mmc_card *card)
if (host->ops->prepare_hs400_tuning)
host->ops->prepare_hs400_tuning(host, >ios);
 
-   return mmc_execute_tuning(card);
+   err = mmc_execute_tuning(card);
+   if (err)
+   return err;
+
+   return mmc_select_hs400(card);
 }
 
 /*
@@ -1733,10 +1738,6 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
err = mmc_hs200_tuning(card);
if (err)
goto free_card;
-
-   err = mmc_select_hs400(card);
-   if (err)
-   goto free_card;
} else if (!mmc_card_hs400es(card)) {
/* Select the desired bus width optionally */
err = mmc_select_bus_width(card);
-- 
2.11.0

[PATCH v4 3/4] mmc: tmio: add eMMC HS400 mode support

[Simon Horman]

From: Masaharu Hayakawa 

This patch adds processing for selecting HS400 mode.

Signed-off-by: Masaharu Hayakawa 
Signed-off-by: Simon Horman 
---
v4 [Simon Horman]
* Make use of proposed new HS400 host operations

v3 [Simon Horman]
* Consolidate disable_scc and reset_hs400_mode into reset_hs400_tuning
  callback

v2 [Simon Horman]
* Updated to new version of BSP patch from BSP v3.6.0
* Dropped 4 and 8 tap differentiation as all SoCs currently supported
  by the driver in upstream use 4 taps for HS400.
* Minor cleanup

v1 [Simon Horman]
* Combined patches by Ai Kyuse and Masaharu Hayakawa.
* Rebase
* Minor clean-up

v0 [Masaharu Hayakawa]
---
 drivers/mmc/host/tmio_mmc.h  |  9 
 drivers/mmc/host/tmio_mmc_core.c | 49 ++--
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index e7d651352dc9..4fffcd1d96da 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -46,6 +46,7 @@
 #define CTL_DMA_ENABLE 0xd8
 #define CTL_RESET_SD 0xe0
 #define CTL_VERSION 0xe2
+#define CTL_SDIF_MODE 0xe6
 #define CTL_SDIO_REGS 0x100
 #define CTL_CLK_AND_WAIT_CTL 0x138
 #define CTL_RESET_SDIO 0x1e0
@@ -191,6 +192,14 @@ struct tmio_mmc_host {
/* Tuning values: 1 for success, 0 for failure */
DECLARE_BITMAP(taps, BITS_PER_BYTE * sizeof(long));
unsigned int tap_num;
+   unsigned long tap_set;
+
+   void (*prepare_hs400_tuning_downgrade)(struct tmio_mmc_host *host,
+  struct mmc_ios *ios);
+   void (*prepare_hs400_tuning)(struct tmio_mmc_host *host,
+struct mmc_ios *ios);
+   void (*complete_hs400_tuning)(struct tmio_mmc_host *host,
+ struct mmc_ios *ios);
 
const struct tmio_mmc_dma_ops *dma_ops;
 };
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 308029930304..4a8332077795 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -199,6 +199,13 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
tmio_mmc_clk_stop(host);
return;
}
+   /*
+* Both HS400 and HS200/SD104 set 200MHz, but some devices need to
+* set 400MHz to distinguish the CPG settings in HS400.
+*/
+   if (host->mmc->ios.timing == MMC_TIMING_MMC_HS400 &&
+   new_clock == 2)
+   new_clock = 4;
 
if (host->clk_update)
clock = host->clk_update(host, new_clock) / 512;
@@ -209,8 +216,13 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
clock <<= 1;
 
/* 1/1 clock is option */
-   if ((host->pdata->flags & TMIO_MMC_CLK_ACTUAL) && ((clk >> 22) & 0x1))
-   clk |= 0xff;
+   if ((host->pdata->flags & TMIO_MMC_CLK_ACTUAL) &&
+   ((clk >> 22) & 0x1)) {
+   if (!(host->mmc->ios.timing == MMC_TIMING_MMC_HS400))
+   clk |= 0xff;
+   else
+   clk &= ~0xff;
+   }
 
if (host->set_clk_div)
host->set_clk_div(host->pdev, (clk >> 22) & 1);
@@ -1053,6 +1065,7 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
"%s.%d: IOS interrupted: clk %u, mode %u",
current->comm, task_pid_nr(current),
ios->clock, ios->power_mode);
+
host->mrq = NULL;
 
host->clk_cache = ios->clock;
@@ -1087,6 +1100,34 @@ static int tmio_multi_io_quirk(struct mmc_card *card,
return blk_size;
 }
 
+int tmio_mmc_prepare_hs400_tuning(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+   struct tmio_mmc_host *host = mmc_priv(mmc);
+
+   if (host->prepare_hs400_tuning)
+   host->prepare_hs400_tuning(host, ios);
+
+   return 0;
+}
+
+void tmio_mmc_prepare_hs400_tuning_downgrade(struct mmc_host *mmc,
+struct mmc_ios *ios)
+{
+   struct tmio_mmc_host *host = mmc_priv(mmc);
+
+   if (host->prepare_hs400_tuning_downgrade)
+   host->prepare_hs400_tuning_downgrade(host, ios);
+}
+
+void tmio_mmc_complete_hs400_tuning(struct mmc_host *mmc,
+   struct mmc_ios *ios)
+{
+   struct tmio_mmc_host *host = mmc_priv(mmc);
+
+   if (host->complete_hs400_tuning)
+   host->complete_hs400_tuning(host, ios);
+}
+
 static const struct mmc_host_ops tmio_mmc_ops = {
.request= tmio_mmc_request,
.set_ios= tmio_mmc_set_ios,
@@ -1096,6 +1137,10 @@ static const struct mmc_host_ops tmio_mmc_ops = {
.multi_io_quirk = tmio_multi_io_quirk,
.hw_reset   = tmio_mmc_hw_reset,
.execute_tuning = 

[PATCH v4 2/4] mmc: core: more fine-grained hooks for HS400 tuning

[Simon Horman]

This adds two new HS400 tuning operations:
* prepare_hs400_tuning_downgrade
* complete_hs400_tuning

These supplement the existing HS400 operation:
* prepare_hs400_tuning

This is motivated by a requirement of Renesas SDHI for the following:
1. Disabling SCC before selecting to HS if selection of HS400 has occurred.
   This can be done in an implementation of prepare_hs400_tuning_downgrade
2. Updating registers after switching to HS400
   This can be done in an implementation of complete_hs400_tuning

After this patch the call sequence is as follows:

* Initial tuning
  i. prepare_hs400_tuning
  2. Tuning procedure
  3. Select HS400
  4. complete_hs400_tuning

* Retune
  1. prepare_hs400_tuning_downgrade
  2. Select HS200
  3. prepare_hs400_tuning
  4. Tuning procedure
  5. Select HS400
  6. complete_hs400_tuning

If prepare_hs400_tuning or complete_hs400_tuning are not implemented they
are not called. And if neither are called the procedure is the same as
before this patch.

Design consideration: In the case of Renesas SDHI it is likely that
prepare_hs400_tuning_downgrade and prepare_hs400_tuning could be combined
if the latter was called before selecting HS200 during tuning. When I say
likely, I believe it matches my understanding of the hardware. However, I
did not test this as I am entirely unsure if moving the
prepare_hs400_tuning call would work for other hardware that uses this
operation and I am in no position to test such hardware.

Signed-off-by: Simon Horman 
---
v4
* New patch
---
 drivers/mmc/core/host.c  | 13 -
 drivers/mmc/core/mmc.c   | 19 ++-
 include/linux/mmc/host.h | 26 +-
 3 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 64b03d6eaf18..5e60df7ca11f 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -138,6 +138,10 @@ int mmc_retune(struct mmc_host *host)
host->doing_retune = 1;
 
if (host->ios.timing == MMC_TIMING_MMC_HS400) {
+   if (host->ops->prepare_hs400_tuning_downgrade)
+   host->ops->prepare_hs400_tuning_downgrade(host,
+ >ios);
+
err = mmc_hs400_to_hs200(host->card);
if (err)
goto out;
@@ -152,8 +156,15 @@ int mmc_retune(struct mmc_host *host)
if (err)
goto out;
 
-   if (return_to_hs400)
+   if (return_to_hs400) {
err = mmc_hs200_to_hs400(host->card);
+   if (err)
+   goto out;
+
+   if (host->ops->complete_hs400_tuning)
+   host->ops->complete_hs400_tuning(host, >ios);
+   }
+
 out:
host->doing_retune = 0;
 
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 099b327e10ca..a108a1a3e27f 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1508,22 +1508,31 @@ static int mmc_select_timing(struct mmc_card *card)
 static int mmc_hs200_tuning(struct mmc_card *card)
 {
struct mmc_host *host = card->host;
+   bool run_hs400_ops;
int err;
 
+   run_hs400_ops = card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
+   host->ios.bus_width == MMC_BUS_WIDTH_8;
+
/*
 * Timing should be adjusted to the HS400 target
 * operation frequency for tuning process
 */
-   if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
-   host->ios.bus_width == MMC_BUS_WIDTH_8)
-   if (host->ops->prepare_hs400_tuning)
-   host->ops->prepare_hs400_tuning(host, >ios);
+   if (run_hs400_ops && host->ops->prepare_hs400_tuning)
+   host->ops->prepare_hs400_tuning(host, >ios);
 
err = mmc_execute_tuning(card);
if (err)
return err;
 
-   return mmc_select_hs400(card);
+   err = mmc_select_hs400(card);
+   if (err)
+   return err;
+
+   if (run_hs400_ops && host->ops->complete_hs400_tuning)
+   host->ops->complete_hs400_tuning(host, >ios);
+
+   return 0;
 }
 
 /*
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 85146235231e..5d3ae1071d2f 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -143,8 +143,32 @@ struct mmc_host_ops {
/* The tuning command opcode value is different for SD and eMMC cards */
int (*execute_tuning)(struct mmc_host *host, u32 opcode);
 
-   /* Prepare HS400 target operating frequency depending host driver */
+   /* Prepare for HS400 downgrade during tuning of target operating 
frequency depending on host driver
+* If provided and retuning is in progress, this is called before:
+* 1. Switching from HS400 to HS200; which preceeds
+* 2. Calling .prepare_hs400_tuning, if present; which preceeds
+* 3. The HS400 tuning 

[PATCH v4 4/4] mmc: renesas_sdhi: add eMMC HS400 mode support

[Simon Horman]

From: Masaharu Hayakawa 

This patch adds processing for selecting HS400 mode.

Signed-off-by: Masaharu Hayakawa 
Signed-off-by: Simon Horman 
---
v4 [Simon Horman]
* Make use of proposed new HS400 host operations

v3 [Simon Horman]
* Consolidate disable_scc and reset_hs400_mode into reset_hs400_tuning
  callback
* Reuse renesas_sdhi_reset_hs400_mode() in renesas_sdhi_hw_reset()
* Factor out renesas_sdhi_reset_scc()

v2 [Simon Horman]
* Updated to new version from BSP v3.6.0
* Dropped 4 and 8 tap differentiation as all SoCs currently supported
  by the driver in upstream use 4 taps for HS400.

v1 [Simon Horman]
* Combined patched by Ai Kyuse and Masaharu Hayakawa
* Rebase

v0 [Masaharu Hayakawa]
---
 drivers/mmc/host/renesas_sdhi_core.c | 136 +--
 1 file changed, 114 insertions(+), 22 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index 51e01f03fb99..6628886788dc 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -211,6 +211,7 @@ static int renesas_sdhi_start_signal_voltage_switch(struct 
mmc_host *mmc,
 #define SH_MOBILE_SDHI_SCC_CKSEL   0x006
 #define SH_MOBILE_SDHI_SCC_RVSCNTL 0x008
 #define SH_MOBILE_SDHI_SCC_RVSREQ  0x00A
+#define SH_MOBILE_SDHI_SCC_TMPPORT20x00E
 
 /* Definitions for values the SH_MOBILE_SDHI_SCC_DTCNTL register */
 #define SH_MOBILE_SDHI_SCC_DTCNTL_TAPENBIT(0)
@@ -223,6 +224,9 @@ static int renesas_sdhi_start_signal_voltage_switch(struct 
mmc_host *mmc,
 #define SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN   BIT(0)
 /* Definitions for values the SH_MOBILE_SDHI_SCC_RVSREQ register */
 #define SH_MOBILE_SDHI_SCC_RVSREQ_RVSERR   BIT(2)
+/* Definitions for values the SH_MOBILE_SDHI_SCC_TMPPORT2 register */
+#define SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL  BIT(4)
+#define SH_MOBILE_SDHI_SCC_TMPPORT2_HS400ENBIT(31)
 
 static inline u32 sd_scc_read32(struct tmio_mmc_host *host,
struct renesas_sdhi *priv, int addr)
@@ -243,33 +247,30 @@ static unsigned int renesas_sdhi_init_tuning(struct 
tmio_mmc_host *host)
 
priv = host_to_priv(host);
 
-   /* set sampling clock selection range */
-   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL,
-  0x8 << SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT);
-
/* Initialize SCC */
sd_ctrl_write32_as_16_and_16(host, CTL_STATUS, 0x0);
 
-   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL,
-  SH_MOBILE_SDHI_SCC_DTCNTL_TAPEN |
-  sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL));
-
sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 
+   /* set sampling clock selection range */
+   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL,
+  SH_MOBILE_SDHI_SCC_DTCNTL_TAPEN |
+  0x8 << SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT);
+
sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_CKSEL,
   SH_MOBILE_SDHI_SCC_CKSEL_DTSEL |
   sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_CKSEL));
 
-   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
-   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
-
sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL,
   ~SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN &
   sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL));
 
sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DT2FF, priv->scc_tappos);
 
+   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
+   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
+
/* Read TAPNUM */
return (sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL) >>
SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT) &
@@ -285,13 +286,102 @@ static void renesas_sdhi_prepare_tuning(struct 
tmio_mmc_host *host,
sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_TAPSET, tap);
 }
 
+static void renesas_sdhi_complete_hs400_tuning(struct tmio_mmc_host *host,
+  struct mmc_ios *ios)
+{
+   struct renesas_sdhi *priv = host_to_priv(host);
+
+   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
+   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
+
+   /* Set HS400 mode */
+   sd_ctrl_write16(host, CTL_SDIF_MODE, 0x0001 |
+   sd_ctrl_read16(host, CTL_SDIF_MODE));
+   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2,
+  (SH_MOBILE_SDHI_SCC_TMPPORT2_HS400EN |
+   SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL) |
+   sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2));
+
+   /* Set the 

[PATCH v3] sh: mm: Fix unprotected access to struct device

[Jacopo Mondi]

With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
operations observe dev->dma_pfn_offset") the generic DMA allocation
function on which the SH 'dma_alloc_coherent()' function relies on,
accesses the 'dma_pfn_offset' field of struct device.

Unfortunately the 'dma_generic_alloc_coherent()' function is called from
several places with a NULL struct device argument, halting the CPU
during the boot process.

This patch fixes the issue by protecting access to dev->dma_pfn_offset,
with a trivial check for validity. It also passes a valid 'struct device'
in the 'platform_resource_setup_memory()' function which is the main user
of 'dma_alloc_coherent()', and inserts a WARN_ON() check to remind to future
(and existing) bogus users of this function to provide a valid 'struct device'
whenever possible.

Fixes: ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping operations 
observe dev->dma_pfn_offset")
Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Thomas Petazzoni 

---
v2 -> v3:
- remove (now) useless parenthesis around pfn assignement as suggested
  by Sergei
- Add changelog to the patch, which I forgot in v2

v1 -> v2:
- Move WARN_ON() closer to dev validity check as suggested by Geert

---
 arch/sh/mm/consistent.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index 8ce9869..f1b4469 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -59,7 +59,9 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t 
size,

split_page(pfn_to_page(virt_to_phys(ret) >> PAGE_SHIFT), order);

-   *dma_handle = virt_to_phys(ret) - PFN_PHYS(dev->dma_pfn_offset);
+   *dma_handle = virt_to_phys(ret);
+   if (!WARN_ON(!dev))
+   *dma_handle -= PFN_PHYS(dev->dma_pfn_offset);

return ret_nocache;
 }
@@ -69,9 +71,12 @@ void dma_generic_free_coherent(struct device *dev, size_t 
size,
   unsigned long attrs)
 {
int order = get_order(size);
-   unsigned long pfn = (dma_handle >> PAGE_SHIFT) + dev->dma_pfn_offset;
+   unsigned long pfn = dma_handle >> PAGE_SHIFT;
int k;

+   if (!WARN_ON(!dev))
+   pfn += dev->dma_pfn_offset;
+
for (k = 0; k < (1 << order); k++)
__free_pages(pfn_to_page(pfn + k), 0);

@@ -143,7 +148,7 @@ int __init platform_resource_setup_memory(struct 
platform_device *pdev,
if (!memsize)
return 0;

-   buf = dma_alloc_coherent(NULL, memsize, _handle, GFP_KERNEL);
+   buf = dma_alloc_coherent(>dev, memsize, _handle, GFP_KERNEL);
if (!buf) {
pr_warning("%s: unable to allocate memory\n", name);
return -ENOMEM;
--
2.7.4

Re: [PATCH v6 11/11] ARM: shmobile: Convert file to use cntvoff

[Geert Uytterhoeven]

Hi Mylène,

On Mon, Apr 16, 2018 at 11:50 PM, Mylène Josserand
 wrote:
> Now that a common function is available for CNTVOFF's
> initialization, let's convert shmobile-apmu code to use
> this function.

Thanks for your patch, works fine on Renesas ALT with R-Car E2,
which suffers from lack of CNTVOFF initialization.

> Signed-off-by: Mylène Josserand 

Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v6 05/11] ARM: smp: Add initialization of CNTVOFF

[Geert Uytterhoeven]

Allo Mylène,

On Mon, Apr 16, 2018 at 11:50 PM, Mylène Josserand
 wrote:
> The CNTVOFF register from arch timer is uninitialized.
> It should be done by the bootloader but it is currently not the case,
> even for boot CPU because this SoC is booting in secure mode.
> It leads to an random offset value meaning that each CPU will have a
> different time, which isn't working very well.
>
> Add assembly code used for boot CPU and secondary CPU cores to make
> sure that the CNTVOFF register is initialized. Because this code can
> be used by different platforms, add this assembly file in ARM's common
> folder.

Thanks for your patch!

> Signed-off-by: Mylène Josserand 

Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] sh: mm: Fix unprotected access to struct device

[Sergei Shtylyov]

Hello!

On 4/17/2018 4:35 PM, Jacopo Mondi wrote:


With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
operations observe dev->dma_pfn_offset") the generic DMA allocation
function on which the SH 'dma_alloc_coherent()' function relies on,
access the 'dma_pfn_offset' field of struct device.

Unfortunately the 'dma_generic_alloc_coherent()' function is called from
several places with a NULL struct device argument, halting the CPU
during the boot process.

This patch fixes the issue protecting access to dev->dma_pfn_offset,
with a trivial check for validity. It also passes a valid 'struct device'
in the 'platform_resource_setup_memory' function which is the main user
of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
(and existing) bogus users of this function they're should provide a valid
'struct device' whenever possible.

Fixes: ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping operations observe 
dev->dma_pfn_offset")
Signed-off-by: Jacopo Mondi 
---
  arch/sh/mm/consistent.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index 8ce9869..b257155 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c

[...]

@@ -69,9 +73,14 @@ void dma_generic_free_coherent(struct device *dev, size_t 
size,
   unsigned long attrs)
  {
int order = get_order(size);
-   unsigned long pfn = (dma_handle >> PAGE_SHIFT) + dev->dma_pfn_offset;
+   unsigned long pfn = (dma_handle >> PAGE_SHIFT);


   Parens no longer needed...

[...]

MBR, Sergei

Re: [PATCH 03/03] ARM: shmobile: stout: Initial support and regulator quirk

[Magnus Damm]

Hi Geert,

On Wed, Apr 18, 2018 at 5:55 PM, Geert Uytterhoeven
 wrote:
> Hi Magnus,
>
> On Wed, Apr 18, 2018 at 10:33 AM, Magnus Damm  wrote:
>> From: Magnus Damm 
>>
>> This is a back port to v4.16 of the following commits merged in v4.17-rc1:
>> ff938cd14d67 ARM: shmobile: stout: enable R-Car Gen2 regulator quirk
>> 92bcfdb334ca ARM: dts: stout: Initial r8a7790 Stout board support
>
> I think you also want
> 60fc75bdf5b1b8ed ("ARM: shmobile: rcar-gen2: Fix error check in
> regulator quirk")

Thanks - good point!

Cheers,

/ magnus

Re: [PATCH] dt-bindings: thermal: rcar-gen3-thermal: update register size in example

[Sergei Shtylyov]

Hello!

On 4/17/2018 11:49 PM, Niklas Söderlund wrote:


From: Niklas Söderlund 

The datasheet have been expanded with more registers and the DT files
have been updated with the new size. This change updates the example so
writing new DT files can use the enchanted driver which uses the new


   Enhanced, maybe? Or was there indeed some magic in the air? :-)


registers.

Signed-off-by: Niklas Söderlund 

[...]

MBR, Sergei

Re: [PATCH 03/03] ARM: shmobile: stout: Initial support and regulator quirk

[Geert Uytterhoeven]

Hi Magnus,

On Wed, Apr 18, 2018 at 10:33 AM, Magnus Damm  wrote:
> From: Magnus Damm 
>
> This is a back port to v4.16 of the following commits merged in v4.17-rc1:
> ff938cd14d67 ARM: shmobile: stout: enable R-Car Gen2 regulator quirk
> 92bcfdb334ca ARM: dts: stout: Initial r8a7790 Stout board support

I think you also want
60fc75bdf5b1b8ed ("ARM: shmobile: rcar-gen2: Fix error check in
regulator quirk")

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 2/2] clk: renesas: cpg-mssr: Add support for R-Car E3

[Yoshihiro Shimoda]

Hi Geert-san,

Thank you for the review!

> From: Geert Uytterhoeven, Sent: Friday, April 13, 2018 7:37 PM
> 
> Hi Shimoda-san,
> 
> On Wed, Apr 11, 2018 at 11:37 AM, Yoshihiro Shimoda
>  wrote:

> > --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> > +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> > @@ -26,6 +26,7 @@ Required Properties:
> >- "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N)
> >- "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M)
> >- "renesas,r8a77980-cpg-mssr" for the r8a77980 SoC (R-Car V3H)
> > +  - "renesas,r8a77990-cpg-mssr" for the r8a77995 SoC (R-Car E3)
> 
> r8a77990 SoC

Oops! I will fix this in v2.

> >- "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3)
> 
> > --- /dev/null
> > +++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
> > @@ -0,0 +1,291 @@
> 
> > +static const struct cpg_core_clk r8a77990_core_clks[] __initconst = {
> 
> > +   /* Core Clock Outputs */
> 
> > +   DEF_GEN3_PE("s0d6c",   R8A77990_CLK_S0D6C, CLK_S0, 6, CLK_PE, 6),
> 
> ... CLK_PE, 2),

I will fix this.

> > +   DEF_GEN3_PE("s3d1c",   R8A77990_CLK_S3D1C, CLK_S3, 1, CLK_PE, 1),
> > +   DEF_GEN3_PE("s3d2c",   R8A77990_CLK_S3D2C, CLK_S3, 2, CLK_PE, 2),
> > +   DEF_GEN3_PE("s3d4c",   R8A77990_CLK_S3D4C, CLK_S3, 4, CLK_PE, 4),
> > +
> > +   DEF_DIV6P1("canfd",R8A77990_CLK_CANFD, CLK_PLL0D6, 0x244),
> 
> I cannot confirm the parent, as Section 8.2.18 ("CAN-FD Clock Frequency
> Control Register (CANFDCKCR)") does not specify the source clock frequency
> for R-Car E3 (unlike for D3). But 800 MHz sounds sane.

According to the Figure 8.1g, PLL0 with 1/2 -- 1/3 -- CANFD clock.
So, the parent clock is PLL0D6 (PLL0 with DIV 6).

> > +   DEF_DIV6P1("csi0", R8A77990_CLK_CSI0,  CLK_PLL1D2, 0x00c),
> 
> I cannot confirm the parent clock, as CSI0 is not documented.
> But given PLL1 runs at 1.6 GHz, PLL1/2 is consistent with PLL1/4 on other
> R-Car Gen3 SoCs with a faster PLL1 (3.2 GHz).

I heard the CSI0 will be documented in the future.

> > +static const struct mssr_mod_clk r8a77990_mod_clks[] __initconst = {
> 
> > +   DEF_MOD("vin7",  804,   R8A77990_CLK_S1D2),
> > +   DEF_MOD("vin6",  805,   R8A77990_CLK_S1D2),
> 
> Vin6/7 have been removed in the Feb. errata.

Oops, I will remove them in v2 patch.

> With the above fixed/confirmed:
> Reviewed-by: Geert Uytterhoeven 

Thanks!

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@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 v6 01/11] ARM: sunxi: smp: Move assembly code into a file

[Maxime Ripard]

On Tue, Apr 17, 2018 at 07:25:15PM +0800, Chen-Yu Tsai wrote:
> On Tue, Apr 17, 2018 at 7:17 PM, Maxime Ripard
>  wrote:
> > On Tue, Apr 17, 2018 at 11:12:41AM +0800, Chen-Yu Tsai wrote:
> >> On Tue, Apr 17, 2018 at 5:50 AM, Mylène Josserand
> >>  wrote:
> >> > Move the assembly code for cluster cache enabling and resuming
> >> > into an assembly file instead of having it directly in C code.
> >> >
> >> > Remove the CFLAGS because we are using the ARM directive "arch"
> >> > instead.
> >> >
> >> > Signed-off-by: Mylène Josserand 
> >> > ---
> >> >  arch/arm/mach-sunxi/Makefile  |  4 +--
> >> >  arch/arm/mach-sunxi/headsmp.S | 80 
> >> > +
> >> >  arch/arm/mach-sunxi/mc_smp.c  | 82 
> >> > +++
> >> >  3 files changed, 85 insertions(+), 81 deletions(-)
> >> >  create mode 100644 arch/arm/mach-sunxi/headsmp.S
> >>
> >> I'm still not convinced about this whole "move ASM to separate
> >> file" thing, especially now that you aren't actually adding any
> >> sunxi-specific ASM code beyond a simple function call.
> >>
> >> Could you drop this for now?
> >
> > I'd really like to have this merged actually. There's a significant
> > readibility improvement, so even if there's no particular functional
> > improvement, I'd still call it a win.
> 
> What parts do you consider hard to read? The extra quotes? Trailing
> newline? Or perhaps the __stringify bits?

All of this, plus the clobbers and operands.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 1/2] dt-bindings: thermal: rcar-gen3-thermal: add r8a77965

[Geert Uytterhoeven]

On Tue, Apr 17, 2018 at 11:00 PM, Niklas Söderlund
 wrote:
> From: Niklas Söderlund 
>
> Based on previous work by Ryo Kataoka .
>
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 2/2] thermal: rcar_gen3_thermal: add r8a77965 support

[Geert Uytterhoeven]

On Tue, Apr 17, 2018 at 11:00 PM, Niklas Söderlund
 wrote:
> From: Niklas Söderlund 
>
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] dt-bindings: thermal: rcar-gen3-thermal: update register size in example

[Geert Uytterhoeven]

On Tue, Apr 17, 2018 at 10:49 PM, Niklas Söderlund
 wrote:
> From: Niklas Söderlund 
>
> The datasheet have been expanded with more registers and the DT files
> have been updated with the new size. This change updates the example so
> writing new DT files can use the enchanted driver which uses the new
> registers.
>
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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/03] ARM: shmobile: stout: Initial support and regulator quirk

[Magnus Damm]

From: Magnus Damm 

This is a back port to v4.16 of the following commits merged in v4.17-rc1:
ff938cd14d67 ARM: shmobile: stout: enable R-Car Gen2 regulator quirk
92bcfdb334ca ARM: dts: stout: Initial r8a7790 Stout board support

Thanks to Marek, Wolfram and Simon for the upstreaming efforts.

Not-Signed-off-by: Magnus Damm 
---

 arch/arm/boot/dts/Makefile |1 
 arch/arm/boot/dts/r8a7790-stout.dts|  363 
 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c |   23 -
 3 files changed, 380 insertions(+), 7 deletions(-)

--- 0001/arch/arm/boot/dts/Makefile
+++ work/arch/arm/boot/dts/Makefile 2018-04-17 16:49:11.080607110 +0900
@@ -784,6 +784,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
+   r8a7790-stout.dtb \
r8a7791-koelsch.dtb \
r8a7791-porter.dtb \
r8a7792-blanche.dtb \
--- /dev/null
+++ work/arch/arm/boot/dts/r8a7790-stout.dts2018-04-17 16:49:12.100607110 
+0900
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Stout board
+ *
+ * Copyright (C) 2018 Marek Vasut 
+ */
+
+/dts-v1/;
+#include "r8a7790.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Stout";
+   compatible = "renesas,stout", "renesas,r8a7790";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x4000>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   led1 {
+   gpios = < 22 GPIO_ACTIVE_LOW>;
+   };
+   led2 {
+   gpios = < 23 GPIO_ACTIVE_LOW>;
+   };
+   led3 {
+   gpios = < 17 GPIO_ACTIVE_LOW>;
+   };
+   led5 {
+   gpios = < 24 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   fixedregulator3v3: regulator-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vcc_sdhi0: regulator-vcc-sdhi0 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI0 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 24 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_out: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   osc1_clk: osc1-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
+
+   osc4_clk: osc4-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1200>;
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 722>,
+< CPG_MOD 726>, < CPG_MOD 725>,
+<_clk>;
+   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1", "dclkin.0";
+
+   ports {
+   port@0 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   port@1 {
+   lvds_connector0: endpoint {
+   };
+   };
+   port@2 {
+   lvds_connector1: endpoint {
+   };
+   };
+   };
+};
+
+_clk {
+   clock-frequency = <2000>;
+};
+
+ {
+
+   pinctrl-0 = <_clk_pins>;
+   pinctrl-names = "default";
+
+   du_pins: du {
+   groups = "du_rgb888", "du_sync_1", "du_clk_out_0";
+   function = "du";
+   };
+
+   scifa0_pins: scifa0 {
+   groups = "scifa0_data_b";
+   function = "scifa0";
+   };
+
+   scif_clk_pins: scif_clk {
+   groups = "scif_clk";
+   function = "scif_clk";
+   };
+
+   ether_pins: ether {
+   groups = "eth_link", "eth_mdio", "eth_rmii";
+   function = "eth";
+   };
+
+   phy1_pins: phy1 {
+   groups = "intc_irq1";
+

[PATCH 00/03] v4.16 backports of M3-N PFC, Stout and RAVB

[Magnus Damm]

v4.16 backports of M3-N PFC, Stout and RAVB

[PATCH 01/03] pinctrl: sh-pfc: r8a77965: Initial support including SCIF
[PATCH 02/03] ravb: MTU support and minor fix
[PATCH 03/03] ARM: shmobile: stout: Initial support and regulator quirk

This series contain various backports useful for testing on v4.16 in case
latest upstream kernel remains unstable.

The series contains support for:
- R-Car M3-N PFC support (Initial support and SCIF device support)
- Ethernet AVB updates (MTU support and fix)
- Stout board support (Initial support and regulator quirk)

Thanks to Niklas, Jacopo and Marek for their efforts with the upstreaming.

Not-Signed-off-by: Magnus Damm 
---

 Fits on top of v4.16 mainline

 Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt |1 
 arch/arm/boot/dts/Makefile|1 
 arch/arm/boot/dts/r8a7790-stout.dts   |  363 +
 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c|   23 
 drivers/net/ethernet/renesas/ravb.h   |1 
 drivers/net/ethernet/renesas/ravb_main.c  |   33 
 drivers/pinctrl/sh-pfc/Kconfig|5 
 drivers/pinctrl/sh-pfc/Makefile   |1 
 drivers/pinctrl/sh-pfc/core.c |6 
 drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 3022 
++
 drivers/pinctrl/sh-pfc/sh_pfc.h   |1 
 11 files changed, 3443 insertions(+), 14 deletions(-)

[PATCH 02/03] ravb: MTU support and minor fix

[Magnus Damm]

From: Magnus Damm 

This is a back port to v4.16 of the following commits merged in v4.17-rc1:
5c3d0fd4b2c0 ravb: remove erroneous comment
75efa06f457b ravb: add support for changing MTU

Thanks to Niklas, Sergei and Dave Miller for the upstreaming efforts.

Not-Signed-off-by: Magnus Damm 
---

 drivers/net/ethernet/renesas/ravb.h  |1 
 drivers/net/ethernet/renesas/ravb_main.c |   33 +++---
 2 files changed, 27 insertions(+), 7 deletions(-)

--- 0001/drivers/net/ethernet/renesas/ravb.h
+++ work/drivers/net/ethernet/renesas/ravb.h2018-04-17 16:47:02.940607110 
+0900
@@ -1018,6 +1018,7 @@ struct ravb_private {
u32 dirty_rx[NUM_RX_QUEUE]; /* Producer ring indices */
u32 cur_tx[NUM_TX_QUEUE];
u32 dirty_tx[NUM_TX_QUEUE];
+   u32 rx_buf_sz;  /* Based on MTU+slack. */
struct napi_struct napi[NUM_RX_QUEUE];
struct work_struct work;
/* MII transceiver section. */
--- 0001/drivers/net/ethernet/renesas/ravb_main.c
+++ work/drivers/net/ethernet/renesas/ravb_main.c   2018-04-17 
16:47:12.030607110 +0900
@@ -238,7 +238,7 @@ static void ravb_ring_free(struct net_de
   le32_to_cpu(desc->dptr)))
dma_unmap_single(ndev->dev.parent,
 le32_to_cpu(desc->dptr),
-PKT_BUF_SZ,
+priv->rx_buf_sz,
 DMA_FROM_DEVICE);
}
ring_size = sizeof(struct ravb_ex_rx_desc) *
@@ -300,9 +300,9 @@ static void ravb_ring_format(struct net_
for (i = 0; i < priv->num_rx_ring[q]; i++) {
/* RX descriptor */
rx_desc = >rx_ring[q][i];
-   rx_desc->ds_cc = cpu_to_le16(PKT_BUF_SZ);
+   rx_desc->ds_cc = cpu_to_le16(priv->rx_buf_sz);
dma_addr = dma_map_single(ndev->dev.parent, 
priv->rx_skb[q][i]->data,
- PKT_BUF_SZ,
+ priv->rx_buf_sz,
  DMA_FROM_DEVICE);
/* We just set the data size to 0 for a failed mapping which
 * should prevent DMA from happening...
@@ -346,6 +346,9 @@ static int ravb_ring_init(struct net_dev
int ring_size;
int i;
 
+   priv->rx_buf_sz = (ndev->mtu <= 1492 ? PKT_BUF_SZ : ndev->mtu) +
+   ETH_HLEN + VLAN_HLEN;
+
/* Allocate RX and TX skb rings */
priv->rx_skb[q] = kcalloc(priv->num_rx_ring[q],
  sizeof(*priv->rx_skb[q]), GFP_KERNEL);
@@ -355,7 +358,7 @@ static int ravb_ring_init(struct net_dev
goto error;
 
for (i = 0; i < priv->num_rx_ring[q]; i++) {
-   skb = netdev_alloc_skb(ndev, PKT_BUF_SZ + RAVB_ALIGN - 1);
+   skb = netdev_alloc_skb(ndev, priv->rx_buf_sz + RAVB_ALIGN - 1);
if (!skb)
goto error;
ravb_set_buffer_align(skb);
@@ -586,7 +589,7 @@ static bool ravb_rx(struct net_device *n
skb = priv->rx_skb[q][entry];
priv->rx_skb[q][entry] = NULL;
dma_unmap_single(ndev->dev.parent, 
le32_to_cpu(desc->dptr),
-PKT_BUF_SZ,
+priv->rx_buf_sz,
 DMA_FROM_DEVICE);
get_ts &= (q == RAVB_NC) ?
RAVB_RXTSTAMP_TYPE_V2_L2_EVENT :
@@ -619,11 +622,12 @@ static bool ravb_rx(struct net_device *n
for (; priv->cur_rx[q] - priv->dirty_rx[q] > 0; priv->dirty_rx[q]++) {
entry = priv->dirty_rx[q] % priv->num_rx_ring[q];
desc = >rx_ring[q][entry];
-   desc->ds_cc = cpu_to_le16(PKT_BUF_SZ);
+   desc->ds_cc = cpu_to_le16(priv->rx_buf_sz);
 
if (!priv->rx_skb[q][entry]) {
skb = netdev_alloc_skb(ndev,
-  PKT_BUF_SZ + RAVB_ALIGN - 1);
+  priv->rx_buf_sz +
+  RAVB_ALIGN - 1);
if (!skb)
break;  /* Better luck next round. */
ravb_set_buffer_align(skb);
@@ -1854,6 +1858,17 @@ static int ravb_do_ioctl(struct net_devi
return phy_mii_ioctl(phydev, req, cmd);
 }
 
+static int ravb_change_mtu(struct net_device *ndev, int new_mtu)
+{
+   if (netif_running(ndev))
+   return -EBUSY;
+
+   ndev->mtu = new_mtu;
+   netdev_update_features(ndev);
+
+   return 0;
+}
+
 static void ravb_set_rx_csum(struct net_device *ndev, 

Re: [PATCH v4] gpio: dwapb: Add support for 1 interrupt per port A GPIO

[Lee Jones]

On Tue, 17 Apr 2018, Phil Edworthy wrote:

> The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> per GPIO in port A, but the driver currently only supports 1 interrupt.
> See the DesignWare DW_apb_gpio Databook description of the
> 'GPIO_INTR_IO' parameter.
> 
> This change allows the driver to work with up to 32 interrupts, it will
> get as many interrupts as specified in the DT 'interrupts' property.
> It doesn't do anything clever with the different interrupts, it just calls
> the same handler used for single interrupt hardware.
> 
> Signed-off-by: Phil Edworthy 
> ---
> One point to mention is that I have made it possible for users to have
> unconncted interrupts by specifying holes in the list of interrupts. This is
> done by supporting the interrupts-extended DT prop.
> However, I have no use for this and had to hack some test case for this.
> Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
> 
> v4:
>  - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping()
> v3:
>  - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect 
> problems
> v2:
>  - Replaced interrupt-mask DT prop with support for the interrupts-extended
>prop. This means replacing the call to irq_of_parse_and_map() with calls
>to of_irq_parse_one() and irq_create_of_mapping().
> 
> Note: There are a few *code* lines over 80 chars, but this is just guidance,
>right? Especially as there are already some lines over 80 chars.
> 
> snps:gpio fix
> 
> Signed-off-by: Phil Edworthy 
> ---
>  .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 +++--
>  drivers/gpio/gpio-dwapb.c  | 42 
> +-
>  drivers/mfd/intel_quark_i2c_gpio.c |  3 +-

If Linus, is happy with the GPIO implementation, then the changes in
MFD look fine:

Acked-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH/RFC 01/11] Documentation: of: Add device-connection-id property

[Yoshihiro Shimoda]

This patch adds a new property for device connection framework.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/graph.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/graph.txt 
b/Documentation/devicetree/bindings/graph.txt
index 0415e2c..fca0030 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -125,4 +125,4 @@ Optional endpoint properties
 
 
 - remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
-
+- device-connection-id: string for device connection.
-- 
1.9.1

[PATCH/RFC 03/11] dt-bindings: usb: add Renesas R-Car USB 3.0 role switch driver

[Yoshihiro Shimoda]

This patch adds a new documentation for Renesas R-Car USB 3.0 role
switch driver.

Signed-off-by: Yoshihiro Shimoda 
---
 .../bindings/usb/renesas,rcar-usb3-role-sw.txt | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt

diff --git 
a/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt 
b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
new file mode 100644
index 000..ed60f66
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
@@ -0,0 +1,56 @@
+Renesas Electronics R-Car USB 3.0 role switch driver
+
+A renesas_usb3's node can contain this node.
+
+Required properties:
+ - compatible: Must contain "renesas,rcar-usb3-role-switch".
+
+Required nodes:
+
+The connection to a USB connector node and USB role switch node need by
+using OF graph bindings. Please refer to the usb-role-switch.txt about
+port number of the OF graph. Note that port@3 is connected to
+the usb-connector.
+
+
+Example of R-Car H3 ES2.0:
+   usb3_peri0: usb@ee02 {
+   compatible = "renesas,r8a7795-usb3-peri",
+"renesas,rcar-gen3-usb3-peri";
+   reg = <0 0xee02 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 328>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 328>;
+
+   usb3-role-sw {
+   compatible = "renesas,rcar-usb3-role-switch";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   usb3_host_sw0: endpoint {
+   remote-endpoint = 
<_host_ep0>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   usb3_peri_sw0: endpoint {
+   remote-endpoint = 
<_peri_ep0>;
+   device-connection-id = 
"usb-role-switch";
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+   usb3_role_sw0_ep: endpoint {
+   };
+   };
+   };
+   };
+   };
-- 
1.9.1

[PATCH/RFC 11/11] arm64: dts: renesas: r8a7795: salvator-xs: add OF graph for usb role switch

[Yoshihiro Shimoda]

This patch adds OF graph properties for usb role switch.

TODO:
 - Each node should be in salvator-common.dtsi.

Signed-off-by: Yoshihiro Shimoda 
---
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index 8b50ceb..c815fca 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -36,6 +36,24 @@
device_type = "memory";
reg = <0x7 0x 0x0 0x4000>;
};
+
+   /* TODO: should be into salvator-common.dtsi */
+   usb3 {
+   compatible = "usb-a-connector";
+   label = "USB3_0";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   usb3_connector0: endpoint {
+   remote-endpoint = <_role_sw0_ep>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -107,3 +125,13 @@
 
status = "okay";
 };
+
+   _role_sw0 {
+   ports {
+   port@3 {
+   usb3_role_sw0_ep: endpoint {
+   remote-endpoint = <_connector0>;
+   };
+   };
+   };
+   };
-- 
1.9.1

[PATCH/RFC 08/11] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Yoshihiro Shimoda]

This patch adds role switch support for R-Car SoCs. Some R-Car SoCs
(e.g. R-Car H3) have USB 3.0 dual-role device controller which has
the USB 3.0 xHCI host and Renesas USB 3.0 peripheral.

Unfortunately, the mode change register contains the USB 3.0 peripheral
controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
manages this register. However, in peripheral mode, the host should
stop. Also the host hardware needs to reinitialize its own registers
when the mode changes from peripheral to host mode. Otherwise,
the host cannot work correctly (e.g. detect a device as high-speed).

To achieve this by a driver, this role switch driver manages
the mode change register and attach/release the xhci-plat driver.
The renesas_usb3 udc driver should call devm_of_platform_populate()
to probe this driver.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/roles/Kconfig |  12 ++
 drivers/usb/roles/Makefile|   1 +
 drivers/usb/roles/rcar-usb3-role-switch.c | 179 ++
 3 files changed, 192 insertions(+)
 create mode 100644 drivers/usb/roles/rcar-usb3-role-switch.c

diff --git a/drivers/usb/roles/Kconfig b/drivers/usb/roles/Kconfig
index f5a5e6f..429d784 100644
--- a/drivers/usb/roles/Kconfig
+++ b/drivers/usb/roles/Kconfig
@@ -11,4 +11,16 @@ config USB_ROLES_INTEL_XHCI
  To compile the driver as a module, choose M here: the module will
  be called intel-xhci-usb-role-switch.
 
+config USB_ROLES_RCAR_USB3
+   tristate "Renesas R-Car USB3.0 Role Switch"
+   depends on ARCH_RENESAS && OF
+   help
+ Driver for the internal USB role switch for switching the USB data
+ lines between the xHCI host controller and the Renesas gadget
+ controller (by using renesas_usb3 driver) found on various Renesas
+ R-Car SoCs.
+
+ To compile the driver as a module, choose M here: the module will
+ be called rcar-usb3-role-switch.
+
 endif # USB_ROLE_SWITCH
diff --git a/drivers/usb/roles/Makefile b/drivers/usb/roles/Makefile
index e44b179..7ce3be3 100644
--- a/drivers/usb/roles/Makefile
+++ b/drivers/usb/roles/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_USB_ROLES_INTEL_XHCI) += intel-xhci-usb-role-switch.o
+obj-$(CONFIG_USB_ROLES_RCAR_USB3) += rcar-usb3-role-switch.o
diff --git a/drivers/usb/roles/rcar-usb3-role-switch.c 
b/drivers/usb/roles/rcar-usb3-role-switch.c
new file mode 100644
index 000..9b56945
--- /dev/null
+++ b/drivers/usb/roles/rcar-usb3-role-switch.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas R-Car USB 3.0 role switch driver
+ *
+ * Copyright (C) 2018  Renesas Electronics Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB3_DRD_CON   0x218
+#define DRD_CON_PERI_CON   BIT(24)
+
+struct rcar_usb3_role_switch {
+   struct usb_role_switch *role_sw;
+   void __iomem *reg;
+   enum usb_role save_role;/* for suspend/resume */
+};
+
+static enum usb_role
+rcar_usb3_role_switch_get_mode(struct rcar_usb3_role_switch *rcar_sw)
+{
+   u32 val = readl(rcar_sw->reg + USB3_DRD_CON);
+
+   if (val & DRD_CON_PERI_CON)
+   return USB_ROLE_DEVICE;
+
+   return USB_ROLE_HOST;
+}
+
+static void
+rcar_usb3_role_switch_set_mode(struct rcar_usb3_role_switch *rcar_sw,
+  bool host)
+{
+   void __iomem *drd_con = rcar_sw->reg + USB3_DRD_CON;
+
+   if (host)
+   writel(readl(drd_con) & ~DRD_CON_PERI_CON, drd_con);
+   else
+   writel(readl(drd_con) | DRD_CON_PERI_CON, drd_con);
+}
+
+static int rcar_usb3_role_switch_set_role(struct device *dev,
+ enum usb_role role)
+{
+   struct rcar_usb3_role_switch *rcar_sw = dev_get_drvdata(dev);
+   struct device *host = usb_role_switch_get_usb3_port(rcar_sw->role_sw);
+   enum usb_role cur_role;
+
+   pm_runtime_get_sync(dev->parent);
+
+   cur_role = rcar_usb3_role_switch_get_mode(rcar_sw);
+   if (cur_role == USB_ROLE_HOST && role == USB_ROLE_DEVICE) {
+   device_release_driver(host);
+   rcar_usb3_role_switch_set_mode(rcar_sw, false);
+   } else if (cur_role == USB_ROLE_DEVICE && role == USB_ROLE_HOST) {
+   /* Must set the mode before device_attach of the host */
+   rcar_usb3_role_switch_set_mode(rcar_sw, true);
+   if (device_attach(host) < 0)
+   dev_err(dev, "device_attach(usb3_port) failed\n");
+   }
+
+   pm_runtime_put(dev->parent);
+
+   return 0;
+}
+
+static enum usb_role rcar_usb3_role_switch_get_role(struct device *dev)
+{
+   struct rcar_usb3_role_switch *rcar_sw = dev_get_drvdata(dev);
+   enum usb_role cur_role;
+
+   pm_runtime_get(dev->parent);
+   cur_role = rcar_usb3_role_switch_get_mode(rcar_sw);
+   pm_runtime_put(dev->parent);
+
+   

[PATCH/RFC 05/11] usb: common: roles: add fwnode graph parsing

[Yoshihiro Shimoda]

This patch adds fwnode graph parsing to set usb[23]_port and udc
into the usb_role_switch structure by usb_role_switch_register().

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/common/roles.c | 40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
index 15cc76e..cc1c55a 100644
--- a/drivers/usb/common/roles.c
+++ b/drivers/usb/common/roles.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 static struct class *role_class;
@@ -219,6 +221,42 @@ static void usb_role_switch_release(struct device *dev)
.release = usb_role_switch_release,
 };
 
+static void usb_role_parse_fwnode_graph(struct usb_role_switch *sw)
+{
+   struct fwnode_handle *parent = sw->dev.parent->fwnode;
+   struct fwnode_handle *child_ep, *child_port;
+   struct fwnode_handle *remote;
+   /* This order comes from DT bindings */
+   struct device **dev[] = {
+   >usb2_port,
+   >usb3_port,
+   >udc,
+   };
+   u32 port;
+
+   fwnode_graph_for_each_endpoint(parent, child_ep) {
+   child_port = fwnode_get_parent(child_ep);
+   if (!child_port)
+   continue;
+
+   if (fwnode_property_read_u32(child_port, "reg", ) < 0)
+   continue;
+
+   if (port >= ARRAY_SIZE(dev))
+   break;
+
+   remote = fwnode_graph_get_remote_port_parent(child_ep);
+   if (remote) {
+   struct device_node *remote_np = to_of_node(remote);
+   struct platform_device *pdev;
+
+   pdev = of_find_device_by_node(remote_np);
+   if (pdev)
+   *dev[port] = >dev;
+   }
+   };
+}
+
 /**
  * usb_role_switch_register - Register USB Role Switch
  * @parent: Parent device for the switch
@@ -267,7 +305,7 @@ struct usb_role_switch *
return ERR_PTR(ret);
}
 
-   /* TODO: Symlinks for the host port and the device controller. */
+   usb_role_parse_fwnode_graph(sw);
 
return sw;
 }
-- 
1.9.1

[PATCH/RFC 02/11] dt-bindings: usb: add usb role switch driver

[Yoshihiro Shimoda]

This patch adds a new documentation for a usb role switch driver.
The usb role switch framework will parse this to get each device
pointer by using each remote-endpoint.

Signed-off-by: Yoshihiro Shimoda 
---
 .../devicetree/bindings/usb/usb-role-switch.txt| 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/usb-role-switch.txt

diff --git a/Documentation/devicetree/bindings/usb/usb-role-switch.txt 
b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
new file mode 100644
index 000..941d582
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
@@ -0,0 +1,42 @@
+USB role switch driver
+
+Optional nodes:
+- If a role switch driver has OF graph ports, the usb role switch framework
+  will parse the remote-endpoints in usb_role_switch_register(). The OF graph
+  port number as follows:
+0: USB 2.0 host port
+1: USB 3.0 host port
+2: UDC port
+
+For example:
+   usb-role-sw {
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   usb2_host_sw0: endpoint {
+   remote-endpoint = <_host_ep0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   usb3_host_sw0: endpoint {
+   remote-endpoint = <_host_ep0>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   udc_sw0: endpoint {
+   remote-endpoint = <_ep0>;
+   };
+   };
+   };
+   };
-- 
1.9.1

[PATCH/RFC 09/11] usb: gadget: udc: renesas_usb3: add support for a usb role switch

[Yoshihiro Shimoda]

This patch adds support for a usb role switch driver. And then,
this driver uses the usb role switch APIs instead of hardware
access to initialize usb host side at specific timings.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/Kconfig|  1 +
 drivers/usb/gadget/udc/renesas_usb3.c | 34 --
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38..7e4a5dd 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -193,6 +193,7 @@ config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
depends on EXTCON && HAS_DMA
+   select USB_ROLE_SWITCH
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 409cde4..38dd759 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* register definitions */
 #define USB3_AXI_INT_STA   0x008
@@ -330,6 +331,7 @@ struct renesas_usb3 {
 
struct usb_gadget gadget;
struct usb_gadget_driver *driver;
+   struct usb_role_switch *role_sw;/* Optional */
struct extcon_dev *extcon;
struct work_struct extcon_work;
struct phy *phy;
@@ -454,7 +456,11 @@ static void usb3_disable_pipe_irq(struct renesas_usb3 
*usb3, int num)
 
 static bool usb3_is_host(struct renesas_usb3 *usb3)
 {
-   return !(usb3_read(usb3, USB3_DRD_CON) & DRD_CON_PERI_CON);
+   if (usb3->role_sw)
+   return usb_role_switch_get_role(usb3->role_sw) ==
+   USB_ROLE_HOST ? true : false;
+   else
+   return !(usb3_read(usb3, USB3_DRD_CON) & DRD_CON_PERI_CON);
 }
 
 static void usb3_init_axi_bridge(struct renesas_usb3 *usb3)
@@ -645,10 +651,16 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
 
 static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
 {
-   if (host)
-   usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
-   else
-   usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   if (usb3->role_sw) {
+   enum usb_role role = host ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+
+   usb_role_switch_set_role(usb3->role_sw, role);
+   } else {
+   if (host)
+   usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   else
+   usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   }
 }
 
 static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
@@ -663,8 +675,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
bool host, bool a_dev)
 {
unsigned long flags;
 
-   spin_lock_irqsave(>lock, flags);
usb3_set_mode(usb3, host);
+   spin_lock_irqsave(>lock, flags);
usb3_vbus_out(usb3, a_dev);
/* for A-Peripheral or forced B-device mode */
if ((!host && a_dev) ||
@@ -2238,6 +2250,10 @@ static int renesas_usb3_start(struct usb_gadget *gadget,
/* hook up the driver */
usb3->driver = driver;
 
+   usb3->role_sw = usb_role_switch_get(usb3_to_dev(usb3));
+   if (IS_ERR_OR_NULL(usb3->role_sw))
+   usb3->role_sw = NULL;
+
if (usb3->phy)
phy_init(usb3->phy);
 
@@ -2260,6 +2276,8 @@ static int renesas_usb3_stop(struct usb_gadget *gadget)
if (usb3->phy)
phy_exit(usb3->phy);
 
+   usb_role_switch_put(usb3->role_sw);
+
pm_runtime_put(usb3_to_dev(usb3));
 
return 0;
@@ -2632,6 +2650,10 @@ static int renesas_usb3_probe(struct platform_device 
*pdev)
if (ret < 0)
goto err_add_udc;
 
+   ret = devm_of_platform_populate(>dev);
+   if (ret < 0)
+   goto err_dev_create;
+
ret = device_create_file(>dev, _attr_role);
if (ret < 0)
goto err_dev_create;
-- 
1.9.1

[PATCH/RFC 04/11] of: platform: add device connection parsing

[Yoshihiro Shimoda]

This patch adds device connection parsing in of_platform_populate().

TODO:
 - How to free the devcon memories?
 - How to remove the devcon instances?

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/of/platform.c | 66 +++
 include/linux/of.h|  1 +
 2 files changed, 67 insertions(+)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index c00d81d..41c018d 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -326,6 +327,63 @@ static const struct of_dev_auxdata *of_dev_lookup(const 
struct of_dev_auxdata *l
return NULL;
 }
 
+static int of_parse_device_connection(struct device_node *np)
+{
+   struct device_node *child_ep, *parent, *remote_parent;
+   struct platform_device *pdev, *remote_pdev;
+   struct device_connection *devcon = NULL;
+   const char *id;
+
+   if (of_node_check_flag(np, OF_DEVICE_CONNECTED)) {
+   pr_debug("%s() - skipping %pOF, already device connected\n",
+   __func__, np);
+   return 0;
+   }
+
+   of_node_set_flag(np, OF_DEVICE_CONNECTED);
+
+   for_each_endpoint_of_node(np, child_ep) {
+   if (of_property_read_string(child_ep, "device-connection-id",
+   ) < 0)
+   continue;
+
+   remote_parent = of_graph_get_remote_port_parent(child_ep);
+   if (!remote_parent)
+   return 0;
+
+   parent = of_graph_get_port_parent(child_ep);
+   if (!parent)
+   return 0;
+
+   pdev = of_find_device_by_node(parent);
+   if (!pdev)
+   return 0;
+
+   /*
+* WARN_ON in really_probe() may happen if devm_kzalloc is
+* used. TODO: How to free this?
+*/
+   devcon = kzalloc(sizeof(*devcon), GFP_KERNEL);
+   if (!devcon)
+   return -ENOMEM;
+
+   devcon->id = id;
+   remote_pdev = of_find_device_by_node(remote_parent);
+   if (!remote_pdev) {
+   kfree(devcon);
+   return 0;
+   }
+
+   devcon->endpoint[0] = dev_name(>dev);
+   devcon->endpoint[1] = dev_name(_pdev->dev);
+
+   /* TODO: How to remove the connection? */
+   device_connection_add(devcon);
+   }
+
+   return 0;
+}
+
 /**
  * of_platform_bus_create() - Create a device for a node and its children.
  * @bus: device node of the bus to instantiate
@@ -477,6 +535,14 @@ int of_platform_populate(struct device_node *root,
}
of_node_set_flag(root, OF_POPULATED_BUS);
 
+   for_each_child_of_node(root, child) {
+   rc = of_parse_device_connection(child);
+   if (rc) {
+   of_node_put(child);
+   break;
+   }
+   }
+
of_node_put(root);
return rc;
 }
diff --git a/include/linux/of.h b/include/linux/of.h
index 4d25e4f..30aa103 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -143,6 +143,7 @@ static inline void of_node_put(struct device_node *node) { }
 #define OF_DETACHED2 /* node has been detached from the device tree */
 #define OF_POPULATED   3 /* device already created for the node */
 #define OF_POPULATED_BUS   4 /* of_platform_populate recursed to children 
of this node */
+#define OF_DEVICE_CONNECTED5 /* checked devcon on of_platform_populate */
 
 #define OF_BAD_ADDR((u64)-1)
 
-- 
1.9.1

[PATCH/RFC 10/11] arm64: dts: renesas: r8a7795: add OF graph for usb role switch

[Yoshihiro Shimoda]

This patch adds OF graph properties for usb role switch in r8a7795.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 44 
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1d5e3ac..61c1fa0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1746,6 +1746,12 @@
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 328>;
status = "disabled";
+
+   port {
+   usb3_host_ep0: endpoint {
+   remote-endpoint = <_host_ep0>;
+   };
+   };
};
 
usb3_peri0: usb@ee02 {
@@ -1757,6 +1763,44 @@
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 328>;
status = "disabled";
+
+   port {
+   usb3_peri_ep0: endpoint {
+   remote-endpoint = <_peri_sw0>;
+   };
+   };
+
+   usb3_role_sw0: usb3-role-sw {
+   compatible = "renesas,rcar-usb3-role-switch";
+   renesas,host = <>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   usb3_host_sw0: endpoint {
+   remote-endpoint = 
<_host_ep0>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   usb3_peri_sw0: endpoint {
+   remote-endpoint = 
<_peri_ep0>;
+   device-connection-id = 
"usb-role-switch";
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+   usb3_role_sw0_ep: endpoint {
+   };
+   };
+   };
+   };
};
 
usb_dmac0: dma-controller@e65a {
-- 
1.9.1

[PATCH/RFC 00/11] add support for R-Car USB3.0 role switch

[Yoshihiro Shimoda]

This patch set is based on v4.17-rc1.

In last week, I submitted a patch as v1 [1]. But, the v1 patch
doesn't use graphs to get usb host device pointer. So, I modified
some frameworks for it.
Since the patch 4 "of: platform: add device connection parsing"
has TODOs, I marked this patch set as "RFC". Before I resolve them,
I would like to know whether this way is good or not.

[1] https://patchwork.kernel.org/patch/10332865/


Yoshihiro Shimoda (11):
  Documentation: of: Add device-connection-id property
  dt-bindings: usb: add usb role switch driver
  dt-bindings: usb: add Renesas R-Car USB 3.0 role switch driver
  of: platform: add device connection parsing
  usb: common: roles: add fwnode graph parsing
  usb: common: roles: Allow if the parent dev_name matches
  usb: common: roles: add getting device pointer APIs
  usb: role: rcar-usb3-role-switch: add support for R-Car SoCs
  usb: gadget: udc: renesas_usb3: add support for a usb role switch
  arm64: dts: renesas: r8a7795: add OF graph for usb role switch
  arm64: dts: renesas: r8a7795: salvator-xs: add OF graph for usb role
switch

 Documentation/devicetree/bindings/graph.txt|   2 +-
 .../bindings/usb/renesas,rcar-usb3-role-sw.txt |  56 +++
 .../devicetree/bindings/usb/usb-role-switch.txt|  42 +
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts |  28 
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  44 +
 drivers/of/platform.c  |  66 
 drivers/usb/common/roles.c |  84 +-
 drivers/usb/gadget/udc/Kconfig |   1 +
 drivers/usb/gadget/udc/renesas_usb3.c  |  34 +++-
 drivers/usb/roles/Kconfig  |  12 ++
 drivers/usb/roles/Makefile |   1 +
 drivers/usb/roles/rcar-usb3-role-switch.c  | 179 +
 include/linux/of.h |   1 +
 include/linux/usb/role.h   |   4 +
 14 files changed, 545 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
 create mode 100644 Documentation/devicetree/bindings/usb/usb-role-switch.txt
 create mode 100644 drivers/usb/roles/rcar-usb3-role-switch.c

-- 
1.9.1

[PATCH/RFC 06/11] usb: common: roles: Allow if the parent dev_name matches

[Yoshihiro Shimoda]

THis patch adds a condition in __switch_match() to allow if
the parent dev_name matches. Otherwise, OF environment cannot match
the usb role switch devices because the usb role switch framework
adds the names of a new child device as the parent dev_name with
"-role-switch".

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/common/roles.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
index cc1c55a..381259c 100644
--- a/drivers/usb/common/roles.c
+++ b/drivers/usb/common/roles.c
@@ -88,7 +88,13 @@ enum usb_role usb_role_switch_get_role(struct 
usb_role_switch *sw)
 
 static int __switch_match(struct device *dev, const void *name)
 {
-   return !strcmp((const char *)name, dev_name(dev));
+   int ret = !strcmp((const char *)name, dev_name(dev));
+
+   /* If doesn't match, this also checks the parent dev_name */
+   if (!ret && dev->parent)
+   ret = !strcmp((const char *)name, dev_name(dev->parent));
+
+   return ret;
 }
 
 static void *usb_role_switch_match(struct device_connection *con, int ep,
-- 
1.9.1

[PATCH/RFC 07/11] usb: common: roles: add getting device pointer APIs

[Yoshihiro Shimoda]

This patch adds APIs that a role switch driver can get device pointer
of USB 2.0/3.0 and udc.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/common/roles.c | 36 
 include/linux/usb/role.h   |  4 
 2 files changed, 40 insertions(+)

diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
index 381259c..5fd14b2 100644
--- a/drivers/usb/common/roles.c
+++ b/drivers/usb/common/roles.c
@@ -34,6 +34,42 @@ struct usb_role_switch {
 #define to_role_switch(d)  container_of(d, struct usb_role_switch, dev)
 
 /**
+ * usb_role_switch_get_usb2_port - Get device of a USB 2.0 host
+ * @sw: USB role switch
+ *
+ * Returns USB 2.0 host device pointer.
+ */
+struct device *usb_role_switch_get_usb2_port(struct usb_role_switch *sw)
+{
+   return sw->usb2_port;
+}
+EXPORT_SYMBOL(usb_role_switch_get_usb2_port);
+
+/**
+ * usb_role_switch_get_usb3_port - Get device of a USB 3.0 host
+ * @sw: USB role switch
+ *
+ * Returns USB 3.0 host device pointer.
+ */
+struct device *usb_role_switch_get_usb3_port(struct usb_role_switch *sw)
+{
+   return sw->usb3_port;
+}
+EXPORT_SYMBOL(usb_role_switch_get_usb3_port);
+
+/**
+ * usb_role_switch_get_udc - Get device of a udc
+ * @sw: USB role switch
+ *
+ * Returns udc device pointer.
+ */
+struct device *usb_role_switch_get_udc(struct usb_role_switch *sw)
+{
+   return sw->udc;
+}
+EXPORT_SYMBOL(usb_role_switch_get_udc);
+
+/**
  * usb_role_switch_set_role - Set USB role for a switch
  * @sw: USB role switch
  * @role: USB role to be switched to
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index edc51be..c7eb73b 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -40,6 +40,10 @@ struct usb_role_switch_desc {
bool allow_userspace_control;
 };
 
+struct device *usb_role_switch_get_usb2_port(struct usb_role_switch *sw);
+struct device *usb_role_switch_get_usb3_port(struct usb_role_switch *sw);
+struct device *usb_role_switch_get_udc(struct usb_role_switch *sw);
+
 int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
 enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
 struct usb_role_switch *usb_role_switch_get(struct device *dev);
-- 
1.9.1

Re: [PATCH v3] gpio: dwapb: Add support for 1 interrupt per port A GPIO

[Hoan Tran]

Hi Phil,

On Fri, Apr 13, 2018 at 9:47 AM, Phil Edworthy
 wrote:
> Hi Hoan,
>
> On 13 April 2018 17:37 Hoan Tran wrote:
>> On Fri, Apr 13, 2018 at 1:51 AM, Phil Edworthy wrote:
>> > The DesignWare GPIO IP can be configured for either 1 interrupt or 1
>> > per GPIO in port A, but the driver currently only supports 1 interrupt.
>> > See the DesignWare DW_apb_gpio Databook description of the
>> > 'GPIO_INTR_IO' parameter.
>> >
>> > This change allows the driver to work with up to 32 interrupts, it
>> > will get as many interrupts as specified in the DT 'interrupts' property.
>> > It doesn't do anything clever with the different interrupts, it just
>> > calls the same handler used for single interrupt hardware.
>> >
>> > Signed-off-by: Phil Edworthy 
>> > ---
>> > One point to mention is that I have made it possible for users to have
>> > unconncted interrupts by specifying holes in the list of interrupts.
>> > This is done by supporting the interrupts-extended DT prop.
>> > However, I have no use for this and had to hack some test case for this.
>> > Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
>> >
>> > v3:
>> >  - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid
>> > bisect problems
>> > v2:
>> >  - Replaced interrupt-mask DT prop with support for the interrupts-
>> extended
>> >prop. This means replacing the call to irq_of_parse_and_map() with calls
>> >to of_irq_parse_one() and irq_create_of_mapping().
>> >
>> > Note: There are a few *code* lines over 80 chars, but this is just 
>> > guidance,
>> >right? Especially as there are already some lines over 80 chars.
>> > ---
> [snip]
>
>> > -   if (has_acpi_companion(dev) && pp->idx == 0)
>> > -   pp->irq = 
>> > platform_get_irq(to_platform_device(dev), 0);
>> > +   if (has_acpi_companion(dev) && pp->idx == 0) {
>> > +   pp->irq[0] = 
>> > platform_get_irq(to_platform_device(dev), 0);
>> > +   if (pp->irq[0])
>> > +   pp->has_irq = true;
>> > +   }
>>
>> It doesn't work for ACPI. Could you do the same logic for ACPI?
> I don’t have access to any device that was baked (i.e. fabbed) with multiple
> output interrupts from the Synopsys GPIO blocks and use ACPI. I don't
> know if any such device exists.

Below code is tested on X-Gene system which supports 1 interrupt per
GPIO on Port A. You can update it into your patch.

-   if (has_acpi_companion(dev) && pp->idx == 0)
-   pp->irq = platform_get_irq(to_platform_device(dev), 0);
+   if (has_acpi_companion(dev) && pp->idx == 0) {
+   unsigned int j;
+   for (j = 0; j < pp->ngpio; j++) {
+   pp->irq[j] =
platform_get_irq(to_platform_device(dev), j);
+   if (pp->irq[j])
+   pp->has_irq = true;
+   }
+   }

Thanks
Hoan

>
> I would prefer not writing code that can be tested easily. I cannot even
> test the current, albeit small, changes to the Intel Quark MFD.
>
> Regards
> Phil
>
>> Thanks
>> Hoan
>>
>> >
>> > pp->irq_shared  = false;
>> > pp->gpio_base   = -1;
>> > diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
>> > b/drivers/mfd/intel_quark_i2c_gpio.c
>> > index 90e35de..5bddb84 100644
>> > --- a/drivers/mfd/intel_quark_i2c_gpio.c
>> > +++ b/drivers/mfd/intel_quark_i2c_gpio.c
>> > @@ -233,7 +233,8 @@ static int intel_quark_gpio_setup(struct pci_dev
>> *pdev, struct mfd_cell *cell)
>> > pdata->properties->idx  = 0;
>> > pdata->properties->ngpio= INTEL_QUARK_MFD_NGPIO;
>> > pdata->properties->gpio_base= INTEL_QUARK_MFD_GPIO_BASE;
>> > -   pdata->properties->irq  = pdev->irq;
>> > +   pdata->properties->irq[0]   = pdev->irq;
>> > +   pdata->properties->has_irq  = true;
>> > pdata->properties->irq_shared   = true;
>> >
>> > cell->platform_data = pdata;
>> > diff --git a/include/linux/platform_data/gpio-dwapb.h
>> > b/include/linux/platform_data/gpio-dwapb.h
>> > index 2dc7f4a..5a52d69 100644
>> > --- a/include/linux/platform_data/gpio-dwapb.h
>> > +++ b/include/linux/platform_data/gpio-dwapb.h
>> > @@ -19,7 +19,8 @@ struct dwapb_port_property {
>> > unsigned intidx;
>> > unsigned intngpio;
>> > unsigned intgpio_base;
>> > -   unsigned intirq;
>> > +   unsigned intirq[32];
>> > +   boolhas_irq;
>> > boolirq_shared;
>> >  };
>> >
>> > --
>> > 2.7.4
>> >