Re: [PATCH] dt-bindings: i2c: sh_mobile: Document R-Car M3-N support

[Simon Horman]

On Mon, Feb 26, 2018 at 04:26:43PM +0100, Geert Uytterhoeven wrote:
> Document support for the IIC Bus Interface for DVFS (IIC for DVFS) in
> the Renesas M3-N (r8a77965) SoC.
> 
> No driver update is needed.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

Re: [PATCH] dt-bindings: irqchip: renesas-irqc: Document R-Car M3-N support

[Simon Horman]

On Mon, Feb 26, 2018 at 04:25:12PM +0100, Geert Uytterhoeven wrote:
> Document support for the Interrupt Controller for Externel Devices
> (INTC-EX) in the Renesas M3-N (r8a77965) SoC.
> 
> No driver update is needed.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

[Ulf Hansson]

On 13 February 2018 at 13:33, Simon Horman  wrote:
> Hi,
>
> this patch-set provides SDHI driver support for eMMC HS400.
>
> Based on mmc/next
>
> Dependencies for applying these patches: none
>
> Dependencies to test eMMC HS400:
> * [PATCH] clk: renesas: rcar-gen3: Fix SD divider setting
> * [PATCH v2] arm64: dts: salvator-common: Enable HS400 of SDHI2
>
> To assist testing and review this patch and the above mentioned
> dependencies, which are necessary and sufficient to enable HS400 on H3 /
> Salvator-X, M3-W 1.0 / Salvator-X and H3 ES2.0 Salvator-XS are available
> at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> topic/hs400-v3
>
> Changes since v2:
> * 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()
>
> Changes since v1:
> * Use updated code from BSP v3.6.0
> * Ironed out dependencies, eMMC HS400 is now working on
>   H3 / Salvator-X, M3-W 1.0 / Salvator-X and H3 ES2.0 Salvator-XS.
>
> Masaharu Hayakawa (2):
>   mmc: tmio: add eMMC HS400 mode support
>   mmc: renesas_sdhi: add eMMC HS400 mode support
>
>  drivers/mmc/host/renesas_sdhi_core.c | 133 
> +--
>  drivers/mmc/host/tmio_mmc.h  |   5 ++
>  drivers/mmc/host/tmio_mmc_core.c |  24 ++-
>  3 files changed, 138 insertions(+), 24 deletions(-)
>
> --
> 2.11.0
>

Simon, Wolfram,

Is this ready to be queued up for next? It looks good to me.

Kind regards
Uffe

[PATCH] dmaengine: usb-dmac: add binding for r8a77965

[Yoshihiro Shimoda]

This patch adds binding for r8a77965 (R-Car M3-N).

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt 
b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
index f3d1f15..9dc935e 100644
--- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
+++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
@@ -11,6 +11,7 @@ Required Properties:
  - "renesas,r8a7794-usb-dmac" (R-Car E2)
  - "renesas,r8a7795-usb-dmac" (R-Car H3)
  - "renesas,r8a7796-usb-dmac" (R-Car M3-W)
+ - "renesas,r8a77965-usb-dmac" (R-Car M3-N)
 - reg: base address and length of the registers block for the DMAC
 - interrupts: interrupt specifiers for the DMAC, one for each entry in
   interrupt-names.
-- 
1.9.1

[PATCH 0/2] phy rcar-gen3-usb[23]: Add support for r8a77965

[Yoshihiro Shimoda]

This patch set adds R-Car Gen3 USB 2.0 and 3.0 support for R8A77965.


Yoshihiro Shimoda (2):
  phy: rcar-gen3-usb2: Add support for r8a77965
  phy: rcar-gen3-usb3: Add binding for r8a77965

 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++
 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt | 2 ++
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 4 
 3 files changed, 8 insertions(+)

-- 
1.9.1

[PATCH 2/2] phy: rcar-gen3-usb3: Add binding for r8a77965

[Yoshihiro Shimoda]

This patch adds binding for r8a77965 (R-Car M3-N).

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt
index f94cea4..47dd296 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt
@@ -11,6 +11,8 @@ Required properties:
  SoC.
  "renesas,r8a7796-usb3-phy" if the device is a part of an R8A7796
  SoC.
+ "renesas,r8a77965-usb3-phy" if the device is a part of an
+ R8A77965 SoC.
  "renesas,rcar-gen3-usb3-phy" for a generic R-Car Gen3 compatible
  device.
 
-- 
1.9.1

[PATCH 1/2] phy: rcar-gen3-usb2: Add support for r8a77965

[Yoshihiro Shimoda]

This patch adds support for r8a77965 (R-Car M3-N). This SoC has
dedicated pins.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index 99b651b..dbd137c 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -8,6 +8,8 @@ Required properties:
  SoC.
  "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796
  SoC.
+ "renesas,usb2-phy-r8a77965" if the device is a part of an
+ R8A77965 SoC.
  "renesas,usb2-phy-r8a77995" if the device is a part of an
  R8A77995 SoC.
  "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible 
device.
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 9c90e7d..fb8f05e 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -397,6 +397,10 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void 
*_ch)
.data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
},
{
+   .compatible = "renesas,usb2-phy-r8a77965",
+   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
+   },
+   {
.compatible = "renesas,rcar-gen3-usb2-phy",
},
{ }
-- 
1.9.1

[PATCH 1/5] arm64: dts: renesas: r8a7795: Add multi-cluster definition

[Gaku Inami]

This patch adds the "cpu-map" for multi-cluster into r8a7795
device-tree. This definition is used to parse the cpu topology.

Signed-off-by: Gaku Inami 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index ce85704..ffcc91e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -34,6 +34,38 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_0>;
+   };
+   core1 {
+   cpu = <_1>;
+   };
+   core2 {
+   cpu = <_2>;
+   };
+   core3 {
+   cpu = <_3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_0>;
+   };
+   core1 {
+   cpu = <_1>;
+   };
+   core2 {
+   cpu = <_2>;
+   };
+   core3 {
+   cpu = <_3>;
+   };
+   };
+   };
+
a57_0: cpu@0 {
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x0>;
-- 
2.7.4

[PATCH 3/5] arm64: dts: renesas: r8a7795: Add cpu capacity-dmips-mhz

[Gaku Inami]

Set the capacity-dmips-mhz for r8a7795, that is based on dhrystone.

Expected cpu capacity:
Cortex-A57@1.5GHz: 1024, Cortex-A53@1.2GHz: 411

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

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index ffcc91e..be15864 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -75,6 +75,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <1024>;
#cooling-cells = <2>;
};
 
@@ -87,6 +88,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <1024>;
#cooling-cells = <2>;
};
 
@@ -99,6 +101,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <1024>;
#cooling-cells = <2>;
};
 
@@ -111,6 +114,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <1024>;
#cooling-cells = <2>;
};
 
@@ -123,6 +127,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <411>;
};
 
a53_1: cpu@101 {
@@ -134,6 +139,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <411>;
};
 
a53_2: cpu@102 {
@@ -145,6 +151,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <411>;
};
 
a53_3: cpu@103 {
@@ -156,6 +163,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7795_CLK_Z2>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <411>;
};
 
L2_CA57: cache-controller-0 {
-- 
2.7.4

[PATCH 2/5] arm64: dts: renesas: r8a7796: Add multi-cluster definition

[Gaku Inami]

This patch adds the "cpu-map" for multi-cluster into r8a7796
device-tree. This definition is used to parse the cpu topology.

Signed-off-by: Gaku Inami 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f8e9313..154df9b 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -64,6 +64,32 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_0>;
+   };
+   core1 {
+   cpu = <_1>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_0>;
+   };
+   core1 {
+   cpu = <_1>;
+   };
+   core2 {
+   cpu = <_2>;
+   };
+   core3 {
+   cpu = <_3>;
+   };
+   };
+   };
+
a57_0: cpu@0 {
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x0>;
-- 
2.7.4

[PATCH 4/5] arm64: dts: renesas: r8a7796: Add cpu capacity-dmips-mhz

[Gaku Inami]

Set the capacity-dmips-mhz for r8a7796, that is based on dhrystone.

Expected cpu capacity:
Cortex-A57@1.5Ghz: 1024, Cortex-A53@1.2GHz: 411

Signed-off-by: Gaku Inami 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 154df9b..a776d29 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -99,6 +99,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7796_CLK_Z>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <1024>;
#cooling-cells = <2>;
};
 
@@ -111,6 +112,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7796_CLK_Z>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <1024>;
#cooling-cells = <2>;
};
 
@@ -123,6 +125,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7796_CLK_Z2>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <411>;
};
 
a53_1: cpu@101 {
@@ -134,6 +137,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7796_CLK_Z2>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <411>;
};
 
a53_2: cpu@102 {
@@ -145,6 +149,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7796_CLK_Z2>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <411>;
};
 
a53_3: cpu@103 {
@@ -156,6 +161,7 @@
enable-method = "psci";
clocks =< CPG_CORE R8A7796_CLK_Z2>;
operating-points-v2 = <_opp>;
+   capacity-dmips-mhz = <411>;
};
 
L2_CA57: cache-controller-0 {
-- 
2.7.4

[PATCH 5/5] soc: renesas: rcar-topology: Add support to be aware cpu capacity

[Gaku Inami]

Some R-Car SoCs support big LITTLE architecture produced by ARM, that
have different power/performance characteristics between each CPUs.
In order to aware such as difference, this patch changes the sched
domain flags that the tasks can be scheduled with capacity awareness.
If you use big LITTLE without this patch, the scheduler may make
unintended behaviors.

Signed-off-by: Gaku Inami 
---
 drivers/soc/renesas/Kconfig |  4 
 drivers/soc/renesas/Makefile|  1 +
 drivers/soc/renesas/rcar-topology.c | 36 
 3 files changed, 41 insertions(+)
 create mode 100644 drivers/soc/renesas/rcar-topology.c

diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 6efd7be..296bdee 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -16,6 +16,7 @@ config SOC_RENESAS
select SYSC_R8A7796 if ARCH_R8A7796
select SYSC_R8A77970 if ARCH_R8A77970
select SYSC_R8A77995 if ARCH_R8A77995
+   select RCAR_CPU_TOPOLOGY if ARCH_R8A7795 || ARCH_R8A7796
 
 if SOC_RENESAS
 
@@ -71,4 +72,7 @@ config RST_RCAR
 config SYSC_RCAR
bool "R-Car System Controller support" if COMPILE_TEST
 
+config RCAR_CPU_TOPOLOGY
+   bool "R-Car CPU Topology" if COMPILE_TEST
+
 endif # SOC_RENESAS
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 845d62a..244f243 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_SYSC_R8A77995)   += r8a77995-sysc.o
 # Family
 obj-$(CONFIG_RST_RCAR) += rcar-rst.o
 obj-$(CONFIG_SYSC_RCAR)+= rcar-sysc.o
+obj-$(CONFIG_RCAR_CPU_TOPOLOGY)+= rcar-topology.o
diff --git a/drivers/soc/renesas/rcar-topology.c 
b/drivers/soc/renesas/rcar-topology.c
new file mode 100644
index 000..7e941cf
--- /dev/null
+++ b/drivers/soc/renesas/rcar-topology.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  R-Car CPU topology for ARM big.LITTLE platforms
+ *
+ * Copyright (C) 2018 Renesas Electronics Corporation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int rcar_cpu_cpu_flags(void)
+{
+   return SD_ASYM_CPUCAPACITY;
+}
+
+static struct sched_domain_topology_level rcar_topology[] = {
+#ifdef CONFIG_SCHED_MC
+   { cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(MC) },
+#endif
+   { cpu_cpu_mask, rcar_cpu_cpu_flags, SD_INIT_NAME(DIE) },
+   { NULL, }
+};
+
+static int __init rcar_topology_init(void)
+{
+   if (of_machine_is_compatible("renesas,r8a7795") ||
+   of_machine_is_compatible("renesas,r8a7796"))
+   set_sched_topology(rcar_topology);
+
+   return 0;
+}
+early_initcall(rcar_topology_init);
-- 
2.7.4

Re: [PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure

[Guenter Roeck]

On Mon, Feb 26, 2018 at 10:49:05PM +0100, Wolfram Sang wrote:
> The datasheet says we should stop the timer before changing the clock
> divider. So, let's meet that recommendation.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  drivers/watchdog/renesas_wdt.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index 831ef83f6de15b..c4a17d72d02506 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -74,12 +74,17 @@ static int rwdt_init_timeout(struct watchdog_device *wdev)
>  static int rwdt_start(struct watchdog_device *wdev)
>  {
>   struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
> + u8 val;
>  
>   pm_runtime_get_sync(wdev->parent);
>  
> - rwdt_write(priv, 0, RWTCSRB);
> - rwdt_write(priv, priv->cks, RWTCSRA);

Isn't this done implicitly with the above already ?
After all, priv->cks won't have RWTCSRA_TME set.

The only exception I can think of is if the watchdog is 
already running during boot, but that situation isn't handled
anyway.

Thanks,
Guenter

> + /* Stop the timer before we modify any register */
> + val = readb_relaxed(priv->base + RWTCSRA) & ~RWTCSRA_TME;
> + rwdt_write(priv, val, RWTCSRA);
> +
>   rwdt_init_timeout(wdev);
> + rwdt_write(priv, priv->cks, RWTCSRA);
> + rwdt_write(priv, 0, RWTCSRB);
>  
>   while (readb_relaxed(priv->base + RWTCSRA) & RWTCSRA_WRFLG)
>   cpu_relax();
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure

[Wolfram Sang]

The datasheet says we should stop the timer before changing the clock
divider. So, let's meet that recommendation.

Signed-off-by: Wolfram Sang 
---
 drivers/watchdog/renesas_wdt.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index 831ef83f6de15b..c4a17d72d02506 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -74,12 +74,17 @@ static int rwdt_init_timeout(struct watchdog_device *wdev)
 static int rwdt_start(struct watchdog_device *wdev)
 {
struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
+   u8 val;
 
pm_runtime_get_sync(wdev->parent);
 
-   rwdt_write(priv, 0, RWTCSRB);
-   rwdt_write(priv, priv->cks, RWTCSRA);
+   /* Stop the timer before we modify any register */
+   val = readb_relaxed(priv->base + RWTCSRA) & ~RWTCSRA_TME;
+   rwdt_write(priv, val, RWTCSRA);
+
rwdt_init_timeout(wdev);
+   rwdt_write(priv, priv->cks, RWTCSRA);
+   rwdt_write(priv, 0, RWTCSRB);
 
while (readb_relaxed(priv->base + RWTCSRA) & RWTCSRA_WRFLG)
cpu_relax();
-- 
2.11.0

[PATCH 13/15] v4l: vsp1: Assign BRU and BRS to pipelines dynamically

[Laurent Pinchart]

The VSPDL variant drives two DU channels through two LIF and two
blenders, BRU and BRS. The DU channels thus share the five available
VSPDL inputs and expose them as five KMS planes.

The current implementation assigns the BRS to the second LIF and thus
artificially limits the number of planes for the second display channel
to two at most.

Lift this artificial limitation by assigning the BRU and BRS to the
display pipelines on demand based on the number of planes used by each
pipeline. When a display pipeline needs more than two inputs and the BRU
is already in use by the other pipeline, this requires reconfiguring the
other pipeline to free the BRU before processing, which can result in
frame drop on both pipelines.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 160 +++--
 drivers/media/platform/vsp1/vsp1_drm.h |   9 ++
 2 files changed, 144 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 6c60b72b6f50..87e31ba0ddf5 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -39,7 +39,13 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
 
if (drm_pipe->du_complete)
-   drm_pipe->du_complete(drm_pipe->du_private, completed);
+   drm_pipe->du_complete(drm_pipe->du_private,
+ completed && !notify);
+
+   if (notify) {
+   drm_pipe->force_bru_release = false;
+   wake_up(_pipe->wait_queue);
+   }
 }
 
 /* 
-
@@ -149,6 +155,10 @@ static int vsp1_du_pipeline_setup_rpf(struct vsp1_device 
*vsp1,
 }
 
 /* Setup the BRU source pad. */
+static int vsp1_du_pipeline_setup_input(struct vsp1_device *vsp1,
+   struct vsp1_pipeline *pipe);
+static void vsp1_du_pipeline_configure(struct vsp1_pipeline *pipe);
+
 static int vsp1_du_pipeline_setup_bru(struct vsp1_device *vsp1,
  struct vsp1_pipeline *pipe)
 {
@@ -156,8 +166,93 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
+   struct vsp1_entity *bru;
int ret;
 
+   /*
+* Pick a BRU:
+* - If we need more than two inputs, use the main BRU.
+* - Otherwise, if we are not forced to release our BRU, keep it.
+* - Else, use any free BRU (randomly starting with the main BRU).
+*/
+   if (pipe->num_inputs > 2)
+   bru = >bru->entity;
+   else if (pipe->bru && !drm_pipe->force_bru_release)
+   bru = pipe->bru;
+   else if (!vsp1->bru->entity.pipe)
+   bru = >bru->entity;
+   else
+   bru = >brs->entity;
+
+   /* Switch BRU if needed. */
+   if (bru != pipe->bru) {
+   struct vsp1_entity *released_bru = NULL;
+
+   /* Release our BRU if we have one. */
+   if (pipe->bru) {
+   /*
+* The BRU might be acquired by the other pipeline in
+* the next step. We must thus remove it from the list
+* of entities for this pipeline. The other pipeline's
+* hardware configuration will reconfigure the BRU
+* routing.
+*
+* However, if the other pipeline doesn't acquire our
+* BRU, we need to keep it in the list, otherwise the
+* hardware configuration step won't disconnect it from
+* the pipeline. To solve this, store the released BRU
+* pointer to add it back to the list of entities later
+* if it isn't acquired by the other pipeline.
+*/
+   released_bru = pipe->bru;
+
+   list_del(>bru->list_pipe);
+   pipe->bru->sink = NULL;
+   pipe->bru->pipe = NULL;
+   pipe->bru = NULL;
+   }
+
+   /*
+* If the BRU we need is in use, force the owner pipeline to
+* switch to the other BRU and wait until the switch completes.
+*/
+   if (bru->pipe) {
+   struct vsp1_drm_pipeline *owner_pipe;
+
+   owner_pipe = to_vsp1_drm_pipeline(bru->pipe);
+   owner_pipe->force_bru_release = true;
+
+   vsp1_du_pipeline_setup_input(vsp1, _pipe->pipe);
+   

[PATCH 10/15] v4l: vsp1: Move DRM pipeline output setup code to a function

[Laurent Pinchart]

In order to make the vsp1_du_setup_lif() easier to read, and for
symmetry with the DRM pipeline input setup, move the pipeline output
setup code to a separate function.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 107 +++--
 1 file changed, 61 insertions(+), 46 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 00ce99bd1605..1c8adda47440 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -276,6 +276,66 @@ static int vsp1_du_pipeline_setup_input(struct vsp1_device 
*vsp1,
return 0;
 }
 
+/* Setup the output side of the pipeline (WPF and LIF). */
+static int vsp1_du_pipeline_setup_output(struct vsp1_device *vsp1,
+struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
+   struct v4l2_subdev_format format = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   int ret;
+
+   format.pad = RWPF_PAD_SINK;
+   format.format.width = drm_pipe->width;
+   format.format.height = drm_pipe->height;
+   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
+   format.format.field = V4L2_FIELD_NONE;
+
+   ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on WPF%u sink\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, pipe->output->entity.index);
+
+   format.pad = RWPF_PAD_SOURCE;
+   ret = v4l2_subdev_call(>output->entity.subdev, pad, get_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: got format %ux%u (%x) on WPF%u source\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, pipe->output->entity.index);
+
+   format.pad = LIF_PAD_SINK;
+   ret = v4l2_subdev_call(>lif->subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on LIF%u sink\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, pipe->lif->index);
+
+   /*
+* Verify that the format at the output of the pipeline matches the
+* requested frame size and media bus code.
+*/
+   if (format.format.width != drm_pipe->width ||
+   format.format.height != drm_pipe->height ||
+   format.format.code != MEDIA_BUS_FMT_ARGB_1X32) {
+   dev_dbg(vsp1->dev, "%s: format mismatch on LIF%u\n", __func__,
+   pipe->lif->index);
+   return -EPIPE;
+   }
+
+   return 0;
+}
+
 /* Configure all entities in the pipeline. */
 static void vsp1_du_pipeline_configure(struct vsp1_pipeline *pipe)
 {
@@ -356,7 +416,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
struct vsp1_drm_pipeline *drm_pipe;
struct vsp1_pipeline *pipe;
struct vsp1_bru *bru;
-   struct v4l2_subdev_format format;
unsigned long flags;
unsigned int i;
int ret;
@@ -417,54 +476,10 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
if (ret < 0)
return ret;
 
-   memset(, 0, sizeof(format));
-   format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
-   format.pad = RWPF_PAD_SINK;
-   format.format.width = cfg->width;
-   format.format.height = cfg->height;
-   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
-   format.format.field = V4L2_FIELD_NONE;
-
-   ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
-  );
+   ret = vsp1_du_pipeline_setup_output(vsp1, pipe);
if (ret < 0)
return ret;
 
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on WPF%u sink\n",
-   __func__, format.format.width, format.format.height,
-   format.format.code, pipe->output->entity.index);
-
-   format.pad = RWPF_PAD_SOURCE;
-   ret = v4l2_subdev_call(>output->entity.subdev, pad, get_fmt, NULL,
-  );
-   if (ret < 0)
-   return ret;
-
-   dev_dbg(vsp1->dev, "%s: got format %ux%u (%x) on WPF%u source\n",
-   __func__, format.format.width, format.format.height,
-   format.format.code, pipe->output->entity.index);
-
-   format.pad = LIF_PAD_SINK;
-   ret = v4l2_subdev_call(>lif->subdev, pad, set_fmt, NULL,
-  );
-   if (ret < 0)
-   return ret;
-
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on LIF%u 

[PATCH 07/15] v4l: vsp1: Move DRM atomic commit pipeline setup to separate function

[Laurent Pinchart]

The DRM pipeline setup code used at atomic commit time is similar to the
setup code used when enabling the pipeline. Move it to a separate
function in order to share it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 347 +
 1 file changed, 180 insertions(+), 167 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 9a043a915c0b..7bf697ba7969 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -46,6 +46,185 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
  * Pipeline Configuration
  */
 
+/* Setup one RPF and the connected BRU sink pad. */
+static int vsp1_du_pipeline_setup_rpf(struct vsp1_device *vsp1,
+ struct vsp1_pipeline *pipe,
+ struct vsp1_rwpf *rpf,
+ unsigned int bru_input)
+{
+   struct v4l2_subdev_selection sel;
+   struct v4l2_subdev_format format;
+   const struct v4l2_rect *crop;
+   int ret;
+
+   /*
+* Configure the format on the RPF sink pad and propagate it up to the
+* BRU sink pad.
+*/
+   crop = >drm->inputs[rpf->entity.index].crop;
+
+   memset(, 0, sizeof(format));
+   format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   format.pad = RWPF_PAD_SINK;
+   format.format.width = crop->width + crop->left;
+   format.format.height = crop->height + crop->top;
+   format.format.code = rpf->fmtinfo->mbus;
+   format.format.field = V4L2_FIELD_NONE;
+
+   ret = v4l2_subdev_call(>entity.subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev,
+   "%s: set format %ux%u (%x) on RPF%u sink\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, rpf->entity.index);
+
+   memset(, 0, sizeof(sel));
+   sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   sel.pad = RWPF_PAD_SINK;
+   sel.target = V4L2_SEL_TGT_CROP;
+   sel.r = *crop;
+
+   ret = v4l2_subdev_call(>entity.subdev, pad, set_selection, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev,
+   "%s: set selection (%u,%u)/%ux%u on RPF%u sink\n",
+   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
+   rpf->entity.index);
+
+   /*
+* RPF source, hardcode the format to ARGB to turn on format
+* conversion if needed.
+*/
+   format.pad = RWPF_PAD_SOURCE;
+
+   ret = v4l2_subdev_call(>entity.subdev, pad, get_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev,
+   "%s: got format %ux%u (%x) on RPF%u source\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, rpf->entity.index);
+
+   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
+
+   ret = v4l2_subdev_call(>entity.subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   /* BRU sink, propagate the format from the RPF source. */
+   format.pad = bru_input;
+
+   ret = v4l2_subdev_call(>bru->subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, BRU_NAME(pipe->bru), format.pad);
+
+   sel.pad = bru_input;
+   sel.target = V4L2_SEL_TGT_COMPOSE;
+   sel.r = vsp1->drm->inputs[rpf->entity.index].compose;
+
+   ret = v4l2_subdev_call(>bru->subdev, pad, set_selection, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
+   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
+   BRU_NAME(pipe->bru), sel.pad);
+
+   return 0;
+}
+
+static unsigned int rpf_zpos(struct vsp1_device *vsp1, struct vsp1_rwpf *rpf)
+{
+   return vsp1->drm->inputs[rpf->entity.index].zpos;
+}
+
+/* Setup the input side of the pipeline (RPFs and BRU sink pads). */
+static int vsp1_du_pipeline_setup_input(struct vsp1_device *vsp1,
+   struct vsp1_pipeline *pipe)
+{
+   struct vsp1_rwpf *inputs[VSP1_MAX_RPF] = { NULL, };
+   struct vsp1_bru *bru = to_bru(>bru->subdev);
+   unsigned int i;
+   int ret;
+
+   /* Count the number of enabled inputs and sort them by Z-order. */
+   pipe->num_inputs = 0;
+
+   for (i = 0; i < 

[PATCH 06/15] v4l: vsp1: Share duplicated DRM pipeline configuration code

[Laurent Pinchart]

Move the duplicated DRM pipeline configuration code to a function and
call it from vsp1_du_setup_lif() and vsp1_du_atomic_flush().

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 95 +++---
 1 file changed, 43 insertions(+), 52 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index e210917fdc3f..9a043a915c0b 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -42,6 +42,47 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
drm_pipe->du_complete(drm_pipe->du_private, completed);
 }
 
+/* 
-
+ * Pipeline Configuration
+ */
+
+/* Configure all entities in the pipeline. */
+static void vsp1_du_pipeline_configure(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_entity *entity;
+   struct vsp1_entity *next;
+   struct vsp1_dl_list *dl;
+
+   dl = vsp1_dl_list_get(pipe->output->dlm);
+
+   list_for_each_entry_safe(entity, next, >entities, list_pipe) {
+   /* Disconnect unused RPFs from the pipeline. */
+   if (entity->type == VSP1_ENTITY_RPF &&
+   !pipe->inputs[entity->index]) {
+   vsp1_dl_list_write(dl, entity->route->reg,
+  VI6_DPR_NODE_UNUSED);
+
+   entity->pipe = NULL;
+   list_del(>list_pipe);
+
+   continue;
+   }
+
+   vsp1_entity_route_setup(entity, pipe, dl);
+
+   if (entity->ops->configure) {
+   entity->ops->configure(entity, pipe, dl,
+  VSP1_ENTITY_PARAMS_INIT);
+   entity->ops->configure(entity, pipe, dl,
+  VSP1_ENTITY_PARAMS_RUNTIME);
+   entity->ops->configure(entity, pipe, dl,
+  VSP1_ENTITY_PARAMS_PARTITION);
+   }
+   }
+
+   vsp1_dl_list_commit(dl);
+}
+
 /* 
-
  * DU Driver API
  */
@@ -85,9 +126,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
struct vsp1_drm_pipeline *drm_pipe;
struct vsp1_pipeline *pipe;
struct vsp1_bru *bru;
-   struct vsp1_entity *entity;
-   struct vsp1_entity *next;
-   struct vsp1_dl_list *dl;
struct v4l2_subdev_format format;
unsigned long flags;
unsigned int i;
@@ -239,22 +277,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0);
 
/* Configure all entities in the pipeline. */
-   dl = vsp1_dl_list_get(pipe->output->dlm);
-
-   list_for_each_entry_safe(entity, next, >entities, list_pipe) {
-   vsp1_entity_route_setup(entity, pipe, dl);
-
-   if (entity->ops->configure) {
-   entity->ops->configure(entity, pipe, dl,
-  VSP1_ENTITY_PARAMS_INIT);
-   entity->ops->configure(entity, pipe, dl,
-  VSP1_ENTITY_PARAMS_RUNTIME);
-   entity->ops->configure(entity, pipe, dl,
-  VSP1_ENTITY_PARAMS_PARTITION);
-   }
-   }
-
-   vsp1_dl_list_commit(dl);
+   vsp1_du_pipeline_configure(pipe);
 
/* Start the pipeline. */
spin_lock_irqsave(>irqlock, flags);
@@ -490,15 +513,9 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
struct vsp1_pipeline *pipe = _pipe->pipe;
struct vsp1_rwpf *inputs[VSP1_MAX_RPF] = { NULL, };
struct vsp1_bru *bru = to_bru(>bru->subdev);
-   struct vsp1_entity *entity;
-   struct vsp1_entity *next;
-   struct vsp1_dl_list *dl;
unsigned int i;
int ret;
 
-   /* Prepare the display list. */
-   dl = vsp1_dl_list_get(pipe->output->dlm);
-
/* Count the number of enabled inputs and sort them by Z-order. */
pipe->num_inputs = 0;
 
@@ -557,33 +574,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
__func__, rpf->entity.index);
}
 
-   /* Configure all entities in the pipeline. */
-   list_for_each_entry_safe(entity, next, >entities, list_pipe) {
-   /* Disconnect unused RPFs from the pipeline. */
-   if (entity->type == VSP1_ENTITY_RPF &&
-   !pipe->inputs[entity->index]) {
-   vsp1_dl_list_write(dl, entity->route->reg,
-  VI6_DPR_NODE_UNUSED);
-
-   

[PATCH 14/15] v4l: vsp1: Add BRx dynamic assignment debugging messages

[Laurent Pinchart]

Dynamic assignment of the BRU and BRS to pipelines is prone to
regressions, add messages to make debugging easier. Keep it as a
separate commit to ease removal of those messages once the code will
deem to be completely stable.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 87e31ba0ddf5..521bbc227110 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -190,6 +190,10 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
 
/* Release our BRU if we have one. */
if (pipe->bru) {
+   dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
+   __func__, pipe->lif->index,
+   BRU_NAME(pipe->bru));
+
/*
 * The BRU might be acquired by the other pipeline in
 * the next step. We must thus remove it from the list
@@ -219,6 +223,9 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
if (bru->pipe) {
struct vsp1_drm_pipeline *owner_pipe;
 
+   dev_dbg(vsp1->dev, "%s: pipe %u: waiting for %s\n",
+   __func__, pipe->lif->index, BRU_NAME(bru));
+
owner_pipe = to_vsp1_drm_pipeline(bru->pipe);
owner_pipe->force_bru_release = true;
 
@@ -245,6 +252,9 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
  >entities);
 
/* Add the BRU to the pipeline. */
+   dev_dbg(vsp1->dev, "%s: pipe %u: acquired %s\n",
+   __func__, pipe->lif->index, BRU_NAME(bru));
+
pipe->bru = bru;
pipe->bru->pipe = pipe;
pipe->bru->sink = >output->entity;
@@ -549,6 +559,10 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
drm_pipe->du_complete = NULL;
pipe->num_inputs = 0;
 
+   dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
+   __func__, pipe->lif->index,
+   BRU_NAME(pipe->bru));
+
list_del(>bru->list_pipe);
pipe->bru->pipe = NULL;
pipe->bru = NULL;
-- 
Regards,

Laurent Pinchart

[PATCH 05/15] v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a pipeline

[Laurent Pinchart]

The DRM pipeline handling code uses the entity's pipe list head to check
whether the entity is already included in a pipeline. This method is a
bit fragile in the sense that it uses list_empty() on a list_head that
is a list member. Replace it by a simpler check for the entity pipe
pointer.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a7ad85ab0b08..e210917fdc3f 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -119,9 +119,9 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
 * Remove the RPF from the pipe and the list of BRU
 * inputs.
 */
-   WARN_ON(list_empty(>entity.list_pipe));
+   WARN_ON(!rpf->entity.pipe);
rpf->entity.pipe = NULL;
-   list_del_init(>entity.list_pipe);
+   list_del(>entity.list_pipe);
pipe->inputs[i] = NULL;
 
bru->inputs[rpf->bru_input].rpf = NULL;
@@ -537,7 +537,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
continue;
}
 
-   if (list_empty(>entity.list_pipe)) {
+   if (!rpf->entity.pipe) {
rpf->entity.pipe = pipe;
list_add_tail(>entity.list_pipe, >entities);
}
@@ -566,7 +566,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
   VI6_DPR_NODE_UNUSED);
 
entity->pipe = NULL;
-   list_del_init(>list_pipe);
+   list_del(>list_pipe);
 
continue;
}
-- 
Regards,

Laurent Pinchart

[PATCH 12/15] v4l: vsp1: Generalize detection of entity removal from DRM pipeline

[Laurent Pinchart]

When disabling a DRM plane, the corresponding RPF is only marked as
removed from the pipeline in the atomic update handler, with the actual
removal happening when configuring the pipeline at atomic commit time.
This is required as the RPF has to be disabled in the hardware, which
can't be done from the atomic update handler.

The current implementation is RPF-specific. Make it independent of the
entity type by using the entity's pipe pointer to mark removal from the
pipeline. This will allow using the mechanism to remove BRU instances.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index d705a6e9fa1d..6c60b72b6f50 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -346,13 +346,12 @@ static void vsp1_du_pipeline_configure(struct 
vsp1_pipeline *pipe)
dl = vsp1_dl_list_get(pipe->output->dlm);
 
list_for_each_entry_safe(entity, next, >entities, list_pipe) {
-   /* Disconnect unused RPFs from the pipeline. */
-   if (entity->type == VSP1_ENTITY_RPF &&
-   !pipe->inputs[entity->index]) {
+   /* Disconnect unused entities from the pipeline. */
+   if (!entity->pipe) {
vsp1_dl_list_write(dl, entity->route->reg,
   VI6_DPR_NODE_UNUSED);
 
-   entity->pipe = NULL;
+   entity->sink = NULL;
list_del(>list_pipe);
 
continue;
@@ -569,10 +568,11 @@ int vsp1_du_atomic_update(struct device *dev, unsigned 
int pipe_index,
rpf_index);
 
/*
-* Remove the RPF from the pipe's inputs. The atomic flush
-* handler will disable the input and remove the entity from the
-* pipe's entities list.
+* Remove the RPF from the pipeline's inputs. Keep it in the
+* pipeline's entity list to let vsp1_du_pipeline_configure()
+* remove it from the hardware pipeline.
 */
+   rpf->entity.pipe = NULL;
drm_pipe->pipe.inputs[rpf_index] = NULL;
return 0;
}
-- 
Regards,

Laurent Pinchart

[PATCH 15/15] v4l: vsp1: Rename BRU to BRx

[Laurent Pinchart]

Some VSP instances have two blending units named BRU (Blend/ROP Unit)
and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU
with only two inputs, but otherwise offers similar features and offers
the same register interface. The BRU and BRS can be used exchangeably in
VSP pipelines (provided no more than two inputs are needed).

Due to historical reasons, the VSP1 driver implements support for both
the BRU and BRS through objects named vsp1_bru. The code uses the name
BRU to refer to either the BRU or the BRS, except in a few places where
noted explicitly. This creates confusion.

In an effort to avoid confusion, rename the vsp1_bru object and the
corresponding API to vsp1_brx, and use BRx to refer to blend unit
instances regardless of their type. The names BRU and BRS are retained
where reference to a particular blend unit type is needed, as well as in
hardware registers to stay close to the datasheet.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/Makefile   |   2 +-
 drivers/media/platform/vsp1/vsp1.h |   6 +-
 .../media/platform/vsp1/{vsp1_bru.c => vsp1_brx.c} | 202 ++---
 .../media/platform/vsp1/{vsp1_bru.h => vsp1_brx.h} |  18 +-
 drivers/media/platform/vsp1/vsp1_drm.c | 172 +-
 drivers/media/platform/vsp1/vsp1_drm.h |   6 +-
 drivers/media/platform/vsp1/vsp1_drv.c |   6 +-
 drivers/media/platform/vsp1/vsp1_pipe.c|  12 +-
 drivers/media/platform/vsp1/vsp1_pipe.h|   4 +-
 drivers/media/platform/vsp1/vsp1_rpf.c |  12 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h|   2 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  16 +-
 drivers/media/platform/vsp1/vsp1_wpf.c |   8 +-
 13 files changed, 233 insertions(+), 233 deletions(-)
 rename drivers/media/platform/vsp1/{vsp1_bru.c => vsp1_brx.c} (63%)
 rename drivers/media/platform/vsp1/{vsp1_bru.h => vsp1_brx.h} (66%)

diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index f5cd6f0491cb..596775f932c0 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -3,7 +3,7 @@ vsp1-y  := vsp1_drv.o 
vsp1_entity.o vsp1_pipe.o
 vsp1-y += vsp1_dl.o vsp1_drm.o vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
-vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
+vsp1-y += vsp1_brx.o vsp1_sru.o vsp1_uds.o
 vsp1-y += vsp1_hgo.o vsp1_hgt.o vsp1_histo.o
 vsp1-y += vsp1_lif.o
 
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 78ef838416b3..894cc725c2d4 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -30,7 +30,7 @@ struct rcar_fcp_device;
 struct vsp1_drm;
 struct vsp1_entity;
 struct vsp1_platform_data;
-struct vsp1_bru;
+struct vsp1_brx;
 struct vsp1_clu;
 struct vsp1_hgo;
 struct vsp1_hgt;
@@ -78,8 +78,8 @@ struct vsp1_device {
struct rcar_fcp_device *fcp;
struct device *bus_master;
 
-   struct vsp1_bru *brs;
-   struct vsp1_bru *bru;
+   struct vsp1_brx *brs;
+   struct vsp1_brx *bru;
struct vsp1_clu *clu;
struct vsp1_hgo *hgo;
struct vsp1_hgt *hgt;
diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_brx.c
similarity index 63%
rename from drivers/media/platform/vsp1/vsp1_bru.c
rename to drivers/media/platform/vsp1/vsp1_brx.c
index e8fd2ae3b3eb..b4af1d546022 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_brx.c
@@ -1,5 +1,5 @@
 /*
- * vsp1_bru.c  --  R-Car VSP1 Blend ROP Unit
+ * vsp1_brx.c  --  R-Car VSP1 Blend ROP Unit (BRU and BRS)
  *
  * Copyright (C) 2013 Renesas Corporation
  *
@@ -17,45 +17,45 @@
 #include 
 
 #include "vsp1.h"
-#include "vsp1_bru.h"
+#include "vsp1_brx.h"
 #include "vsp1_dl.h"
 #include "vsp1_pipe.h"
 #include "vsp1_rwpf.h"
 #include "vsp1_video.h"
 
-#define BRU_MIN_SIZE   1U
-#define BRU_MAX_SIZE   8190U
+#define BRX_MIN_SIZE   1U
+#define BRX_MAX_SIZE   8190U
 
 /* 
-
  * Device Access
  */
 
-static inline void vsp1_bru_write(struct vsp1_bru *bru, struct vsp1_dl_list 
*dl,
+static inline void vsp1_brx_write(struct vsp1_brx *brx, struct vsp1_dl_list 
*dl,
  u32 reg, u32 data)
 {
-   vsp1_dl_list_write(dl, bru->base + reg, data);
+   vsp1_dl_list_write(dl, brx->base + reg, data);
 }
 
 /* 

[PATCH 00/15] R-Car VSP1: Dynamically assign blend units to display pipelines

[Laurent Pinchart]

Hello,

On R-Car H3 ES2.0+ and M3-N SoCs, two display pipelines are served by the same
VSP instance (named VSPDL). The VSPDL includes two blending units named BRU
and BRS, unlike the other display-related VSPD that serves a single display
channel with a single blending unit.

The VSPDL has five inputs and can freely assign them at runtime to two display
pipelines, using the BRU and BRS to blend multiple inputs. The BRU supports
blending up to five inputs, while the BRS is limited to two inputs.

Each display pipeline requires a blending unit, and the BRU and BRS are
currently assigned statically to the first and second pipeline respectively.
This artificially limits the number of inputs for the second pipeline to two.
To overcome that limitation, the BRU and BRS need to be dynamically assigned
to the display pipelines, which is what this patch series does.

Patches 01/15 to 10/15 perform small cleanups and refactoring to prepare for
the rest of the series. Patches 11/15 and 12/15 implement new internal
features for the same purpose, and patch 13/15 performs the bulk of the work
by implementing dynamic BRU and BRS assignment to pipelines.

Reassigning the BRU and BRS when two pipelines are running results in flicker
as one pipeline has to first release its blending unit. Synchronization
between the two pipelines also require locking that effectively serializes
page flips for the two pipelines, even when not interacting with each other.
This is currently believed to be unavoidable due to the hardware design, but
please feel free to prove me wrong (ideally with a patch - one can always
dream).

Patch 14/15 then adds messages useful for debugging this new feature. I have
kept it separate from 13/15 to make it easier to remove those messages once
dynamic assignment of blending units will be deemed perfectly stable, but I
won't oppose squashing it with 13/15 if that is preferred.

Patch 15/15 finally rename BRU to BRx to avoid confusion between the BRU terms
that refer to the BRU in particular, and the ones that refer to any of the BRU
or BRS. As this might be a bit controversial I've put the patch last in the
series in case it needs to be dropped.

I have decided to CC the dri-devel mailing list even though the code doesn't
touch the R-Car DU driver and will be merged through the Linux media tree as
the display is involved and the series could benefit from the expertise of the
DRM/KMS community from that point of view.

The patches are based on top of the latest Linux media master branch. For
convenience their are available from

git://linuxtv.org/pinchartl/media.git v4l2/vsp1/bru-brs

The series passes the DU test suite with the new BRx dynamic assignment
test available from

git://git.ideasonboard.com/renesas/kms-tests.git bru-brs

The VSP test suite also runs without any noticed regression.

Laurent Pinchart (15):
  v4l: vsp1: Don't start/stop media pipeline for DRM
  v4l: vsp1: Remove outdated comment
  v4l: vsp1: Remove unused field from vsp1_drm_pipeline structure
  v4l: vsp1: Store pipeline pointer in vsp1_entity
  v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a
pipeline
  v4l: vsp1: Share duplicated DRM pipeline configuration code
  v4l: vsp1: Move DRM atomic commit pipeline setup to separate function
  v4l: vsp1: Setup BRU at atomic commit time
  v4l: vsp1: Replace manual DRM pipeline input setup in
vsp1_du_setup_lif
  v4l: vsp1: Move DRM pipeline output setup code to a function
  v4l: vsp1: Add per-display list completion notification support
  v4l: vsp1: Generalize detection of entity removal from DRM pipeline
  v4l: vsp1: Assign BRU and BRS to pipelines dynamically
  v4l: vsp1: Add BRx dynamic assignment debugging messages
  v4l: vsp1: Rename BRU to BRx

 drivers/media/platform/vsp1/Makefile   |   2 +-
 drivers/media/platform/vsp1/vsp1.h |   6 +-
 .../media/platform/vsp1/{vsp1_bru.c => vsp1_brx.c} | 202 ++---
 .../media/platform/vsp1/{vsp1_bru.h => vsp1_brx.h} |  18 +-
 drivers/media/platform/vsp1/vsp1_dl.c  |  27 +-
 drivers/media/platform/vsp1/vsp1_dl.h  |   4 +-
 drivers/media/platform/vsp1/vsp1_drm.c | 829 -
 drivers/media/platform/vsp1/vsp1_drm.h |  16 +-
 drivers/media/platform/vsp1/vsp1_drv.c |   8 +-
 drivers/media/platform/vsp1/vsp1_entity.h  |   2 +
 drivers/media/platform/vsp1/vsp1_histo.c   |   2 +-
 drivers/media/platform/vsp1/vsp1_histo.h   |   3 -
 drivers/media/platform/vsp1/vsp1_pipe.c|  50 +-
 drivers/media/platform/vsp1/vsp1_pipe.h|   7 +-
 drivers/media/platform/vsp1/vsp1_rpf.c |  12 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h|   4 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  37 +-
 drivers/media/platform/vsp1/vsp1_wpf.c |   8 +-
 18 files changed, 705 insertions(+), 532 deletions(-)
 rename drivers/media/platform/vsp1/{vsp1_bru.c => 

[PATCH 02/15] v4l: vsp1: Remove outdated comment

[Laurent Pinchart]

The entities in the pipeline are all started when the LIF is setup.
Remove the outdated comment that state otherwise.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index e31fb371eaf9..a1f2ba044092 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -221,11 +221,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
return -EPIPE;
}
 
-   /*
-* Enable the VSP1. We don't start the entities themselves right at this
-* point as there's no plane configured yet, so we can't start
-* processing buffers.
-*/
+   /* Enable the VSP1. */
ret = vsp1_device_get(vsp1);
if (ret < 0)
return ret;
-- 
Regards,

Laurent Pinchart

[PATCH 08/15] v4l: vsp1: Setup BRU at atomic commit time

[Laurent Pinchart]

To implement fully dynamic plane assignment to pipelines, we need to
reassign the BRU and BRS to the DRM pipelines in the atomic commit
handler. In preparation for this setup factor out the BRU source pad
code and call it both at LIF setup and atomic commit time.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 56 +-
 drivers/media/platform/vsp1/vsp1_drm.h |  5 +++
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 7bf697ba7969..6ad8aa6c8138 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -148,12 +148,51 @@ static int vsp1_du_pipeline_setup_rpf(struct vsp1_device 
*vsp1,
return 0;
 }
 
+/* Setup the BRU source pad. */
+static int vsp1_du_pipeline_setup_bru(struct vsp1_device *vsp1,
+ struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
+   struct v4l2_subdev_format format = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   int ret;
+
+   /*
+* Configure the format on the BRU source and verify that it matches the
+* requested format. We don't set the media bus code as it is configured
+* on the BRU sink pad 0 and propagated inside the entity, not on the
+* source pad.
+*/
+   format.pad = pipe->bru->source_pad;
+   format.format.width = drm_pipe->width;
+   format.format.height = drm_pipe->height;
+   format.format.field = V4L2_FIELD_NONE;
+
+   ret = v4l2_subdev_call(>bru->subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, BRU_NAME(pipe->bru), pipe->bru->source_pad);
+
+   if (format.format.width != drm_pipe->width ||
+   format.format.height != drm_pipe->height) {
+   dev_dbg(vsp1->dev, "%s: format mismatch\n", __func__);
+   return -EPIPE;
+   }
+
+   return 0;
+}
+
 static unsigned int rpf_zpos(struct vsp1_device *vsp1, struct vsp1_rwpf *rpf)
 {
return vsp1->drm->inputs[rpf->entity.index].zpos;
 }
 
-/* Setup the input side of the pipeline (RPFs and BRU sink pads). */
+/* Setup the input side of the pipeline (RPFs and BRU). */
 static int vsp1_du_pipeline_setup_input(struct vsp1_device *vsp1,
struct vsp1_pipeline *pipe)
 {
@@ -191,6 +230,18 @@ static int vsp1_du_pipeline_setup_input(struct vsp1_device 
*vsp1,
inputs[j] = rpf;
}
 
+   /*
+* Setup the BRU. This must be done before setting up the RPF input
+* pipelines as the BRU sink compose rectangles depend on the BRU source
+* format.
+*/
+   ret = vsp1_du_pipeline_setup_bru(vsp1, pipe);
+   if (ret < 0) {
+   dev_err(vsp1->dev, "%s: failed to setup %s source\n", __func__,
+   BRU_NAME(pipe->bru));
+   return ret;
+   }
+
/* Setup the RPF input pipeline for every enabled input. */
for (i = 0; i < pipe->bru->source_pad; ++i) {
struct vsp1_rwpf *rpf = inputs[i];
@@ -355,6 +406,9 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
return 0;
}
 
+   drm_pipe->width = cfg->width;
+   drm_pipe->height = cfg->height;
+
dev_dbg(vsp1->dev, "%s: configuring LIF%u with format %ux%u\n",
__func__, pipe_index, cfg->width, cfg->height);
 
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 9aa19325cbe9..c8dd75ba01f6 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -20,12 +20,17 @@
 /**
  * vsp1_drm_pipeline - State for the API exposed to the DRM driver
  * @pipe: the VSP1 pipeline used for display
+ * @width: output display width
+ * @height: output display height
  * @du_complete: frame completion callback for the DU driver (optional)
  * @du_private: data to be passed to the du_complete callback
  */
 struct vsp1_drm_pipeline {
struct vsp1_pipeline pipe;
 
+   unsigned int width;
+   unsigned int height;
+
/* Frame synchronisation */
void (*du_complete)(void *, bool);
void *du_private;
-- 
Regards,

Laurent Pinchart

[PATCH 04/15] v4l: vsp1: Store pipeline pointer in vsp1_entity

[Laurent Pinchart]

Various types of objects subclassing vsp1_entity currently store a
pointer to the pipeline. Move the pointer to vsp1_entity to simplify the
code and avoid storing the pipeline in more entity subclasses later.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c| 20 +--
 drivers/media/platform/vsp1/vsp1_drv.c|  2 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  2 ++
 drivers/media/platform/vsp1/vsp1_histo.c  |  2 +-
 drivers/media/platform/vsp1/vsp1_histo.h  |  3 ---
 drivers/media/platform/vsp1/vsp1_pipe.c   | 33 +--
 drivers/media/platform/vsp1/vsp1_rwpf.h   |  2 --
 drivers/media/platform/vsp1/vsp1_video.c  | 17 +++-
 8 files changed, 34 insertions(+), 47 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a267f12f0cc8..a7ad85ab0b08 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -120,6 +120,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
 * inputs.
 */
WARN_ON(list_empty(>entity.list_pipe));
+   rpf->entity.pipe = NULL;
list_del_init(>entity.list_pipe);
pipe->inputs[i] = NULL;
 
@@ -536,8 +537,10 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
continue;
}
 
-   if (list_empty(>entity.list_pipe))
+   if (list_empty(>entity.list_pipe)) {
+   rpf->entity.pipe = pipe;
list_add_tail(>entity.list_pipe, >entities);
+   }
 
bru->inputs[i].rpf = rpf;
rpf->bru_input = i;
@@ -562,6 +565,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
vsp1_dl_list_write(dl, entity->route->reg,
   VI6_DPR_NODE_UNUSED);
 
+   entity->pipe = NULL;
list_del_init(>list_pipe);
 
continue;
@@ -625,24 +629,28 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
 
vsp1_pipeline_init(pipe);
 
+   pipe->frame_end = vsp1_du_pipeline_frame_end;
+
/*
 * The DRM pipeline is static, add entities manually. The first
 * pipeline uses the BRU and the second pipeline the BRS.
 */
pipe->bru = i == 0 ? >bru->entity : >brs->entity;
-   pipe->lif = >lif[i]->entity;
pipe->output = vsp1->wpf[i];
-   pipe->output->pipe = pipe;
-   pipe->frame_end = vsp1_du_pipeline_frame_end;
+   pipe->lif = >lif[i]->entity;
 
+   pipe->bru->pipe = pipe;
pipe->bru->sink = >output->entity;
pipe->bru->sink_pad = 0;
+   list_add_tail(>bru->list_pipe, >entities);
+
+   pipe->output->entity.pipe = pipe;
pipe->output->entity.sink = pipe->lif;
pipe->output->entity.sink_pad = 0;
+   list_add_tail(>output->entity.list_pipe, >entities);
 
-   list_add_tail(>bru->list_pipe, >entities);
+   pipe->lif->pipe = pipe;
list_add_tail(>lif->list_pipe, >entities);
-   list_add_tail(>output->entity.list_pipe, >entities);
}
 
/* Disable all RPFs initially. */
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index eed9516e25e1..58a7993f2306 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -63,7 +63,7 @@ static irqreturn_t vsp1_irq_handler(int irq, void *data)
vsp1_write(vsp1, VI6_WPF_IRQ_STA(i), ~status & mask);
 
if (status & VI6_WFP_IRQ_STA_DFE) {
-   vsp1_pipeline_frame_end(wpf->pipe);
+   vsp1_pipeline_frame_end(wpf->entity.pipe);
ret = IRQ_HANDLED;
}
}
diff --git a/drivers/media/platform/vsp1/vsp1_entity.h 
b/drivers/media/platform/vsp1/vsp1_entity.h
index 408602ebeb97..c26523c56c05 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -106,6 +106,8 @@ struct vsp1_entity {
unsigned int index;
const struct vsp1_route *route;
 
+   struct vsp1_pipeline *pipe;
+
struct list_head list_dev;
struct list_head list_pipe;
 
diff --git a/drivers/media/platform/vsp1/vsp1_histo.c 
b/drivers/media/platform/vsp1/vsp1_histo.c
index afab77cf4fa5..8638ebc514b4 100644
--- a/drivers/media/platform/vsp1/vsp1_histo.c
+++ b/drivers/media/platform/vsp1/vsp1_histo.c
@@ -61,7 +61,7 @@ void vsp1_histogram_buffer_complete(struct vsp1_histogram 

[PATCH 01/15] v4l: vsp1: Don't start/stop media pipeline for DRM

[Laurent Pinchart]

The DRM support code manages a pipeline of VSP entities, each backed by
a media entity. When starting or stopping the pipeline, it starts and
stops the media pipeline through the media API in order to store the
pipeline pointer in every entity.

The driver doesn't use the pipe pointer in media entities, neither does
it rely on the other effects of the media_pipeline_start() and
media_pipeline_stop() functions. Furthermore, as the media links for the
DRM pipeline are never set up correctly, and as the pipeline can be
modified dynamically when enabling or disabling planes, the current
implementation is not correct. Remove the incorrect and unneeded code.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index b8fee1834253..e31fb371eaf9 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -109,8 +109,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
if (ret == -ETIMEDOUT)
dev_err(vsp1->dev, "DRM pipeline stop timeout\n");
 
-   media_pipeline_stop(>output->entity.subdev.entity);
-
for (i = 0; i < ARRAY_SIZE(pipe->inputs); ++i) {
struct vsp1_rwpf *rpf = pipe->inputs[i];
 
@@ -224,11 +222,9 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
}
 
/*
-* Mark the pipeline as streaming and enable the VSP1. This will store
-* the pipeline pointer in all entities, which the s_stream handlers
-* will need. We don't start the entities themselves right at this point
-* as there's no plane configured yet, so we can't start processing
-* buffers.
+* Enable the VSP1. We don't start the entities themselves right at this
+* point as there's no plane configured yet, so we can't start
+* processing buffers.
 */
ret = vsp1_device_get(vsp1);
if (ret < 0)
@@ -241,14 +237,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
drm_pipe->du_complete = cfg->callback;
drm_pipe->du_private = cfg->callback_data;
 
-   ret = media_pipeline_start(>output->entity.subdev.entity,
- >pipe);
-   if (ret < 0) {
-   dev_dbg(vsp1->dev, "%s: pipeline start failed\n", __func__);
-   vsp1_device_put(vsp1);
-   return ret;
-   }
-
/* Disable the display interrupts. */
vsp1_write(vsp1, VI6_DISP_IRQ_STA, 0);
vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0);
-- 
Regards,

Laurent Pinchart

[PATCH 11/15] v4l: vsp1: Add per-display list completion notification support

[Laurent Pinchart]

Display list completion is already reported to the frame end handler,
but that mechanism is global to all display lists. In order to implement
BRU and BRS reassignment in DRM pipelines we will need to wait for
completion of a particular display list. Extend the display list and
frame end handler APIs to support such a notification.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c| 27 +--
 drivers/media/platform/vsp1/vsp1_dl.h|  4 ++--
 drivers/media/platform/vsp1/vsp1_drm.c   |  4 ++--
 drivers/media/platform/vsp1/vsp1_pipe.c  |  5 +++--
 drivers/media/platform/vsp1/vsp1_pipe.h  |  3 ++-
 drivers/media/platform/vsp1/vsp1_video.c |  4 ++--
 6 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 0b86ed01e85d..eb2971218e28 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -72,6 +72,7 @@ struct vsp1_dl_body {
  * @fragments: list of extra display list bodies
  * @has_chain: if true, indicates that there's a partition chain
  * @chain: entry in the display list partition chain
+ * @notify: whether the display list completion should be notified
  */
 struct vsp1_dl_list {
struct list_head list;
@@ -85,6 +86,8 @@ struct vsp1_dl_list {
 
bool has_chain;
struct list_head chain;
+
+   bool notify;
 };
 
 enum vsp1_dl_mode {
@@ -550,8 +553,16 @@ static void vsp1_dl_list_commit_continuous(struct 
vsp1_dl_list *dl)
 * case we can't replace the queued list by the new one, as we could
 * race with the hardware. We thus mark the update as pending, it will
 * be queued up to the hardware by the frame end interrupt handler.
+*
+* If a display list is already pending we simply drop it as the new
+* display list is assumed to contain a more recent configuration. It is
+* an error if the already pending list has the notify flag set, as
+* there is then a process waiting for that list to complete. This
+* shouldn't happen as the waiting process should perform proper
+* locking, but warn just in case.
 */
if (vsp1_dl_list_hw_update_pending(dlm)) {
+   WARN_ON(dlm->pending && dlm->pending->notify);
__vsp1_dl_list_put(dlm->pending);
dlm->pending = dl;
return;
@@ -581,7 +592,7 @@ static void vsp1_dl_list_commit_singleshot(struct 
vsp1_dl_list *dl)
dlm->active = dl;
 }
 
-void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
+void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool notify)
 {
struct vsp1_dl_manager *dlm = dl->dlm;
struct vsp1_dl_list *dl_child;
@@ -598,6 +609,8 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
}
}
 
+   dl->notify = notify;
+
spin_lock_irqsave(>lock, flags);
 
if (dlm->singleshot)
@@ -615,16 +628,23 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
 /**
  * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
  * @dlm: the display list manager
+ * @notify: whether the display list that completed has notification enabled
  *
  * Return true if the previous display list has completed at frame end, or 
false
  * if it has been delayed by one frame because the display list commit raced
  * with the frame end interrupt. The function always returns true in header 
mode
  * as display list processing is then not continuous and races never occur.
+ *
+ * Upon return, the @notify parameter is set to true if the previous display
+ * list has completed and had been queued with the notify flag, or to false
+ * otherwise. Notification is only supported for continuous mode.
  */
-bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm, bool *notify)
 {
bool completed = false;
 
+   *notify = false;
+
spin_lock(>lock);
 
/*
@@ -652,6 +672,9 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 * frame end interrupt. The display list thus becomes active.
 */
if (dlm->queued) {
+   *notify = dlm->queued->notify;
+   dlm->queued->notify = false;
+
__vsp1_dl_list_put(dlm->active);
dlm->active = dlm->queued;
dlm->queued = NULL;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index ee3508172f0a..480c6b0dd2e4 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -27,12 +27,12 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
unsigned int prealloc);
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
-bool 

[PATCH 09/15] v4l: vsp1: Replace manual DRM pipeline input setup in vsp1_du_setup_lif

[Laurent Pinchart]

The vsp1_du_setup_lif() function setups the DRM pipeline input manually.
This duplicates the code from the vsp1_du_pipeline_setup_input()
function. Replace the manual implementation by a call to the function.

As the pipeline has no enabled input in vsp1_du_setup_lif(), the
vsp1_du_pipeline_setup_input() function will not setup any RPF, and will
thus not setup formats on the BRU sink pads. This isn't a problem as all
inputs are disabled, and the BRU sink pads will be reconfigured from the
atomic commit handler when inputs will be enabled.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 40 +-
 1 file changed, 6 insertions(+), 34 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 6ad8aa6c8138..00ce99bd1605 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -412,47 +412,19 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
dev_dbg(vsp1->dev, "%s: configuring LIF%u with format %ux%u\n",
__func__, pipe_index, cfg->width, cfg->height);
 
-   /*
-* Configure the format at the BRU sinks and propagate it through the
-* pipeline.
-*/
+   /* Setup formats through the pipeline. */
+   ret = vsp1_du_pipeline_setup_input(vsp1, pipe);
+   if (ret < 0)
+   return ret;
+
memset(, 0, sizeof(format));
format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
-
-   for (i = 0; i < pipe->bru->source_pad; ++i) {
-   format.pad = i;
-
-   format.format.width = cfg->width;
-   format.format.height = cfg->height;
-   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
-   format.format.field = V4L2_FIELD_NONE;
-
-   ret = v4l2_subdev_call(>bru->subdev, pad,
-  set_fmt, NULL, );
-   if (ret < 0)
-   return ret;
-
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
-   __func__, format.format.width, format.format.height,
-   format.format.code, BRU_NAME(pipe->bru), i);
-   }
-
-   format.pad = pipe->bru->source_pad;
+   format.pad = RWPF_PAD_SINK;
format.format.width = cfg->width;
format.format.height = cfg->height;
format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
format.format.field = V4L2_FIELD_NONE;
 
-   ret = v4l2_subdev_call(>bru->subdev, pad, set_fmt, NULL,
-  );
-   if (ret < 0)
-   return ret;
-
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
-   __func__, format.format.width, format.format.height,
-   format.format.code, BRU_NAME(pipe->bru), i);
-
-   format.pad = RWPF_PAD_SINK;
ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
   );
if (ret < 0)
-- 
Regards,

Laurent Pinchart

[PATCH 03/15] v4l: vsp1: Remove unused field from vsp1_drm_pipeline structure

[Laurent Pinchart]

The vsp1_drm_pipeline enabled field is set but never used. Remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 4 
 drivers/media/platform/vsp1/vsp1_drm.h | 2 --
 2 files changed, 6 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a1f2ba044092..a267f12f0cc8 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -273,10 +273,6 @@ EXPORT_SYMBOL_GPL(vsp1_du_setup_lif);
  */
 void vsp1_du_atomic_begin(struct device *dev, unsigned int pipe_index)
 {
-   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
-   struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
-
-   drm_pipe->enabled = drm_pipe->pipe.num_inputs != 0;
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_begin);
 
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 1cd9db785bf7..9aa19325cbe9 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -20,13 +20,11 @@
 /**
  * vsp1_drm_pipeline - State for the API exposed to the DRM driver
  * @pipe: the VSP1 pipeline used for display
- * @enabled: pipeline state at the beginning of an update
  * @du_complete: frame completion callback for the DU driver (optional)
  * @du_private: data to be passed to the du_complete callback
  */
 struct vsp1_drm_pipeline {
struct vsp1_pipeline pipe;
-   bool enabled;
 
/* Frame synchronisation */
void (*du_complete)(void *, bool);
-- 
Regards,

Laurent Pinchart

[PATCH v2 2/2] arm64: dts: renesas: eagle: add I2C0 support

[Sergei Shtylyov]

Define the Eagle board dependent part of the I2C0 device node.

The I2C0 bus is populated by ON Semiconductor PCA9653 I/O expander and
Analog Devices ADV7511W HDMI transmitter (but we're only describing the
former chip now).

Based on the original (and large) patch by Vladimir Barinov.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 

---
Changes in version 2:
- resolved rejects (with the patch adding EtherAVB pins removed for now).

 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts |   20 
 1 file changed, 20 insertions(+)

Index: renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -54,7 +54,27 @@
clock-frequency = <32768>;
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+   clock-frequency = <40>;
+
+   io_expander: gpio@20 {
+   compatible = "onnn,pca9654";
+   reg = <0x20>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+};
+
  {
+   i2c0_pins: i2c0 {
+   groups = "i2c0";
+   function = "i2c0";
+   };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";

[PATCH v2 1/2] arm64: dts: renesas: r8a77970: add I2C support

[Sergei Shtylyov]

Define the generic R8A77970 parts of the I2C[0-4] device node.

Based on the original (and large) patch by Daisuke Matsushita
.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 

---
Changes in version 2:
- made  use of  the SYSC power domain #define's;
- moved the I2C nodes before HSCIF nodes.

 arch/arm64/boot/dts/renesas/r8a77970.dtsi |   88 ++
 1 file changed, 88 insertions(+)

Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -19,6 +19,14 @@
#address-cells = <2>;
#size-cells = <2>;
 
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
@@ -338,6 +346,86 @@
   <_ds1 22>, <_ds1 23>;
};
 
+   i2c0: i2c@e650 {
+   compatible = "renesas,i2c-r8a77970",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe650 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 931>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 931>;
+   dmas = < 0x91>, < 0x90>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@e6508000 {
+   compatible = "renesas,i2c-r8a77970",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe6508000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 930>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 930>;
+   dmas = < 0x93>, < 0x92>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@e651 {
+   compatible = "renesas,i2c-r8a77970",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe651 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 929>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 929>;
+   dmas = < 0x95>, < 0x94>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@e66d {
+   compatible = "renesas,i2c-r8a77970",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe66d 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 928>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 928>;
+   dmas = < 0x97>, < 0x96>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c4: i2c@e66d8000 {
+   compatible = "renesas,i2c-r8a77970",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe66d8000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 927>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 927>;
+   dmas = < 0x99>, < 0x98>;
+   dma-names = "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
hscif0: serial@e654 {
compatible = "renesas,hscif-r8a77970",
 "renesas,rcar-gen3-hscif",

[PATCH v2 0/2] Add R8A77970/Eagle I2C support

[Sergei Shtylyov]

Hello!

Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180226-v4.16-rc3' tag. We're adding the R8A77970 I2C nodes
and then describing the PCA9654 I/O expander connected to the I2C0 bus.

[1/2] arm64: dts: renesas: r8a77970: add I2C support
[2/2] arm64: dts: renesas: eagle: add I2C0 support

WBR, Sergei

Re: [PATCH] DT: net: renesas,ravb: document R8A77980 bindings

[David Miller]

From: Simon Horman 
Date: Mon, 26 Feb 2018 11:58:24 +0100

> On Sat, Feb 24, 2018 at 09:53:17PM -0500, David Miller wrote:
>> From: Sergei Shtylyov 
>> Date: Sat, 24 Feb 2018 21:01:15 +0300
>> 
>> > On 02/01/2018 11:13 PM, Sergei Shtylyov wrote:
>> > 
>> >> Renesas R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible EtherAVB
>> >> device, so document the SoC specific bindings.
>> >> 
>> >> Signed-off-by: Sergei Shtylyov 
>> >> 
>> >> ---
>> >> The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if 
>> >> it's
>> >> applied to 'net.git' instead. :-)
>> > 
>> >David, I see this patch was marked as "not applicable" in patchwork. 
>> > Why, because
>> > it was posted during the merge window?
>> 
>> No because I thought the relevant architecture tree would take a mere
>> DT update.
> 
> Hi Dave,
> 
> I am happy to take these kinds of changes for the ravb and sh_eth drivers
> if that is your preference. I am also just as happy for you to take them,
> which I think has been the case for similar changes in the past.

No, it's not a problem.  Applied to 'net', thanks.

Re: [PATCH v2 4/5] i2c: rcar: document R8A77995 bindings

[Wolfram Sang]

On Mon, Jan 29, 2018 at 04:45:47PM +0100, Ulrich Hecht wrote:
> R-Car D3 (R8A77995) SoC has a R-Car Gen3-compatible I2C controller.
> 
> Signed-off-by: Ulrich Hecht 
> Reviewed-by: Geert Uytterhoeven 

Fixed $subject according to Rob's request and applied to for-next,
thanks!



signature.asc
Description: PGP signature

Re: [PATCH net-next] sh_eth: fix TSU init on SH7734/R8A7740

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 24 Feb 2018 22:41:45 +0300

> It appears that the single port Ether controllers having TSU (like SH7734/
> R8A7740) need the same kind of treating in sh_eth_tsu_init() as R7S72100
> currently has -- they also don't have the TSU registers related e.g. to
> passing the frames between ports. Add the 'sh_eth_cpu_data::dual_port'
> flag and use it as a new criterion for taking a "short path" in the TSU
> init sequence in order to avoid writing to the non-existant registers...
> 
> Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
> Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740")
> Signed-off-by: Sergei Shtylyov 

Applied with commit messsage spelling problem fixed.

Thanks.

Re: [PATCH net-next] sh_eth: TSU_QTAG0/1 registers the same as TSU_QTAGM0/1

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 24 Feb 2018 20:28:16 +0300

> The TSU_QTAG0/1 registers found in the Gigabit Ether controllers actually
> have the same long name  as the TSU_QTAGM0/1 registers in the early Ether
> controllers:  Qtag Addition/Deletion Set Register (Port 0/1 to 1/0); thus
> there's no need to make a difference in sh_eth_tsu_init() between those
> controllers. Unfortunately, we can't just remove TSU_QTAG0/1 from the
> register *enum* because that would break the ethtool register dump...
> 
> Fixes: b0ca2a21f769 ("sh_eth: Add support of SH7763 to sh_eth")
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH 0/8] R-Car M3-N: Enable EtherAVB device node

[Geert Uytterhoeven]

Hi Jacopo,

On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi  wrote:
>   as discussed with you Sergei and Geert, in order to enable EtherAVB for
> R8A77965 we first wanted to make the phy-mode "rgmii-txid" a board specific
> property for all other SoCs.

Thanks for your series!

> This series adds  the phy-mode property to salvator-common.dtsi and reset the
> one for R8A77965/R8A7796/R8A77995 to "rgmii".

I forgot that r8a7795.dtsi and r8a7796.dtsi are used for the ULCB boards, too.
So to avoid regressions, you need to make a similar change to ulcb.dtsi like you
made for salvator-common.dtsi.

In addition, r8a77995.dtsi is only used for the Draak board.
So you have to update r8a7795-draak.dtsi first, too.

> Then, in order to enable EtherAVB for R-Car M3-N, iommu nodes had to be added
> as they are referenced by the "avb" device node (CC the iommu list for the
> series for that reason).

I don't think we need the iommu properties and nodes at this early stage.
Ethernet works fine without them. Simon, do you agree?

P.S. scripts/dtc/dtx_diff is a great tool to compare DTBs before and after your
  changes. It would have revealed the changes for ULCB and Draak.

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 8/8] arm64: dts: renesas: r8a77965: Add EtherAVB device node

[Geert Uytterhoeven]

Hi Jacopo,

On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi  wrote:
> Populate the ethernet@e680 device node to enable Ethernet interface
> for R-Car M3-N (R8A77965) SoC.
>
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
>
> ---
> v1 -> v2:
> - Replace ALWAYS_ON power area identifier with numeric constant

And you added the iommus property, which I wouldn't bother doing at this
early stage.

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 6/8] iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code

[Geert Uytterhoeven]

On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi  wrote:
> Add support for R-Car M3-N (R8A77965) SoC IPMMUs.
>
> Signed-off-by: Jacopo Mondi 

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 5/8] dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965)

[Geert Uytterhoeven]

On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi  wrote:
> Add Renesas R-Car M3-N (R8A77965) compat string to IPMMU DT bindings
> documentation.
>
> Signed-off-by: Jacopo Mondi 

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 4/8] arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"

[Geert Uytterhoeven]

On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi  wrote:
> Set the "phy-mode" property of EtherAVB device to "rgmii" and let board
> files override it if the installed PHY layer provides delays for the
> RX/TX channels.
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

But you need a patch to update r8a7795-draak.dtsi first.

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/8] arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"

[Geert Uytterhoeven]

On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi  wrote:
> Set the "phy-mode" property of EtherAVB device to "rgmii" and let board
> files override it if the installed PHY layer provides delays for the
> RX/TX channels.
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

But you need a patch to update ulcb.dtsi first.

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 3/8] arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"

[Geert Uytterhoeven]

On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi  wrote:
> Set the "phy-mode" property of EtherAVB device to "rgmii" and let board
> files override it if the installed PHY layer provides delays for the
> RX/TX channels.
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

But you need a patch to update ulcb.dtsi first.

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 1/8] arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode

[Geert Uytterhoeven]

On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi  wrote:
> As the PHY interface installed on the Salvator-X[S] board, provides TX
> channel delay, make the "phy-mode" property a board-specific one, meant
> to override the one specified in the SoC DTSI.
>
> Follow up patches will reset the SoC DTSI to use "rgmii" mode and let
> the board file override that.
>
> Signed-off-by: Jacopo Mondi 

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] media: platform: Drop OF dependency of VIDEO_RENESAS_VSP1

[Geert Uytterhoeven]

VIDEO_RENESAS_VSP1 depends on ARCH_RENESAS && OF.
As ARCH_RENESAS implies OF, the latter can be dropped.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 614fbef08ddcabb0..2b8b1ad0edd9eb31 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -448,7 +448,7 @@ config VIDEO_RENESAS_FCP
 config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
-   depends on (ARCH_RENESAS && OF) || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
-- 
2.7.4

[PATCH 1/4] dt-bindings: arm: Document SoC compatible value for Armadillo-800 EVA

[Geert Uytterhoeven]

The compatible property of the root node in a DTS for Atmark Techno
Armadillo-800 EVA should include the compatible value for the R-Mobile
A1 SoC, too.

Fixes: d2c2a0776899ba2d ("ARM: shmobile: Add platform device tree bindings 
documentation")
Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 63edc11e83ef287f..ded2cd3b5f4df0c8 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -56,7 +56,7 @@ Boards:
   - APE6-EVM
 compatible = "renesas,ape6evm", "renesas,r8a73a4"
   - Atmark Techno Armadillo-800 EVA
-compatible = "renesas,armadillo800eva"
+compatible = "renesas,armadillo800eva", "renesas,r8a7740"
   - Blanche (RTP0RC7792SEB00010S)
 compatible = "renesas,blanche", "renesas,r8a7792"
   - BOCK-W
-- 
2.7.4

[PATCH 4/4] dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-XS board

[Geert Uytterhoeven]

The Renesas Salvator-XS development board can be equipped with an R-Car
H3, M3-W, or M3-N SiP, which are pin-compatible.

Document board part number and compatible values for the version with
R-Car M3-N.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 51e4428856be4557..303f04e639431837 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -114,6 +114,8 @@ Boards:
 compatible = "renesas,salvator-xs", "renesas,r8a7795"
   - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
 compatible = "renesas,salvator-xs", "renesas,r8a7796"
+  - Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S)
+compatible = "renesas,salvator-xs", "renesas,r8a77965"
   - SILK (RTP0RC7794LCB00011S)
 compatible = "renesas,silk", "renesas,r8a7794"
   - SK-RZG1E (YR8A77450S000BE)
-- 
2.7.4

[PATCH 2/4] dt-bindings: arm: Document Renesas V3MSK and Wheat board part numbers

[Geert Uytterhoeven]

The DT binding documentation for the Renesas V3MSK and Wheat boards
lacked board part numbers.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index ded2cd3b5f4df0c8..82908a9447e4b051 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -120,9 +120,9 @@ Boards:
 compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
   - Stout (ADAS Starterkit, Y-R-CAR-ADAS-SKH2-BOARD)
 compatible = "renesas,stout", "renesas,r8a7790"
-  - V3MSK
+  - V3MSK (Y-ASK-RCAR-V3M-WS10)
 compatible = "renesas,v3msk", "renesas,r8a77970"
-  - Wheat
+  - Wheat (RTP0RC7792ASKB0010JE)
 compatible = "renesas,wheat", "renesas,r8a7792"
 
 
-- 
2.7.4

[PATCH 0/4] dt-bindings: arm: Improve Renesas Board Documentation

[Geert Uytterhoeven]

Hi Simon, Magnus,

This patch series improves the DT binding documentation for Renesas
boards.

Thanks!

Geert Uytterhoeven (4):
  dt-bindings: arm: Document SoC compatible value for Armadillo-800 EVA
  dt-bindings: arm: Document Renesas V3MSK and Wheat board part numbers
  dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-X board
  dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-XS board

 Documentation/devicetree/bindings/arm/shmobile.txt | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

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

[PATCH 3/4] dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-X board

[Geert Uytterhoeven]

The Renesas Salvator-X development board can be equipped with an R-Car
H3, M3-W, or M3-N SiP, which are pin-compatible.

Document board part number and compatible values for the version with
R-Car M3-N.

The board part number was extracted from a big patch by Takeshi Kihara
in the BSP.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 82908a9447e4b051..51e4428856be4557 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -108,6 +108,8 @@ Boards:
 compatible = "renesas,salvator-x", "renesas,r8a7795"
   - Salvator-X (RTP0RC7796SIPB0011S)
 compatible = "renesas,salvator-x", "renesas,r8a7796"
+  - Salvator-X (RTP0RC7796SIPB0011S (M3N))
+compatible = "renesas,salvator-x", "renesas,r8a77965"
   - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
 compatible = "renesas,salvator-xs", "renesas,r8a7795"
   - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
-- 
2.7.4

[PATCH 1/8] arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode

[Jacopo Mondi]

As the PHY interface installed on the Salvator-X[S] board, provides TX
channel delay, make the "phy-mode" property a board-specific one, meant
to override the one specified in the SoC DTSI.

Follow up patches will reset the SoC DTSI to use "rgmii" mode and let
the board file override that.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 8e8ec30..c725f9b 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -279,6 +279,7 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
phy-handle = <>;
+   phy-mode = "rgmii-txid";
status = "okay";
 
phy0: ethernet-phy@0 {
-- 
2.7.4

[PATCH 2/8] arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"

[Jacopo Mondi]

Set the "phy-mode" property of EtherAVB device to "rgmii" and let board
files override it if the installed PHY layer provides delays for the
RX/TX channels.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 6075511..a99b0b2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -974,7 +974,7 @@
clocks = < CPG_MOD 812>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
resets = < 812>;
-   phy-mode = "rgmii-txid";
+   phy-mode = "rgmii";
iommus = <_ds0 16>;
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.4

[PATCH 3/8] arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"

[Jacopo Mondi]

Set the "phy-mode" property of EtherAVB device to "rgmii" and let board
files override it if the installed PHY layer provides delays for the
RX/TX channels.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1f32340..87327eb 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -873,7 +873,7 @@
clocks = < CPG_MOD 812>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 812>;
-   phy-mode = "rgmii-txid";
+   phy-mode = "rgmii";
iommus = <_ds0 16>;
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.4

[PATCH 4/8] arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"

[Jacopo Mondi]

Set the "phy-mode" property of EtherAVB device to "rgmii" and let board
files override it if the installed PHY layer provides delays for the
RX/TX channels.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index cd3c6a3..fc48677 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -512,7 +512,7 @@
clocks = < CPG_MOD 812>;
power-domains = < R8A77995_PD_ALWAYS_ON>;
resets = < 812>;
-   phy-mode = "rgmii-txid";
+   phy-mode = "rgmii";
iommus = <_ds0 16>;
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.4

[PATCH 5/8] dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965)

[Jacopo Mondi]

Add Renesas R-Car M3-N (R8A77965) compat string to IPMMU DT bindings
documentation.

Signed-off-by: Jacopo Mondi 
---
 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
index 1fd5d69..0143fd4 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
@@ -17,6 +17,7 @@ Required Properties:
 - "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
 - "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
 - "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU.
+- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU.
 - "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU.
 - "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU.
 - "renesas,ipmmu-vmsa" for generic R-Car Gen2 VMSA-compatible IPMMU.
-- 
2.7.4

[PATCH 6/8] iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code

[Jacopo Mondi]

Add support for R-Car M3-N (R8A77965) SoC IPMMUs.

Signed-off-by: Jacopo Mondi 
---
 drivers/iommu/ipmmu-vmsa.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 933a3da..6a0e714 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -763,6 +763,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
 static const struct soc_device_attribute soc_rcar_gen3[] = {
{ .soc_id = "r8a7795", },
{ .soc_id = "r8a7796", },
+   { .soc_id = "r8a77965", },
{ .soc_id = "r8a77970", },
{ .soc_id = "r8a77995", },
{ /* sentinel */ }
@@ -945,6 +946,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
.compatible = "renesas,ipmmu-r8a7796",
.data = _features_rcar_gen3,
}, {
+   .compatible = "renesas,ipmmu-r8a77965",
+   .data = _features_rcar_gen3,
+   }, {
.compatible = "renesas,ipmmu-r8a77970",
.data = _features_rcar_gen3,
}, {
@@ -1127,6 +1131,7 @@ module_exit(ipmmu_exit);
 IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
 IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
 IOMMU_OF_DECLARE(ipmmu_r8a7796_iommu_of, "renesas,ipmmu-r8a7796");
+IOMMU_OF_DECLARE(ipmmu_r8a77965_iommu_of, "renesas,ipmmu-r8a77965");
 IOMMU_OF_DECLARE(ipmmu_r8a77970_iommu_of, "renesas,ipmmu-r8a77970");
 IOMMU_OF_DECLARE(ipmmu_r8a77995_iommu_of, "renesas,ipmmu-r8a77995");
 
-- 
2.7.4

[PATCH 7/8] arm64: dts: renesas: r8a77965: Add IPMMU mm and ds0 blocks

[Jacopo Mondi]

Add IPMMU device nodes for mm and ds0 domains. "ipmmu_ds0" is a
dependency for EtherAVB enablement and it has "ipmmu_mm" as it main
ipmmu.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 8c9648a..b3c0be8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -169,6 +169,23 @@
reg = <0 0xe606 0 0x50c>;
};
 
+   ipmmu_ds0: mmu@e674 {
+   compatible = "renesas,ipmmu-r8a77965";
+   reg = <0 0xe674 0 0x1000>;
+   renesas,ipmmu-main = <_mm 0>;
+   power-domains = < 32>;
+   #iommu-cells = <1>;
+   };
+
+   ipmmu_mm: mmu@e67b {
+   compatible = "renesas,ipmmu-r8a77965";
+   reg = <0 0xe67b 0 0x1000>;
+   interrupts = ,
+;
+   power-domains = < 32>;
+   #iommu-cells = <1>;
+   };
+
cpg: clock-controller@e615 {
compatible = "renesas,r8a77965-cpg-mssr";
reg = <0 0xe615 0 0x1000>;
-- 
2.7.4

[PATCH 8/8] arm64: dts: renesas: r8a77965: Add EtherAVB device node

[Jacopo Mondi]

Populate the ethernet@e680 device node to enable Ethernet interface
for R-Car M3-N (R8A77965) SoC.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 

---
v1 -> v2:
- Replace ALWAYS_ON power area identifier with numeric constant
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 44 ---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index b3c0be8..37aac63 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -539,11 +539,49 @@
};
 
avb: ethernet@e680 {
+   compatible = "renesas,etheravb-r8a77965",
+"renesas,etheravb-rcar-gen3";
+   reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   interrupt-names = "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14", "ch15",
+ "ch16", "ch17", "ch18", "ch19",
+ "ch20", "ch21", "ch22", "ch23",
+ "ch24";
+   clocks = < CPG_MOD 812>;
+   power-domains = < 32>;
+   resets = < 812>;
+   phy-mode = "rgmii";
+   iommus = <_ds0 16>;
#address-cells = <1>;
#size-cells = <0>;
-
-   reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
-   /* placeholder */
+   status = "disabled";
};
 
csi20: csi2@fea8 {
-- 
2.7.4

[PATCH 0/8] R-Car M3-N: Enable EtherAVB device node

[Jacopo Mondi]

Hi Simon,
  as discussed with you Sergei and Geert, in order to enable EtherAVB for
R8A77965 we first wanted to make the phy-mode "rgmii-txid" a board specific
property for all other SoCs.

This series adds  the phy-mode property to salvator-common.dtsi and reset the
one for R8A77965/R8A7796/R8A77995 to "rgmii".

Then, in order to enable EtherAVB for R-Car M3-N, iommu nodes had to be added
as they are referenced by the "avb" device node (CC the iommu list for the
series for that reason).

Series based on what you already applied to your development tree (M3-N initial
support - EtherAVB + DTS fixes). A branch for testing is available at

git://jmondi.org/linux m3-n/renesas-drivers-2018-02-13-v4.16-rc1/v2-simon

Thanks
   j

Jacopo Mondi (8):
  arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode
  arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"
  arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"
  arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"
  dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965)
  iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code
  arm64: dts: renesas: r8a77965: Add IPMMU mm and ds0 blocks
  arm64: dts: renesas: r8a77965: Add EtherAVB device node

 .../bindings/iommu/renesas,ipmmu-vmsa.txt  |  1 +
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  2 +-
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  2 +-
 arch/arm64/boot/dts/renesas/r8a77965.dtsi  | 61 --
 arch/arm64/boot/dts/renesas/r8a77995.dtsi  |  2 +-
 arch/arm64/boot/dts/renesas/salvator-common.dtsi   |  1 +
 drivers/iommu/ipmmu-vmsa.c |  5 ++
 7 files changed, 68 insertions(+), 6 deletions(-)

--
2.7.4

Re: [PATCH 2/2] pinctrl: sh-pfc: add R8A77980 PFC support

[Sergei Shtylyov]

Hello!

On 02/26/2018 03:42 PM, Geert Uytterhoeven wrote:

>> Add the PFC support for the R8A77980 SoC including pin groups for some
>> on-chip devices such as AVB, CAN-FD, GETHER, [H]SCIF, I2C, INTC-EX, MMC,
>> MSIOF, PWM, and VIN...
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov 
>> Signed-off-by: Sergei Shtylyov 
> 
> Thanks for your patch!
> 
> To avoid scaring off potential reviewers, it may be better to not include that
> many pin groups and functions in future initial submissions.
> This also helps if issues are detected during review in some of them (like
> below), delaying queuing of basic functionality and other correct parts.
> 
> I only looked at CPU_ALL_PORT(), pins, groups, and functions.
> Comments below.
> 
>> --- /dev/null
>> +++ renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77980.c
> 
>> +/* - AVB 
>>  */
>> +static const unsigned int avb_link_pins[] = {
>> +   /* AVB_LINK */
>> +   RCAR_GP_PIN(1, 18),
>> +};
>> +static const unsigned int avb_link_mux[] = {
>> +   AVB_LINK_MARK,
>> +};
>> +static const unsigned int avb_magic_pins[] = {
>> +   /* AVB_MAGIC */
>> +   RCAR_GP_PIN(1, 16),
>> +};
>> +static const unsigned int avb_magic_mux[] = {
>> +   AVB_MAGIC_MARK,
>> +};
>> +static const unsigned int avb_phy_int_pins[] = {
>> +   /* AVB_PHY_INT */
>> +   RCAR_GP_PIN(1, 17),
>> +};
>> +static const unsigned int avb_phy_int_mux[] = {
>> +   AVB_PHY_INT_MARK,
>> +};
>> +static const unsigned int avb_mdio_pins[] = {
>> +   /* AVB_MDC, AVB_MDIO */
>> +   RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14),
>> +};
>> +static const unsigned int avb_mdio_mux[] = {
>> +   AVB_MDC_MARK, AVB_MDIO_MARK,
>> +};
> 
> The grouping is different from other R-Car Gen3 SoCs.

   Not true AFAICS -- only the group naming is different.

>> +/* - CANFD0 
>> - */
>> +static const unsigned int canfd0_data_a_pins[] = {
>> +   /* CANFD0_TX, CANFD0_RX */
>> +   RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
>> +};
>> +static const unsigned int canfd0_data_a_mux[] = {
>> +   CANFD0_TX_A_MARK, CANFD0_RX_A_MARK,
>> +};
>> +static const unsigned int canfd_clk_a_pins[] = {
>> +   /* CANFD_CLK */
>> +   RCAR_GP_PIN(1, 25),
>> +};
>> +static const unsigned int canfd_clk_a_mux[] = {
>> +   CANFD_CLK_A_MARK,
>> +};
>> +static const unsigned int canfd0_data_b_pins[] = {
>> +   /* CANFD0_TX, CANFD0_RX */
>> +   RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
>> +};
>> +static const unsigned int canfd0_data_b_mux[] = {
>> +   CANFD0_TX_B_MARK, CANFD0_RX_B_MARK,
>> +};
>> +static const unsigned int canfd_clk_b_pins[] = {
>> +   /* CANFD_CLK */
>> +   RCAR_GP_PIN(3, 8),
>> +};
>> +static const unsigned int canfd_clk_b_mux[] = {
>> +   CANFD_CLK_B_MARK,
>> +};
> 
> Please move the canfd_clk pins to their own section.

   Are you aware the CANFD_CLK is controlled by MOD_SEL0.SEL_CANFD0? If it's 
allowed
to have the pins controlled by a single MOD_SEL field in the diff groups, I'll 
place
CANFD_CLK into a separate group...

> Note that they are called can_clk in the pin function sheet, but the
> PFC section uses both can_clk and canfd_clk.
> Given V3H (like V3M) has no plain CAN, only CANFD, using canfd_clk
> sounds right to me, though.
> 
>> +/* - DU 
>> - */
>> +static const unsigned int du_rgb666_pins[] = {
>> +   /* DU_R[7:2], DU_G[7:2], DU_B[7:2] */
>> +   RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 3),
>> +   RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 1), RCAR_GP_PIN(0, 0),
>> +   RCAR_GP_PIN(0, 11), RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 9),
>> +   RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 7), RCAR_GP_PIN(0, 6),
>> +   RCAR_GP_PIN(0, 17), RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 15),
>> +   RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 13), RCAR_GP_PIN(0, 12),
>> +};
>> +static const unsigned int du_rgb666_mux[] = {
>> +   DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK,
>> +   DU_DR4_MARK, DU_DR3_MARK, DU_DR2_MARK,
>> +   DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK,
>> +   DU_DG4_MARK, DU_DG3_MARK, DU_DG2_MARK,
>> +   DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK,
>> +   DU_DB4_MARK, DU_DB3_MARK, DU_DB2_MARK,
>> +};
> 
> du_rgb888 is missing (see GP2_19..GP2_24).

   OK, seeing...

>> +/* - HSCIF0 
>> - */
> 
>> +static const unsigned int scif_clk_a_pins[] = {
>> +   /* SCIF_CLK */
>> +   RCAR_GP_PIN(0, 10),
>> +};
>> +static const unsigned int scif_clk_a_mux[] = {
>> +   SCIF_CLK_A_MARK,
>> +};
> 
> 
> [...]
> 
>> +static const unsigned int scif_clk_b_pins[] = {
>> +   /* SCIF_CLK */
>> +   RCAR_GP_PIN(1, 25),
>> +};
>> +static const unsigned int 

Re: [PATCHv2 6/8] arm_pmu: explicitly enable/disable SPIs at hotplug

[Mark Rutland]

On Mon, Feb 26, 2018 at 03:22:53PM +, Will Deacon wrote:
> On Mon, Feb 26, 2018 at 04:16:19PM +0100, Geert Uytterhoeven wrote:
> > On Mon, Feb 5, 2018 at 5:42 PM, Mark Rutland  wrote:
> > > To support ACPI systems, we need to request IRQs before CPUs are
> > > hotplugged, and thus we need to request IRQs before we know their
> > > associated PMU.
> > >
> > > This is problematic if a PMU IRQ is pending out of reset, as it may be
> > > taken before we know the PMU, and thus the IRQ handler won't be able to
> > > handle it, leaving it screaming.
> > >
> > > To avoid such problems, lets request all IRQs in a disabled state, and
> > > explicitly enable/disable them at hotplug time, when we're sure the PMU
> > > has been probed.
> > >
> > > Signed-off-by: Mark Rutland 
> > 
> > This is now commit 6de3f79112cc26bf in v4.16-rc3, and causes a BUG during
> > CPU offlining (e.g. during system suspend, or during boot with
> > CONFIG_ARM_PSCI_CHECKER=y).
> > 
> > With CONFIG_ARM_PSCI_CHECKER=y:
> > 
> > psci_checker: PSCI checker started using 6 CPUs
> > psci_checker: Starting hotplug tests
> > psci_checker: Trying to turn off and on again all CPUs
> > BUG: sleeping function called from invalid context at 
> > kernel/irq/manage.c:112
> > in_atomic(): 1, irqs_disabled(): 128, pid: 15, name: migration/1
> > no locks held by migration/1/15.
> > irq event stamp: 192
> > hardirqs last  enabled at (191): [<803c2507>]
> > _raw_spin_unlock_irq+0x2c/0x4c
> > hardirqs last disabled at (192): [<7f57ad28>] 
> > multi_cpu_stop+0x9c/0x140
> > softirqs last  enabled at (0): [<04ee1b58>]
> > copy_process.isra.77.part.78+0x43c/0x1504
> > softirqs last disabled at (0): [<  (null)>]   (null)
> > CPU: 1 PID: 15 Comm: migration/1 Not tainted 4.16.0-rc3-salvator-x #1651
> > Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
> > Call trace:
> >  dump_backtrace+0x0/0x140
> >  show_stack+0x14/0x1c
> >  dump_stack+0xb4/0xf0
> >  ___might_sleep+0x1fc/0x218
> >  __might_sleep+0x70/0x80
> >  synchronize_irq+0x40/0xa8
> >  disable_irq+0x20/0x2c
> 
> Given that these things are CPU-affine, I reckon this should be
> disable_irq_nosync. Mark?

Given IRQs are disabled, this should be fine, yes.

FWIW, if you spin this as a patch:

Acked-by: Mark Rutland 

Mark.

> 
> Will
> 
> --->8
> 
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 0c2ed11c0603..f63db346c219 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -638,7 +638,7 @@ static int arm_perf_teardown_cpu(unsigned int cpu, struct 
> hlist_node *node)
>   if (irq_is_percpu_devid(irq))
>   disable_percpu_irq(irq);
>   else
> - disable_irq(irq);
> + disable_irq_nosync(irq);
>   }
>  
>   per_cpu(cpu_armpmu, cpu) = NULL;

Re: [PATCH net-next] sh_eth: fix TSU init on SH7734/R8A7740

[Sergei Shtylyov]

On 02/24/2018 10:41 PM, Sergei Shtylyov wrote:

> It appears that the single port Ether controllers having TSU (like SH7734/
> R8A7740) need the same kind of treating in sh_eth_tsu_init() as R7S72100
> currently has -- they also don't have the TSU registers related e.g. to
> passing the frames between ports. Add the 'sh_eth_cpu_data::dual_port'
> flag and use it as a new criterion for taking a "short path" in the TSU
> init sequence in order to avoid writing to the non-existant registers...

   Spell checker tells it should have been "non-existent" -- would it be 
possible
to fix while merging?

> Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
> Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740")
> Signed-off-by: Sergei Shtylyov 
[...]

MBR, Sergei

Re: [PATCHv2 6/8] arm_pmu: explicitly enable/disable SPIs at hotplug

[Geert Uytterhoeven]

Hi Will,

On Mon, Feb 26, 2018 at 4:22 PM, Will Deacon  wrote:
> On Mon, Feb 26, 2018 at 04:16:19PM +0100, Geert Uytterhoeven wrote:
>> On Mon, Feb 5, 2018 at 5:42 PM, Mark Rutland  wrote:
>> > To support ACPI systems, we need to request IRQs before CPUs are
>> > hotplugged, and thus we need to request IRQs before we know their
>> > associated PMU.
>> >
>> > This is problematic if a PMU IRQ is pending out of reset, as it may be
>> > taken before we know the PMU, and thus the IRQ handler won't be able to
>> > handle it, leaving it screaming.
>> >
>> > To avoid such problems, lets request all IRQs in a disabled state, and
>> > explicitly enable/disable them at hotplug time, when we're sure the PMU
>> > has been probed.
>> >
>> > Signed-off-by: Mark Rutland 
>>
>> This is now commit 6de3f79112cc26bf in v4.16-rc3, and causes a BUG during
>> CPU offlining (e.g. during system suspend, or during boot with
>> CONFIG_ARM_PSCI_CHECKER=y).
>>
>> With CONFIG_ARM_PSCI_CHECKER=y:
>>
>> psci_checker: PSCI checker started using 6 CPUs
>> psci_checker: Starting hotplug tests
>> psci_checker: Trying to turn off and on again all CPUs
>> BUG: sleeping function called from invalid context at kernel/irq/manage.c:112
>> in_atomic(): 1, irqs_disabled(): 128, pid: 15, name: migration/1
>> no locks held by migration/1/15.
>> irq event stamp: 192
>> hardirqs last  enabled at (191): [<803c2507>]
>> _raw_spin_unlock_irq+0x2c/0x4c
>> hardirqs last disabled at (192): [<7f57ad28>] 
>> multi_cpu_stop+0x9c/0x140
>> softirqs last  enabled at (0): [<04ee1b58>]
>> copy_process.isra.77.part.78+0x43c/0x1504
>> softirqs last disabled at (0): [<  (null)>]   (null)
>> CPU: 1 PID: 15 Comm: migration/1 Not tainted 4.16.0-rc3-salvator-x #1651
>> Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
>> Call trace:
>>  dump_backtrace+0x0/0x140
>>  show_stack+0x14/0x1c
>>  dump_stack+0xb4/0xf0
>>  ___might_sleep+0x1fc/0x218
>>  __might_sleep+0x70/0x80
>>  synchronize_irq+0x40/0xa8
>>  disable_irq+0x20/0x2c
>
> Given that these things are CPU-affine, I reckon this should be
> disable_irq_nosync. Mark?
>
> Will
>
> --->8
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 0c2ed11c0603..f63db346c219 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -638,7 +638,7 @@ static int arm_perf_teardown_cpu(unsigned int cpu, struct 
> hlist_node *node)
> if (irq_is_percpu_devid(irq))
> disable_percpu_irq(irq);
> else
> -   disable_irq(irq);
> +   disable_irq_nosync(irq);
> }
>
> per_cpu(cpu_armpmu, cpu) = NULL;

Tested-by: Geert Uytterhoeven 

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 net-next] sh_eth: fix TSU init on SH7734/R8A7740

[Geert Uytterhoeven]

Hi Sergei,

On Sat, Feb 24, 2018 at 8:41 PM, Sergei Shtylyov
 wrote:
> It appears that the single port Ether controllers having TSU (like SH7734/
> R8A7740) need the same kind of treating in sh_eth_tsu_init() as R7S72100
> currently has -- they also don't have the TSU registers related e.g. to
> passing the frames between ports. Add the 'sh_eth_cpu_data::dual_port'
> flag and use it as a new criterion for taking a "short path" in the TSU
> init sequence in order to avoid writing to the non-existant registers...
>
> Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
> Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740")
> Signed-off-by: Sergei Shtylyov 

Thanks for your patch!

Ethernet (nfsroot and WoL) is still working fine on r8a7740/armadillo,
which has a single "gether" port.

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

[PATCH 1/2] arm64: dts: r8a77965: Add IIC-DVFS device node

[Geert Uytterhoeven]

Populate the device node for the IIC Bus Interface for DVFS (IIC for
DVFS) on R-Car M3-N, and add an alias to fix its bus number.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index ebda00397d5310a1..7435297d2581c410 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -18,6 +18,10 @@
#address-cells = <2>;
#size-cells = <2>;
 
+   aliases {
+   i2c7 = _dvfs;
+   };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
@@ -700,9 +704,17 @@
i2c_dvfs: i2c@e60b {
#address-cells = <1>;
#size-cells = <0>;
-
+   compatible = "renesas,iic-r8a77965",
+"renesas,rcar-gen3-iic",
+"renesas,rmobile-iic";
reg = <0 0xe60b 0 0x425>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 926>;
+   power-domains = < 32>;
+   resets = < 926>;
+   dmas = < 0x11>, < 0x10>;
+   dma-names = "tx", "rx";
+   status = "disabled";
};
 
pwm0: pwm@e6e3 {
-- 
2.7.4

[PATCH 0/2] arm64: dts: r8a77965: salvator-x(s): Enable s2ram and PMIC

[Geert Uytterhoeven]

Hi Simon, Magnus,

This patch populates the placeholders in the R-Car M3-N DTS file for the
IIC Bus Interface for DVFS (IIC for DVFS) and Interrupt Controller for
External Devices (INTC-EX) device nodes.

After applying the first patch, you can start using s2ram (PSCI
suspend), like on other Salvator-X(S) boards
(https://elinux.org/R-Car/Boards/Salvator-XS#PSCI_System_Suspend).

The second patch enables dependencies for the BD9571MWV PMIC device,
which is described in salvator-common.dtsi. Note that operation still
depends on "[PATCH] pinctrl: sh-pfc: r8a77965: Add support for INTC-EX
IRQ pins".

Thanks!

Geert Uytterhoeven (2):
  arm64: dts: r8a77965: Add IIC-DVFS device node
  arm64: dts: r8a77965: Add INTC-EX device node

 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

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

[PATCH 2/2] arm64: dts: r8a77965: Add INTC-EX device node

[Geert Uytterhoeven]

Populate the device node for the Interrupt Controller for External
Devices (INTC-EX) on R-Car M3-N, which serves external IRQ pins
IRQ[0-5].

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 7435297d2581c410..2f3d1784343cf3ec 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -320,10 +320,19 @@
};
 
intc_ex: interrupt-controller@e61c {
+   compatible = "renesas,intc-ex-r8a77965", "renesas,irqc";
#interrupt-cells = <2>;
interrupt-controller;
reg = <0 0xe61c 0 0x200>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 407>;
+   power-domains = < 32>;
+   resets = < 407>;
};
 
dmac0: dma-controller@e670 {
-- 
2.7.4

Re: [PATCHv2 6/8] arm_pmu: explicitly enable/disable SPIs at hotplug

[Geert Uytterhoeven]

Hi Mark,

On Mon, Feb 5, 2018 at 5:42 PM, Mark Rutland  wrote:
> To support ACPI systems, we need to request IRQs before CPUs are
> hotplugged, and thus we need to request IRQs before we know their
> associated PMU.
>
> This is problematic if a PMU IRQ is pending out of reset, as it may be
> taken before we know the PMU, and thus the IRQ handler won't be able to
> handle it, leaving it screaming.
>
> To avoid such problems, lets request all IRQs in a disabled state, and
> explicitly enable/disable them at hotplug time, when we're sure the PMU
> has been probed.
>
> Signed-off-by: Mark Rutland 

This is now commit 6de3f79112cc26bf in v4.16-rc3, and causes a BUG during
CPU offlining (e.g. during system suspend, or during boot with
CONFIG_ARM_PSCI_CHECKER=y).

With CONFIG_ARM_PSCI_CHECKER=y:

psci_checker: PSCI checker started using 6 CPUs
psci_checker: Starting hotplug tests
psci_checker: Trying to turn off and on again all CPUs
BUG: sleeping function called from invalid context at kernel/irq/manage.c:112
in_atomic(): 1, irqs_disabled(): 128, pid: 15, name: migration/1
no locks held by migration/1/15.
irq event stamp: 192
hardirqs last  enabled at (191): [<803c2507>]
_raw_spin_unlock_irq+0x2c/0x4c
hardirqs last disabled at (192): [<7f57ad28>] multi_cpu_stop+0x9c/0x140
softirqs last  enabled at (0): [<04ee1b58>]
copy_process.isra.77.part.78+0x43c/0x1504
softirqs last disabled at (0): [<  (null)>]   (null)
CPU: 1 PID: 15 Comm: migration/1 Not tainted 4.16.0-rc3-salvator-x #1651
Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
Call trace:
 dump_backtrace+0x0/0x140
 show_stack+0x14/0x1c
 dump_stack+0xb4/0xf0
 ___might_sleep+0x1fc/0x218
 __might_sleep+0x70/0x80
 synchronize_irq+0x40/0xa8
 disable_irq+0x20/0x2c
 arm_perf_teardown_cpu+0x80/0xac
 cpuhp_invoke_callback+0x5a0/0xd18
 take_cpu_down+0x84/0xc4
 multi_cpu_stop+0xb0/0x140
 cpu_stopper_thread+0xbc/0x128
 smpboot_thread_fn+0x218/0x234
 kthread+0x11c/0x124
 ret_from_fork+0x10/0x18
CPU1: shutdown
psci: CPU1 killed.

Reverting that commit on v4.16-rc3 fixes the issue.

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] pinctrl: sh-pfc: r8a77965: Add support for INTC-EX IRQ pins

[Geert Uytterhoeven]

From: Takeshi Kihara 

Most pins on the R8A77965 SoC can be configured in GPIO mode for
interrupt and GPIO functionality, while a couple of them can also
be routed to the INTC-EX hardware block (formerly known as IRQC).

On R8A77965 the INTC-EX hardware handles pins IRQ0 -> IRQ5 and
this patch adds support for them to the PFC driver as "intc_ex_irqN".

Based on a similar patch for the R8A7795 PFC driver by Magnus Damm
.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Geert Uytterhoeven 
---
To be queued in sh-pfc-for-v4.17.

 drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 61 +++
 1 file changed, 61 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index acd57d5b2fb18b25..363ccc3b1bdc7a88 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -1661,6 +1661,51 @@ static const unsigned int avb_avtp_capture_b_pins[] = {
 static const unsigned int avb_avtp_capture_b_mux[] = {
AVB_AVTP_CAPTURE_B_MARK,
 };
+
+/* - INTC-EX  
*/
+static const unsigned int intc_ex_irq0_pins[] = {
+   /* IRQ0 */
+   RCAR_GP_PIN(2, 0),
+};
+static const unsigned int intc_ex_irq0_mux[] = {
+   IRQ0_MARK,
+};
+static const unsigned int intc_ex_irq1_pins[] = {
+   /* IRQ1 */
+   RCAR_GP_PIN(2, 1),
+};
+static const unsigned int intc_ex_irq1_mux[] = {
+   IRQ1_MARK,
+};
+static const unsigned int intc_ex_irq2_pins[] = {
+   /* IRQ2 */
+   RCAR_GP_PIN(2, 2),
+};
+static const unsigned int intc_ex_irq2_mux[] = {
+   IRQ2_MARK,
+};
+static const unsigned int intc_ex_irq3_pins[] = {
+   /* IRQ3 */
+   RCAR_GP_PIN(2, 3),
+};
+static const unsigned int intc_ex_irq3_mux[] = {
+   IRQ3_MARK,
+};
+static const unsigned int intc_ex_irq4_pins[] = {
+   /* IRQ4 */
+   RCAR_GP_PIN(2, 4),
+};
+static const unsigned int intc_ex_irq4_mux[] = {
+   IRQ4_MARK,
+};
+static const unsigned int intc_ex_irq5_pins[] = {
+   /* IRQ5 */
+   RCAR_GP_PIN(2, 5),
+};
+static const unsigned int intc_ex_irq5_mux[] = {
+   IRQ5_MARK,
+};
+
 /* - SCIF0 -- 
*/
 static const unsigned int scif0_data_pins[] = {
/* RX, TX */
@@ -1883,6 +1928,12 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_avtp_capture_a),
SH_PFC_PIN_GROUP(avb_avtp_match_b),
SH_PFC_PIN_GROUP(avb_avtp_capture_b),
+   SH_PFC_PIN_GROUP(intc_ex_irq0),
+   SH_PFC_PIN_GROUP(intc_ex_irq1),
+   SH_PFC_PIN_GROUP(intc_ex_irq2),
+   SH_PFC_PIN_GROUP(intc_ex_irq3),
+   SH_PFC_PIN_GROUP(intc_ex_irq4),
+   SH_PFC_PIN_GROUP(intc_ex_irq5),
SH_PFC_PIN_GROUP(scif0_data),
SH_PFC_PIN_GROUP(scif0_clk),
SH_PFC_PIN_GROUP(scif0_ctrl),
@@ -1927,6 +1978,15 @@ static const char * const avb_groups[] = {
"avb_avtp_capture_b",
 };
 
+static const char * const intc_ex_groups[] = {
+   "intc_ex_irq0",
+   "intc_ex_irq1",
+   "intc_ex_irq2",
+   "intc_ex_irq3",
+   "intc_ex_irq4",
+   "intc_ex_irq5",
+};
+
 static const char * const scif0_groups[] = {
"scif0_data",
"scif0_clk",
@@ -1978,6 +2038,7 @@ static const char * const scif_clk_groups[] = {
 
 static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(avb),
+   SH_PFC_FUNCTION(intc_ex),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif1),
SH_PFC_FUNCTION(scif2),
-- 
2.7.4

Re: [PATCHv2 6/8] arm_pmu: explicitly enable/disable SPIs at hotplug

[Will Deacon]

On Mon, Feb 26, 2018 at 04:16:19PM +0100, Geert Uytterhoeven wrote:
> On Mon, Feb 5, 2018 at 5:42 PM, Mark Rutland  wrote:
> > To support ACPI systems, we need to request IRQs before CPUs are
> > hotplugged, and thus we need to request IRQs before we know their
> > associated PMU.
> >
> > This is problematic if a PMU IRQ is pending out of reset, as it may be
> > taken before we know the PMU, and thus the IRQ handler won't be able to
> > handle it, leaving it screaming.
> >
> > To avoid such problems, lets request all IRQs in a disabled state, and
> > explicitly enable/disable them at hotplug time, when we're sure the PMU
> > has been probed.
> >
> > Signed-off-by: Mark Rutland 
> 
> This is now commit 6de3f79112cc26bf in v4.16-rc3, and causes a BUG during
> CPU offlining (e.g. during system suspend, or during boot with
> CONFIG_ARM_PSCI_CHECKER=y).
> 
> With CONFIG_ARM_PSCI_CHECKER=y:
> 
> psci_checker: PSCI checker started using 6 CPUs
> psci_checker: Starting hotplug tests
> psci_checker: Trying to turn off and on again all CPUs
> BUG: sleeping function called from invalid context at kernel/irq/manage.c:112
> in_atomic(): 1, irqs_disabled(): 128, pid: 15, name: migration/1
> no locks held by migration/1/15.
> irq event stamp: 192
> hardirqs last  enabled at (191): [<803c2507>]
> _raw_spin_unlock_irq+0x2c/0x4c
> hardirqs last disabled at (192): [<7f57ad28>] 
> multi_cpu_stop+0x9c/0x140
> softirqs last  enabled at (0): [<04ee1b58>]
> copy_process.isra.77.part.78+0x43c/0x1504
> softirqs last disabled at (0): [<  (null)>]   (null)
> CPU: 1 PID: 15 Comm: migration/1 Not tainted 4.16.0-rc3-salvator-x #1651
> Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
> Call trace:
>  dump_backtrace+0x0/0x140
>  show_stack+0x14/0x1c
>  dump_stack+0xb4/0xf0
>  ___might_sleep+0x1fc/0x218
>  __might_sleep+0x70/0x80
>  synchronize_irq+0x40/0xa8
>  disable_irq+0x20/0x2c

Given that these things are CPU-affine, I reckon this should be
disable_irq_nosync. Mark?

Will

--->8

diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 0c2ed11c0603..f63db346c219 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -638,7 +638,7 @@ static int arm_perf_teardown_cpu(unsigned int cpu, struct 
hlist_node *node)
if (irq_is_percpu_devid(irq))
disable_percpu_irq(irq);
else
-   disable_irq(irq);
+   disable_irq_nosync(irq);
}
 
per_cpu(cpu_armpmu, cpu) = NULL;

[PATCH] dt-bindings: i2c: sh_mobile: Document R-Car M3-N support

[Geert Uytterhoeven]

Document support for the IIC Bus Interface for DVFS (IIC for DVFS) in
the Renesas M3-N (r8a77965) SoC.

No driver update is needed.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt 
b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
index 224390999e817f33..fc7e178027467bcd 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
@@ -13,6 +13,7 @@ Required properties:
- "renesas,iic-r8a7794" (R-Car E2)
- "renesas,iic-r8a7795" (R-Car H3)
- "renesas,iic-r8a7796" (R-Car M3-W)
+   - "renesas,iic-r8a77965" (R-Car M3-N)
- "renesas,iic-sh73a0" (SH-Mobile AG5)
- "renesas,rcar-gen2-iic" (generic R-Car Gen2 or RZ/G1
compatible device)
-- 
2.7.4

[PATCH] dt-bindings: irqchip: renesas-irqc: Document R-Car M3-N support

[Geert Uytterhoeven]

Document support for the Interrupt Controller for Externel Devices
(INTC-EX) in the Renesas M3-N (r8a77965) SoC.

No driver update is needed.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
index 33c9a10fdc91a1dc..20f121daa9106f17 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
@@ -14,6 +14,7 @@ Required properties:
 - "renesas,irqc-r8a7794" (R-Car E2)
 - "renesas,intc-ex-r8a7795" (R-Car H3)
 - "renesas,intc-ex-r8a7796" (R-Car M3-W)
+- "renesas,intc-ex-r8a77965" (R-Car M3-N)
 - "renesas,intc-ex-r8a77970" (R-Car V3M)
 - "renesas,intc-ex-r8a77995" (R-Car D3)
 - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in
-- 
2.7.4

Re: [PATCH 02/02] ARM: dts: silk: Add GPIO keys to DT

[Geert Uytterhoeven]

On Mon, Feb 19, 2018 at 12:49 PM, Magnus Damm  wrote:
> From: Magnus Damm 
>
> Extend the Silk board support to include SW3, SW4, SW6 and SW12. They
> are all connected via GPIO lines and handled by the gpio-keys driver.
>
> Signed-off-by: Magnus Damm 

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 01/02] ARM: dts: silk: Add r1ex24002 EEPROM to DT

[Geert Uytterhoeven]

On Mon, Feb 19, 2018 at 12:49 PM, Magnus Damm  wrote:
> From: Magnus Damm 
>
> Extend the Silk board support to include U14 which is an I2C based EEPROM
> hooked up to the I2C1 bus.
>
> Signed-off-by: Magnus Damm 

late
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] pinctrl: sh-pfc: add R8A77980 PFC support

[Geert Uytterhoeven]

Hi Sergei,

On Sun, Feb 25, 2018 at 7:14 PM, Sergei Shtylyov
 wrote:
> Add the PFC support for the R8A77980 SoC including pin groups for some
> on-chip devices such as AVB, CAN-FD, GETHER, [H]SCIF, I2C, INTC-EX, MMC,
> MSIOF, PWM, and VIN...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 

Thanks for your patch!

To avoid scaring off potential reviewers, it may be better to not include that
many pin groups and functions in future initial submissions.
This also helps if issues are detected during review in some of them (like
below), delaying queuing of basic functionality and other correct parts.

I only looked at CPU_ALL_PORT(), pins, groups, and functions.
Comments below.

> --- /dev/null
> +++ renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77980.c

> +/* - AVB 
>  */
> +static const unsigned int avb_link_pins[] = {
> +   /* AVB_LINK */
> +   RCAR_GP_PIN(1, 18),
> +};
> +static const unsigned int avb_link_mux[] = {
> +   AVB_LINK_MARK,
> +};
> +static const unsigned int avb_magic_pins[] = {
> +   /* AVB_MAGIC */
> +   RCAR_GP_PIN(1, 16),
> +};
> +static const unsigned int avb_magic_mux[] = {
> +   AVB_MAGIC_MARK,
> +};
> +static const unsigned int avb_phy_int_pins[] = {
> +   /* AVB_PHY_INT */
> +   RCAR_GP_PIN(1, 17),
> +};
> +static const unsigned int avb_phy_int_mux[] = {
> +   AVB_PHY_INT_MARK,
> +};
> +static const unsigned int avb_mdio_pins[] = {
> +   /* AVB_MDC, AVB_MDIO */
> +   RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14),
> +};
> +static const unsigned int avb_mdio_mux[] = {
> +   AVB_MDC_MARK, AVB_MDIO_MARK,
> +};

The grouping is different from other R-Car Gen3 SoCs.

> +/* - CANFD0 
> - */
> +static const unsigned int canfd0_data_a_pins[] = {
> +   /* CANFD0_TX, CANFD0_RX */
> +   RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
> +};
> +static const unsigned int canfd0_data_a_mux[] = {
> +   CANFD0_TX_A_MARK, CANFD0_RX_A_MARK,
> +};
> +static const unsigned int canfd_clk_a_pins[] = {
> +   /* CANFD_CLK */
> +   RCAR_GP_PIN(1, 25),
> +};
> +static const unsigned int canfd_clk_a_mux[] = {
> +   CANFD_CLK_A_MARK,
> +};
> +static const unsigned int canfd0_data_b_pins[] = {
> +   /* CANFD0_TX, CANFD0_RX */
> +   RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> +};
> +static const unsigned int canfd0_data_b_mux[] = {
> +   CANFD0_TX_B_MARK, CANFD0_RX_B_MARK,
> +};
> +static const unsigned int canfd_clk_b_pins[] = {
> +   /* CANFD_CLK */
> +   RCAR_GP_PIN(3, 8),
> +};
> +static const unsigned int canfd_clk_b_mux[] = {
> +   CANFD_CLK_B_MARK,
> +};

Please move the canfd_clk pins to their own section.

Note that they are called can_clk in the pin function sheet, but the
PFC section uses both can_clk and canfd_clk.
Given V3H (like V3M) has no plain CAN, only CANFD, using canfd_clk
sounds right to me, though.

> +/* - DU 
> - */
> +static const unsigned int du_rgb666_pins[] = {
> +   /* DU_R[7:2], DU_G[7:2], DU_B[7:2] */
> +   RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 3),
> +   RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 1), RCAR_GP_PIN(0, 0),
> +   RCAR_GP_PIN(0, 11), RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 9),
> +   RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 7), RCAR_GP_PIN(0, 6),
> +   RCAR_GP_PIN(0, 17), RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 15),
> +   RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 13), RCAR_GP_PIN(0, 12),
> +};
> +static const unsigned int du_rgb666_mux[] = {
> +   DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK,
> +   DU_DR4_MARK, DU_DR3_MARK, DU_DR2_MARK,
> +   DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK,
> +   DU_DG4_MARK, DU_DG3_MARK, DU_DG2_MARK,
> +   DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK,
> +   DU_DB4_MARK, DU_DB3_MARK, DU_DB2_MARK,
> +};

du_rgb888 is missing (see GP2_19..GP2_24).

> +/* - HSCIF0 
> - */

> +static const unsigned int scif_clk_a_pins[] = {
> +   /* SCIF_CLK */
> +   RCAR_GP_PIN(0, 10),
> +};
> +static const unsigned int scif_clk_a_mux[] = {
> +   SCIF_CLK_A_MARK,
> +};


[...]

> +static const unsigned int scif_clk_b_pins[] = {
> +   /* SCIF_CLK */
> +   RCAR_GP_PIN(1, 25),
> +};
> +static const unsigned int scif_clk_b_mux[] = {
> +   SCIF_CLK_B_MARK,
> +};

Please move the scif_clk pins to their own section, as they are shared by
HSCIF and SCIF.

> +/* - VIN0 
> --- */

> +static const unsigned int vin0_sync_pins[] = {
> +   /* VI0_VSYNC#, VI0_HSYNC# */
> +   RCAR_GP_PIN(2, 3), RCAR_GP_PIN(2, 2),
> +};
> +static const unsigned 

[PATCH 1/2] arm: add basic support for Renesas RZ/N1 boards

[Michel Pollet]

This adds the Renesas RZ/N1 CPU and bare bone support.

This currently only handles generic parts (gic, architected timer)
and a UART.
This also relies on the bootloader to set the pinctrl and clocks.

Signed-off-by: Michel Pollet 
---
 Documentation/devicetree/bindings/arm/shmobile.txt |   3 +-
 arch/arm/boot/dts/rzn1.dtsi|  94 +++
 arch/arm/mach-shmobile/Kconfig |   5 +
 arch/arm/mach-shmobile/Makefile|   1 +
 arch/arm/mach-shmobile/setup-r9a06g032.c   |  60 ++
 .../dt-bindings/interrupt-controller/rzn1-irq.h| 137 
 include/dt-bindings/soc/renesas,rzn1-map.h | 173 +
 include/soc/rzn1/sysctrl.h | 736 +
 8 files changed, 1208 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/rzn1.dtsi
 create mode 100644 arch/arm/mach-shmobile/setup-r9a06g032.c
 create mode 100644 include/dt-bindings/interrupt-controller/rzn1-irq.h
 create mode 100644 include/dt-bindings/soc/renesas,rzn1-map.h
 create mode 100644 include/soc/rzn1/sysctrl.h

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 63edc11..153f69bb 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -47,7 +47,8 @@ SoCs:
 compatible = "renesas,r8a77980"
   - R-Car D3 (R8A77995)
 compatible = "renesas,r8a77995"
-
+  - RZ/N1D (R9A06G032)
+compatible = "renesas,r9a06g032"
 
 Boards:
 
diff --git a/arch/arm/boot/dts/rzn1.dtsi b/arch/arm/boot/dts/rzn1.dtsi
new file mode 100644
index 000..bc134b0
--- /dev/null
+++ b/arch/arm/boot/dts/rzn1.dtsi
@@ -0,0 +1,94 @@
+/*
+ * Base Device Tree Source for the Renesas RZ/N1 SoC
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "renesas,r9a06g032";
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   };
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <1>;
+   };
+   };
+   aliases {
+   serial0 = 
+   };
+   arm_timer: timer {
+   compatible = "arm,armv7-timer";
+   arm,cpu-registers-not-fw-configured;
+   interrupts =
+   ,
+   ,
+   ,
+   ;
+   };
+   gic: interrupt-controller@RZN1_GIC_BASE {
+   compatible = "arm,cortex-a7-gic";
+   reg = <0x44101000 0x1000>,  /* Distributer */
+ <0x44102000 0x1000>,  /* CPU interface */
+ <0x44104000 0x2000>,  /* Virt interface control */
+ <0x44106000 0x2000>;  /* Virt CPU interface */
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   interrupts =
+   ;
+   };
+   clocks: clocks@0 {
+   /*
+* this is fixed clock for now,
+* until the clock driver is merged
+*/
+   clk_uarts: clk_uarts@0 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <47619047>;
+   };
+   };
+   bus {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   uart0: serial@RZN1_UART0_BASE {
+   compatible = "snps,dw-apb-uart";
+   reg = ;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = <_uarts>;
+   clock-names = "baudclk";
+   status = "disabled";
+   };
+   };
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 280e731..e2cd7aa 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -110,6 +110,11 @@ config ARCH_R8A7794
bool "R-Car E2 (R8A77940)"
select ARCH_RCAR_GEN2
 
+config ARCH_R9A06G032
+   bool "RZ/N1D (R9A06G032)"
+   select ARM_AMBA
+   select CPU_V7
+
 config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 

[PATCH 2/2] arm: rzn1: Add basic support for RZN1D-DB Board

[Michel Pollet]

Only enables the uart0 for now, and also relies on the bootloader
for setting up the clocks and pinctrl.

Signed-off-by: Michel Pollet 
---
 Documentation/devicetree/bindings/arm/shmobile.txt |  2 ++
 arch/arm/boot/dts/rzn1d400-db.dts  | 25 ++
 2 files changed, 27 insertions(+)
 create mode 100644 arch/arm/boot/dts/rzn1d400-db.dts

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 153f69bb..498871b 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -105,6 +105,8 @@ Boards:
 compatible = "renesas,porter", "renesas,r8a7791"
   - RSKRZA1 (YR0K77210C000BE)
 compatible = "renesas,rskrza1", "renesas,r7s72100"
+  - RZN1D-DB (RZ/N1D Demo Board)
+compatible = "renesas,rzn1d-db", "renesas,r9a06g032"
   - Salvator-X (RTP0RC7795SIPB0010S)
 compatible = "renesas,salvator-x", "renesas,r8a7795"
   - Salvator-X (RTP0RC7796SIPB0011S)
diff --git a/arch/arm/boot/dts/rzn1d400-db.dts 
b/arch/arm/boot/dts/rzn1d400-db.dts
new file mode 100644
index 000..1b686f0
--- /dev/null
+++ b/arch/arm/boot/dts/rzn1d400-db.dts
@@ -0,0 +1,25 @@
+/*
+ * Device Tree Source for the RZN1D-DB Board
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+/dts-v1/;
+
+#include "rzn1.dtsi"
+
+/ {
+   model = "RZN1D-DB Board";
+   compatible = "renesas,rzn1d-db", "renesas,r9a06g032";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   stdout-path = 
+   linux,stdout-path = 
+   };
+};
+ {
+   status = "okay";
+};
-- 
2.7.4

Re: [PATCH 0/2] Add Renesas R8A77970 PFC driver

[Sergei Shtylyov]

Sorry, should read R8A77980 in the subject...

Re: [PATCH] ARM: dts: porter: Add missing PMIC nodes

[Marek Vasut]

On 02/26/2018 11:55 AM, Simon Horman wrote:
> On Sat, Feb 24, 2018 at 11:11:31PM +0100, Marek Vasut wrote:
>> On 02/18/2018 04:07 PM, Geert Uytterhoeven wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> CC Steve Twiss
>>>
>>> On Sat, Feb 17, 2018 at 3:07 AM, Marek Vasut  wrote:
 Add PMIC nodes to Porter and connect CPU DVFS supply. There is
 one DA9063 and one DA9210 on Porter, the only difference from
 the other boards is that DA9063 is at I2C address 0x5a rather
 than 0x58 .

 Signed-off-by: Marek Vasut 
>>>
>>> Thanks for your patch!
>>>
 --- a/arch/arm/boot/dts/r8a7791-porter.dts
 +++ b/arch/arm/boot/dts/r8a7791-porter.dts
 @@ -354,10 +354,47 @@
 clock-frequency = <40>;
  };

 + {
 +   status = "okay";
 +   clock-frequency = <10>;
 +
 +   pmic@5a {
 +   compatible = "dlg,da9063";
>>>
>>> Does it matter that this is a DA9063L ("Variant 6B")?
>>> Do we need a new compatible value, or can this be detected at runtime?
>>
>> The driver detects it
>>
>> da9063 6-005a: Device detected (chip-ID: 0x61, var-ID: 0x63)
>>
>> Comparing the datasheets makes it obvious that 9063L is just a cut-down
>> version of 9063, with less LDOs and one less ADC. So I think we should
>> have extra compatible and have the driver restrict which LDOs can be
>> used with this smaller PMIC.
> 
> Thanks, and sorry to ping yo about this while you were in transit.
> 
> It sounds like this patch should be updated.
> Accordingly I'm marking it as "Changes Requested".

Correct

-- 
Best regards,
Marek Vasut

Re: [PATCH] arm64: defconfig: enable R8A77965 SoC

[Simon Horman]

On Mon, Feb 26, 2018 at 09:23:33AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Fri, Feb 23, 2018 at 4:00 PM, Simon Horman  wrote:
> > On Fri, Feb 23, 2018 at 10:19:45AM +0100, Geert Uytterhoeven wrote:
> >> On Fri, Feb 23, 2018 at 9:51 AM, Simon Horman
> >>  wrote:
> >> > Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 defconfig.
> >> >
> >> > Signed-off-by: Simon Horman 
> >>
> >> Acked-by: Geert Uytterhoeven 
> >
> > I have applied this to the topic/renesas-defconfig branch which is included
> > in the devel branch and tags of the Renesas tree as a convenience to
> > developers.  The branch is not, however, included in the next branch or
> > tags nor is it targeted at upstream.
> 
> Looks like it accidentally ended up in your next branch.
> 
> Merge report from sfr:
> 
> Merging renesas/next (60d04a4b6d41 Merge branch
> 'topic/renesas-defconfig' into next)

Yes, indeed. I'll fix that.

Re: [PATCH] arm64: defconfig: enable R8A77965 SoC

[Simon Horman]

On Fri, Feb 23, 2018 at 05:27:30PM +0200, Vladimir Zapolskiy wrote:
> Hi Simon,
> 
> On 02/23/2018 10:51 AM, Simon Horman wrote:
> > Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 defconfig.
> 
> If I'm not mistaken in my tardy note, then M3-W is R8A7796 and R8A77965 is 
> M3-N, no?

On Fri, Feb 23, 2018 at 03:29:08PM +, Yao Lihua wrote:
> On Friday, February 23, 2018 04:51 PM, Simon Horman wrote:
> > Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 defconfig.
> R8A77965 should be M3-N?

Thanks, I have fixed this up to read M3-N.

Re: [PATCH] DT: net: renesas,ravb: document R8A77980 bindings

[Simon Horman]

On Sat, Feb 24, 2018 at 09:53:17PM -0500, David Miller wrote:
> From: Sergei Shtylyov 
> Date: Sat, 24 Feb 2018 21:01:15 +0300
> 
> > On 02/01/2018 11:13 PM, Sergei Shtylyov wrote:
> > 
> >> Renesas R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible EtherAVB
> >> device, so document the SoC specific bindings.
> >> 
> >> Signed-off-by: Sergei Shtylyov 
> >> 
> >> ---
> >> The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if 
> >> it's
> >> applied to 'net.git' instead. :-)
> > 
> >David, I see this patch was marked as "not applicable" in patchwork. 
> > Why, because
> > it was posted during the merge window?
> 
> No because I thought the relevant architecture tree would take a mere
> DT update.

Hi Dave,

I am happy to take these kinds of changes for the ravb and sh_eth drivers
if that is your preference. I am also just as happy for you to take them,
which I think has been the case for similar changes in the past.

Re: [PATCH] ARM: dts: porter: Add missing PMIC nodes

[Simon Horman]

On Sat, Feb 24, 2018 at 11:11:31PM +0100, Marek Vasut wrote:
> On 02/18/2018 04:07 PM, Geert Uytterhoeven wrote:
> > Hi Marek,
> 
> Hi,
> 
> > CC Steve Twiss
> > 
> > On Sat, Feb 17, 2018 at 3:07 AM, Marek Vasut  wrote:
> >> Add PMIC nodes to Porter and connect CPU DVFS supply. There is
> >> one DA9063 and one DA9210 on Porter, the only difference from
> >> the other boards is that DA9063 is at I2C address 0x5a rather
> >> than 0x58 .
> >>
> >> Signed-off-by: Marek Vasut 
> > 
> > Thanks for your patch!
> > 
> >> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> >> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> >> @@ -354,10 +354,47 @@
> >> clock-frequency = <40>;
> >>  };
> >>
> >> + {
> >> +   status = "okay";
> >> +   clock-frequency = <10>;
> >> +
> >> +   pmic@5a {
> >> +   compatible = "dlg,da9063";
> > 
> > Does it matter that this is a DA9063L ("Variant 6B")?
> > Do we need a new compatible value, or can this be detected at runtime?
> 
> The driver detects it
> 
> da9063 6-005a: Device detected (chip-ID: 0x61, var-ID: 0x63)
> 
> Comparing the datasheets makes it obvious that 9063L is just a cut-down
> version of 9063, with less LDOs and one less ADC. So I think we should
> have extra compatible and have the driver restrict which LDOs can be
> used with this smaller PMIC.

Thanks, and sorry to ping yo about this while you were in transit.

It sounds like this patch should be updated.
Accordingly I'm marking it as "Changes Requested".

Re: [PATCH 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Geert Uytterhoeven]

Hi Uli,

On Mon, Feb 26, 2018 at 10:21 AM, Geert Uytterhoeven
 wrote:
> On Mon, Feb 26, 2018 at 10:02 AM, Ulrich Hecht
>  wrote:
>> On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
>>  wrote:
>>> Would there be a use case for vin4_data4 and vin5_data4, or is that
>>> mode only supported on R-Car H2?
>>
>> The docs don't mention it, so I would assume it's not supported.
>
> Thank you, queuing (also for r8a7795 and r8a77995) in sh-pfc-for-v4.17.

Please send follow-up patches to reduce vin_data duplication.

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 1/2] pinctrl: sh-pfc: add PORT_GP_CFG_25() helper macro

[Geert Uytterhoeven]

On Sun, Feb 25, 2018 at 7:13 PM, Sergei Shtylyov
 wrote:
> They follow the style of the existing PORT_GP_CFG_() macros and
> will be used by a follow-up patch for the R8A77980 SoC.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 
i.e. queuing in sh-pfc-for-v4.17.

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 1/2] vfio: platform: Fix reset module leak in error path

[Auger Eric]

Hi Geert,

On 13/02/18 17:36, Geert Uytterhoeven wrote:
> If the IOMMU group setup fails, the reset module is not released.
> 
> Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by 
> default")
> Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Eric Auger 

Thanks

Eric
> ---
>  drivers/vfio/platform/vfio_platform_common.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index 35469af87f88678e..b60bb5326668498c 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -680,18 +680,23 @@ int vfio_platform_probe_common(struct 
> vfio_platform_device *vdev,
>   group = vfio_iommu_group_get(dev);
>   if (!group) {
>   pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto put_reset;
>   }
>  
>   ret = vfio_add_group_dev(dev, _platform_ops, vdev);
> - if (ret) {
> - vfio_iommu_group_put(group, dev);
> - return ret;
> - }
> + if (ret)
> + goto put_iommu;
>  
>   mutex_init(>igate);
>  
>   return 0;
> +
> +put_iommu:
> + vfio_iommu_group_put(group, dev);
> +put_reset:
> + vfio_platform_put_reset(vdev);
> + return ret;
>  }
>  EXPORT_SYMBOL_GPL(vfio_platform_probe_common);
>  
> 

Re: [PATCH 1/2] vfio: platform: Fix reset module leak in error path

[Auger Eric]

Hi Geert,

On 21/02/18 17:07, Geert Uytterhoeven wrote:
> Hi Eric,
> 
> On Wed, Feb 14, 2018 at 10:32 AM, Geert Uytterhoeven
>  wrote:
>> On Wed, Feb 14, 2018 at 9:36 AM, Auger Eric  wrote:
>>> If I am not wrong we also leak the reset_module if
>>> vfio_platform_get_reset() fails to find the reset function (of_reset ==
>>> NULL), in which case we should do the module_put() in
>>> vfio_platform_get_reset().
>>
>> Correct. Will look into fixing it...
> 
> Upon second look, I don't think there's a leak in vfio_platform_get_reset().
> 
> If try_module_get() succeeded, there will always be a valid reset function
> (unless someone registered a vfio_reset_handler with a NULL reset function).
Hum yes, you are right. So the code is fine as is. Sorry for the noise.

Thanks

Eric


> 
> Or do you mean the call to request_module()?
> That one doesn't do a module_get(), it merely tries to load a module.
> Hence there's no need to do a module_put() afterwards.
> 
> 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 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Geert Uytterhoeven]

Hi Ulrich,

On Mon, Feb 26, 2018 at 10:02 AM, Ulrich Hecht
 wrote:
> On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
>  wrote:
>> Would there be a use case for vin4_data4 and vin5_data4, or is that
>> mode only supported on R-Car H2?
>
> The docs don't mention it, so I would assume it's not supported.

Thank you, queuing (also for r8a7795 and r8a77995) in sh-pfc-for-v4.17.

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 1/4] pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions

[Ulrich Hecht]

On Tue, Feb 20, 2018 at 2:58 PM, Geert Uytterhoeven
 wrote:
> Would there be a use case for vin4_data4 and vin5_data4, or is that
> mode only supported on R-Car H2?

The docs don't mention it, so I would assume it's not supported.

CU
Uli

Re: [PATCH] arm64: defconfig: enable R8A77965 SoC

[Geert Uytterhoeven]

Hi Simon,

On Fri, Feb 23, 2018 at 4:00 PM, Simon Horman  wrote:
> On Fri, Feb 23, 2018 at 10:19:45AM +0100, Geert Uytterhoeven wrote:
>> On Fri, Feb 23, 2018 at 9:51 AM, Simon Horman
>>  wrote:
>> > Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 defconfig.
>> >
>> > Signed-off-by: Simon Horman 
>>
>> Acked-by: Geert Uytterhoeven 
>
> I have applied this to the topic/renesas-defconfig branch which is included
> in the devel branch and tags of the Renesas tree as a convenience to
> developers.  The branch is not, however, included in the next branch or
> tags nor is it targeted at upstream.

Looks like it accidentally ended up in your next branch.

Merge report from sfr:

Merging renesas/next (60d04a4b6d41 Merge branch
'topic/renesas-defconfig' into next)

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 v2 01/19] clk: renesas: cpg-mssr: Add support for R-Car M3-N

[Geert Uytterhoeven]

Hi Jacopo,

On Tue, Feb 20, 2018 at 4:12 PM, Jacopo Mondi  wrote:
> Initial support for R-Car M3-N (r8a77965), including core and module
> clocks.
>
> Based on Table 8.2d of "R-Car Series, 3rd Generation User's Manual:
> Hardware (Rev. 0.80, Oct 31, 2017)".
>
> Signed-off-by: Jacopo Mondi 

> --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> @@ -22,6 +22,7 @@ Required Properties:
>- "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2)
>- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
>- "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
> +  - "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N)
>- "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M)
>- "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3)

You forgot to update the list of external parent clock names.
No need to fix and resend, I've squashed in the following:

--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
@@ -34,8 +34,8 @@ Required Properties:
 clock-names
   - clock-names: List of external parent clock names. Valid names are:
   - "extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794,
-r8a7795, r8a7796, r8a77970, r8a77980, r8a77995)
-  - "extalr" (r8a7795, r8a7796, r8a77970, r8a77980)
+r8a7795, r8a7796, r8a77965, r8a77970, r8a77980, r8a77995)
+  - "extalr" (r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
   - "usb_extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7793, r8a7794)

   - #clock-cells: Must be 2

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