Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue

[Kuninori Morimoto]

Hi Vinod

> > > > This is now commit 847449f23dcbff68 ("dmaengine: rcar-dmac: use TCRB
> > > > instead of TCR for residue") in slave-dma/next, and breaks serial 
> > > > console
> > > > input on koelsch (shmobile_defconfig) and salvator-x 
> > > > (renesas_defconfig).
> > > > Reverting that commit fixes the issue for me.
> > 
> > Okay since we are close to merge window I can drop this patch for now,
> > unless we identify the fix very quickly
> 
> I have not seen a resolution to this, so reverted it.

We are sorry, but we still don't have solution about this.

Best regards
---
Kuninori Morimoto

Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue

[Vinod Koul]

On Tue, Oct 31, 2017 at 05:11:13PM +0530, Vinod Koul wrote:
> On Tue, Oct 31, 2017 at 11:46:36AM +0100, Geert Uytterhoeven wrote:
> > >
> > > This is now commit 847449f23dcbff68 ("dmaengine: rcar-dmac: use TCRB
> > > instead of TCR for residue") in slave-dma/next, and breaks serial console
> > > input on koelsch (shmobile_defconfig) and salvator-x (renesas_defconfig).
> > > Reverting that commit fixes the issue for me.
> 
> Okay since we are close to merge window I can drop this patch for now,
> unless we identify the fix very quickly

I have not seen a resolution to this, so reverted it.

-- 
~Vinod

Re: [PATCH 1/2] ARM: dts: r8a7745: Add DU support

[Simon Horman]

On Tue, Nov 07, 2017 at 06:05:37AM +0200, Laurent Pinchart wrote:
> Hi Fabrizio,
> 
> Thank you for the patch.
> 
> On Monday, 6 November 2017 20:26:53 EET Fabrizio Castro wrote:
> > Add du node to r8a7745 SoC DT. Boards that want to enable the DU
> > need to specify the output topology.
> > 
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> 
> Reviewed-by: Laurent Pinchart 
> 
> > ---
> >  arch/arm/boot/dts/r8a7745.dtsi | 27 +++
> >  1 file changed, 27 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
> > index 846c27a..53eb1ce4 100644
> > --- a/arch/arm/boot/dts/r8a7745.dtsi
> > +++ b/arch/arm/boot/dts/r8a7745.dtsi
> > @@ -821,6 +821,33 @@
> > status = "disabled";
> > };
> > 
> > +   du: display@feb0 {
> > +   compatible = "renesas,du-r8a7745";

Hi,

could you provide some information on the status of upstreaming
the binding used above?

Re: [PATCH v3 0/5] PM / Domains: Remove gpd_dev_ops.active_wakeup() callback

[Rafael J. Wysocki]

On Tuesday, November 7, 2017 1:48:10 PM CET Geert Uytterhoeven wrote:
>   Hi Rafael, Ulf, Kevin,
> 
> It is quite common for PM Domains to require slave devices to be kept
> active during system suspend if they are to be used as wakeup sources.
> To enable this, currently each PM Domain or driver has to provide its
> own gpd_dev_ops.active_wakeup() callback.
> 
> All existing callbacks either return always true, or a fixed value
> depending on the PM Domain.
> 
> Hence this patch series simplifies active wakeup handling by replacing
> the callback by a flag:
>   - Patch 1 adds a new new flag GENPD_FLAG_ACTIVE_WAKEUP, to be set by
> PM Domain drivers that want to use the new handling,
>   - Patches 2-4 convert all existing users of the callback to the new
> flag,
>   - Patch 5 removes the callback.
> 
> This series was extracted from "[PATCH 00/10] PM / Domain: renesas: Fix
> active wakeup behavior", and retains only PM Domain changes to existing
> drivers.
> 
> Changes compared to v2:
>   - Add Acked-by, Reviewed-by,
>   - Drop RFC status from dependent patches, as everything can go in
> through the pm tree.
> 
> Changes compared to v1 (most suggested by Ulf):
>   - Use the flag in se instead of setting up an "always true" callback,
>   - Convert the mediatek and rockchip PM Domain drivers,
>   - Remove the callback.
> 
> Thanks for applying for v4.15!

Queued up for 4.15, thanks!

Rafael

Re: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support

[Geert Uytterhoeven]

On Tue, Nov 7, 2017 at 4:10 PM, Fabrizio Castro
 wrote:
> Document "renesas,can-r8a7743" and "renesas,can-r8a7745" compatible
> strings. Since the fallback compatible string ("renesas,rcar-gen2-can")
> activates the right code in the driver, no driver change is needed.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 8/8] ARM: dts: iwg20d-q7-dbcm-ca: Add can1 support to camera DB

[Fabrizio Castro]

CAN1 interface is exposed via connector J3 found on the camera daughter
board. This patch enables can1 DT node from within the daughter board
specific dtsi.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi 
b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index 4db18f2..476273b 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -32,6 +32,13 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -94,6 +101,11 @@
 };
 
  {
+   can1_pins: can1 {
+   groups = "can1_data_d";
+   function = "can1";
+   };
+
du_pins: du {
groups = "du_rgb888", "du_sync", "du_oddf", "du_clk_out_0";
function = "du";
-- 
2.7.4

[PATCH 5/8] ARM: dts: iwg22d-sodimm-dbhd-ca: Add can1 support to HDMI DB

[Fabrizio Castro]

CAN1 interface is exposed via connector J1 found on the HDMI daughter
board. This patch enables can1 DT node from within the daughter board
specific device tree.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts 
b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
index a8a4ec8..d34de82 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
@@ -54,6 +54,13 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -105,6 +112,11 @@
 };
 
  {
+   can1_pins: can1 {
+   groups = "can1_data_b";
+   function = "can1";
+   };
+
du0_pins: du0 {
groups = "du0_rgb888", "du0_sync", "du0_disp", "du0_clk0_out";
function = "du0";
-- 
2.7.4

[PATCH 4/8] ARM: dts: iwg22d-sodimm: Add can0 support to carrier board

[Fabrizio Castro]

This patch enables CAN0 interface exposed through connector J15 on the
carrier board.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts 
b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index 80c82aa..39ce7e7 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -59,6 +59,13 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -85,6 +92,11 @@
function = "avb";
};
 
+   can0_pins: can0 {
+   groups = "can0_data";
+   function = "can0";
+   };
+
hscif1_pins: hscif1 {
groups = "hscif1_data", "hscif1_ctrl";
function = "hscif1";
-- 
2.7.4

[PATCH 6/8] ARM: dts: r8a7743: Add CAN[01] SoC support

[Fabrizio Castro]

Add the definitions for can0 and can1 to the SoC .dtsi.

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

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 6aa86b7..12c7b92 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1067,6 +1067,34 @@
};
};
 
+   can0: can@e6e8 {
+   compatible = "renesas,can-r8a7743",
+"renesas,rcar-gen2-can";
+   reg = <0 0xe6e8 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 916>,
+< CPG_CORE R8A7743_CLK_RCAN>,
+<_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 916>;
+   status = "disabled";
+   };
+
+   can1: can@e6e88000 {
+   compatible = "renesas,can-r8a7743",
+"renesas,rcar-gen2-can";
+   reg = <0 0xe6e88000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 915>,
+< CPG_CORE R8A7743_CLK_RCAN>,
+<_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 915>;
+   status = "disabled";
+   };
+
pci0: pci@ee09 {
compatible = "renesas,pci-r8a7743",
 "renesas,pci-rcar-gen2";
@@ -1153,6 +1181,14 @@
clock-frequency = <4800>;
};
 
+   /* External CAN clock */
+   can_clk: can {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overridden by the board. */
+   clock-frequency = <0>;
+   };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
-- 
2.7.4

[PATCH 7/8] ARM: dts: iwg20d-q7-common: Add can0 support to carrier board

[Fabrizio Castro]

This patch enables CAN0 interface exposed through connector J20 on the
carrier board.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 arch/arm/boot/dts/iwg20d-q7-common.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi 
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index c865499..3e4bc4d 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -59,6 +59,13 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+};
+
  {
status = "okay";
pinctrl-0 = <_pins>;
@@ -90,6 +97,11 @@
 };
 
  {
+   can0_pins: can0 {
+   groups = "can0_data_d";
+   function = "can0";
+   };
+
avb_pins: avb {
groups = "avb_mdio", "avb_gmii";
function = "avb";
-- 
2.7.4

[PATCH 3/8] ARM: dts: r8a7745: Add CAN[01] SoC support

[Fabrizio Castro]

Add the definitions for can0 and can1 to the SoC .dtsi.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 arch/arm/boot/dts/r8a7745.dtsi | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 2b32638..529e8c6 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -1065,6 +1065,34 @@
#phy-cells = <1>;
};
};
+
+   can0: can@e6e8 {
+   compatible = "renesas,can-r8a7745",
+"renesas,rcar-gen2-can";
+   reg = <0 0xe6e8 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 916>,
+< CPG_CORE R8A7745_CLK_RCAN>,
+<_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   power-domains = < R8A7745_PD_ALWAYS_ON>;
+   resets = < 916>;
+   status = "disabled";
+   };
+
+   can1: can@e6e88000 {
+   compatible = "renesas,can-r8a7745",
+"renesas,rcar-gen2-can";
+   reg = <0 0xe6e88000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 915>,
+< CPG_CORE R8A7745_CLK_RCAN>,
+<_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   power-domains = < R8A7745_PD_ALWAYS_ON>;
+   resets = < 915>;
+   status = "disabled";
+   };
};
 
/* External root clock */
@@ -1082,6 +1110,14 @@
clock-frequency = <4800>;
};
 
+   /* External CAN clock */
+   can_clk: can {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overridden by the board. */
+   clock-frequency = <0>;
+   };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
-- 
2.7.4

[PATCH 0/8] Add CAN support to iwg2[02]d

[Fabrizio Castro]

Hello,

this series delivers all of the changes necessary to add CAN bus
support to the:
* iW-RainboW-G22D SODIMM, and
* iW-RainboW-G20M-Qseven-RZG1M
development platforms, including documentation, pinctrl driver, SoC
specific device trees, and board specific device trees.

This work has been based and tested on top of:
renesas-devel-20171106-v4.14-rc8

Best regards,

Fabrizio Castro (8):
  dt-bindings: can: rcar_can: document r8a774[35] can support
  pinctrl: sh-pfc: r8a7745: Add CAN[01] support
  ARM: dts: r8a7745: Add CAN[01] SoC support
  ARM: dts: iwg22d-sodimm: Add can0 support to carrier board
  ARM: dts: iwg22d-sodimm-dbhd-ca: Add can1 support to HDMI DB
  ARM: dts: r8a7743: Add CAN[01] SoC support
  ARM: dts: iwg20d-q7-common: Add can0 support to carrier board
  ARM: dts: iwg20d-q7-dbcm-ca: Add can1 support to camera DB

 .../devicetree/bindings/net/can/rcar_can.txt   |   7 +-
 arch/arm/boot/dts/iwg20d-q7-common.dtsi|  12 ++
 arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi   |  12 ++
 arch/arm/boot/dts/r8a7743.dtsi |  36 +
 .../arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts |  12 ++
 arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts|  12 ++
 arch/arm/boot/dts/r8a7745.dtsi |  36 +
 drivers/pinctrl/sh-pfc/pfc-r8a7794.c   | 146 +
 8 files changed, 271 insertions(+), 2 deletions(-)

-- 
2.7.4

[PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support

[Fabrizio Castro]

Document "renesas,can-r8a7743" and "renesas,can-r8a7745" compatible
strings. Since the fallback compatible string ("renesas,rcar-gen2-can")
activates the right code in the driver, no driver change is needed.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 Documentation/devicetree/bindings/net/can/rcar_can.txt | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt 
b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 06bb7cc..94a7f33 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -2,7 +2,9 @@ Renesas R-Car CAN controller Device Tree Bindings
 -
 
 Required properties:
-- compatible: "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
+- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
+ "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
+ "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
  "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
  "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
  "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC.
@@ -12,7 +14,8 @@ Required properties:
  "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
  "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
  "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible 
device.
- "renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible 
device.
+ "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
+ compatible device.
  "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible 
device.
  When compatible with the generic version, nodes must list the
  SoC-specific version corresponding to the platform first
-- 
2.7.4

[PATCH 2/8] pinctrl: sh-pfc: r8a7745: Add CAN[01] support

[Fabrizio Castro]

This patch adds PFC CAN0 and CAN1 pin groups and functions, enabling CAN
bus on the RZ/G1E.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 drivers/pinctrl/sh-pfc/pfc-r8a7794.c | 146 +++
 1 file changed, 146 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7794.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
index 333a3470..e5b3d5f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
@@ -1608,6 +1608,116 @@ static const unsigned int avb_gmii_mux[] = {
AVB_TX_EN_MARK, AVB_TX_ER_MARK, AVB_TX_CLK_MARK,
AVB_COL_MARK,
 };
+
+/* - CAN  
*/
+static const unsigned int can0_data_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(6, 15), RCAR_GP_PIN(6, 14),
+};
+
+static const unsigned int can0_data_mux[] = {
+   CAN0_TX_MARK, CAN0_RX_MARK,
+};
+
+static const unsigned int can0_data_b_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(3, 16), RCAR_GP_PIN(3, 15),
+};
+
+static const unsigned int can0_data_b_mux[] = {
+   CAN0_TX_B_MARK, CAN0_RX_B_MARK,
+};
+
+static const unsigned int can0_data_c_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(2, 17), RCAR_GP_PIN(2, 16),
+};
+
+static const unsigned int can0_data_c_mux[] = {
+   CAN0_TX_C_MARK, CAN0_RX_C_MARK,
+};
+
+static const unsigned int can0_data_d_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(5, 12), RCAR_GP_PIN(5, 11),
+};
+
+static const unsigned int can0_data_d_mux[] = {
+   CAN0_TX_D_MARK, CAN0_RX_D_MARK,
+};
+
+static const unsigned int can1_data_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(6, 25), RCAR_GP_PIN(6, 24),
+};
+
+static const unsigned int can1_data_mux[] = {
+   CAN1_TX_MARK, CAN1_RX_MARK,
+};
+
+static const unsigned int can1_data_b_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 1),
+};
+
+static const unsigned int can1_data_b_mux[] = {
+   CAN1_TX_B_MARK, CAN1_RX_B_MARK,
+};
+
+static const unsigned int can1_data_c_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(5, 6), RCAR_GP_PIN(5, 5),
+};
+
+static const unsigned int can1_data_c_mux[] = {
+   CAN1_TX_C_MARK, CAN1_RX_C_MARK,
+};
+
+static const unsigned int can1_data_d_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(3, 31), RCAR_GP_PIN(3, 30),
+};
+
+static const unsigned int can1_data_d_mux[] = {
+   CAN1_TX_D_MARK, CAN1_RX_D_MARK,
+};
+
+static const unsigned int can_clk_pins[] = {
+   /* CLK */
+   RCAR_GP_PIN(3, 31),
+};
+
+static const unsigned int can_clk_mux[] = {
+   CAN_CLK_MARK,
+};
+
+static const unsigned int can_clk_b_pins[] = {
+   /* CLK */
+   RCAR_GP_PIN(1, 23),
+};
+
+static const unsigned int can_clk_b_mux[] = {
+   CAN_CLK_B_MARK,
+};
+
+static const unsigned int can_clk_c_pins[] = {
+   /* CLK */
+   RCAR_GP_PIN(1, 0),
+};
+
+static const unsigned int can_clk_c_mux[] = {
+   CAN_CLK_C_MARK,
+};
+
+static const unsigned int can_clk_d_pins[] = {
+   /* CLK */
+   RCAR_GP_PIN(5, 0),
+};
+
+static const unsigned int can_clk_d_mux[] = {
+   CAN_CLK_D_MARK,
+};
+
 /* - DU - 
*/
 static const unsigned int du0_rgb666_pins[] = {
/* R[7:2], G[7:2], B[7:2] */
@@ -3459,6 +3569,18 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_mdio),
SH_PFC_PIN_GROUP(avb_mii),
SH_PFC_PIN_GROUP(avb_gmii),
+   SH_PFC_PIN_GROUP(can0_data),
+   SH_PFC_PIN_GROUP(can0_data_b),
+   SH_PFC_PIN_GROUP(can0_data_c),
+   SH_PFC_PIN_GROUP(can0_data_d),
+   SH_PFC_PIN_GROUP(can1_data),
+   SH_PFC_PIN_GROUP(can1_data_b),
+   SH_PFC_PIN_GROUP(can1_data_c),
+   SH_PFC_PIN_GROUP(can1_data_d),
+   SH_PFC_PIN_GROUP(can_clk),
+   SH_PFC_PIN_GROUP(can_clk_b),
+   SH_PFC_PIN_GROUP(can_clk_c),
+   SH_PFC_PIN_GROUP(can_clk_d),
SH_PFC_PIN_GROUP(du0_rgb666),
SH_PFC_PIN_GROUP(du0_rgb888),
SH_PFC_PIN_GROUP(du0_clk0_out),
@@ -3731,6 +3853,28 @@ static const char * const avb_groups[] = {
"avb_gmii",
 };
 
+static const char * const can0_groups[] = {
+   "can0_data",
+   "can0_data_b",
+   "can0_data_c",
+   "can0_data_d",
+   "can_clk",
+   "can_clk_b",
+   "can_clk_c",
+   "can_clk_d",
+};
+
+static const char * const can1_groups[] = {
+   "can1_data",
+   "can1_data_b",
+   "can1_data_c",
+   "can1_data_d",
+   "can_clk",
+   "can_clk_b",
+   "can_clk_c",
+   "can_clk_d",
+};
+
 static const char * const du0_groups[] = {
"du0_rgb666",
"du0_rgb888",
@@ -4102,6 +4246,8 @@ static const char * const vin1_groups[] = {
 static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(audio_clk),
SH_PFC_FUNCTION(avb),
+   SH_PFC_FUNCTION(can0),
+   

Re: [PATCH 1/2] dt-bindings: usb-xhci: Document r8a7743 support

[Mathias Nyman]

On 07.11.2017 13:00, Biju Das wrote:

Hi Mathias,

Does this patch look okay to you?



Yes, Adding to queue, Will send out after rc1

Thanks
-Mathias

Re: [PATCH] mmc: tmio: Replace msleep() of 20ms or less with usleep_range()

[Ulf Hansson]

On 3 November 2017 at 10:36, Simon Horman  wrote:
> From: Masaharu Hayakawa 
>
> As documented in Documentation/timers/timers-howto.txt
> as follows, replace msleep() with usleep_range().
>
> msleep(1~20) may not do what the caller intends, and
> will often sleep longer (~20 ms actual sleep for any
> value given in the 1~20ms range). In many cases this
> is not the desired behavior.
>
> Signed-off-by: Masaharu Hayakawa 
> Signed-off-by: Simon Horman 

Thanks, applied for next!

Kind regards
Uffe

> ---
> v1 [Simon Horman]
> * Extend to cover all instances of msleep(<20);
>
> v0 [Masaharu Hayakawa]
>
> This patch is based on a patch in BSP v3.5.6
> ---
>  drivers/mmc/host/tmio_mmc_core.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_core.c 
> b/drivers/mmc/host/tmio_mmc_core.c
> index 4c8198f8b04a..583bf3262df5 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -167,11 +167,11 @@ static void tmio_mmc_clk_start(struct tmio_mmc_host 
> *host)
>
> /* HW engineers overrode docs: no sleep needed on R-Car2+ */
> if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2))
> -   msleep(10);
> +   usleep_range(1, 11000);
>
> if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG) {
> sd_ctrl_write16(host, CTL_CLK_AND_WAIT_CTL, 0x0100);
> -   msleep(10);
> +   usleep_range(1, 11000);
> }
>  }
>
> @@ -179,7 +179,7 @@ static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
>  {
> if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG) {
> sd_ctrl_write16(host, CTL_CLK_AND_WAIT_CTL, 0x);
> -   msleep(10);
> +   usleep_range(1, 11000);
> }
>
> sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
> @@ -187,7 +187,7 @@ static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
>
> /* HW engineers overrode docs: no sleep needed on R-Car2+ */
> if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2))
> -   msleep(10);
> +   usleep_range(1, 11000);
>  }
>
>  static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
> @@ -219,7 +219,7 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
> sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
> sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & CLK_CTL_DIV_MASK);
> if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2))
> -   msleep(10);
> +   usleep_range(1, 11000);
>
> tmio_mmc_clk_start(host);
>  }
> @@ -230,11 +230,11 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
> sd_ctrl_write16(host, CTL_RESET_SD, 0x);
> if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
> sd_ctrl_write16(host, CTL_RESET_SDIO, 0x);
> -   msleep(10);
> +   usleep_range(1, 11000);
> sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
> if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
> sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
> -   msleep(10);
> +   usleep_range(1, 11000);
>
> if (host->pdata->flags & TMIO_MMC_SDIO_IRQ) {
> sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host->sdio_irq_mask);
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/5] soc: rockchip: power-domain: Use GENPD_FLAG_ACTIVE_WAKEUP

[Geert Uytterhoeven]

Set the newly introduced GENPD_FLAG_ACTIVE_WAKEUP, which allows to
remove the driver's own flag-based callback.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Ulf Hansson 
Acked-by: Heiko Stuebner 
---
Compile-tested only.

v3:
  - Add Acked-by,
  - Drop RFC status,

v2:
  - New.
---
 drivers/soc/rockchip/pm_domains.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c 
b/drivers/soc/rockchip/pm_domains.c
index 40b75748835f552c..5c342167b9db7a16 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -358,17 +358,6 @@ static void rockchip_pd_detach_dev(struct 
generic_pm_domain *genpd,
pm_clk_destroy(dev);
 }
 
-static bool rockchip_active_wakeup(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-   struct rockchip_pm_domain *pd;
-
-   genpd = pd_to_genpd(dev->pm_domain);
-   pd = container_of(genpd, struct rockchip_pm_domain, genpd);
-
-   return pd->info->active_wakeup;
-}
-
 static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu,
  struct device_node *node)
 {
@@ -489,8 +478,9 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu 
*pmu,
pd->genpd.power_on = rockchip_pd_power_on;
pd->genpd.attach_dev = rockchip_pd_attach_dev;
pd->genpd.detach_dev = rockchip_pd_detach_dev;
-   pd->genpd.dev_ops.active_wakeup = rockchip_active_wakeup;
pd->genpd.flags = GENPD_FLAG_PM_CLK;
+   if (pd_info->active_wakeup)
+   pd->genpd.flags |= GENPD_FLAG_ACTIVE_WAKEUP;
pm_genpd_init(>genpd, NULL, false);
 
pmu->genpd_data.domains[id] = >genpd;
-- 
2.7.4

[PATCH v3 2/5] ARM: shmobile: pm-rmobile: Use GENPD_FLAG_ACTIVE_WAKEUP

[Geert Uytterhoeven]

Set the newly introduced GENPD_FLAG_ACTIVE_WAKEUP, which allows to
remove the driver's own "always true" callback.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Ulf Hansson 
Acked-by: Simon Horman 
---
v3:
  - Add Acked-by,
  - Drop RFC status,

v2:
  - No changes.
---
 arch/arm/mach-shmobile/pm-rmobile.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/mach-shmobile/pm-rmobile.c 
b/arch/arm/mach-shmobile/pm-rmobile.c
index 3a4ed4c33a68e51e..e348bcfe389da51b 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -120,18 +120,12 @@ static int rmobile_pd_power_up(struct generic_pm_domain 
*genpd)
return __rmobile_pd_power_up(to_rmobile_pd(genpd), true);
 }
 
-static bool rmobile_pd_active_wakeup(struct device *dev)
-{
-   return true;
-}
-
 static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd)
 {
struct generic_pm_domain *genpd = _pd->genpd;
struct dev_power_governor *gov = rmobile_pd->gov;
 
-   genpd->flags |= GENPD_FLAG_PM_CLK;
-   genpd->dev_ops.active_wakeup= rmobile_pd_active_wakeup;
+   genpd->flags |= GENPD_FLAG_PM_CLK | GENPD_FLAG_ACTIVE_WAKEUP;
genpd->power_off= rmobile_pd_power_down;
genpd->power_on = rmobile_pd_power_up;
genpd->attach_dev   = cpg_mstp_attach_dev;
-- 
2.7.4

[PATCH v3 3/5] soc: mediatek: Use GENPD_FLAG_ACTIVE_WAKEUP

[Geert Uytterhoeven]

Set the newly introduced GENPD_FLAG_ACTIVE_WAKEUP, which allows to
remove the driver's own flag-based callback.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Ulf Hansson 
Acked-by: Matthias Brugger 
---
Compile-tested only.

v3:
  - Add Acked-by,
  - Drop RFC status,

v2:
  - New.
---
 drivers/soc/mediatek/mtk-scpsys.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index e1ce8b1b5090aa0a..e570b6af2e6ffbdd 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -361,17 +361,6 @@ static int scpsys_power_off(struct generic_pm_domain 
*genpd)
return ret;
 }
 
-static bool scpsys_active_wakeup(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-   struct scp_domain *scpd;
-
-   genpd = pd_to_genpd(dev->pm_domain);
-   scpd = container_of(genpd, struct scp_domain, genpd);
-
-   return scpd->data->active_wakeup;
-}
-
 static void init_clks(struct platform_device *pdev, struct clk **clk)
 {
int i;
@@ -466,7 +455,8 @@ static struct scp *init_scp(struct platform_device *pdev,
genpd->name = data->name;
genpd->power_off = scpsys_power_off;
genpd->power_on = scpsys_power_on;
-   genpd->dev_ops.active_wakeup = scpsys_active_wakeup;
+   if (scpd->data->active_wakeup)
+   genpd->flags |= GENPD_FLAG_ACTIVE_WAKEUP;
}
 
return scp;
-- 
2.7.4

[PATCH v3 0/5] PM / Domains: Remove gpd_dev_ops.active_wakeup() callback

[Geert Uytterhoeven]

Hi Rafael, Ulf, Kevin,

It is quite common for PM Domains to require slave devices to be kept
active during system suspend if they are to be used as wakeup sources.
To enable this, currently each PM Domain or driver has to provide its
own gpd_dev_ops.active_wakeup() callback.

All existing callbacks either return always true, or a fixed value
depending on the PM Domain.

Hence this patch series simplifies active wakeup handling by replacing
the callback by a flag:
  - Patch 1 adds a new new flag GENPD_FLAG_ACTIVE_WAKEUP, to be set by
PM Domain drivers that want to use the new handling,
  - Patches 2-4 convert all existing users of the callback to the new
flag,
  - Patch 5 removes the callback.

This series was extracted from "[PATCH 00/10] PM / Domain: renesas: Fix
active wakeup behavior", and retains only PM Domain changes to existing
drivers.

Changes compared to v2:
  - Add Acked-by, Reviewed-by,
  - Drop RFC status from dependent patches, as everything can go in
through the pm tree.

Changes compared to v1 (most suggested by Ulf):
  - Use the flag in se instead of setting up an "always true" callback,
  - Convert the mediatek and rockchip PM Domain drivers,
  - Remove the callback.

Thanks for applying for v4.15!

Geert Uytterhoeven (5):
  PM / Domains: Allow genpd users to specify default active wakeup
behavior
  ARM: shmobile: pm-rmobile: Use GENPD_FLAG_ACTIVE_WAKEUP
  soc: mediatek: Use GENPD_FLAG_ACTIVE_WAKEUP
  soc: rockchip: power-domain: Use GENPD_FLAG_ACTIVE_WAKEUP
  PM / Domains: Remove gpd_dev_ops.active_wakeup() callback

 arch/arm/mach-shmobile/pm-rmobile.c |  8 +---
 drivers/base/power/domain.c | 13 -
 drivers/soc/mediatek/mtk-scpsys.c   | 14 ++
 drivers/soc/rockchip/pm_domains.c   | 14 ++
 include/linux/pm_domain.h   |  8 
 5 files changed, 13 insertions(+), 44 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

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

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

[PATCH v3 5/5] PM / Domains: Remove gpd_dev_ops.active_wakeup() callback

[Geert Uytterhoeven]

There are no more users left of the gpd_dev_ops.active_wakeup()
callback.  All have been converted to GENPD_FLAG_ACTIVE_WAKEUP.
Hence remove the callback.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Ulf Hansson 
Reviewed-by: Kevin Hilman 
---
v3:
  - Add Acked-by, Reviewed-by,
  - Drop RFC status,

v2:
  - New.
---
 drivers/base/power/domain.c | 14 +++---
 include/linux/pm_domain.h   |  1 -
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index c5172d70b742f288..8768e56ecf101203 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -864,14 +864,6 @@ static bool genpd_present(const struct generic_pm_domain 
*genpd)
 
 #ifdef CONFIG_PM_SLEEP
 
-static bool genpd_dev_active_wakeup(const struct generic_pm_domain *genpd,
-   struct device *dev)
-{
-   if (genpd_is_active_wakeup(genpd))
-   return true;
-   return GENPD_DEV_CALLBACK(genpd, bool, active_wakeup, dev);
-}
-
 /**
  * genpd_sync_power_off - Synchronously power off a PM domain and its masters.
  * @genpd: PM domain to power off, if possible.
@@ -976,7 +968,7 @@ static bool resume_needed(struct device *dev,
if (!device_can_wakeup(dev))
return false;
 
-   active_wakeup = genpd_dev_active_wakeup(genpd, dev);
+   active_wakeup = genpd_is_active_wakeup(genpd);
return device_may_wakeup(dev) ? active_wakeup : !active_wakeup;
 }
 
@@ -1045,7 +1037,7 @@ static int genpd_finish_suspend(struct device *dev, bool 
poweroff)
if (IS_ERR(genpd))
return -EINVAL;
 
-   if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+   if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))
return 0;
 
if (poweroff)
@@ -1100,7 +1092,7 @@ static int genpd_resume_noirq(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
 
-   if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+   if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))
return 0;
 
genpd_lock(genpd);
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 28c24c58d479e3b4..04dbef9847d3ad3b 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -36,7 +36,6 @@ struct dev_power_governor {
 struct gpd_dev_ops {
int (*start)(struct device *dev);
int (*stop)(struct device *dev);
-   bool (*active_wakeup)(struct device *dev);
 };
 
 struct genpd_power_state {
-- 
2.7.4

[PATCH v3 1/5] PM / Domains: Allow genpd users to specify default active wakeup behavior

[Geert Uytterhoeven]

It is quite common for PM Domains to require slave devices to be kept
active during system suspend if they are to be used as wakeup sources.
To enable this, currently each PM Domain or driver has to provide its
own gpd_dev_ops.active_wakeup() callback.

Introduce a new flag GENPD_FLAG_ACTIVE_WAKEUP to consolidate this.
If specified, all slave devices configured as wakeup sources will be
kept active during system suspend.

PM Domains that need more fine-grained controls, based on the slave
device, can still provide their own callbacks, as before.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Ulf Hansson 
Reviewed-by: Kevin Hilman 
---
v3:
  - Add Acked-by, Reviewed-by,

v2:
  - Use the flag in se instead of setting up an "always true" callback.
---
 drivers/base/power/domain.c | 3 +++
 include/linux/pm_domain.h   | 7 ---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 7eaee557aa615dbc..c5172d70b742f288 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -124,6 +124,7 @@ static const struct genpd_lock_ops genpd_spin_ops = {
 #define genpd_status_on(genpd) (genpd->status == GPD_STATE_ACTIVE)
 #define genpd_is_irq_safe(genpd)   (genpd->flags & GENPD_FLAG_IRQ_SAFE)
 #define genpd_is_always_on(genpd)  (genpd->flags & GENPD_FLAG_ALWAYS_ON)
+#define genpd_is_active_wakeup(genpd)  (genpd->flags & 
GENPD_FLAG_ACTIVE_WAKEUP)
 
 static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev,
const struct generic_pm_domain *genpd)
@@ -866,6 +867,8 @@ static bool genpd_present(const struct generic_pm_domain 
*genpd)
 static bool genpd_dev_active_wakeup(const struct generic_pm_domain *genpd,
struct device *dev)
 {
+   if (genpd_is_active_wakeup(genpd))
+   return true;
return GENPD_DEV_CALLBACK(genpd, bool, active_wakeup, dev);
 }
 
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 9af0356bd69c1597..28c24c58d479e3b4 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -18,9 +18,10 @@
 #include 
 
 /* Defines used for the flags field in the struct generic_pm_domain */
-#define GENPD_FLAG_PM_CLK  (1U << 0) /* PM domain uses PM clk */
-#define GENPD_FLAG_IRQ_SAFE(1U << 1) /* PM domain operates in atomic */
-#define GENPD_FLAG_ALWAYS_ON   (1U << 2) /* PM domain is always powered on */
+#define GENPD_FLAG_PM_CLK   (1U << 0) /* PM domain uses PM clk */
+#define GENPD_FLAG_IRQ_SAFE (1U << 1) /* PM domain operates in atomic */
+#define GENPD_FLAG_ALWAYS_ON(1U << 2) /* PM domain is always powered on */
+#define GENPD_FLAG_ACTIVE_WAKEUP (1U << 3) /* Keep devices active if wakeup */
 
 enum gpd_status {
GPD_STATE_ACTIVE = 0,   /* PM domain is active */
-- 
2.7.4

Re: [PATCH] ARM: dts: iwg20d-q7: Add support for ttySC3

[Geert Uytterhoeven]

Hi Fabrizio,

On Mon, Oct 23, 2017 at 3:25 PM, Fabrizio Castro
 wrote:
>> > > --- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
>> > > +++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
>> > > @@ -11,6 +11,7 @@
>> > >  / {
>> > > aliases {
>> > > serial0 = 
>> > > +   serial3 = 
>> >
>> > Given this port is not labeled "serial3", but called "data uart", you may 
>> > want
>> > to add a comment to avoid confusion:
>>
>> It's a little bit confusing, isn't it? The lines related to such interface 
>> are named as UART0_x on the carrier board schematic, the section
>> of the schematic that contains the header is named "data uart header", and 
>> the board documentation names it explicitly as "UART 3 -
>> /dev/ttySC3 (SCIFB1)".

And you cannot use "serial0" (to match "UART0"), as that's already in use
for the SOM...

>> I don't think there is anything we can do to make this easier for the user 
>> really, is there? :D
>> If we decide to add a comment to serial 3, I guess we need to be consistent 
>> and add comments for the other serial interfaces too.
>> If you still prefer having a comment there I'll send a v2 and patch(es) for 
>> adding comments to the other interfaces, just let me know.
>
> Any thoughts about this?

Making life easier for the user is good.
Consistency is also good.

I have no strong feelings about this, so do as you please...

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH 1/2] dt-bindings: usb-xhci: Document r8a7743 support

[Biju Das]

Hi Mathias,

Does this patch look okay to you?

Regards,
Biju

> -Original Message-
> From: Yoshihiro Shimoda
> Sent: 17 October 2017 02:34
> To: Biju Das ; Greg Kroah-Hartman
> ; Felipe Balbi ; Rob Herring
> ; Mark Rutland ; Mathias
> Nyman 
> Cc: Simon Horman ; Magnus Damm
> ; Chris Paterson ;
> Fabrizio Castro ;
> devicet...@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: RE: [PATCH 1/2] dt-bindings: usb-xhci: Document r8a7743 support
>
> Hi Biju-san,
> (and added Mathias-san of the XHCI maintainer as TO)
>
> Thank you for the patch!
>
> > From: Biju Das, Sent: Monday, October 16, 2017 7:13 PM
> >
> > From: Fabrizio Castro 
> >
> > Document r8a7743 xhci support. The driver will use the fallback
> > compatible string "renesas,rcar-gen2-xhci", therefore no driver change
> > is needed.
> >
> > Signed-off-by: Fabrizio Castro 
> > ---
> >  Documentation/devicetree/bindings/usb/usb-xhci.txt | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> > b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> > index 2d80b60..4125d02 100644
> > --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> > +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> > @@ -7,12 +7,14 @@ Required properties:
> >  - "marvell,armada3700-xhci" for Armada 37xx SoCs
> >  - "marvell,armada-375-xhci" for Armada 375 SoCs
> >  - "marvell,armada-380-xhci" for Armada 38x SoCs
> > +- "renesas,xhci-r8a7743" for r8a7743 SoC
> >  - "renesas,xhci-r8a7790" for r8a7790 SoC
> >  - "renesas,xhci-r8a7791" for r8a7791 SoC
> >  - "renesas,xhci-r8a7793" for r8a7793 SoC
> >  - "renesas,xhci-r8a7795" for r8a7795 SoC
> >  - "renesas,xhci-r8a7796" for r8a7796 SoC
> > -- "renesas,rcar-gen2-xhci" for a generic R-Car Gen2 compatible device
> > +- "renesas,rcar-gen2-xhci" for a generic R-Car Gen2 or RZ/G1 compatible
> > +  device
> >  - "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 compatible device
> >  - "xhci-platform" (deprecated)
> >
>
> It seems good to me. So,
>
> Reviewed-by: Yoshihiro Shimoda 
>
> Best regards,
> Yoshihiro Shimoda




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH 1/2] arm64: dts: renesas: r8a77995: Add IPMMU device nodes

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:35 AM, Simon Horman
 wrote:
> Add r8a77995 IPMMU nodes and keep all disabled by default.
>
> Based on work for the r8a7795 and r8a7796 by Magnus Damm
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

My comment for r8a7795.dtsi about IPMMU-* comments is applicable here, too.
My comment about power-domains properties probably isn't, as R-Car D3
doesn't have I/O power domains, which table 16.2 doesn't take into account.

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] arm64: dts: renesas: r8a77970: Enable IPMMU-DS1, RT and MM

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:35 AM, Simon Horman
 wrote:
> Enable the r8a77970 device nodes for IPMMU-DS1, IPMMU-RT
> and the shared IPMMU-MM device.
>
> Based on work for the r8a7796 by Magnus Damm.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 3/4] arm64: dts: renesas: r8a77970: Connect Ethernet-AVB to IPMMU-RT

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:35 AM, Simon Horman
 wrote:
> Add IPMMU-RT to the Ethernet-AVB device node.
>
> Based on work by Magnus Damm for the r8a7795.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/2] arm64: dts: renesas: r8a77995: Connect Ethernet-AVB to IPMMU-RT

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:35 AM, Simon Horman
 wrote:
> Add IPMMU-RT to the Ethernet-AVB device node.
>
> Based on work by Magnus Damm for the r8a7795.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/4] arm64: dts: renesas: r8a77970: Tie SYS-DMAC to IPMMU-DS1

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:35 AM, Simon Horman
 wrote:
> Hook up r8a77970 DMAC nodes to the IPMMU. In particular
> SYS-DMAC1 and SYS-DMAC2 get tied to IPMMU-DS1.
>
> Based on work for the r8a7796 by Magnus Damm.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 1/4] arm64: dts: renesas: r8a77970: Add IPMMU device nodes

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:35 AM, Simon Horman
 wrote:
> Add r8a77970 IPMMU nodes and keep all disabled by default.
>
> Based on work for the r8a7796 by Magnus Damm
>
> Signed-off-by: Simon Horman 

With the compatible value for ipmmu_ds1 fixed:
Reviewed-by: Geert Uytterhoeven 

My comments for r8a7795.dtsi about IPMMU-* comments and power-domains
properties are applicable here, too.

> --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi

[...]

> +   ipmmu_ds1: mmu@e774 {
> +   compatible = "renesas,ipmmu-r8a7796";

"renesas,ipmmu-r8a77970"

> +   reg = <0 0xe774 0 0x1000>; /* IPMMU-DS1 */
> +   renesas,ipmmu-main = <_mm 1>;
> +   #iommu-cells = <1>;
> +   status = "disabled";
> +   };

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 0/4] arm64: dts: renesas: r8a7796: IPMMU upstream integration

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:35 AM, Simon Horman
 wrote:
> This series adds DT nodes for IPMMU instances on r8a77970 together with
> connections to r8a77970 on-chip devices: SYS-DMAC and Ethernet-AVB.

Subject s/7796/77970/.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 0/7] arm64: dts: renesas: r8a7795: IPMMU upstream integration

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> This series adds DT nodes for IPMMU instances on r8a7796 together with
> connections to various r8a7796 on-chip devices such as Audio-DMAC, SYS-DMAC,
> Ethernet-AVB and a bunch of multimedia devices that make use of FCP.

Subject s/7795/7796/.

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 v4 14/15] arm64: dts: renesas: r8a7795: Enable IPMMU-VI, VP, DS0, DS1 and MM

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Enable the r8a7795 device nodes for IPMMU-VI, IPMMU-VP, IPMMU-DS0,

VI0, VP0

> IPMMU-DS1 and the shared IPMMU-MM device.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 6/7] arm64: dts: renesas: r8a7796: Connect Ethernet-AVB to IPMMU-DS0

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> Add IPMMU-DS0 to the Ethernet-AVB device node.
>
> Based on work by Magnus Damm for the r8a7795.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 7/7] arm64: dts: renesas: r8a7796: Enable IPMMU-DS0, DS1, MP, VI0, VC0 and MM

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Enable the r8a7795 device nodes for IPMMU-DS0, IPMMU-DS1, IPMMU-MP,
> IPMMU-VI0, IPMMU-VC0 and the shared IPMMU-MM device.
>
> Signed-off-by: Magnus Damm 
> [simon: enable IPMMU-MP, VI0 and VC0]
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 5/7] arm64: dts: renesas: r8a7796: Point VSPI via FCPVI to IPMMU-VC0

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> Hook up the FCPVI devices to allow use of VSPI with IPMMU-VC0.
>
> Based on work for the r8a7795 by Magnus Damm.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 4/7] arm64: dts: renesas: r8a7796: Point FDP1 via FCPF to IPMMU-VI0

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> Hook up the FCPF devices to allow use of FDP1 with IPMMU-VI0.
>
> Based on work by Magnus Damm for the r8a7795.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 3/7] arm64: dts: renesas: r8a7796: Tie Audio-DMAC to IPMMU-MP

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> Hook up r8a7796 Audio-DMAC nodes to the IPMMU-MP.
>
> Based on work for the r8a7795 by Magnus Damm.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/7] arm64: dts: renesas: r8a7796: Tie SYS-DMAC to IPMMU-DS0/1

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up r8a7796 DMAC nodes to the IPMMUs. In particular SYS-DMAC0
> gets tied to IPMMU-DS0, and SYS-DMAC1 and SYS-DMAC2 get tied to IPMMU-DS1.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 1/7] arm64: dts: renesas: r8a7796: Add IPMMU device nodes

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Add r8a7796 IPMMU nodes and keep all disabled by default.
>
> Signed-off-by: Magnus Damm 
> [simon: update names]
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

My comments for r8a7795.dtsi about IPMMU-* comments and power-domains
properties are applicable here, too.

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 v4 12/15] arm64: dts: renesas: r8a7795: Connect Ethernet-AVB to IPMMU-DS0

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Add IPMMU-DS0 to the Ethernet-AVB device node.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 13/15] arm64: dts: renesas: r8a7795: Connect SATA to IPMMU-HC

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Add IPMMU-HC to the SATA device node.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 11/15] arm64: dts: renesas: r8a7795-es1: Point VSPI via FCPVI to IPMMU-VP

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up the FCPVI devices to allow use of VSPI with IPMMU-VP.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 10/15] arm64: dts: renesas: r8a7795: Point VSPI via FCPVI to IPMMU-VP0/1

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up the FCPVI devices to allow use of VSPI with
> IPMMU-VP0 and IPMMU-VP1.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> @@ -155,6 +155,10 @@
> iommus = <_vp0 1>;
>  };
>
> + {
> +   iommus = <_vp0 9>;
> +};

Do we sort labels alphabetically?
Or do we follow the order of the original targets?

(Random comment that may apply elsewhere, too)

> +
>   {
> iommus = <_vi0 10>;
>  };

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 v4 09/15] arm64: dts: renesas: r8a7795: Point VSPBC/VSPBD via FCPVB to IPMMU-VP0/1

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up the FCPVB devices to allow use of VSPBC/VSPBD with
> IPMMU-VP0 and IPMMU-VP1.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 08/15] arm64: dts: renesas: r8a7795-es1: Point FDP1 via FCPF to IPMMU-VP0

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up the FCPF devices to allow use of FDP1 with IPMMU-VP0.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 07/15] arm64: dts: renesas: r8a7795: Point FDP1 via FCPF to IPMMU-VP0/1

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up the FCPF devices to allow use of FDP1 with IPMMU-VP.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 05/15] arm64: dts: renesas: r8a7795: Point DU/VSPD via FCPVD to IPMMU-VI0/1

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up the FCPVD devices to allow use of the VSP and DU
> together with IPMMU-VI1 and IPMMU-VI1.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 06/15] arm64: dts: renesas: r8a7795-es1: Point DU/VSPD via FCPVD to IPMMU-VI0

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up the FCPVD devices to allow use of the VSP and DU
> together with IPMMU-VI0.
>
> Signed-off-by: Magnus Damm 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 04/15] arm64: dts: renesas: r8a7795: Tie Audio-DMAC to IPMMU-MP0/1

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up r8a7795 ES2.0 Audio-DMAC nodes to the IPMMU-MP0.
> Hook up r8a7795 ES1.x Audio-DMAC nodes to the IPMMU-MP1.
>
> Signed-off-by: Magnus Damm 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 03/15] arm64: dts: renesas: r8a7795: Tie SYS-DMAC to IPMMU-DS0/1

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Hook up r8a7795 SYS-DMAC nodes to the IPMMUs. In particular SYS-DMAC0 gets
> tied to IPMMU-DS0, and SYS-DMAC1 and SYS-DMAC2 get tied to IPMMU-DS1.
>
> Signed-off-by: Magnus Damm 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 01/15] arm64: dts: renesas: r8a7795: Add IPMMU device nodes

[Geert Uytterhoeven]

Hi Simon,

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Add r8a7795 IPMMU nodes and keep all disabled by default.
>
> This includes all IPMMU devices for r8a7795 ES2.0. Those
> not present in r8a7795 ES1.x are removed from the DT for those
> SoCs using delete-node. A follow-up patch will add IPMMU devices
> to ES1.x which are not also present in ES2.0.
>
> Signed-off-by: Magnus Damm 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Simon Horman 

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> @@ -86,6 +91,22 @@
> };
>  };
>
> +_vi0 {
> +   renesas,ipmmu-main = <_mm 11>;
> +};
> +
> +_vp0 {
> +   renesas,ipmmu-main = <_mm 12>;
> +};
> +
> +_vc0 {
> +   renesas,ipmmu-main = <_mm 12>;

Should be 9.

> +};

Missing override:

_vc1 {
renesas,ipmmu-main = <_mm 10>;
}

> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -421,6 +421,133 @@
> resets = < 407>;
> };
>
> +   ipmmu_vi0: mmu@febd {
> +   compatible = "renesas,ipmmu-r8a7795";
> +   reg = <0 0xfebd 0 0x1000>; /* IPMMU-VI0 */

Given the label names, do we need comments like "IPMMU-VI0"?

> +   ipmmu_vp0: mmu@fe99 {
> +   compatible = "renesas,ipmmu-r8a7795";
> +   reg = <0 0xfe99 0 0x1000>; /* IPMMU-VP0 */
> +   renesas,ipmmu-main = <_mm 16>;
> +   #iommu-cells = <1>;

According to Table 16.2, some IPMMU instances (e.g VP0) are part of a power
domain.  While I doubt the kernel code handles that correctly, it should be
described in DT nevertheless.

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 v4 02/15] arm64: dts: renesas: r8a7795-es1: Add IPMMU device nodes

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> From: Magnus Damm 
>
> Add r8a7795 ES1.x IPMMU nodes and keep all disabled by default.
>
> This is a follow-up to a patch that adds IPMMU device nodes that
> are common to r8a7795 ES1.x and ES2.0
>
> Signed-off-by: Magnus Damm 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> @@ -26,6 +26,22 @@
> /delete-node/ mmu@fd96;
> /delete-node/ mmu@fd97;
>
> +   ipmmu_mp1: mmu@ec68 {
> +   compatible = "renesas,ipmmu-r8a7795";
> +   reg = <0 0xec68 0 0x1000>; /* IPMMU-MP1 */

Do we need the comments?

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/2] iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> Support the r8a77970 (R-Car V3M) and r8a77995 (R-Car D3) IPMMUs by sharing
> feature flags with r8a7795 (R-Car H3) and r8a7796 (R-Car M3-W). Also update
> IOMMU_OF_DECLARE to hook up the compat strings.
>
> Based on work for the r8a7796 by Magnus Damm
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 1/2] iommu/ipmmu-vmsa: Add r8a779(70|95) DT bindings

[Geert Uytterhoeven]

On Wed, Nov 1, 2017 at 11:34 AM, Simon Horman
 wrote:
> Update the IPMMU DT binding documentation to include the
> r8a77970 (R-Car V3M) and r8a77995 (R-Car D3) compat strings.
>
> Based on work for r8a7796 by Magnus Damm.
>
> Signed-off-by: Simon Horman 

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