Re: [PATCH 4/6] arm64: renesas: r8a7796: add I2C support

[Wolfram Sang]

On Wed, Sep 14, 2016 at 06:46:09PM +0200, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH 1/6] i2c: rcar: add support for r8a7796 (R-Car M3-W)

[Wolfram Sang]

On Wed, Sep 14, 2016 at 06:46:06PM +0200, Ulrich Hecht wrote:
> Same as r8a7795.
> 
> Signed-off-by: Ulrich Hecht 

Applied to for-next, thanks!



signature.asc
Description: PGP signature

[PATCH RFC 8/8] ARM: dts: sk-rzg1m: initial device tree

[Sergei Shtylyov]

Add the initial device  tree for the R8A7743 SoC based SK-RZG1M board.
The board has one debug serial port (SCIF0); include support for it, so
that  the serial  console  can work.

Based on the original (and large) patch by Dmitry Shifrin
.

Signed-off-by: Sergei Shtylyov 

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

Index: renesas/arch/arm/boot/dts/Makefile
===
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -654,6 +654,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r7s72100-rskrza1.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
+   r8a7743-sk-rzg1m.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the SK-RZG1M board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7743.dtsi"
+
+/ {
+   model = "SK-RZG1M";
+   compatible = "renesas,sk-rzg1m", "renesas,r8a7743";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   bootargs = "ignore_loglevel";
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x4000>;
+   };
+
+   memory@2 {
+   device_type = "memory";
+   reg = <2 0x 0 0x4000>;
+   };
+};
+
+_clk {
+   clock-frequency = <2000>;
+};
+
+ {
+   status = "okay";
+};

[PATCH RFC 7/8] ARM: dts: r8a7743: add [H]SCIF support

[Sergei Shtylyov]

Describe [H]SCIFs in the R8A7743 device tree.

Based on the original (and large) patch by Dmitry Shifrin
.

Signed-off-by: Sergei Shtylyov 

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

Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -154,6 +154,268 @@
dma-channels = <15>;
};
 
+   scifa0: serial@e6c4 {
+   compatible = "renesas,scifa-r8a7743",
+"renesas,rcar-gen2-scifa", "renesas,scifa";
+   reg = <0 0xe6c4 0 64>;
+   interrupts = ;
+   clocks = <_clks R8A7743_CLK_SCIFA0>;
+   clock-names = "fck";
+   dmas = < 0x21>, < 0x22>,
+  < 0x21>, < 0x22>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   scifa1: serial@e6c5 {
+   compatible = "renesas,scifa-r8a7743",
+"renesas,rcar-gen2-scifa", "renesas,scifa";
+   reg = <0 0xe6c5 0 64>;
+   interrupts = ;
+   clocks = <_clks R8A7743_CLK_SCIFA1>;
+   clock-names = "fck";
+   dmas = < 0x25>, < 0x26>,
+  < 0x25>, < 0x26>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   scifa2: serial@e6c6 {
+   compatible = "renesas,scifa-r8a7743",
+"renesas,rcar-gen2-scifa", "renesas,scifa";
+   reg = <0 0xe6c6 0 64>;
+   interrupts = ;
+   clocks = <_clks R8A7743_CLK_SCIFA2>;
+   clock-names = "fck";
+   dmas = < 0x27>, < 0x28>,
+  < 0x27>, < 0x28>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   scifa3: serial@e6c7 {
+   compatible = "renesas,scifa-r8a7743",
+"renesas,rcar-gen2-scifa", "renesas,scifa";
+   reg = <0 0xe6c7 0 64>;
+   interrupts = ;
+   clocks = <_clks R8A7743_CLK_SCIFA3>;
+   clock-names = "fck";
+   dmas = < 0x1b>, < 0x1c>,
+  < 0x1b>, < 0x1c>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   scifa4: serial@e6c78000 {
+   compatible = "renesas,scifa-r8a7743",
+"renesas,rcar-gen2-scifa", "renesas,scifa";
+   reg = <0 0xe6c78000 0 64>;
+   interrupts = ;
+   clocks = <_clks R8A7743_CLK_SCIFA4>;
+   clock-names = "fck";
+   dmas = < 0x1f>, < 0x20>,
+  < 0x1f>, < 0x20>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   scifa5: serial@e6c8 {
+   compatible = "renesas,scifa-r8a7743",
+"renesas,rcar-gen2-scifa", "renesas,scifa";
+   reg = <0 0xe6c8 0 64>;
+   interrupts = ;
+   clocks = <_clks R8A7743_CLK_SCIFA5>;
+   clock-names = "fck";
+   dmas = < 0x23>, < 0x24>,
+  < 0x23>, < 0x24>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   scifb0: serial@e6c2 {
+   compatible = "renesas,scifb-r8a7743",
+"renesas,rcar-gen2-scifb", "renesas,scifb";
+   reg = <0 0xe6c2 0 64>;
+   interrupts = ;
+   clocks = <_clks R8A7743_CLK_SCIFB0>;
+   

[PATCH RFC 6/8] ARM: dts: r8a7743: add SYS-DMAC support

[Sergei Shtylyov]

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

Based on the original (and large) patch by Dmitry Shifrin
.

Signed-off-by: Sergei Shtylyov 

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

Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -90,6 +90,70 @@
#power-domain-cells = <1>;
};
 
+   dmac0: dma-controller@e670 {
+   compatible = "renesas,dmac-r8a7743",
+"renesas,rcar-dmac";
+   reg = <0 0xe670 0 0x2>;
+   interrupts = ;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7",
+   "ch8", "ch9", "ch10", "ch11",
+   "ch12", "ch13", "ch14";
+   clocks = <_clks R8A7743_CLK_SYS_DMAC0>;
+   clock-names = "fck";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   #dma-cells = <1>;
+   dma-channels = <15>;
+   };
+
+   dmac1: dma-controller@e672 {
+   compatible = "renesas,dmac-r8a7743",
+"renesas,rcar-dmac";
+   reg = <0 0xe672 0 0x2>;
+   interrupts = ;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7",
+   "ch8", "ch9", "ch10", "ch11",
+   "ch12", "ch13", "ch14";
+   clocks = <_clks R8A7743_CLK_SYS_DMAC1>;
+   clock-names = "fck";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   #dma-cells = <1>;
+   dma-channels = <15>;
+   };
+
/* Special CPG clocks */
cpg_clocks: cpg_clocks@e615 {
compatible = "renesas,r8a7743-cpg-clocks",

[PATCH RFC 4/8] ARM: shmobile: r8a7743: basic SoC support

[Sergei Shtylyov]

Add minimal support for the RZ/G1M (R8A7743) SoC.

Based on the original (and large) patch by Dmitry Shifrin
.

Signed-off-by: Sergei Shtylyov 

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

Index: renesas/arch/arm/mach-shmobile/Kconfig
===
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -68,6 +68,11 @@ config ARCH_R8A7740
select ARCH_RMOBILE
select RENESAS_INTC_IRQPIN
 
+config ARCH_R8A7743
+   bool "RZ/G1M (R8A77430)"
+   select ARCH_RCAR_GEN2
+   select I2C
+
 config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
Index: renesas/arch/arm/mach-shmobile/Makefile
===
--- renesas.orig/arch/arm/mach-shmobile/Makefile
+++ renesas/arch/arm/mach-shmobile/Makefile
@@ -9,6 +9,7 @@ obj-y   := timer.o
 obj-$(CONFIG_ARCH_SH73A0)  += setup-sh73a0.o
 obj-$(CONFIG_ARCH_R8A73A4) += setup-r8a73a4.o
 obj-$(CONFIG_ARCH_R8A7740) += setup-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7743) += setup-r8a7743.o
 obj-$(CONFIG_ARCH_R8A7778) += setup-r8a7778.o
 obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o pm-r8a7779.o
 obj-$(CONFIG_ARCH_R8A7790) += setup-r8a7790.o
Index: renesas/arch/arm/mach-shmobile/setup-r8a7743.c
===
--- /dev/null
+++ renesas/arch/arm/mach-shmobile/setup-r8a7743.c
@@ -0,0 +1,34 @@
+/*
+ * r8a7743 processor support
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation; of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+#include 
+
+#include "common.h"
+#include "rcar-gen2.h"
+
+static const char * const r8a7743_boards_compat_dt[] __initconst = {
+   "renesas,r8a7743",
+   NULL,
+};
+
+DT_MACHINE_START(R8A7743_DT, "Generic R8A7743 (Flattened Device Tree)")
+   .init_early = shmobile_init_delay,
+   .init_time  = rcar_gen2_timer_init,
+   .init_late  = shmobile_init_late,
+   .reserve= rcar_gen2_reserve,
+   .dt_compat  = r8a7743_boards_compat_dt,
+MACHINE_END

[PATCH RFC 5/8] ARM: dts: r8a7743: initial SoC device tree

[Sergei Shtylyov]

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

Based on the original (and large) patch by Dmitry Shifrin
.

Signed-off-by: Sergei Shtylyov 

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

Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,210 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "renesas,r8a7743";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0>;
+   clock-frequency = <15>;
+   clocks = <_clocks R8A7743_CLK_Z>;
+   power-domains = < R8A7743_PD_CA15_CPU0>;
+   next-level-cache = <_CA15>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <1>;
+   clock-frequency = <15>;
+   power-domains = < R8A7743_PD_CA15_CPU1>;
+   next-level-cache = <_CA15>;
+   };
+
+   L2_CA15: cache-controller@0 {
+   compatible = "cache";
+   reg = <0>;
+   cache-unified;
+   cache-level = <2>;
+   power-domains = < R8A7743_PD_CA15_SCU>;
+   };
+   };
+
+   soc {
+   compatible = "simple-bus";
+   interrupt-parent = <>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   gic: interrupt-controller@f1001000 {
+   compatible = "arm,gic-400";
+   #interrupt-cells = <3>;
+   #address-cells = <0>;
+   interrupt-controller;
+   reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+   interrupts = ;
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+,
+,
+;
+   };
+
+   sysc: system-controller@e618 {
+   compatible = "renesas,r8a7743-sysc";
+   reg = <0 0xe618 0 0x0200>;
+   #power-domain-cells = <1>;
+   };
+
+   /* Special CPG clocks */
+   cpg_clocks: cpg_clocks@e615 {
+   compatible = "renesas,r8a7743-cpg-clocks",
+"renesas,rcar-gen2-cpg-clocks";
+   reg = <0 0xe615 0 0x1000>;
+   clocks = <_clk _extal_clk>;
+   #clock-cells = <1>;
+   clock-output-names = "main", "pll0", "pll1", "pll3",
+"lb", "qspi", "sdh", "sd0", "z",
+"rcan";
+   #power-domain-cells = <0>;
+   };
+
+   /* Fixed factor clocks */
+   pll1_div2_clk: pll1_div2 {
+   compatible = "fixed-factor-clock";
+   clocks = <_clocks R8A7743_CLK_PLL1>;
+   #clock-cells = <0>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+   zs_clk: zs {
+   compatible = "fixed-factor-clock";
+   clocks = <_clocks R8A7743_CLK_PLL1>;
+   #clock-cells = <0>;
+   clock-div = <6>;
+   clock-mult = <1>;
+   };
+   p_clk: p {
+   compatible = "fixed-factor-clock";
+   clocks = <_clocks R8A7743_CLK_PLL1>;
+   #clock-cells = <0>;
+   clock-div = <24>;
+   clock-mult = 

[PATCH RFC 3/8] soc: renesas: rcar-sysc: add R8A7743 support

[Sergei Shtylyov]

Add support for RZ/G1M (R8A7743) SoC power areas to the SYSC driver.

Based on the original (and large) patch by Dmitry Shifrin
.

Signed-off-by: Sergei Shtylyov 

---
 drivers/soc/renesas/Makefile   |1 +
 drivers/soc/renesas/r8a7743-sysc.c |   32 
 drivers/soc/renesas/rcar-sysc.c|3 +++
 drivers/soc/renesas/rcar-sysc.h|1 +
 4 files changed, 37 insertions(+)

Index: renesas/drivers/soc/renesas/r8a7743-sysc.c
===
--- /dev/null
+++ renesas/drivers/soc/renesas/r8a7743-sysc.c
@@ -0,0 +1,32 @@
+/*
+ * Renesas RZ/G1M System Controller
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation; of the License.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "rcar-sysc.h"
+
+static const struct rcar_sysc_area r8a7743_areas[] __initconst = {
+   { "always-on",  0, 0, R8A7743_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
+   { "ca15-scu",   0x180, 0, R8A7743_PD_CA15_SCU,  R8A7743_PD_ALWAYS_ON,
+ PD_SCU },
+   { "ca15-cpu0",   0x40, 0, R8A7743_PD_CA15_CPU0, R8A7743_PD_CA15_SCU,
+ PD_CPU_NOCR },
+   { "ca15-cpu1",   0x40, 1, R8A7743_PD_CA15_CPU1, R8A7743_PD_CA15_SCU,
+ PD_CPU_NOCR },
+   { "sgx", 0xc0, 0, R8A7743_PD_SGX,   R8A7743_PD_ALWAYS_ON },
+};
+
+const struct rcar_sysc_info r8a7743_sysc_info __initconst = {
+   .areas = r8a7743_areas,
+   .num_areas = ARRAY_SIZE(r8a7743_areas),
+};
Index: renesas/drivers/soc/renesas/Makefile
===
--- renesas.orig/drivers/soc/renesas/Makefile
+++ renesas/drivers/soc/renesas/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_ARCH_R8A7743) += rcar-sysc.o r8a7743-sysc.o
 obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
 obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
 obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
Index: renesas/drivers/soc/renesas/rcar-sysc.c
===
--- renesas.orig/drivers/soc/renesas/rcar-sysc.c
+++ renesas/drivers/soc/renesas/rcar-sysc.c
@@ -275,6 +275,9 @@ finalize:
 }
 
 static const struct of_device_id rcar_sysc_matches[] = {
+#ifdef CONFIG_ARCH_R8A7743
+   { .compatible = "renesas,r8a7743-sysc", .data = _sysc_info },
+#endif
 #ifdef CONFIG_ARCH_R8A7779
{ .compatible = "renesas,r8a7779-sysc", .data = _sysc_info },
 #endif
Index: renesas/drivers/soc/renesas/rcar-sysc.h
===
--- renesas.orig/drivers/soc/renesas/rcar-sysc.h
+++ renesas/drivers/soc/renesas/rcar-sysc.h
@@ -50,6 +50,7 @@ struct rcar_sysc_info {
unsigned int num_areas;
 };
 
+extern const struct rcar_sysc_info r8a7743_sysc_info;
 extern const struct rcar_sysc_info r8a7779_sysc_info;
 extern const struct rcar_sysc_info r8a7790_sysc_info;
 extern const struct rcar_sysc_info r8a7791_sysc_info;

[PATCH RFC 2/8] ARM: shmobile: r8a7743: add power domain index macros

[Sergei Shtylyov]

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

Based on the original (and large) patch by Dmitry Shifrin
.

Signed-off-by: Sergei Shtylyov 

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

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

[PATCH RFC 1/8] ARM: shmobile: r8a7743: add clock index macros

[Sergei Shtylyov]

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

Based on the original (and large) patch by Dmitry Shifrin
.

Signed-off-by: Sergei Shtylyov 

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

Index: renesas/include/dt-bindings/clock/r8a7743-clock.h
===
--- /dev/null
+++ renesas/include/dt-bindings/clock/r8a7743-clock.h
@@ -0,0 +1,157 @@
+/*
+ * Copyright 2013 Ideas On Board SPRL
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_R8A7743_H__
+#define __DT_BINDINGS_CLOCK_R8A7743_H__
+
+/* CPG */
+#define R8A7743_CLK_MAIN   0
+#define R8A7743_CLK_PLL0   1
+#define R8A7743_CLK_PLL1   2
+#define R8A7743_CLK_PLL3   3
+#define R8A7743_CLK_LB 4
+#define R8A7743_CLK_QSPI   5
+#define R8A7743_CLK_SDH6
+#define R8A7743_CLK_SD07
+#define R8A7743_CLK_Z  8
+#define R8A7743_CLK_RCAN   9
+
+/* MSTP0 */
+#define R8A7743_CLK_MSIOF0 0
+
+/* MSTP1 */
+#define R8A7743_CLK_VCP0   1
+#define R8A7743_CLK_VPC0   3
+#define R8A7743_CLK_TMU1   11
+#define R8A7743_CLK_3DG12
+#define R8A7743_CLK_2DDMAC 15
+#define R8A7743_CLK_FDP1_1 18
+#define R8A7743_CLK_FDP1_0 19
+#define R8A7743_CLK_TMU3   21
+#define R8A7743_CLK_TMU2   22
+#define R8A7743_CLK_CMT0   24
+#define R8A7743_CLK_TMU0   25
+#define R8A7743_CLK_VSP1_DU1   27
+#define R8A7743_CLK_VSP1_DU0   28
+#define R8A7743_CLK_VSP1_S 31
+
+/* MSTP2 */
+#define R8A7743_CLK_SCIFA2 2
+#define R8A7743_CLK_SCIFA1 3
+#define R8A7743_CLK_SCIFA0 4
+#define R8A7743_CLK_MSIOF2 5
+#define R8A7743_CLK_SCIFB0 6
+#define R8A7743_CLK_SCIFB1 7
+#define R8A7743_CLK_MSIOF1 8
+#define R8A7743_CLK_SCIFB2 16
+#define R8A7743_CLK_SYS_DMAC1  18
+#define R8A7743_CLK_SYS_DMAC0  19
+
+/* MSTP3 */
+#define R8A7743_CLK_TPU0   4
+#define R8A7743_CLK_SDHI2  11
+#define R8A7743_CLK_SDHI1  12
+#define R8A7743_CLK_SDHI0  14
+#define R8A7743_CLK_MMCIF0 15
+#define R8A7743_CLK_IIC0   18
+#define R8A7743_CLK_PCIEC  19
+#define R8A7743_CLK_IIC1   23
+#define R8A7743_CLK_SSUSB  28
+#define R8A7743_CLK_CMT1   29
+#define R8A7743_CLK_USBDMAC0   30
+#define R8A7743_CLK_USBDMAC1   31
+
+/* MSTP4 */
+#define R8A7743_CLK_IRQC   7
+
+/* MSTP5 */
+#define R8A7743_CLK_AUDIO_DMAC11
+#define R8A7743_CLK_AUDIO_DMAC02
+#define R8A7743_CLK_THERMAL22
+#define R8A7743_CLK_PWM23
+
+/* MSTP7 */
+#define R8A7743_CLK_EHCI   3
+#define R8A7743_CLK_HSUSB  4
+#define R8A7743_CLK_HSCIF2 13
+#define R8A7743_CLK_SCIF5  14
+#define R8A7743_CLK_SCIF4  15
+#define R8A7743_CLK_HSCIF1 16
+#define R8A7743_CLK_HSCIF0 17
+#define R8A7743_CLK_SCIF3  18
+#define R8A7743_CLK_SCIF2  19
+#define R8A7743_CLK_SCIF1  20
+#define R8A7743_CLK_SCIF0  21
+#define R8A7743_CLK_DU123
+#define R8A7743_CLK_DU024
+#define R8A7743_CLK_LVDS0  26
+
+/* MSTP8 */
+#define R8A7743_CLK_IPMMU_SGX  0
+#define R8A7743_CLK_VIN2   9
+#define R8A7743_CLK_VIN1   10
+#define R8A7743_CLK_VIN0   11
+#define R8A7743_CLK_ETHER  13
+#define R8A7743_CLK_SATA1  14
+#define R8A7743_CLK_SATA0  15
+
+/* MSTP9 */
+#define R8A7743_CLK_GPIO7  4
+#define R8A7743_CLK_GPIO6  5
+#define R8A7743_CLK_GPIO5  7
+#define R8A7743_CLK_GPIO4  8
+#define R8A7743_CLK_GPIO3  9
+#define R8A7743_CLK_GPIO2  10
+#define R8A7743_CLK_GPIO1  11
+#define R8A7743_CLK_GPIO0  12
+#define R8A7743_CLK_RCAN1  15
+#define R8A7743_CLK_RCAN0  16
+#define R8A7743_CLK_QSPI_MOD   17
+#define R8A7743_CLK_I2C5   25
+#define R8A7743_CLK_IICDVFS26
+#define R8A7743_CLK_I2C4   27
+#define R8A7743_CLK_I2C3   28
+#define R8A7743_CLK_I2C2   29
+#define 

[PATCH RFC 0/8] Add R8A7743/SK-RZG1M board support

[Sergei Shtylyov]

Hello.

   Here's the set of 8 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160916-v4.8-rc6' tag. I'm adding the device tree support for
the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
seems  identical to the R8A7791/Porter board. Only serial console is supported
for now, no DHCP/NFS support yet, it will be done RSN... :-)

[1/8] ARM: shmobile: r8a7743: add clock index macros
[2/8] ARM: shmobile: r8a7743: add power domain index macros
[3/8] soc: renesas: rcar-sysc: add R8A7743 support
[4/8] ARM: shmobile: r8a7743: basic SoC support
[5/8] ARM: dts: r8a7743: initial SoC device tree
[6/8] ARM: dts: r8a7743: add SYS-DMAC support
[7/8] ARM: dts: r8a7743: add [H]SCIF support
[8/8] ARM: dts: sk-rzg1m: initial device tree

WBR, Sergei

[PATCH 3/3] ARM: dts: gose: add composite video input

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7793-gose.dts | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index e22d63c..981f0fe 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -379,6 +379,11 @@
groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
function = "vin0";
};
+
+   vin1_pins: vin1 {
+   groups = "vin1_data8", "vin1_clk";
+   function = "vin1";
+   };
 };
 
  {
@@ -504,6 +509,19 @@
reg = <0x12>;
};
 
+   composite-in@20 {
+   compatible = "adi,adv7180";
+   reg = <0x20>;
+   remote = <>;
+
+   port {
+   adv7180: endpoint {
+   bus-width = <8>;
+   remote-endpoint = <>;
+   };
+   };
+   };
+
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
@@ -599,3 +617,21 @@
};
};
 };
+
+/* composite video input */
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vin1ep: endpoint {
+   remote-endpoint = <>;
+   bus-width = <8>;
+   };
+   };
+};
-- 
2.9.3

[PATCH 2/3] ARM: dts: gose: add HDMI input

[Ulrich Hecht]

Identical to the setup on Lager.

Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7793-gose.dts | 41 ++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index 90af186..e22d63c 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -374,6 +374,11 @@
groups = "audio_clk_a";
function = "audio_clk";
};
+
+   vin0_pins: vin0 {
+   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
+   function = "vin0";
+   };
 };
 
  {
@@ -531,6 +536,21 @@
};
};
 
+   hdmi-in@4c {
+   compatible = "adi,adv7612";
+   reg = <0x4c>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+   remote = <>;
+   default-input = <0>;
+
+   port {
+   adv7612: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
+
eeprom@50 {
compatible = "renesas,r1ex24002", "atmel,24c02";
reg = <0x50>;
@@ -558,3 +578,24 @@
  {
shared-pin;
 };
+
+/* HDMI video input */
+ {
+   status = "okay";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vin0ep: endpoint {
+   remote-endpoint = <>;
+   bus-width = <24>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
-- 
2.9.3

[PATCH 1/3] ARM: dts: r8a7793: Enable VIN0, VIN1

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7793.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 8d02aac..0898668 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -30,6 +30,8 @@
i2c7 = 
i2c8 = 
spi0 = 
+   vin0 = 
+   vin1 = 
};
 
cpus {
@@ -852,6 +854,24 @@
status = "disabled";
};
 
+   vin0: video@e6ef {
+   compatible = "renesas,vin-r8a7793";
+   reg = <0 0xe6ef 0 0x1000>;
+   interrupts = ;
+   clocks = <_clks R8A7793_CLK_VIN0>;
+   power-domains = < R8A7793_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   vin1: video@e6ef1000 {
+   compatible = "renesas,vin-r8a7793";
+   reg = <0 0xe6ef1000 0 0x1000>;
+   interrupts = ;
+   clocks = <_clks R8A7793_CLK_VIN1>;
+   power-domains = < R8A7793_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
qspi: spi@e6b1 {
compatible = "renesas,qspi-r8a7793", "renesas,qspi";
reg = <0 0xe6b1 0 0x2c>;
-- 
2.9.3

[PATCH 1/2] ARM: dts: lager: Add entries for VIN HDMI input support

[Ulrich Hecht]

From: William Towle 

Add DT entries for vin0, vin0_pins, and adv7612.

Sets the 'default-input' property for ADV7612, enabling image and video
capture without the need to have userspace specifying routing.

Signed-off-by: William Towle 
Signed-off-by: Rob Taylor 
[uli: added interrupt, renamed endpoint, merged default-input]
Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 39 +
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 52b56fc..fc9d129 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -427,6 +427,11 @@
function = "usb2";
};
 
+   vin0_pins: vin0 {
+   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
+   function = "vin0";
+   };
+
vin1_pins: vin1 {
groups = "vin1_data8", "vin1_clk";
function = "vin1";
@@ -651,6 +656,21 @@
};
};
};
+
+   hdmi-in@4c {
+   compatible = "adi,adv7612";
+   reg = <0x4c>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+   remote = <>;
+   default-input = <0>;
+
+   port {
+   adv7612: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
 };
 
  {
@@ -722,6 +742,25 @@
status = "okay";
 };
 
+/* HDMI video input */
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "ok";
+
+   port {
+   vin0ep0: endpoint {
+   remote-endpoint = <>;
+   bus-width = <24>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
+
 /* composite video input */
  {
pinctrl-0 = <_pins>;
-- 
2.9.3

[PATCH 0/3] r8a7793 Gose video input support

[Ulrich Hecht]

Hi!

This is a by-the-datasheet implementation of analog and digital video input
on the Gose board.

I don't have that hardware, so if somebody could test this, I would
appreciate it.  To get the digital part to work, use Hans's R-Car branch
(https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=rcar) plus the
"media: adv7604: automatic "default-input" selection" patch.

CU
Uli


Ulrich Hecht (3):
  ARM: dts: r8a7793: Enable VIN0, VIN1
  ARM: dts: gose: add HDMI input
  ARM: dts: gose: add composite video input

 arch/arm/boot/dts/r8a7793-gose.dts | 77 ++
 arch/arm/boot/dts/r8a7793.dtsi | 20 ++
 2 files changed, 97 insertions(+)

-- 
2.9.3

[PATCH 0/2] Renesas Lager/Koelsch HDMI input

[Ulrich Hecht]

Hi!

This series enables HDMI input on the Lager and Koelsch boards.
It sits on renesas-devel-20160913-v4.8-rc6 and also applies to the media
tree.

Testing this on a Lager board with v4l2-compliance on top of Hans's R-Car
branch (https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=rcar) with
"media: adv7604: automatic "default-input" selection" applied, it gets a
perfect score (172/172 pass).

CU
Uli


Hans Verkuil (1):
  ARM: dts: koelsch: add HDMI input

William Towle (1):
  ARM: dts: lager: Add entries for VIN HDMI input support

 arch/arm/boot/dts/r8a7790-lager.dts   | 39 +
 arch/arm/boot/dts/r8a7791-koelsch.dts | 41 +++
 2 files changed, 80 insertions(+)

-- 
2.9.3

[PATCH 2/2] ARM: dts: koelsch: add HDMI input

[Ulrich Hecht]

From: Hans Verkuil 

Add support in the dts for the HDMI input. Based on the Lager dts
patch from Ulrich Hecht.

Signed-off-by: Hans Verkuil 
[uli: removed "renesas," prefixes from pfc nodes]
Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f8a7d09..45b8b5f 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -393,6 +393,11 @@
function = "usb1";
};
 
+   vin0_pins: vin0 {
+   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
+   function = "vin0";
+   };
+
vin1_pins: vin1 {
groups = "vin1_data8", "vin1_clk";
function = "vin1";
@@ -596,6 +601,21 @@
};
};
 
+   hdmi-in@4c {
+   compatible = "adi,adv7612";
+   reg = <0x4c>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+   remote = <>;
+   default-input = <0>;
+
+   port {
+   adv7612: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
+
eeprom@50 {
compatible = "renesas,24c02";
reg = <0x50>;
@@ -672,6 +692,27 @@
cpu0-supply = <_dvfs>;
 };
 
+/* HDMI video input */
+ {
+   status = "okay";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vin0ep: endpoint {
+   remote-endpoint = <>;
+   bus-width = <24>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
+
 /* composite video input */
  {
status = "okay";
-- 
2.9.3

RE: [PATCH 2/4] ARM: dts: r7s72100: add mmcif to device tree

[Chris Brandt]

Hi Geert,

On 9/15/2016, Geert Uytterhoeven wrote:
> > +   interrupts =  > + GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>;
> 
> The bindings do not say anything about interrupts (hence that should be
> added).

I'm sorry, I'm confused...
Are you saying:
 A) I forgot to add something?
 B) As a general statement, the renesas,mmcif.txt file doesn't say anything 
about interrupts?


> The driver handles either 1 combined or 2 separate interrupts.
> The datasheet says MMC has 3 interrupt requests, though?

The IP itself has 3 interrupts:
 #1. MMC0,299: Card detect
 #2. MMC1,300: Status Change
 #3. MMC2,301: Error

Many of the 'Linux' SoC devices that use this MMC (SH4, R-Car) are only ever 
going to use eMMC, so the card detection portion of the IP was irrelevant. I 
agree this is the same case for the RZ/A (who would ever use an MMC card now a 
days?)
The 'smaller' SoCs kept it in (SH2A, RZ/A1) but the 'bigger' SoCs left it out 
(SH4A, R-Car).

The only way to enable that interrupt is to write to the CE_DETECT register 
(offset 0x70) which the driver doesn't do.

Howeverif you look in sh_mmcif.h, you'll see that same offset (0x70) is 
called CE_CLK_CTRL2

#define MMCIF_CE_CLK_CTRL2  0x0070

Which it only writes to if 'clk_ctrl2_enable' is designated.

if (host->clk_ctrl2_enable)
sh_mmcif_writel(host->addr, MMCIF_CE_CLK_CTRL2, 0x0F0F);

And, I see no Renesas SoC that ever sets that or would ever use it so I can't 
even tell you what SoC that was for (SH4, SH-Mobile, ARM)


So after all that ranting...I see no need to support card detect for MMC for 
the RZ/A (or any future RZ) so I'd like to just leave it as is.

Do you agree?

Chris

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Laurent Pinchart]

Hi Robin,

On Friday 16 Sep 2016 13:49:21 Robin Murphy wrote:
> On 16/09/16 13:05, Laurent Pinchart wrote:
> [...]
> 
>  One concern I have is that we might get an awkward situation if we ever
>  encounter one DMA engine hardware that is used in different systems
>  that all have an IOMMU, but on some of them the connection between the
>  DMA master and the slave FIFO bypasses the IOMMU while on others the
>  IOMMU is required.
> >>> 
> >>> Do you mean systems where some of the channels of a specific DMA engine
> >>> go through the IOMMU while others do not ? We indeed have no solution
> >>> today for such a situation.
> >>> 
> >>> The problem is a bit broader than that, we'll also have an issue with
> >>> DMA engines that have different channels served by different IOMMUs. I
> >>> recall discussing this in the past with you, and the solution you
> >>> proposed was to add a channel index to struct dma_attrs seems good to
> >>> me. To support the case where some channels don't go through an IOMMU we
> >>> would only need support for null entries in the IOMMUs list associated
> >>> with a device (for instance in the DT case null entries in the iommus
> >>> property).
> >> 
> >> I think at that point we just create the channels as child devices of
> >> the main dmaengine device so they each get their own DMA ops, and can do
> >> whatever. The Qualcomm HIDMA driver already does that for a very similar
> >> reason (so that the IOMMU can map individual channels into different
> >> guest VMs).
> > 
> > That's another option, but it seems more like a workaround to me, instead
> > of a proper solution to fix the more global problem of multiple memory
> > paths within a single device. I have other hardware devices that can act
> > as bus masters through different paths (for instance a display-related
> > device that fetches data and commands through different paths). Luckily
> > so far all those paths are served by the same IOMMU, but there's no
> > guarantee this will remain true in the future. Furthermore, even today,
> > the IOMMU connected to that device has the ability to selectively enable
> > and disable its ports. I have to keep them all enabled due to the lack of
> > channel information in the DMA mapping and IOMMU APIs, leading to
> > increased power consumption.
> 
> Indeed, I think both the Exynos and Rockchip IOMMU drivers already do
> cater for a device mastering though multiple discrete IOMMUs, not being
> the fancy multi-port multi-context ones like yours and mine.
> 
> I guess what we could really do with is a decent abstraction of
> multi-master peripherals at the device level; a "threads within the same
> process" sort of granularity, as it were. I'd envisage it more along the
> lines of how we handle NUMA, i.e. dma_map_page_attrs(...) becomes a
> wrapper for dma_map_page_attrs_multi(..., CHANNEL_ALL), and trickier
> users can call the latter with the a more specific channel(s) argument
> (maybe it's a bitmask rather than an index).

That's pretty much what I've discussed with Arnd in the past, except that we 
were planning to add the channel to struct dma_attrs. Hence my disappointment 
seeing the structure go away.

> Meanwhile, dev->archdata.dma_ops may point to a device-specific array of
> dma_map_ops, which the DMA API backend iterates over if necessary.
> 
> Strangely, that doesn't actually sound too horrible.

-- 
Regards,

Laurent Pinchart

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Laurent Pinchart]

Hi Arnd,

On Friday 16 Sep 2016 14:22:31 Arnd Bergmann wrote:
> On Friday, September 16, 2016 3:09:29 PM CEST Laurent Pinchart wrote:
> >> I wasn't thinking quite that far, though that is also a theoretical
> >> problem. However, the simple solution would be to have a bit in the DMA
> >> specifier let the driver know whether translation is needed or not.
> >> 
> >> The simpler case I was thinking of is where the entire DMA engine
> >> either goes through an IOMMU or doesn't (depending on the integration
> >> into the SoC), so we'd have to find out through some DT property
> >> or compatible string in the DMA enginen driver.
> > 
> > Don't we already get that information from the iommus DT property ? If the
> > DMA engine goes through an IOMMU the property will be set, otherwise it
> > will not.
>
> It depends. A dmaengine typically at least has two DMA masters,
> possibly more. It's likely that some dmaengine implementations are
> connected to RAM through an IOMMU, but have direct access to an
> I/O bus for the slave FIFOs.

Sure, but I expect the DMA engine DT node to list all the relevant IOMMU(s) 
(if any) in the iommus property in a way that allows the DMA engine driver to 
know what IOMMU port is used for what purpose. It will then be up to the DMA 
engine driver to select the right port identifier to pass to the DMA mapping 
API.

I'm not sure how this would work with Robin's proposal of creating one device 
per channel though, as there would still be a single node in DT for the DMA 
engine device. Furthermore, a single channel might indeed have multiple DMA 
masters, not all of them being served by an IOMMU. We would thus still need 
memory port identifiers in the DMA mapping API.

> >>> The problem is a bit broader than that, we'll also have an issue with
> >>> DMA engines that have different channels served by different IOMMUs.
> >> 
> >> Do you mean a theoretical problem, or a chip that you already know
> >> exists?
> > 
> > That's theoretical. The problem I'm facing today is a DMA engine whose
> > channels are served by different ports of the same IOMMU. This works in a
> > suboptimal way because I have to keep all the IOMMU ports enabled
> > regardless of whether they're used or not, as the DMA engine and IOMMU
> > APIs don't carry channel information.
> 
> Ok

-- 
Regards,

Laurent Pinchart

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Robin Murphy]

On 16/09/16 13:05, Laurent Pinchart wrote:
[...]
 One concern I have is that we might get an awkward situation if we ever
 encounter one DMA engine hardware that is used in different systems that
 all have an IOMMU, but on some of them the connection between the DMA
 master and the slave FIFO bypasses the IOMMU while on others the IOMMU
 is required.
>>>
>>> Do you mean systems where some of the channels of a specific DMA engine go
>>> through the IOMMU while others do not ? We indeed have no solution today
>>> for such a situation.
>>>
>>> The problem is a bit broader than that, we'll also have an issue with DMA
>>> engines that have different channels served by different IOMMUs. I recall
>>> discussing this in the past with you, and the solution you proposed was to
>>> add a channel index to struct dma_attrs seems good to me. To support the
>>> case where some channels don't go through an IOMMU we would only need
>>> support for null entries in the IOMMUs list associated with a device (for
>>> instance in the DT case null entries in the iommus property).
>>
>> I think at that point we just create the channels as child devices of
>> the main dmaengine device so they each get their own DMA ops, and can do
>> whatever. The Qualcomm HIDMA driver already does that for a very similar
>> reason (so that the IOMMU can map individual channels into different
>> guest VMs).
> 
> That's another option, but it seems more like a workaround to me, instead of 
> a 
> proper solution to fix the more global problem of multiple memory paths 
> within 
> a single device. I have other hardware devices that can act as bus masters 
> through different paths (for instance a display-related device that fetches 
> data and commands through different paths). Luckily so far all those paths 
> are 
> served by the same IOMMU, but there's no guarantee this will remain true in 
> the future. Furthermore, even today, the IOMMU connected to that device has 
> the ability to selectively enable and disable its ports. I have to keep them 
> all enabled due to the lack of channel information in the DMA mapping and 
> IOMMU APIs, leading to increased power consumption.

Indeed, I think both the Exynos and Rockchip IOMMU drivers already do
cater for a device mastering though multiple discrete IOMMUs, not being
the fancy multi-port multi-context ones like yours and mine.

I guess what we could really do with is a decent abstraction of
multi-master peripherals at the device level; a "threads within the same
process" sort of granularity, as it were. I'd envisage it more along the
lines of how we handle NUMA, i.e. dma_map_page_attrs(...) becomes a
wrapper for dma_map_page_attrs_multi(..., CHANNEL_ALL), and trickier
users can call the latter with the a more specific channel(s) argument
(maybe it's a bitmask rather than an index). Meanwhile,
dev->archdata.dma_ops may point to a device-specific array of
dma_map_ops, which the DMA API backend iterates over if necessary.

Strangely, that doesn't actually sound too horrible.

Robin.

> 
>>> Now I see that struct dma_attrs has been replaced by unsigned long in
>>>
>>> commit 00085f1efa387a8ce100e3734920f7639c80caa3
>>> Author: Krzysztof Kozlowski 
>>> Date:   Wed Aug 3 13:46:00 2016 -0700
>>>
>>> dma-mapping: use unsigned long for dma_attrs
>>>
>>> We still have enough bits to reserve some of them for a channel number,
>>> but I'm not very happy with that patch as I can see how a future proposal
>>> to handle the channel number through the DMA attributes will get rejected
>>> on the grounds of bits starvation then :-(
>>>
 I don't have any idea for how this could be handled in a generic way, so
 my best answer here is to hope we never get there, and if we do, handle
 it using some local hack in the driver.
> 

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Arnd Bergmann]

On Friday, September 16, 2016 3:09:29 PM CEST Laurent Pinchart wrote:
> > I wasn't thinking quite that far, though that is also a theoretical
> > problem. However, the simple solution would be to have a bit in the DMA
> > specifier let the driver know whether translation is needed or not.
> > 
> > The simpler case I was thinking of is where the entire DMA engine
> > either goes through an IOMMU or doesn't (depending on the integration
> > into the SoC), so we'd have to find out through some DT property
> > or compatible string in the DMA enginen driver.
> 
> Don't we already get that information from the iommus DT property ? If the 
> DMA 
> engine goes through an IOMMU the property will be set, otherwise it will not.

It depends. A dmaengine typically at least has two DMA masters,
possibly more. It's likely that some dmaengine implementations are
connected to RAM through an IOMMU, but have direct access to an
I/O bus for the slave FIFOs.

> > > The problem is a bit broader than that, we'll also have an issue with DMA
> > > engines that have different channels served by different IOMMUs.
> > 
> > Do you mean a theoretical problem, or a chip that you already know exists?
> 
> That's theoretical. The problem I'm facing today is a DMA engine whose 
> channels are served by different ports of the same IOMMU. This works in a 
> suboptimal way because I have to keep all the IOMMU ports enabled regardless 
> of whether they're used or not, as the DMA engine and IOMMU APIs don't carry 
> channel information.

Ok

Arnd

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Laurent Pinchart]

Hi Arnd,

On Friday 16 Sep 2016 14:02:35 Arnd Bergmann wrote:
> On Friday, September 16, 2016 12:48:23 PM CEST Laurent Pinchart wrote:
> > On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> >> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> >>> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
>  On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> >>
> >> I had not looked at the series earlier, but this version looks entirely
> >> reasonable to me, so
> >> 
> >> Acked-by: Arnd Bergmann 
> >> 
> >> 
> >> One concern I have is that we might get an awkward situation if we ever
> >> encounter one DMA engine hardware that is used in different systems that
> >> all have an IOMMU, but on some of them the connection between the DMA
> >> master and the slave FIFO bypasses the IOMMU while on others the IOMMU
> >> is required.
> >
> > Do you mean systems where some of the channels of a specific DMA engine go
> > through the IOMMU while others do not ? We indeed have no solution today
> > for such a situation.
> 
> I wasn't thinking quite that far, though that is also a theoretical
> problem. However, the simple solution would be to have a bit in the DMA
> specifier let the driver know whether translation is needed or not.
> 
> The simpler case I was thinking of is where the entire DMA engine
> either goes through an IOMMU or doesn't (depending on the integration
> into the SoC), so we'd have to find out through some DT property
> or compatible string in the DMA enginen driver.

Don't we already get that information from the iommus DT property ? If the DMA 
engine goes through an IOMMU the property will be set, otherwise it will not.

> > The problem is a bit broader than that, we'll also have an issue with DMA
> > engines that have different channels served by different IOMMUs.
> 
> Do you mean a theoretical problem, or a chip that you already know exists?

That's theoretical. The problem I'm facing today is a DMA engine whose 
channels are served by different ports of the same IOMMU. This works in a 
suboptimal way because I have to keep all the IOMMU ports enabled regardless 
of whether they're used or not, as the DMA engine and IOMMU APIs don't carry 
channel information.

> > I recall discussing this in the past with you, and the solution you
> > proposed was to add a channel index to struct dma_attrs seems good to me.
> > To support the case where some channels don't go through an IOMMU we would
> > only need support for null entries in the IOMMUs list associated with a
> > device (for instance in the DT case null entries in the iommus property).
> > 
> > Now I see that struct dma_attrs has been replaced by unsigned long in
> > 
> > commit 00085f1efa387a8ce100e3734920f7639c80caa3
> > Author: Krzysztof Kozlowski 
> > Date:   Wed Aug 3 13:46:00 2016 -0700
> > 
> > dma-mapping: use unsigned long for dma_attrs
> > 
> > We still have enough bits to reserve some of them for a channel number,
> > but I'm not very happy with that patch as I can see how a future proposal
> > to handle the channel number through the DMA attributes will get rejected
> > on the grounds of bits starvation then :-(
> 
> Agreed, that can become interesting.

Does the above-mentioned patch really fix a performance, memory consumption or 
other issue ?

-- 
Regards,

Laurent Pinchart

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Laurent Pinchart]

Hi Rubin,

On Friday 16 Sep 2016 11:36:29 Robin Murphy wrote:
> On 16/09/16 10:48, Laurent Pinchart wrote:
> > On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> >> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> >>> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
>  On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> > Hi,
> > 
> > This series tries to solve the problem with DMA with device registers
> > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > recent patch '9575632 (dmaengine: make slave address physical)'
> > clarifies that DMA slave address provided by clients is the physical
> > address. This puts the task of mapping the DMA slave address from a
> > phys_addr_t to a dma_addr_t on the DMA engine.
> > 
> > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > the same and no special care is needed. However if you have a IOMMU
> > you need to map the DMA slave phys_addr_t to a dma_addr_t using
> > something like this.
> > 
> > This series is based on top of v4.8-rc1. And I'm hoping to be able to
> > collect a Ack from Russell King on patch 4/6 that adds the ARM
> > specific part and then be able to take the whole series through the
> > dmaengine tree. If this is not the best route I'm more then happy to
> > do it another way.
> > 
> > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting
> > with /dev/mmcblk1, i2c and the serial console which are devices behind
> > the iommu.
>  
>  As I said in last one, the dmaengine parts look fine to me. But to go
>  thru dmaengine tree I would need ACK on non dmaengine patches.
> >>> 
> >>> I havent heard back from this one and I am inclined to merge this one
> >>> now. If anyone has any objects, please speak up now...
> >>> 
> >>> Also ACKs welcome...
> >> 
> >> I had not looked at the series earlier, but this version looks entirely
> >> reasonable to me, so
> >> 
> >> Acked-by: Arnd Bergmann 
> >> 
> >> 
> >> One concern I have is that we might get an awkward situation if we ever
> >> encounter one DMA engine hardware that is used in different systems that
> >> all have an IOMMU, but on some of them the connection between the DMA
> >> master and the slave FIFO bypasses the IOMMU while on others the IOMMU
> >> is required.
> >
> > Do you mean systems where some of the channels of a specific DMA engine go
> > through the IOMMU while others do not ? We indeed have no solution today
> > for such a situation.
> > 
> > The problem is a bit broader than that, we'll also have an issue with DMA
> > engines that have different channels served by different IOMMUs. I recall
> > discussing this in the past with you, and the solution you proposed was to
> > add a channel index to struct dma_attrs seems good to me. To support the
> > case where some channels don't go through an IOMMU we would only need
> > support for null entries in the IOMMUs list associated with a device (for
> > instance in the DT case null entries in the iommus property).
> 
> I think at that point we just create the channels as child devices of
> the main dmaengine device so they each get their own DMA ops, and can do
> whatever. The Qualcomm HIDMA driver already does that for a very similar
> reason (so that the IOMMU can map individual channels into different
> guest VMs).

That's another option, but it seems more like a workaround to me, instead of a 
proper solution to fix the more global problem of multiple memory paths within 
a single device. I have other hardware devices that can act as bus masters 
through different paths (for instance a display-related device that fetches 
data and commands through different paths). Luckily so far all those paths are 
served by the same IOMMU, but there's no guarantee this will remain true in 
the future. Furthermore, even today, the IOMMU connected to that device has 
the ability to selectively enable and disable its ports. I have to keep them 
all enabled due to the lack of channel information in the DMA mapping and 
IOMMU APIs, leading to increased power consumption.

> > Now I see that struct dma_attrs has been replaced by unsigned long in
> > 
> > commit 00085f1efa387a8ce100e3734920f7639c80caa3
> > Author: Krzysztof Kozlowski 
> > Date:   Wed Aug 3 13:46:00 2016 -0700
> > 
> > dma-mapping: use unsigned long for dma_attrs
> > 
> > We still have enough bits to reserve some of them for a channel number,
> > but I'm not very happy with that patch as I can see how a future proposal
> > to handle the channel number through the DMA attributes will get rejected
> > on the grounds of bits starvation then :-(
> > 
> >> I don't have any idea for how this could be handled in a generic way, so
> >> my best answer here is to hope 

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Arnd Bergmann]

On Friday, September 16, 2016 12:48:23 PM CEST Laurent Pinchart wrote:
> On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> > On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> > > On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> > >> On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> > I had not looked at the series earlier, but this version looks entirely
> > reasonable to me, so
> > 
> > Acked-by: Arnd Bergmann 
> > 
> > 
> > One concern I have is that we might get an awkward situation if we ever
> > encounter one DMA engine hardware that is used in different systems that all
> > have an IOMMU, but on some of them the connection between the DMA master and
> > the slave FIFO bypasses the IOMMU while on others the IOMMU is required.
> 
> Do you mean systems where some of the channels of a specific DMA engine go 
> through the IOMMU while others do not ? We indeed have no solution today for 
> such a situation.

I wasn't thinking quite that far, though that is also a theoretical
problem. However, the simple solution would be to have a bit in the DMA
specifier let the driver know whether translation is needed or not.

The simpler case I was thinking of is where the entire DMA engine
either goes through an IOMMU or doesn't (depending on the integration
into the SoC), so we'd have to find out through some DT property
or compatible string in the DMA enginen driver.

> The problem is a bit broader than that, we'll also have an issue with DMA 
> engines that have different channels served by different IOMMUs.

Do you mean a theoretical problem, or a chip that you already know exists?

> I recall 
> discussing this in the past with you, and the solution you proposed was to 
> add 
> a channel index to struct dma_attrs seems good to me. To support the case 
> where some channels don't go through an IOMMU we would only need support for 
> null entries in the IOMMUs list associated with a device (for instance in the 
> DT case null entries in the iommus property).
> 
> Now I see that struct dma_attrs has been replaced by unsigned long in
> 
> commit 00085f1efa387a8ce100e3734920f7639c80caa3
> Author: Krzysztof Kozlowski 
> Date:   Wed Aug 3 13:46:00 2016 -0700
> 
> dma-mapping: use unsigned long for dma_attrs
> 
> We still have enough bits to reserve some of them for a channel number, but 
> I'm not very happy with that patch as I can see how a future proposal to 
> handle the channel number through the DMA attributes will get rejected on the 
> grounds of bits starvation then :-(

Agreed, that can become interesting.

Arnd

Re: [PATCH] arm64: dts: r8a7796 salvator-x: External SCIF3/HSCIF3 loop

[Geert Uytterhoeven]

Hi Simon,

On Fri, Sep 16, 2016 at 12:14 PM, Simon Horman  wrote:
> On Wed, Sep 14, 2016 at 06:47:41PM +0200, Ulrich Hecht wrote:
>> Add SCIF3 and HSCIF3 as two new serial ports to the r8a7796
>> Salvator-X DT file.
>>
>> Signed-off-by: Ulrich Hecht 
>
> Please repost once the (at least DT) dependencies have been merged
> (or at least reposted).

As this is for testing (H)SCIF only, and requires external wiring,
I think this is something we do not want to upstream.

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/4] ARM: dts: rskrza1: add mmc DT support

[Sergei Shtylyov]

On 9/15/2016 10:34 PM, Chris Brandt wrote:


Since the MMC and SDHI1 on the RSK share the same socket connector (CN1),
you cannot enabled MMC and SDHI1 at the same time. Therefore the status


   Enable.


has been set to disabled because SDHI is more popular with this board.
However, keeping this code in here serves as a good way to document how
the MMC on the RZ/A1 has been known to work for someone that does want
to use MMC instead of SDHI1.

A fixed 3.3 regulator is included because it is required by the mmc
driver.

Signed-off-by: Chris Brandt 

[...]

MBR, Sergei

Re: [PATCH v7 08/11] arm64: dts: r8a7796: add SDHI nodes

[Simon Horman]

On Fri, Sep 16, 2016 at 12:30:48PM +0200, Wolfram Sang wrote:
> On Tue, Sep 13, 2016 at 12:57:05PM +0200, Simon Horman wrote:
> > Add SDHI nodes to the DT of the r8a7796 SoC.
> > 
> > Based on the DT of the r8a7795 SoC.
> > 
> > Signed-off-by: Simon Horman 
> > Reviewed-by: Geert Uytterhoeven 
> 
> If you remove the two lines you removed from H3 already:

Thanks, done.

> Reviewed-by: Wolfram Sang 

Re: [PATCH v7 07/11] ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104

[Simon Horman]

On Fri, Sep 16, 2016 at 12:27:10PM +0200, Wolfram Sang wrote:
> On Tue, Sep 13, 2016 at 12:57:04PM +0200, Simon Horman wrote:
> > Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1}.
> > And the sd-uhs-sdr104 property to SDHI0.
> > 
> > Signed-off-by: Simon Horman 
> 
> If you drop sdr104 here for now as well:
> 
> Reviewed-by: Wolfram Sang 

Thanks, done.

The result is as follows:

From: Simon Horman 
Date: Tue, 13 Sep 2016 12:57:04 +0200
Subject: [PATCH] ARM: dts: alt: enable UHS for SDHI 0 & 1

Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1}.

Signed-off-by: Simon Horman 
Reviewed-by: Wolfram Sang 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7794-alt.dts | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794-alt.dts 
b/arch/arm/boot/dts/r8a7794-alt.dts
index 8d1b35afaf82..325d3f972c57 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -207,11 +207,25 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_uhs: sd0_uhs {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
};
 
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+   power-source = <3300>;
+   };
+
+   sdhi1_pins_uhs: sd1_uhs {
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
+   power-source = <1800>;
};
 };
 
@@ -255,23 +269,27 @@
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi0>;
vqmmc-supply = <_sdhi0>;
cd-gpios = < 6 GPIO_ACTIVE_LOW>;
wp-gpios = < 7 GPIO_ACTIVE_LOW>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi1>;
vqmmc-supply = <_sdhi1>;
cd-gpios = < 14 GPIO_ACTIVE_LOW>;
wp-gpios = < 15 GPIO_ACTIVE_LOW>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Robin Murphy]

On 16/09/16 10:48, Laurent Pinchart wrote:
> Hi Arnd,
> 
> On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
>> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
>>> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
 On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> Hi,
>
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
>
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU
> you need to map the DMA slave phys_addr_t to a dma_addr_t using
> something like this.
>
> This series is based on top of v4.8-rc1. And I'm hoping to be able to
> collect a Ack from Russell King on patch 4/6 that adds the ARM
> specific part and then be able to take the whole series through the
> dmaengine tree. If this is not the best route I'm more then happy to
> do it another way.
>
> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting
> with /dev/mmcblk1, i2c and the serial console which are devices behind
> the iommu.

 As I said in last one, the dmaengine parts look fine to me. But to go
 thru dmaengine tree I would need ACK on non dmaengine patches.
>>>
>>> I havent heard back from this one and I am inclined to merge this one now.
>>> If anyone has any objects, please speak up now...
>>>
>>> Also ACKs welcome...
>>
>> I had not looked at the series earlier, but this version looks entirely
>> reasonable to me, so
>>
>> Acked-by: Arnd Bergmann 
>>
>>
>> One concern I have is that we might get an awkward situation if we ever
>> encounter one DMA engine hardware that is used in different systems that all
>> have an IOMMU, but on some of them the connection between the DMA master and
>> the slave FIFO bypasses the IOMMU while on others the IOMMU is required.
> 
> Do you mean systems where some of the channels of a specific DMA engine go 
> through the IOMMU while others do not ? We indeed have no solution today for 
> such a situation.
> 
> The problem is a bit broader than that, we'll also have an issue with DMA 
> engines that have different channels served by different IOMMUs. I recall 
> discussing this in the past with you, and the solution you proposed was to 
> add 
> a channel index to struct dma_attrs seems good to me. To support the case 
> where some channels don't go through an IOMMU we would only need support for 
> null entries in the IOMMUs list associated with a device (for instance in the 
> DT case null entries in the iommus property).

I think at that point we just create the channels as child devices of
the main dmaengine device so they each get their own DMA ops, and can do
whatever. The Qualcomm HIDMA driver already does that for a very similar
reason (so that the IOMMU can map individual channels into different
guest VMs).

Robin.

> Now I see that struct dma_attrs has been replaced by unsigned long in
> 
> commit 00085f1efa387a8ce100e3734920f7639c80caa3
> Author: Krzysztof Kozlowski 
> Date:   Wed Aug 3 13:46:00 2016 -0700
> 
> dma-mapping: use unsigned long for dma_attrs
> 
> We still have enough bits to reserve some of them for a channel number, but 
> I'm not very happy with that patch as I can see how a future proposal to 
> handle the channel number through the DMA attributes will get rejected on the 
> grounds of bits starvation then :-(
> 
>> I don't have any idea for how this could be handled in a generic way, so my
>> best answer here is to hope we never get there, and if we do, handle it
>> using some local hack in the driver.
> 

Re: [PATCH v7 10/11] arm64: dts: r8a7796: salvator-x: enable UHS for SDHI 0 & 3

[Wolfram Sang]

On Tue, Sep 13, 2016 at 12:57:07PM +0200, Simon Horman wrote:
> Based on work for the r8a7796 by Wolfram Sang.
> 
> Cc: Wolfram Sang 
> Signed-off-by: Simon Horman 

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH v7 09/11] arm64: dts: r8a7796: salvator-x: enable SDHI0 & 3

[Wolfram Sang]

On Tue, Sep 13, 2016 at 12:57:06PM +0200, Simon Horman wrote:
> Enable the exposed SD card slots in the DT of the r8a7796/salvator-x.
> 
> Based on work for the r8a7795/salvator-x by Ai Kyuse.
> 
> Signed-off-by: Simon Horman 
> Reviewed-by: Geert Uytterhoeven 

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH 2/2 v2][resend] drm: bridge: add DesignWare HDMI I2S audio support

[Mark Brown]

On Fri, Sep 16, 2016 at 08:01:01AM +, Kuninori Morimoto wrote:
> 
> Hi Mark
> 
> Can I have feedback about this patch ?

These are DRM patches, I'd expect them to go via the DRM subsystem.

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

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


signature.asc
Description: PGP signature

Re: [PATCH v7 08/11] arm64: dts: r8a7796: add SDHI nodes

[Wolfram Sang]

On Tue, Sep 13, 2016 at 12:57:05PM +0200, Simon Horman wrote:
> Add SDHI nodes to the DT of the r8a7796 SoC.
> 
> Based on the DT of the r8a7795 SoC.
> 
> Signed-off-by: Simon Horman 
> Reviewed-by: Geert Uytterhoeven 

If you remove the two lines you removed from H3 already:

Reviewed-by: Wolfram Sang 

> + sdhi2: sd@ee14 {
> + compatible = "renesas,sdhi-r8a7796";
> + reg = <0 0xee14 0 0x2000>;
> + interrupts = ;
> + clocks = < CPG_MOD 312>;
> + max-frequency = <2>;
> + power-domains = < R8A7796_PD_ALWAYS_ON>;
> + cap-mmc-highspeed;
This one...

> + status = "disabled";
> + };
> +
> + sdhi3: sd@ee16 {
> + compatible = "renesas,sdhi-r8a7796";
> + reg = <0 0xee16 0 0x2000>;
> + interrupts = ;
> + clocks = < CPG_MOD 311>;
> + max-frequency = <2>;
> + power-domains = < R8A7796_PD_ALWAYS_ON>;
> + cap-mmc-highspeed;

... and ditto.



signature.asc
Description: PGP signature

Re: [PATCH v7 07/11] ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104

[Wolfram Sang]

On Tue, Sep 13, 2016 at 12:57:04PM +0200, Simon Horman wrote:
> Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1}.
> And the sd-uhs-sdr104 property to SDHI0.
> 
> Signed-off-by: Simon Horman 

If you drop sdr104 here for now as well:

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH v7 06/11] ARM: dts: r8a7794: set maximum frequency for SDHI clocks

[Wolfram Sang]

On Tue, Sep 13, 2016 at 12:57:03PM +0200, Simon Horman wrote:
> Define the upper limit otherwise the driver cannot utilize max speeds.
> 
> Signed-off-by: Simon Horman 

Reviewed-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104

[Wolfram Sang]

On Fri, Sep 16, 2016 at 12:00:32PM +0200, Simon Horman wrote:
> On Tue, Sep 13, 2016 at 12:57:02PM +0200, Simon Horman wrote:
> > Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
> > And the sd-uhs-sdr104 property to SDHI0.
> > 
> > Signed-off-by: Simon Horman 
> 
> As SDR50 support is present in the driver in mainline (correct me if I am
> wrong!) I have queued this up after dropping the sdr104 portion and
> updating the changelog accordingly.

Looks good!

Acked-by: Wolfram Sang 




signature.asc
Description: PGP signature

Re: [PATCH v7 02/11] arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3

[Wolfram Sang]

On Fri, Sep 16, 2016 at 11:55:00AM +0200, Simon Horman wrote:
> On Tue, Sep 13, 2016 at 12:56:59PM +0200, Simon Horman wrote:
> > From: Wolfram Sang 
> > 
> > Reviewed-by: Geert Uytterhoeven 
> > Signed-off-by: Wolfram Sang 
> > Signed-off-by: Simon Horman 
> 
> As SDR50 support is present in the driver in mainline (correct me if I am
> wrong!) I am queuing this up.

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: r8a7796 salvator-x: External SCIF3/HSCIF3 loop

[Simon Horman]

On Wed, Sep 14, 2016 at 06:47:41PM +0200, Ulrich Hecht wrote:
> Add SCIF3 and HSCIF3 as two new serial ports to the r8a7796
> Salvator-X DT file.
> 
> Signed-off-by: Ulrich Hecht 

Please repost once the (at least DT) dependencies have been merged
(or at least reposted).

Re: [PATCH] ARM: dts: wheat: add DU support

[Simon Horman]

On Mon, Sep 12, 2016 at 08:52:40PM +0300, Sergei Shtylyov wrote:
> On 09/02/2016 12:29 AM, Sergei Shtylyov wrote:
> 
> >Define  the  Wheat board dependent  part of the DU device node.
> >Add the device nodes for the Analog Devices ADV7513 HDMI transmitters
> >connected to DU0/1.  Add the necessary subnodes to interconnect DU with
> >HDMI transmitters/connectors.
> >
> >Signed-off-by: Sergei Shtylyov 
> >
> >---
> >This patch is against the 'renesas-devel-20160901-v4.8-rc4' of Simon Horman's
> >'renesas.git' repo plus the Wheat CAN and SDHI patches posted earlier...
> >The path depends on the 2 DRM patches just posted in order to work correctly!
> 
>In principle, both these patches have been queued by the maintainers...
> Simon, are you going to wait till they hit media_tree.git? Linus' tree?

I don't think that is necessary. I was waiting for some review.
But in any case it looks like this patch no longer applies cleanly.
Could you rebase?

[PATCH] ARM: dts: gose: use generic pinctrl properties in SDHI nodes

[Simon Horman]

Since 16ccaf5bb5a5 ("pinctrl: sh-pfc: Accept standard function, pins and
groups properties") renesas pfc drivers accept generic "function", "pins"
and "groups" properties.

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

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index 90af18600124..dc311eba 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -346,18 +346,18 @@
};
 
sdhi0_pins: sd0 {
-   renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
-   renesas,function = "sdhi0";
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
};
 
sdhi1_pins: sd1 {
-   renesas,groups = "sdhi1_data4", "sdhi1_ctrl";
-   renesas,function = "sdhi1";
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
};
 
sdhi2_pins: sd2 {
-   renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
-   renesas,function = "sdhi2";
+   groups = "sdhi2_data4", "sdhi2_ctrl";
+   function = "sdhi2";
};
 
qspi_pins: qspi {
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104

[Simon Horman]

On Tue, Sep 13, 2016 at 12:57:02PM +0200, Simon Horman wrote:
> Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
> And the sd-uhs-sdr104 property to SDHI0.
> 
> Signed-off-by: Simon Horman 

As SDR50 support is present in the driver in mainline (correct me if I am
wrong!) I have queued this up after dropping the sdr104 portion and
updating the changelog accordingly.

The result is as follows:

From: Simon Horman 
Date: Tue, 13 Sep 2016 12:57:02 +0200
Subject: [PATCH] ARM: dts: koelsch: arm64: dts: r8a7795: salvator-x: enable
 UHS for SDHI 0, 1 & 3

Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f8a7d090fd01..f17bfa000f73 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -360,16 +360,37 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_uhs: sd0_uhs {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
};
 
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+   power-source = <3300>;
+   };
+
+   sdhi1_pins_uhs: sd1_uhs {
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
+   power-source = <1800>;
};
 
sdhi2_pins: sd2 {
groups = "sdhi2_data4", "sdhi2_ctrl";
function = "sdhi2";
+   power-source = <3300>;
+   };
+
+   sdhi2_pins_uhs: sd2_uhs {
+   groups = "sdhi2_data4", "sdhi2_ctrl";
+   function = "sdhi2";
+   power-source = <1800>;
};
 
qspi_pins: qspi {
@@ -454,33 +475,39 @@
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi0>;
vqmmc-supply = <_sdhi0>;
cd-gpios = < 6 GPIO_ACTIVE_LOW>;
wp-gpios = < 7 GPIO_ACTIVE_HIGH>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi1>;
vqmmc-supply = <_sdhi1>;
cd-gpios = < 14 GPIO_ACTIVE_LOW>;
wp-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi2>;
vqmmc-supply = <_sdhi2>;
cd-gpios = < 22 GPIO_ACTIVE_LOW>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH 2/2] media: adv7604: automatic "default-input" selection

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Friday 16 Sep 2016 11:39:42 Ulrich Hecht wrote:
> Fall back to input 0 if "default-input" property is not present.
> 
> Documentation states that the "default-input" property should reside
> directly in the node for adv7612.

Not just fo adv7612.

> Hence, also adjust the parsing to make the implementation consistent with
> this.
> 
> Based on patch by William Towle .
> 
> Signed-off-by: Ulrich Hecht 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/i2c/adv7604.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 4003831..055c9df 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -3077,10 +3077,13 @@ static int adv76xx_parse_dt(struct adv76xx_state
> *state)
>   if (!of_property_read_u32(endpoint, "default-input", ))

Should this be removed if the property has to be in the device node and not in 
the endpoint ?

>   state->pdata.default_input = v;
>   else
> - state->pdata.default_input = -1;
> + state->pdata.default_input = 0;

What was the use case for setting it to -1 ? Is it safe to change that ?

>   of_node_put(endpoint);
> 
> + if (!of_property_read_u32(np, "default-input", ))
> + state->pdata.default_input = v;
> +
>   flags = bus_cfg.bus.parallel.flags;
> 
>   if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)

-- 
Regards,

Laurent Pinchart

Re: [PATCH v7 02/11] arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3

[Simon Horman]

On Tue, Sep 13, 2016 at 12:56:59PM +0200, Simon Horman wrote:
> From: Wolfram Sang 
> 
> Reviewed-by: Geert Uytterhoeven 
> Signed-off-by: Wolfram Sang 
> Signed-off-by: Simon Horman 

As SDR50 support is present in the driver in mainline (correct me if I am
wrong!) I am queuing this up.

Re: [PATCH 1/2] media: adv7604: fix bindings inconsistency for default-input

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Friday 16 Sep 2016 11:39:41 Ulrich Hecht wrote:
> The text states that default-input is an endpoint property, but in the
> example it is a device property.  The example makes more sense.

You should explain why it makes more sense. Something along the lines of

"The example makes more sense as the default input is a property of the chip, 
not of a particular port."

With that changed,

Reviewed-by: Laurent Pinchart 

> Signed-off-by: Ulrich Hecht 
> ---
>  Documentation/devicetree/bindings/media/i2c/adv7604.txt | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
> 8337f75..9cbd92e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> @@ -34,6 +34,7 @@ The digital output port node must contain at least one
> endpoint. Optional Properties:
> 
>- reset-gpios: Reference to the GPIO connected to the device's reset pin.
> +  - default-input: Select which input is selected after reset.
> 
>  Optional Endpoint Properties:
> 
> @@ -47,8 +48,6 @@ Optional Endpoint Properties:
>If none of hsync-active, vsync-active and pclk-sample is specified the
>endpoint will use embedded BT.656 synchronization.
> 
> -  - default-input: Select which input is selected after reset.
> -
>  Example:
> 
>   hdmi_receiver@4c {

-- 
Regards,

Laurent Pinchart

Re: [PATCH v7 04/11] ARM: dts: r8a7791: set maximum frequency for SDHI clocks

[Simon Horman]

On Tue, Sep 13, 2016 at 12:57:01PM +0200, Simon Horman wrote:
> Define the upper limit otherwise the driver cannot utilize max speeds.
> 
> Signed-off-by: Simon Horman 

I have queued this up.

Re: [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.9

[Simon Horman]

On Tue, Sep 13, 2016 at 05:35:25PM +0200, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 9:49:30 AM CEST Simon Horman wrote:
> > Second Round of Renesas ARM Based SoC DT Updates for v4.9
> > 
> > Fixes (for v4.9):
> > * Correct PWM clock parent on r8a7794 SoC
> > 
> > Clean-up:
> > * Remove obsolete vsp1 properties from r8a779[01] SoCs
> > 
> > New boards:
> > * Add r8a7792/wheat and r7s72100/rskrza1 boards
> > 
> > Enablement:
> > * Enable LEDs, DU, SDHI on r8a7792/blanche board
> > * Enable MMCIF and SDHI on r8a7794/alt board
> > * Add SPI and VSP1 to r8a7792 SoC
> > * Add ethernet to r7s72100 SoC
> > 
> 
> Pulled into next/dt, thanks!

Great, thanks for handling this and the other pull requests I sent last week.

Re: [PATCH 4/6] arm64: renesas: r8a7796: add I2C support

[Simon Horman]

On Wed, Sep 14, 2016 at 06:46:09PM +0200, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 

I would like to see some testing of this with 64bit memory enabled -
or some assurance there is no issue with such a configuration.

I am marking this patch and other arm64 patches in this series as Deferred
for now.

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Laurent Pinchart]

Hi Arnd,

On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> > On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> >> On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> >>> Hi,
> >>> 
> >>> This series tries to solve the problem with DMA with device registers
> >>> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> >>> recent patch '9575632 (dmaengine: make slave address physical)'
> >>> clarifies that DMA slave address provided by clients is the physical
> >>> address. This puts the task of mapping the DMA slave address from a
> >>> phys_addr_t to a dma_addr_t on the DMA engine.
> >>> 
> >>> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> >>> the same and no special care is needed. However if you have a IOMMU
> >>> you need to map the DMA slave phys_addr_t to a dma_addr_t using
> >>> something like this.
> >>> 
> >>> This series is based on top of v4.8-rc1. And I'm hoping to be able to
> >>> collect a Ack from Russell King on patch 4/6 that adds the ARM
> >>> specific part and then be able to take the whole series through the
> >>> dmaengine tree. If this is not the best route I'm more then happy to
> >>> do it another way.
> >>> 
> >>> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> >>> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting
> >>> with /dev/mmcblk1, i2c and the serial console which are devices behind
> >>> the iommu.
> >> 
> >> As I said in last one, the dmaengine parts look fine to me. But to go
> >> thru dmaengine tree I would need ACK on non dmaengine patches.
> > 
> > I havent heard back from this one and I am inclined to merge this one now.
> > If anyone has any objects, please speak up now...
> > 
> > Also ACKs welcome...
> 
> I had not looked at the series earlier, but this version looks entirely
> reasonable to me, so
> 
> Acked-by: Arnd Bergmann 
> 
> 
> One concern I have is that we might get an awkward situation if we ever
> encounter one DMA engine hardware that is used in different systems that all
> have an IOMMU, but on some of them the connection between the DMA master and
> the slave FIFO bypasses the IOMMU while on others the IOMMU is required.

Do you mean systems where some of the channels of a specific DMA engine go 
through the IOMMU while others do not ? We indeed have no solution today for 
such a situation.

The problem is a bit broader than that, we'll also have an issue with DMA 
engines that have different channels served by different IOMMUs. I recall 
discussing this in the past with you, and the solution you proposed was to add 
a channel index to struct dma_attrs seems good to me. To support the case 
where some channels don't go through an IOMMU we would only need support for 
null entries in the IOMMUs list associated with a device (for instance in the 
DT case null entries in the iommus property).

Now I see that struct dma_attrs has been replaced by unsigned long in

commit 00085f1efa387a8ce100e3734920f7639c80caa3
Author: Krzysztof Kozlowski 
Date:   Wed Aug 3 13:46:00 2016 -0700

dma-mapping: use unsigned long for dma_attrs

We still have enough bits to reserve some of them for a channel number, but 
I'm not very happy with that patch as I can see how a future proposal to 
handle the channel number through the DMA attributes will get rejected on the 
grounds of bits starvation then :-(

> I don't have any idea for how this could be handled in a generic way, so my
> best answer here is to hope we never get there, and if we do, handle it
> using some local hack in the driver.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/3] arm64: renesas: r8a7796: Add all SCIF nodes

[Simon Horman]

On Thu, Sep 15, 2016 at 08:33:38PM +0200, Geert Uytterhoeven wrote:
> On Wed, Sep 14, 2016 at 6:46 PM, Ulrich Hecht
>  wrote:
> > Add the device nodes for all R-Car H3 SCIF serial ports, incl. clocks
> > and clock domain.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Reviewed-by: Geert Uytterhoeven 

Unfortunately this does not apply to my tree.

Ulrich, please consider rebasing the latest renesas/next branch
(currently renesas-next-20160908-v4.8-rc1 tag) and reposting.

I'd be happy to see this patch reposted without the rest of the series
if that would be most expedient for you.

[PATCH 2/2] media: adv7604: automatic "default-input" selection

[Ulrich Hecht]

Fall back to input 0 if "default-input" property is not present.

Documentation states that the "default-input" property should reside
directly in the node for adv7612.  Hence, also adjust the parsing to make
the implementation consistent with this.

Based on patch by William Towle .

Signed-off-by: Ulrich Hecht 
Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/adv7604.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 4003831..055c9df 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -3077,10 +3077,13 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
if (!of_property_read_u32(endpoint, "default-input", ))
state->pdata.default_input = v;
else
-   state->pdata.default_input = -1;
+   state->pdata.default_input = 0;
 
of_node_put(endpoint);
 
+   if (!of_property_read_u32(np, "default-input", ))
+   state->pdata.default_input = v;
+
flags = bus_cfg.bus.parallel.flags;
 
if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
-- 
2.9.3

[PATCH 1/2] media: adv7604: fix bindings inconsistency for default-input

[Ulrich Hecht]

The text states that default-input is an endpoint property, but in the
example it is a device property.  The example makes more sense.

Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/media/i2c/adv7604.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 8337f75..9cbd92e 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -34,6 +34,7 @@ The digital output port node must contain at least one 
endpoint.
 Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the device's reset pin.
+  - default-input: Select which input is selected after reset.
 
 Optional Endpoint Properties:
 
@@ -47,8 +48,6 @@ Optional Endpoint Properties:
   If none of hsync-active, vsync-active and pclk-sample is specified the
   endpoint will use embedded BT.656 synchronization.
 
-  - default-input: Select which input is selected after reset.
-
 Example:
 
hdmi_receiver@4c {
-- 
2.9.3

Re: [PATCH 0/2] gen3: dts: enable on-board eMMC

[Simon Horman]

On Wed, Sep 14, 2016 at 07:09:41PM +0200, Wolfram Sang wrote:
> From: Wolfram Sang 
> 
> Here are the DTS changes to enable the on-board eMMC memory at 8 bit bus
> widths on R-Car Gen3 Salvator-X boards.
> 
> Note that 'non-removable' is not supported yet because of Runtime PM issues. 
> It
> seems we need to overhaul Runtime PM handling for other reasons as well, so I
> suggest the basic support goes in like this and DTS do not use 'non-removable'
> for now.
> 
> Note also that I decided to use the pattern that pinctrl-0 is 3.3v and
> pinctrl-1 is 1.8v, although the eMMC is fixed at 1.8v. I tried a few ways to
> only use pinctrl-0 being 1.8v here, but they all ended up to be confusing for
> users IMO, so I sticked to the most consistent solution after all.
> 
> These patches are based on top of Simon's sdr104-v7 patches and the 
> accompanied
> driver patches sent a minute ago. A branch can be found here:

Please ping me / repost once these patches are ready to be merged.

[PATCH 0/2] media: adv7604: fix default-input property inconsistencies

[Ulrich Hecht]

Hi!

This is a fix for the inconsistency in the adv7604 bindings regarding the
default-input property, clarifying that it should be a property of the
device, not the endpoint, and a patch to implement it.

CU
Uli


Ulrich Hecht (2):
  media: adv7604: fix bindings inconsistency for default-input
  media: adv7604: automatic "default-input" selection

 Documentation/devicetree/bindings/media/i2c/adv7604.txt | 3 +--
 drivers/media/i2c/adv7604.c | 5 -
 2 files changed, 5 insertions(+), 3 deletions(-)

-- 
2.9.3

Re: [PATCH 1/4] ARM: dts: r7s72100: add mmcif clock to device tree

[Simon Horman]

On Fri, Sep 16, 2016 at 09:00:12AM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 15, 2016 at 9:34 PM, Chris Brandt  
> wrote:
> > Signed-off-by: Chris Brandt 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, I have queued this up for v4.10.

I am not planning to queue up the other patches in this series
until discussion of patch 2/4 is resolved. Most likely the
remaining 3 patches should be reposted once that has happened.

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

[Arnd Bergmann]

On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> > On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> > > Hi,
> > > 
> > > This series tries to solve the problem with DMA with device registers
> > > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > > recent patch '9575632 (dmaengine: make slave address physical)'
> > > clarifies that DMA slave address provided by clients is the physical
> > > address. This puts the task of mapping the DMA slave address from a
> > > phys_addr_t to a dma_addr_t on the DMA engine.
> > > 
> > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > > the same and no special care is needed. However if you have a IOMMU you
> > > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > > like this.
> > > 
> > > This series is based on top of v4.8-rc1. And I'm hoping to be able to 
> > > collect a
> > > Ack from Russell King on patch 4/6 that adds the ARM specific part and 
> > > then be
> > > able to take the whole series through the dmaengine tree. If this is not 
> > > the
> > > best route I'm more then happy to do it another way.
> > > 
> > > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> > > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> > > /dev/mmcblk1, i2c and the serial console which are devices behind the
> > > iommu.
> > 
> > As I said in last one, the dmaengine parts look fine to me. But to go thru
> > dmaengine tree I would need ACK on non dmaengine patches.
> 
> I havent heard back from this one and I am inclined to merge this one now.
> If anyone has any objects, please speak up now...
> 
> Also ACKs welcome...
> 


I had not looked at the series earlier, but this version looks entirely
reasonable to me, so

Acked-by: Arnd Bergmann 


One concern I have is that we might get an awkward situation if we
ever encounter one DMA engine hardware that is used in different
systems that all have an IOMMU, but on some of them the connection
between the DMA master and the slave FIFO bypasses the IOMMU
while on others the IOMMU is required. I don't have any idea for
how this could be handled in a generic way, so my best answer
here is to hope we never get there, and if we do, handle it
using some local hack in the driver.

Arnd

Re: [PATCH v8 1/2] media: adv7604: automatic "default-input" selection

[Hans Verkuil]

Hi Ulrich,

What should I do with this? I dropped it for now.

I'm just going ahead and post the pull request without this patch as I
don't want this to be a blocker.

Regards,

Hans

On 09/15/2016 06:42 PM, Laurent Pinchart wrote:
> Hi Ulrich,
> 
> Thank you for the patch.
> 
> On Thursday 15 Sep 2016 15:24:07 Ulrich Hecht wrote:
>> Fall back to input 0 if "default-input" property is not present.
>>
>> Additionally, documentation in commit bf9c82278c34 ("[media]
>> media: adv7604: ability to read default input port from DT") states
>> that the "default-input" property should reside directly in the node
>> for adv7612.
> 
> Actually it doesn't. The DT bindings specifies "default-input" as an endpoint 
> property, even though the example sets it in the device node. That's 
> inconsistent so the DT bindings document should be fixed. I believe the 
> property should be set in the device node, it doesn't make much sense to have 
> different default inputs per port.
> 
>> Hence, also adjust the parsing to make the implementation
>> consistent with this.
>>
>> Based on patch by William Towle .
>>
>> Signed-off-by: Ulrich Hecht 
>> ---
>>  drivers/media/i2c/adv7604.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
>> index 4003831..055c9df 100644
>> --- a/drivers/media/i2c/adv7604.c
>> +++ b/drivers/media/i2c/adv7604.c
>> @@ -3077,10 +3077,13 @@ static int adv76xx_parse_dt(struct adv76xx_state
>> *state) if (!of_property_read_u32(endpoint, "default-input", ))
>>  state->pdata.default_input = v;
>>  else
>> -state->pdata.default_input = -1;
>> +state->pdata.default_input = 0;
>>
>>  of_node_put(endpoint);
>>
>> +if (!of_property_read_u32(np, "default-input", ))
>> +state->pdata.default_input = v;
>> +
>>  flags = bus_cfg.bus.parallel.flags;
>>
>>  if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> 

Re: [PATCH 2/2 v2][resend] drm: bridge: add DesignWare HDMI I2S audio support

[Kuninori Morimoto]

Hi Mark

Can I have feedback about this patch ?

> From: Kuninori Morimoto 
> 
> Current dw-hdmi is supporting sound via AHB bus, but it has
> I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
> This HDMI I2S is supported by using ALSA SoC common HDMI encoder
> driver.
> 
> Tested-by: Jose Abreu 
> Signed-off-by: Kuninori Morimoto 
> ---
> v1 -> v2
> 
>  - tidyup return value of snd_dw_hdmi_probe()
> 
>  drivers/gpu/drm/bridge/Kconfig |   8 ++
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/dw-hdmi-audio.h |   7 ++
>  drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c | 130 
> +
>  drivers/gpu/drm/bridge/dw-hdmi.c   |  22 -
>  drivers/gpu/drm/bridge/dw-hdmi.h   |  21 +
>  6 files changed, 187 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8f7423f..8e2a22d 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -32,6 +32,14 @@ config DRM_DW_HDMI_AHB_AUDIO
> Designware HDMI block.  This is used in conjunction with
> the i.MX6 HDMI driver.
>  
> +config DRM_DW_HDMI_I2S_AUDIO
> + tristate "Synopsis Designware I2S Audio interface"
> + depends on DRM_DW_HDMI
> + select SND_SOC_HDMI_CODEC
> + help
> +   Support the I2S Audio interface which is part of the Synopsis
> +   Designware HDMI block.
> +
>  config DRM_NXP_PTN3460
>   tristate "NXP PTN3460 DP/LVDS bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 96b13b3..1af92ad 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> +obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi-audio.h 
> b/drivers/gpu/drm/bridge/dw-hdmi-audio.h
> index 91f631b..fd1f745 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi-audio.h
> +++ b/drivers/gpu/drm/bridge/dw-hdmi-audio.h
> @@ -11,4 +11,11 @@ struct dw_hdmi_audio_data {
>   u8 *eld;
>  };
>  
> +struct dw_hdmi_i2s_audio_data {
> + struct dw_hdmi *hdmi;
> +
> + void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
> + u8 (*read)(struct dw_hdmi *hdmi, int offset);
> +};
> +
>  #endif
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c 
> b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
> new file mode 100644
> index 000..7dd2091
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
> @@ -0,0 +1,130 @@
> +/*
> + * dw-hdmi-i2s-audio.c
> + *
> + * Copyright (c) 2016 Kuninori Morimoto 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +
> +#include 
> +
> +#include "dw-hdmi.h"
> +#include "dw-hdmi-audio.h"
> +
> +#define DRIVER_NAME "dw-hdmi-i2s-audio"
> +
> +static inline void hdmi_write(struct dw_hdmi_i2s_audio_data *audio,
> +   u8 val, int offset)
> +{
> + struct dw_hdmi *hdmi = audio->hdmi;
> +
> + audio->write(hdmi, val, offset);
> +}
> +
> +static inline u8 hdmi_read(struct dw_hdmi_i2s_audio_data *audio, int offset)
> +{
> + struct dw_hdmi *hdmi = audio->hdmi;
> +
> + return audio->read(hdmi, offset);
> +}
> +
> +static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
> +  struct hdmi_codec_daifmt *fmt,
> +  struct hdmi_codec_params *hparms)
> +{
> + struct dw_hdmi_i2s_audio_data *audio = data;
> + struct dw_hdmi *hdmi = audio->hdmi;
> + u8 conf0 = 0;
> + u8 conf1 = 0;
> + u8 inputclkfs = 0;
> +
> + /* it cares I2S only */
> + if ((fmt->fmt != HDMI_I2S) ||
> + (fmt->bit_clk_master | fmt->frame_clk_master)) {
> + dev_err(dev, "unsupported format/settings\n");
> + return -EINVAL;
> + }
> +
> + inputclkfs  = HDMI_AUD_INPUTCLKFS_64FS;
> + conf0   = HDMI_AUD_CONF0_I2S_ALL_ENABLE;
> +
> + switch (hparms->sample_width) {
> + case 16:
> + conf1 = HDMI_AUD_CONF1_WIDTH_16;
> + break;
> + case 24:
> + case 32:
> + conf1 = HDMI_AUD_CONF1_WIDTH_24;
> + break;
> + }
> +
> + dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> +
> +  

Re: [PATCH 2/4] ARM: dts: r7s72100: add mmcif to device tree

[Geert Uytterhoeven]

Hi Chris,

On Thu, Sep 15, 2016 at 9:34 PM, Chris Brandt  wrote:
> Signed-off-by: Chris Brandt 
> ---
>  arch/arm/boot/dts/r7s72100.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
> index e18d4e6..4054db3 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -450,4 +450,15 @@
> #size-cells = <0>;
> status = "disabled";
> };
> +
> +   mmcif: mmc@e804c800 {
> +   compatible = "renesas,mmcif-r7s72100", "renesas,sh-mmcif";
> +   reg = <0xe804c800 0x80>;
> +   interrupts =  + GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>;

The bindings do not say anything about interrupts (hence that should be
added).
The driver handles either 1 combined or 2 separate interrupts.
The datasheet says MMC has 3 interrupt requests, though?

> +   clocks = <_clks R7S72100_CLK_MMCIF>;
> +   reg-io-width = <4>;
> +   bus-width = <8>;
> +   status = "disabled";
> +   };
>  };

The rest looks OK to me.

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/4] mmc: sh_mmcif: Document r7s72100 DT bindings

[Geert Uytterhoeven]

On Thu, Sep 15, 2016 at 9:34 PM, Chris Brandt  wrote:
> Signed-off-by: Chris Brandt 

Acked-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 1/4] ARM: dts: r7s72100: add mmcif clock to device tree

[Geert Uytterhoeven]

On Thu, Sep 15, 2016 at 9:34 PM, Chris Brandt  wrote:
> Signed-off-by: Chris Brandt 

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