[PATCH 6/7] arm64: dts: renesas: salvator-common: Add ADV7482 support

[Niklas Söderlund]

From: Kieran Bingham 

The Salvator boards use an ADV7482 receiver for HDMI and CVBS inputs.

Provide ADV7482 node on the i2c4 bus, along with connectors for the
hdmi and cvbs inputs, and link to the csi20 and csi40 nodes as outputs.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Niklas Söderlund 
---
 .../boot/dts/renesas/salvator-common.dtsi | 103 ++
 1 file changed, 103 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 96b51e5726663e75..2709df989847e889 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -66,6 +66,29 @@
enable-gpios = < 7 GPIO_ACTIVE_HIGH>;
};
 
+   cvbs-in {
+   compatible = "composite-video-connector";
+   label = "CVBS IN";
+
+   port {
+   cvbs_con: endpoint {
+   remote-endpoint = <_ain7>;
+   };
+   };
+   };
+
+   hdmi-in {
+   compatible = "hdmi-connector";
+   label = "HDMI IN";
+   type = "a";
+
+   port {
+   hdmi_in_con: endpoint {
+   remote-endpoint = <_hdmi>;
+   };
+   };
+   };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
@@ -260,6 +283,37 @@
};
 };
 
+ {
+   status = "okay";
+
+   ports {
+   port@0 {
+   reg = <0>;
+   csi20_in: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   remote-endpoint = <_txb>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@0 {
+   reg = <0>;
+
+   csi40_in: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1 2 3 4>;
+   remote-endpoint = <_txa>;
+   };
+   };
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -357,6 +411,55 @@
 
shunt-resistor-micro-ohms = <5000>;
};
+
+   video-receiver@70 {
+   compatible = "adi,adv7482";
+   reg = <0x70>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   interrupt-parent = <>;
+   interrupt-names = "intrq1", "intrq2";
+   interrupts = <30 IRQ_TYPE_LEVEL_LOW>,
+<31 IRQ_TYPE_LEVEL_LOW>;
+
+   port@7 {
+   reg = <7>;
+
+   adv7482_ain7: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+
+   port@8 {
+   reg = <8>;
+
+   adv7482_hdmi: endpoint {
+   remote-endpoint = <_in_con>;
+   };
+   };
+
+   port@10 {
+   reg = <10>;
+
+   adv7482_txa: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1 2 3 4>;
+   remote-endpoint = <_in>;
+   };
+   };
+
+   port@11 {
+   reg = <11>;
+
+   adv7482_txb: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   remote-endpoint = <_in>;
+   };
+   };
+   };
 };
 
 _dvfs {
-- 
2.17.0

[PATCH 4/7] arm64: dts: renesas: r8a77965: add VIN and CSI-2 nodes

[Niklas Söderlund]

Signed-off-by: Niklas Söderlund 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 326 +-
 1 file changed, 316 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 1f67aea493050a34..486aecacb22abcf2 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -886,43 +886,259 @@
};
 
vin0: video@e6ef {
+   compatible = "renesas,vin-r8a77965";
reg = <0 0xe6ef 0 0x1000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 811>;
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 811>;
+   renesas,id = <0>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin0csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin0csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
};
 
vin1: video@e6ef1000 {
+   compatible = "renesas,vin-r8a77965";
reg = <0 0xe6ef1000 0 0x1000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 810>;
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 810>;
+   renesas,id = <1>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin1csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin1csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
};
 
vin2: video@e6ef2000 {
+   compatible = "renesas,vin-r8a77965";
reg = <0 0xe6ef2000 0 0x1000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 809>;
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 809>;
+   renesas,id = <2>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin2csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin2csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
};
 
vin3: video@e6ef3000 {
+   compatible = "renesas,vin-r8a77965";
reg = <0 0xe6ef3000 0 0x1000>;
-   /* placeholder */
+   interrupts = ;
+   clocks = < CPG_MOD 808>;
+   power-domains = < 

[PATCH 5/7] arm64: dts: renesas: r8a77970: add VIN and CSI-2 nodes

[Niklas Söderlund]

Signed-off-by: Niklas Söderlund 
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 152 ++
 1 file changed, 152 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index c8464d1ef1b20590..98a2317a16c470bb 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -547,6 +547,119 @@
status = "disabled";
};
 
+
+   vin0: video@e6ef {
+   compatible = "renesas,vin-r8a77970";
+   reg = <0 0xe6ef 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 811>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 811>;
+   renesas,id = <0>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin0csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin1: video@e6ef1000 {
+   compatible = "renesas,vin-r8a77970";
+   reg = <0 0xe6ef1000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 810>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 810>;
+   renesas,id = <1>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin1csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin2: video@e6ef2000 {
+   compatible = "renesas,vin-r8a77970";
+   reg = <0 0xe6ef2000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 809>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 809>;
+   renesas,id = <2>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin2csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin3: video@e6ef3000 {
+   compatible = "renesas,vin-r8a77970";
+   reg = <0 0xe6ef3000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 808>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 808>;
+   renesas,id = <3>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin3csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
dmac1: 

[PATCH 7/7] arm64: dts: renesas: salvator-common: enable VIN

[Niklas Söderlund]

Signed-off-by: Niklas Söderlund 
---
 .../boot/dts/renesas/salvator-common.dtsi | 32 +++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 2709df989847e889..9256fbaaab7f3297 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -806,6 +806,38 @@
clock-frequency = <1>;
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
timeout-sec = <60>;
status = "okay";
-- 
2.17.0

[PATCH 1/7] arm64: dts: renesas: r8a7795: add VIN and CSI-2 nodes

[Niklas Söderlund]

Signed-off-by: Niklas Söderlund 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 389 +++
 1 file changed, 389 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 91486b4910cee3d7..d842940b2f439d35 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1397,6 +1397,262 @@
status = "disabled";
};
 
+   vin0: video@e6ef {
+   compatible = "renesas,vin-r8a7795";
+   reg = <0 0xe6ef 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 811>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 811>;
+   renesas,id = <0>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin0csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin0csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin1: video@e6ef1000 {
+   compatible = "renesas,vin-r8a7795";
+   reg = <0 0xe6ef1000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 810>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 810>;
+   renesas,id = <1>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin1csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin1csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin2: video@e6ef2000 {
+   compatible = "renesas,vin-r8a7795";
+   reg = <0 0xe6ef2000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 809>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 809>;
+   renesas,id = <2>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin2csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin2csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin3: video@e6ef3000 {
+   compatible = "renesas,vin-r8a7795";
+   reg = <0 0xe6ef3000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 808>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 808>;
+   renesas,id = <3>;
+   status = "disabled";
+
+ 

[PATCH 3/7] arm64: dts: renesas: r8a7796: add VIN and CSI-2 nodes

[Niklas Söderlund]

Signed-off-by: Niklas Söderlund 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 367 +++
 1 file changed, 367 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 6ffab2da07cb9d67..7c25be6b5af3eea8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1280,6 +1280,262 @@
status = "disabled";
};
 
+   vin0: video@e6ef {
+   compatible = "renesas,vin-r8a7796";
+   reg = <0 0xe6ef 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 811>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 811>;
+   renesas,id = <0>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin0csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin0csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin1: video@e6ef1000 {
+   compatible = "renesas,vin-r8a7796";
+   reg = <0 0xe6ef1000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 810>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 810>;
+   renesas,id = <1>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin1csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin1csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin2: video@e6ef2000 {
+   compatible = "renesas,vin-r8a7796";
+   reg = <0 0xe6ef2000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 809>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 809>;
+   renesas,id = <2>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   vin2csi20: endpoint@0 {
+   reg = <0>;
+   remote-endpoint= <>;
+   };
+   vin2csi40: endpoint@2 {
+   reg = <2>;
+   remote-endpoint= <>;
+   };
+   };
+   };
+   };
+
+   vin3: video@e6ef3000 {
+   compatible = "renesas,vin-r8a7796";
+   reg = <0 0xe6ef3000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 808>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 808>;
+   renesas,id = <3>;
+   status = "disabled";
+
+ 

[PATCH 0/7] arm64: dts: renesas: enable VIN, CSI-2 and ADV7482

[Niklas Söderlund]

Hi Simon,

This series enable capture for H3, M3-W, M3-N Salvator-X and Salvator-XS 
boards. It also adds the VIN and CSI-2 nodes for V3M, but as the ADV7482 
is on the V3M expansion boards I have chosen not include that enablement 
in this series.

Patch 1-5/6 adds the VIN and CSI-2 for each SoC, patch 5/6 adds the 
ADV7482 to the common salvator-common.dtsi which is shared between all 
Salvator-{X,XS} boards. And finally patch 6/6 set the status of the VINs 
to okay.

The CSI-2 bindings are acked and in Sakaris branch for-4.18-6 [1]. All 
VIN bindings except r8a77965 is already in the media tree [2]. The 
r8a77965 compability string [3] have not yet been picked up but as it 
just building on the already accepted pattern I see little risk. If this 
troubles please disregard patch 4/6.

1. https://git.linuxtv.org/sailus/media_tree.git/
2. https://git.linuxtv.org/media_tree.git/
3. https://patchwork.linuxtv.org/patch/49476/

Kieran Bingham (1):
  arm64: dts: renesas: salvator-common: Add ADV7482 support

Niklas Söderlund (6):
  arm64: dts: renesas: r8a7795: add VIN and CSI-2 nodes
  arm64: dts: renesas: r8a7795-es1: add CSI-2 node
  arm64: dts: renesas: r8a7796: add VIN and CSI-2 nodes
  arm64: dts: renesas: r8a77965: add VIN and CSI-2 nodes
  arm64: dts: renesas: r8a77970: add VIN and CSI-2 nodes
  arm64: dts: renesas: salvator-common: enable VIN

 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi  | 143 +++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 389 ++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 367 +
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 326 ++-
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 152 +++
 .../boot/dts/renesas/salvator-common.dtsi | 135 ++
 6 files changed, 1502 insertions(+), 10 deletions(-)

-- 
2.17.0

RE: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Andy Duan]

From: Florian Fainelli  Sent: 2018年5月16日 7:56
> A number of drivers have the following pattern:
> 
> if (np)
>   of_mdiobus_register()
> else
>   mdiobus_register()
> 
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
> 
> Signed-off-by: Florian Fainelli 

For drivers/net/ethernet/freescale/fec_main.c:

Reviewed-by: Fugang Duan 
> ---
>  drivers/net/dsa/bcm_sf2.c |  8 ++--
>  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
>  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
>  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
>  drivers/net/ethernet/marvell/mvmdio.c |  5 +
>  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
>  drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
>  drivers/net/phy/mdio-gpio.c   |  6 +-
>  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
>  drivers/net/usb/lan78xx.c |  7 ++-
>  11 files changed, 20 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c index
> ac621f44237a..02e8982519ce 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch
> *ds)
>   priv->slave_mii_bus->parent = ds->dev->parent;
>   priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
> 
> - if (dn)
> - err = of_mdiobus_register(priv->slave_mii_bus, dn);
> - else
> - err = mdiobus_register(priv->slave_mii_bus);
> -
> - if (err)
> + err = of_mdiobus_register(priv->slave_mii_bus, dn);
> + if (err && dn)
>   of_node_put(dn);
> 
>   return err;
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
> b/drivers/net/dsa/mv88e6xxx/chip.c
> index b23c11d9f4b2..2bb3f03ee1cb 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct
> mv88e6xxx_chip *chip,
>   return err;
>   }
> 
> - if (np)
> - err = of_mdiobus_register(bus, np);
> - else
> - err = mdiobus_register(bus);
> + err = of_mdiobus_register(bus, np);
>   if (err) {
>   dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
>   mv88e6xxx_g2_irq_mdio_free(chip, bus); diff --git
> a/drivers/net/ethernet/cadence/macb_main.c
> b/drivers/net/ethernet/cadence/macb_main.c
> index b4c9268100bb..3e93df5d4e3b 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
>   dev_set_drvdata(>dev->dev, bp->mii_bus);
> 
>   np = bp->pdev->dev.of_node;
> + if (pdata)
> + bp->mii_bus->phy_mask = pdata->phy_mask;
> 
> - if (np) {
> - err = of_mdiobus_register(bp->mii_bus, np);
> - } else {
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> - err = mdiobus_register(bp->mii_bus);
> - }
> -
> + err = of_mdiobus_register(bp->mii_bus, np);
>   if (err)
>   goto err_out_free_mdiobus;
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index d4604bc8eb5b..f3e43db0d6cb 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device
> *pdev)
>   fep->mii_bus->parent = >dev;
> 
>   node = of_get_child_by_name(pdev->dev.of_node, "mdio");
> - if (node) {
> - err = of_mdiobus_register(fep->mii_bus, node);
> + err = of_mdiobus_register(fep->mii_bus, node);
> + if (node)
>   of_node_put(node);
> - } else {
> - err = mdiobus_register(fep->mii_bus);
> - }
> -
>   if (err)
>   goto err_out_free_mdiobus;
> 
> diff --git a/drivers/net/ethernet/marvell/mvmdio.c
> b/drivers/net/ethernet/marvell/mvmdio.c
> index 0495487f7b42..c5dac6bd2be4 100644
> --- a/drivers/net/ethernet/marvell/mvmdio.c
> +++ b/drivers/net/ethernet/marvell/mvmdio.c
> @@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device
> *pdev)
>   goto out_mdio;
>   }
> 
> - if (pdev->dev.of_node)
> - ret = of_mdiobus_register(bus, pdev->dev.of_node);
> - else
> - ret = mdiobus_register(bus);
> + ret = of_mdiobus_register(bus, pdev->dev.of_node);
>   if (ret < 0) {
>   dev_err(>dev, "Cannot register MDIO bus (%d)\n", ret);
>   goto out_mdio;
> diff --git 

Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Grygorii Strashko]

On 05/15/2018 06:56 PM, Florian Fainelli wrote:

A number of drivers have the following pattern:

if (np)
of_mdiobus_register()
else
mdiobus_register()

which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.

Signed-off-by: Florian Fainelli 
---
  drivers/net/dsa/bcm_sf2.c |  8 ++--
  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
  drivers/net/ethernet/marvell/mvmdio.c |  5 +
  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
  drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-


for drivers/net/ethernet/ti/davinci_mdio.c:
Reviewed-by: Grygorii Strashko 


  drivers/net/phy/mdio-gpio.c   |  6 +-
  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
  drivers/net/usb/lan78xx.c |  7 ++-
  11 files changed, 20 insertions(+), 61 deletions(-)


--
regards,
-grygorii

[PATCH net-next v2 1/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Florian Fainelli]

When the device_node specified is NULL, fall back to mdiobus_register().
We have a number of drivers having a similar pattern which is:

if (np)
of_mdiobus_register()
else
mdiobus_register()

so incorporate that behavior within the core of_mdiobus_register()
function. This is also consistent with the stub version that we defined
when CONFIG_OF=n.

Signed-off-by: Florian Fainelli 
---
 drivers/of/of_mdio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 8c0c92712fc9..d963baf8e53a 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -204,6 +204,9 @@ int of_mdiobus_register(struct mii_bus *mdio, struct 
device_node *np)
bool scanphys = false;
int addr, rc;
 
+   if (!np)
+   return mdiobus_register(mdio);
+
/* Do not continue if the node is disabled */
if (!of_device_is_available(np))
return -ENODEV;
-- 
2.14.1

[PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Florian Fainelli]

Hi all,

This patch series updates of_mdiobus_register() such that when the device_node
argument is NULL, it calls mdiobus_register() directly. This is consistent with
the behavior of of_mdiobus_register() when CONFIG_OF=n.

I only converted the most obvious drivers, there are others that have a much
less obvious behavior and specifically attempt to deal with CONFIG_ACPI.

Changes in v2:

- fixed build error in davincin_mdio.c (Grygorii)
- reworked first patch a bit: commit message, subject and removed useless
  code comment

Florian Fainelli (2):
  of: mdio: Fall back to mdiobus_register() with NULL device_node
  drivers: net: Remove device_node checks with of_mdiobus_register()

 drivers/net/dsa/bcm_sf2.c |  8 ++--
 drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
 drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
 drivers/net/ethernet/freescale/fec_main.c |  8 ++--
 drivers/net/ethernet/marvell/mvmdio.c |  5 +
 drivers/net/ethernet/renesas/sh_eth.c | 11 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
 drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
 drivers/net/phy/mdio-gpio.c   |  6 +-
 drivers/net/phy/mdio-mscc-miim.c  |  6 +-
 drivers/net/usb/lan78xx.c |  7 ++-
 drivers/of/of_mdio.c  |  3 +++
 12 files changed, 23 insertions(+), 61 deletions(-)

-- 
2.14.1

[PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Florian Fainelli]

A number of drivers have the following pattern:

if (np)
of_mdiobus_register()
else
mdiobus_register()

which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.

Signed-off-by: Florian Fainelli 
---
 drivers/net/dsa/bcm_sf2.c |  8 ++--
 drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
 drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
 drivers/net/ethernet/freescale/fec_main.c |  8 ++--
 drivers/net/ethernet/marvell/mvmdio.c |  5 +
 drivers/net/ethernet/renesas/sh_eth.c | 11 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
 drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
 drivers/net/phy/mdio-gpio.c   |  6 +-
 drivers/net/phy/mdio-mscc-miim.c  |  6 +-
 drivers/net/usb/lan78xx.c |  7 ++-
 11 files changed, 20 insertions(+), 61 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ac621f44237a..02e8982519ce 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
priv->slave_mii_bus->parent = ds->dev->parent;
priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
 
-   if (dn)
-   err = of_mdiobus_register(priv->slave_mii_bus, dn);
-   else
-   err = mdiobus_register(priv->slave_mii_bus);
-
-   if (err)
+   err = of_mdiobus_register(priv->slave_mii_bus, dn);
+   if (err && dn)
of_node_put(dn);
 
return err;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b23c11d9f4b2..2bb3f03ee1cb 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip 
*chip,
return err;
}
 
-   if (np)
-   err = of_mdiobus_register(bus, np);
-   else
-   err = mdiobus_register(bus);
+   err = of_mdiobus_register(bus, np);
if (err) {
dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
mv88e6xxx_g2_irq_mdio_free(chip, bus);
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index b4c9268100bb..3e93df5d4e3b 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
dev_set_drvdata(>dev->dev, bp->mii_bus);
 
np = bp->pdev->dev.of_node;
+   if (pdata)
+   bp->mii_bus->phy_mask = pdata->phy_mask;
 
-   if (np) {
-   err = of_mdiobus_register(bp->mii_bus, np);
-   } else {
-   if (pdata)
-   bp->mii_bus->phy_mask = pdata->phy_mask;
-
-   err = mdiobus_register(bp->mii_bus);
-   }
-
+   err = of_mdiobus_register(bp->mii_bus, np);
if (err)
goto err_out_free_mdiobus;
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..f3e43db0d6cb 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device 
*pdev)
fep->mii_bus->parent = >dev;
 
node = of_get_child_by_name(pdev->dev.of_node, "mdio");
-   if (node) {
-   err = of_mdiobus_register(fep->mii_bus, node);
+   err = of_mdiobus_register(fep->mii_bus, node);
+   if (node)
of_node_put(node);
-   } else {
-   err = mdiobus_register(fep->mii_bus);
-   }
-
if (err)
goto err_out_free_mdiobus;
 
diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
b/drivers/net/ethernet/marvell/mvmdio.c
index 0495487f7b42..c5dac6bd2be4 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
goto out_mdio;
}
 
-   if (pdev->dev.of_node)
-   ret = of_mdiobus_register(bus, pdev->dev.of_node);
-   else
-   ret = mdiobus_register(bus);
+   ret = of_mdiobus_register(bus, pdev->dev.of_node);
if (ret < 0) {
dev_err(>dev, "Cannot register MDIO bus (%d)\n", ret);
goto out_mdio;
diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index 5970d9e5ddf1..8dd41e08a6c6 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3025,15 +3025,10 @@ static int sh_mdio_init(struct sh_eth_private *mdp,
 

Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Florian Fainelli]

On 05/15/2018 03:57 PM, Grygorii Strashko wrote:
> 
> 
> On 05/15/2018 04:59 PM, Florian Fainelli wrote:
>> A number of drivers have the following pattern:
>>
>> if (np)
>> of_mdiobus_register()
>> else
>> mdiobus_register()
>>
>> which the implementation of of_mdiobus_register() now takes care of.
>> Remove that pattern in drivers that strictly adhere to it.
>>
>> Signed-off-by: Florian Fainelli 
>> ---
>>   drivers/net/dsa/bcm_sf2.c |  8 ++--
>>   drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
>>   drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
>>   drivers/net/ethernet/freescale/fec_main.c |  8 ++--
>>   drivers/net/ethernet/marvell/mvmdio.c |  5 +
>>   drivers/net/ethernet/renesas/sh_eth.c | 11 +++
>>   drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
>>   drivers/net/ethernet/ti/davinci_mdio.c    |  6 ++
>>   drivers/net/phy/mdio-gpio.c   |  6 +-
>>   drivers/net/phy/mdio-mscc-miim.c  |  6 +-
>>   drivers/net/usb/lan78xx.c |  7 ++-
>>   11 files changed, 19 insertions(+), 60 deletions(-)
>>
> 
> ...
> 
>>   goto bus_register_fail;
>> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
>> b/drivers/net/ethernet/ti/davinci_mdio.c
>> index 98a1c97fb95e..e720244e7f71 100644
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -431,10 +431,8 @@ static int davinci_mdio_probe(struct
>> platform_device *pdev)
>>    */
>>   if (dev->of_node && of_get_child_count(dev->of_node)) {
> 
> It causes build error due to "{" above.

Humpf, shame on me for not enabling that driver, thanks for catching this!

> 
>>   data->skip_scan = true;
>> -    ret = of_mdiobus_register(data->bus, dev->of_node);
>> -    } else {
>> -    ret = mdiobus_register(data->bus);
>> -    }
>> +
>> +    ret = of_mdiobus_register(data->bus, dev->of_node);
>>   if (ret)
>>   goto bail_out;
>>   diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
>> index b501221819e1..4e4c8daf44c3 100644
>> --- a/drivers/net/phy/mdio-gpio.c
>> +++ b/drivers/net/phy/mdio-gpio.c
>> @@ -179,11 +179,7 @@ static int mdio_gpio_probe(struct platform_device
>> *pdev)
> 
> [...]
> 


-- 
Florian

Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Grygorii Strashko]

On 05/15/2018 04:59 PM, Florian Fainelli wrote:

A number of drivers have the following pattern:

if (np)
of_mdiobus_register()
else
mdiobus_register()

which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.

Signed-off-by: Florian Fainelli 
---
  drivers/net/dsa/bcm_sf2.c |  8 ++--
  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
  drivers/net/ethernet/marvell/mvmdio.c |  5 +
  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
  drivers/net/ethernet/ti/davinci_mdio.c|  6 ++
  drivers/net/phy/mdio-gpio.c   |  6 +-
  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
  drivers/net/usb/lan78xx.c |  7 ++-
  11 files changed, 19 insertions(+), 60 deletions(-)



...


goto bus_register_fail;
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c 
b/drivers/net/ethernet/ti/davinci_mdio.c
index 98a1c97fb95e..e720244e7f71 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -431,10 +431,8 @@ static int davinci_mdio_probe(struct platform_device *pdev)
 */
if (dev->of_node && of_get_child_count(dev->of_node)) {


It causes build error due to "{" above.


data->skip_scan = true;
-   ret = of_mdiobus_register(data->bus, dev->of_node);
-   } else {
-   ret = mdiobus_register(data->bus);
-   }
+
+   ret = of_mdiobus_register(data->bus, dev->of_node);
if (ret)
goto bail_out;
  
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c

index b501221819e1..4e4c8daf44c3 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -179,11 +179,7 @@ static int mdio_gpio_probe(struct platform_device *pdev)


[...]

--
regards,
-grygorii

Re: [git pull] clk: renesas: Updates for v4.18

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-05-09 09:52:34)
> Hi Mike, Stephen,
> 
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> 
>   Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.18-tag1
> 
> for you to fetch changes up to 3570a2af473789c5d5f5b9e04f72295102967824:
> 
>   clk: renesas: cpg-mssr: Add support for R-Car E3 (2018-05-09 18:43:57 +0200)
> 
> 
> clk: renesas: Updates for v4.18
> 
>   - Add support for the MSIOF module clocks on R-Car M3-N,
>   - Add support for the new RZ/G1C and R-Car E3 SoCs,
>   - Small fixes and cleanups.

Thanks. Pulled into clk-next.

[PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Florian Fainelli]

A number of drivers have the following pattern:

if (np)
of_mdiobus_register()
else
mdiobus_register()

which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.

Signed-off-by: Florian Fainelli 
---
 drivers/net/dsa/bcm_sf2.c |  8 ++--
 drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
 drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
 drivers/net/ethernet/freescale/fec_main.c |  8 ++--
 drivers/net/ethernet/marvell/mvmdio.c |  5 +
 drivers/net/ethernet/renesas/sh_eth.c | 11 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
 drivers/net/ethernet/ti/davinci_mdio.c|  6 ++
 drivers/net/phy/mdio-gpio.c   |  6 +-
 drivers/net/phy/mdio-mscc-miim.c  |  6 +-
 drivers/net/usb/lan78xx.c |  7 ++-
 11 files changed, 19 insertions(+), 60 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ac621f44237a..02e8982519ce 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
priv->slave_mii_bus->parent = ds->dev->parent;
priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
 
-   if (dn)
-   err = of_mdiobus_register(priv->slave_mii_bus, dn);
-   else
-   err = mdiobus_register(priv->slave_mii_bus);
-
-   if (err)
+   err = of_mdiobus_register(priv->slave_mii_bus, dn);
+   if (err && dn)
of_node_put(dn);
 
return err;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b23c11d9f4b2..2bb3f03ee1cb 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip 
*chip,
return err;
}
 
-   if (np)
-   err = of_mdiobus_register(bus, np);
-   else
-   err = mdiobus_register(bus);
+   err = of_mdiobus_register(bus, np);
if (err) {
dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
mv88e6xxx_g2_irq_mdio_free(chip, bus);
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index b4c9268100bb..3e93df5d4e3b 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
dev_set_drvdata(>dev->dev, bp->mii_bus);
 
np = bp->pdev->dev.of_node;
+   if (pdata)
+   bp->mii_bus->phy_mask = pdata->phy_mask;
 
-   if (np) {
-   err = of_mdiobus_register(bp->mii_bus, np);
-   } else {
-   if (pdata)
-   bp->mii_bus->phy_mask = pdata->phy_mask;
-
-   err = mdiobus_register(bp->mii_bus);
-   }
-
+   err = of_mdiobus_register(bp->mii_bus, np);
if (err)
goto err_out_free_mdiobus;
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..f3e43db0d6cb 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device 
*pdev)
fep->mii_bus->parent = >dev;
 
node = of_get_child_by_name(pdev->dev.of_node, "mdio");
-   if (node) {
-   err = of_mdiobus_register(fep->mii_bus, node);
+   err = of_mdiobus_register(fep->mii_bus, node);
+   if (node)
of_node_put(node);
-   } else {
-   err = mdiobus_register(fep->mii_bus);
-   }
-
if (err)
goto err_out_free_mdiobus;
 
diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
b/drivers/net/ethernet/marvell/mvmdio.c
index 0495487f7b42..c5dac6bd2be4 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
goto out_mdio;
}
 
-   if (pdev->dev.of_node)
-   ret = of_mdiobus_register(bus, pdev->dev.of_node);
-   else
-   ret = mdiobus_register(bus);
+   ret = of_mdiobus_register(bus, pdev->dev.of_node);
if (ret < 0) {
dev_err(>dev, "Cannot register MDIO bus (%d)\n", ret);
goto out_mdio;
diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index 5970d9e5ddf1..8dd41e08a6c6 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3025,15 +3025,10 @@ static int sh_mdio_init(struct sh_eth_private *mdp,
 

[PATCH net-next 1/2] of: mdio: Fall back to mdiobus_register() with np is NULL

[Florian Fainelli]

When the Device Tree node specified is NULL, fall back to
mdiobus_register(). We have a number of drivers having a similar pattern
which is:

if (np)
of_mdiobus_register()
else
mdiobus_register()

so incorporate that behavior within the core of_mdiobus_register()
function. This is also consistent with the stub version that we defined
when CONFIG_OF=n.

Signed-off-by: Florian Fainelli 
---
 drivers/of/of_mdio.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 8c0c92712fc9..2341dbf675bf 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -204,6 +204,12 @@ int of_mdiobus_register(struct mii_bus *mdio, struct 
device_node *np)
bool scanphys = false;
int addr, rc;
 
+   /* If the Device Tree node does not exist, fall back to traditional
+* registration
+*/
+   if (!np)
+   return mdiobus_register(mdio);
+
/* Do not continue if the node is disabled */
if (!of_device_is_available(np))
return -ENODEV;
-- 
2.14.1

[PATCH net-next 0/2] of: mdio: Fall back to mdiobus_register() with np is NULL

[Florian Fainelli]

Hi all,

This patch series updates of_mdiobus_register() such that when the device_node
argument is NULL, it calls mdiobus_register() directly. This is consistent with
the behavior of of_mdiobus_register() when CONFIG_OF=n.

I only converted the most obvious drivers, there are others that have a much
less obvious behavior and specifically attempt to deal with CONFIG_ACPI.

Florian Fainelli (2):
  of: mdio: Fall back to mdiobus_register() with np is NULL
  drivers: net: Remove device_node checks with of_mdiobus_register()

 drivers/net/dsa/bcm_sf2.c |  8 ++--
 drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
 drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
 drivers/net/ethernet/freescale/fec_main.c |  8 ++--
 drivers/net/ethernet/marvell/mvmdio.c |  5 +
 drivers/net/ethernet/renesas/sh_eth.c | 11 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
 drivers/net/ethernet/ti/davinci_mdio.c|  6 ++
 drivers/net/phy/mdio-gpio.c   |  6 +-
 drivers/net/phy/mdio-mscc-miim.c  |  6 +-
 drivers/net/usb/lan78xx.c |  7 ++-
 drivers/of/of_mdio.c  |  6 ++
 12 files changed, 25 insertions(+), 60 deletions(-)

-- 
2.14.1

Re: [PATCH 05/61] clk: samsung: simplify getting .drvdata

[Stephen Boyd]

Quoting Wolfram Sang (2018-04-19 07:05:35)
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
> ---

Applied to clk-next

Re: [PATCH 05/61] clk: samsung: simplify getting .drvdata

[Stephen Boyd]

Quoting Sylwester Nawrocki (2018-05-15 02:32:12)
> On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> > We should get drvdata from struct device directly. Going via
> > platform_device is an unneeded step back and forth.
> > 
> > Signed-off-by: Wolfram Sang 
> 
> Acked-by: Sylwester Nawrocki 
> 
> It seems to be the only clk/samsung patch in the v4.18 queue, please
> feel free to apply it directly.

Ok. I'll pick it up.

Re: [PATCH] drm: rcar-du: Fix rcar_du_of_init() stub

[Kieran Bingham]

Hi Laurent

Thanks for identifying this fault and posting the fix.

(+linux-renesas-soc)

On 15/05/18 16:57, Laurent Pinchart wrote:
> The rcar_du_of_init() function is supposed to be defined as a stub when
> CONFIG_DRM_RCAR_LVDS is disabled as the rcar_du_of.c file isn't compiled
> in that case. However, a bug in the configuration option check makes it
> a stub when CONFIG_DRM_RCAR_LVDS=m as well, which prevents legacy DTs
> from being fixed at boot time. Fix the configuration option check by
> using IS_ENABLED.
> 
> Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder 
> nodes")
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_of.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_of.h
> index c2e65a727e91..8dd3fbe96650 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_of.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.h
> @@ -11,7 +11,7 @@
>  
>  struct of_device_id;
>  
> -#ifdef CONFIG_DRM_RCAR_LVDS
> +#if IS_ENABLED(CONFIG_DRM_RCAR_LVDS)
>  void __init rcar_du_of_init(const struct of_device_id *of_ids);
>  #else
>  static inline void rcar_du_of_init(const struct of_device_id *of_ids) { }
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH/RFT v3 1/3] thermal: rcar_thermal: add r8a77995 support

[Yoshihiro Kaneko]

2018-05-15 16:26 GMT+09:00 Simon Horman :
> On Mon, May 14, 2018 at 06:11:59AM +0900, Yoshihiro Kaneko wrote:
>> Hi Simon-san,
>>
>> 2018年5月10日(木) 3:11 Simon Horman :
>>
>> > On Tue, Apr 03, 2018 at 09:43:03PM +0900, Yoshihiro Kaneko wrote:
>> > > Add support for R-Car D3 (r8a77995) thermal sensor.
>> > >
>> > > Signed-off-by: Yoshihiro Kaneko 
>> > > ---
>> > >  drivers/thermal/rcar_thermal.c | 154
>> > -
>> > >  1 file changed, 122 insertions(+), 32 deletions(-)
>> > >
>> > > diff --git a/drivers/thermal/rcar_thermal.c
>> > b/drivers/thermal/rcar_thermal.c
>> > > index 73e5fee..5ec47a9 100644
>> > > --- a/drivers/thermal/rcar_thermal.c
>> > > +++ b/drivers/thermal/rcar_thermal.c
>> > > @@ -58,10 +58,43 @@ struct rcar_thermal_common {
>> > >   spinlock_t lock;
>> > >  };
>> > >
>> > > +struct rcar_thermal_chip {
>> > > + unsigned int use_of_thermal : 1;
>> > > + unsigned int has_filonoff : 1;
>> > > + unsigned int irq_per_ch : 1;
>> > > + unsigned int needs_suspend_resume : 1;
>> > > + unsigned int nirqs;
>> > > +};
>> > > +
>> > > +static const struct rcar_thermal_chip rcar_thermal = {
>> > > + .use_of_thermal = 0,
>> > > + .has_filonoff = 1,
>> > > + .irq_per_ch = 0,
>> > > + .needs_suspend_resume = 0,
>> > > + .nirqs = 1,
>> > > +};
>> > > +
>> > > +static const struct rcar_thermal_chip rcar_gen2_thermal = {
>> > > + .use_of_thermal = 1,
>> > > + .has_filonoff = 1,
>> > > + .irq_per_ch = 0,
>> > > + .needs_suspend_resume = 0,
>> > > + .nirqs = 1,
>> > > +};
>> > > +
>> > > +static const struct rcar_thermal_chip rcar_gen3_thermal = {
>> > > + .use_of_thermal = 1,
>> > > + .has_filonoff = 0,
>> > > + .irq_per_ch = 1,
>> > > + .needs_suspend_resume = 1,
>> > > + .nirqs = 2,
>> > > +};
>> >
>> > The binding and dts patches in this series describe 3 interrupts
>> > for R-Car D3. But the above specifies two. Am I missing something obvious?
>>
>>
>> R-Car D3 has 3 interrupts, but this driver uses only 2 interrupts to detect
>> a temperature change, rise or fall.
>
> Thanks, that makes perfect sense.
>
> Perhaps a comment above ".nirqs = 2" would make it more obvious to the casual
> observer?

I agree with you.
I will update this patch.

Re: [PATCH] drm: rcar-du: disable dtc graph-endpoint warnings on DT overlays

[Laurent Pinchart]

Hi Rob,

Thank you for the patch.

On Friday, 11 May 2018 17:33:23 EEST Rob Herring wrote:
> The rcar DT overlays are missing symetrical remote-endpoint properties
> in their graph nodes because the remote-endpoint is fixed up at
> run-time. Disable the dtc 'graph-endpoint' warnings when compiling these
> overlays. If this becomes a common problem for overlays, then perhaps
> this check needs to be disabled for all overlays.
> 
> Reported-by: Stephen Rothwell 
> Cc: Laurent Pinchart 
> Cc: David Airlie 
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-renesas-soc@vger.kernel.org
> Signed-off-by: Rob Herring 

Acked-by: Laurent Pinchart 

> ---
> This needs to go thru my tree because it is dependent on the dtc update
> that adds the warning (perhaps we're going to need to add option
> checking for dtc).
> 
> Rob
> 
>  drivers/gpu/drm/rcar-du/Makefile | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile index 3e58ed93d5b1..2a3b8d7972b5 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -17,3 +17,10 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
>  obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
>  obj-$(CONFIG_DRM_RCAR_DW_HDMI)   += rcar_dw_hdmi.o
>  obj-$(CONFIG_DRM_RCAR_LVDS)  += rcar_lvds.o
> +
> +# 'remote-endpoint' is fixed up at run-time
> +DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7791 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7793 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7795 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7796 += -Wno-graph_endpoint


-- 
Regards,

Laurent Pinchart

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

[Geert Uytterhoeven]

Hi Gilad,

On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef  wrote:
> Add bindings for CryptoCell instance in the SoC.
>
> Signed-off-by: Gilad Ben-Yossef 

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -528,6 +528,14 @@
> status = "disabled";
> };
>
> +   arm_cc630p: crypto@e6601000 {
> +   compatible = "arm,cryptocell-630p-ree";
> +   interrupts = ;
> +   #interrupt-cells = <2>;

I believe the #interrupt-cells property is not needed.

> +   reg = <0x0 0xe6601000 0 0x1000>;
> +   clocks = < CPG_MOD 229>;
> +   };

The rest looks good, but I cannot verify the register block.

> +
> i2c3: i2c@e66d {
> #address-cells = <1>;
> #size-cells = <0>;

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/3] clk: renesas: r8a7795: Add ccree clock

[Geert Uytterhoeven]

Hi Gilad,

On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef  wrote:
> This patch adds the clock used by the CryptoCell 630p instance in the SoC.
>
> Signed-off-by: Gilad Ben-Yossef 

Thanks for your patch!

> --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> @@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata 
> = {
> DEF_MOD("sys-dmac2", 217,   R8A7795_CLK_S0D3),
> DEF_MOD("sys-dmac1", 218,   R8A7795_CLK_S0D3),
> DEF_MOD("sys-dmac0", 219,   R8A7795_CLK_S0D3),
> +   DEF_MOD("ccree", 229,   R8A7795_CLK_S3D2),

I don't know if "ccree" is the proper name for this clock, as there
may be multiple
instances.
I also can't verify the parent clock.

> DEF_MOD("cmt3",  300,   R8A7795_CLK_R),
> DEF_MOD("cmt2",  301,   R8A7795_CLK_R),
> DEF_MOD("cmt1",  302,   R8A7795_CLK_R),

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

renesas-drivers-2018-05-15-v4.17-rc5

[Geert Uytterhoeven]

I have pushed renesas-drivers-2018-05-15-v4.17-rc5 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20180514-v4.17-rc5.

Included branches with driver code:
  - clk-renesas
  - sh-pfc
  - topic/rcar-gen2-wdt-v6
  - topic/bd9571-ddr-backup-mode-driver-v3
  - topic/r8a77990-soc-v1
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/cpufreq-automatic
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/ipmmu-driver-v6
  - git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
  - git://linuxtv.org/pinchartl/media.git#tags/vsp1-discom-v3-20180428
  - git://linuxtv.org/pinchartl/media.git#tags/drm-next-colorkey-v1-20171215
  - git://git.ragnatech.se/linux#for-renesas-drivers
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/tlb-optimise/v9
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#d3/i2c-conflict/drm
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/du/interlaced/v4
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/drm/du/m3n

Included fixes:
  - [LOCAL] arm64: defconfig: Update renesas_defconfig

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next

Gr{oetje,eeting}s,

Geert

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

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

Re: Booting Salvator-X ES1 board with upstream kernel

[Gilad Ben-Yossef]

On Mon, May 14, 2018 at 5:29 PM, Geert Uytterhoeven
 wrote:
> Hi Gilad,
>
> On Thu, May 10, 2018 at 10:12 AM, Gilad Ben-Yossef  
> wrote:
>> I am trying to add support for the CryptoCell security IP in the
>> R-Rcar boards to mainline but I've run into some trouble.
>
> Ah, we have found a user ;-)

Yes. I would be very happy if all our customer would be as cooperative
as Renesas.
That would make my life and the life of the users easier :-)

I've also have the HiKey960 on my todo list.

>
>> I have an R-Car 3rd gen Salvator-X ES1 board. I've been able to boot
>> Linux 4.9 on it from the rareness-bsp tree, using the defconfig and
>> the r8a7795-es1-salvator-x DTB with no problems, so the HW is fine.
>>
>> However, I can't seem to boot an upstream kernel (Linus master or
>> soc-for-v4.17 branch) on it. I just get total silence on the UART
>> after u-boot.
>>
>> Any tips or ideas for me to try?
>
> Please try appending the following to the kernel command line:
>
> earlycon keep_bootcon
>
> FWIW, I'm using:
>
> tftpboot 0x4808 h3-salvator-x/Image
> tftpboot 0x49f0 h3-salvator-x/r8a7795-es1-salvator-x.dtb
> booti 0x4808 - 0x49f0
>
> Which firmware revision do you have? It may be too old to boot moden
> (large) kernel images. Check the first line of BL2 output.
>
> Which config are you using? Please try renesas_defconfig from Simon's
> repository.

That was it. I was building with defoncfig and getting a kernel that won't be.
Simon's config did the trick.

Many thanks!

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

[PATCH 1/3] crypto: ccree: drop signature register check

[Gilad Ben-Yossef]

We were using the content of the signature register as a sanity
check for the hardware functioning but it turns out not all
implementers use the same values so the check is giving false
negative on certain SoCs and so we drop it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/crypto/ccree/cc_driver.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 89ce013..f8ff358 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -38,21 +38,20 @@ MODULE_PARM_DESC(cc_dump_bytes, "Dump buffers to kernel log 
as debugging aid");
 struct cc_hw_data {
char *name;
enum cc_hw_rev rev;
-   u32 sig;
 };
 
 /* Hardware revisions defs. */
 
 static const struct cc_hw_data cc712_hw = {
-   .name = "712", .rev = CC_HW_REV_712, .sig =  0xDCC71200U
+   .name = "712", .rev = CC_HW_REV_712
 };
 
 static const struct cc_hw_data cc710_hw = {
-   .name = "710", .rev = CC_HW_REV_710, .sig =  0xDCC63200U
+   .name = "710", .rev = CC_HW_REV_710
 };
 
 static const struct cc_hw_data cc630p_hw = {
-   .name = "630P", .rev = CC_HW_REV_630, .sig = 0xDCC63000U
+   .name = "630P", .rev = CC_HW_REV_630
 };
 
 static const struct of_device_id arm_ccree_dev_of_match[] = {
@@ -186,7 +185,6 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
struct cc_drvdata *new_drvdata;
struct device *dev = _dev->dev;
struct device_node *np = dev->of_node;
-   u32 signature_val;
u64 dma_mask;
const struct cc_hw_data *hw_rev;
const struct of_device_id *dev_id;
@@ -275,16 +273,6 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
return rc;
}
 
-   /* Verify correct mapping */
-   signature_val = cc_ioread(new_drvdata, CC_REG(HOST_SIGNATURE));
-   if (signature_val != hw_rev->sig) {
-   dev_err(dev, "Invalid CC signature: SIGNATURE=0x%08X != 
expected=0x%08X\n",
-   signature_val, hw_rev->sig);
-   rc = -EINVAL;
-   goto post_clk_err;
-   }
-   dev_dbg(dev, "CC SIGNATURE=0x%08X\n", signature_val);
-
/* Display HW versions */
dev_info(dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver 
version %s\n",
 hw_rev->name, cc_ioread(new_drvdata, CC_REG(HOST_VERSION)),
-- 
2.7.4

[PATCH 2/3] clk: renesas: r8a7795: Add ccree clock

[Gilad Ben-Yossef]

This patch adds the clock used by the CryptoCell 630p instance in the SoC.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c 
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 775b0ce..642706a 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
DEF_MOD("sys-dmac2", 217,   R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac1", 218,   R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac0", 219,   R8A7795_CLK_S0D3),
+   DEF_MOD("ccree", 229,   R8A7795_CLK_S3D2),
DEF_MOD("cmt3",  300,   R8A7795_CLK_R),
DEF_MOD("cmt2",  301,   R8A7795_CLK_R),
DEF_MOD("cmt1",  302,   R8A7795_CLK_R),
-- 
2.7.4

[PATCH 0/3] enable ccree on Renesas R-Car platform

[Gilad Ben-Yossef]

The following patch set enables CryptoCell present in the Renesas
R-Car SoC.

Gilad Ben-Yossef (3):
  crypto: ccree: drop signature register check
  clk: renesas: r8a7795: Add ccree clock
  arm64: dts: renesas: r8a7795: add ccree binding

 arch/arm64/boot/dts/renesas/r8a7795.dtsi |  8 
 drivers/clk/renesas/r8a7795-cpg-mssr.c   |  1 +
 drivers/crypto/ccree/cc_driver.c | 18 +++---
 3 files changed, 12 insertions(+), 15 deletions(-)

-- 
2.7.4

[PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

[Gilad Ben-Yossef]

Add bindings for CryptoCell instance in the SoC.

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

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 91486b4..6c76841 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -528,6 +528,14 @@
status = "disabled";
};
 
+   arm_cc630p: crypto@e6601000 {
+   compatible = "arm,cryptocell-630p-ree";
+   interrupts = ;
+   #interrupt-cells = <2>;
+   reg = <0x0 0xe6601000 0 0x1000>;
+   clocks = < CPG_MOD 229>;
+   };
+
i2c3: i2c@e66d {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.4

[PATCH 4/5] arm64: dts: renesas: r8a77995-draak: add HDMI output

[Ulrich Hecht]

Adds LVDS decoder, HDMI encoder and connector for Draak boards.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 80 ++
 1 file changed, 80 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 9d73de8..b059e32 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -27,6 +27,41 @@
stdout-path = "serial0:115200n8";
};
 
+   lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+   vcc-supply = <_3p3v>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   thc63lvd1024_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   thc63lvd1024_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_out: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
vga {
compatible = "vga-connector";
 
@@ -154,6 +189,39 @@
reg = <0x50>;
pagesize = <8>;
};
+
+   hdmi@39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>, <0x3f>, <0x38>, <0x3c>;
+   reg-names = "main", "edid", "packet", "cec";
+   interrupt-parent = <>;
+   interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con_out>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -176,6 +244,18 @@
};
 };
 
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
+   lvds0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

[PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support

[Ulrich Hecht]

Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3d2d3bb..58fb9f8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info 
rcar_lvds_r8a77970_info = {
.quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
 };
 
+static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
+   .gen = 3,
+   .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
+};
+
 static const struct of_device_id rcar_lvds_of_table[] = {
{ .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
{ .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info 
},
@@ -519,6 +524,7 @@ static const struct of_device_id rcar_lvds_of_table[] = {
{ .compatible = "renesas,r8a7795-lvds", .data = _lvds_gen3_info },
{ .compatible = "renesas,r8a7796-lvds", .data = _lvds_gen3_info },
{ .compatible = "renesas,r8a77970-lvds", .data = 
_lvds_r8a77970_info },
+   { .compatible = "renesas,r8a77995-lvds", .data = 
_lvds_r8a77995_info },
{ }
 };
 
-- 
2.7.4

[PATCH 3/5] arm64: dts: renesas: r8a77995: Add LVDS support

[Ulrich Hecht]

From: Kieran Bingham 

The r8a77995 D3 platform has 2 LVDS channels connected to the DU.

Signed-off-by: Kieran Bingham 
[uli: moved lvds* into the soc node, added PM domains, resets]
Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index ba98865..8e78110d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -757,12 +757,68 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
};
};
 
port@2 {
reg = <2>;
du_out_lvds1: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds-encoder@feb9 {
+   compatible = "renesas,r8a77995-lvds";
+   reg = <0 0xfeb9 0 0x20>;
+   clocks = < CPG_MOD 727>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 727>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
+
+   lvds1: lvds-encoder@feb90100 {
+   compatible = "renesas,r8a77995-lvds";
+   reg = <0 0xfeb90100 0 0x20>;
+   clocks = < CPG_MOD 727>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 727>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds1_in: endpoint {
+   remote-endpoint = 
<_out_lvds1>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   lvds1_out: endpoint {
};
};
};
-- 
2.7.4

[PATCH 5/5] arm64: dts: renesas: r8a77995-draak: add X12 input dot clock

[Ulrich Hecht]

74.25 Mhz oscillator X12 is connected to DU_DOTCLKIN0.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index b059e32..04d2018 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -117,6 +117,12 @@
regulator-boot-on;
regulator-always-on;
};
+
+   x12_clk: x12 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <7425>;
+   };
 };
 
 _clk {
@@ -235,6 +241,11 @@
pinctrl-names = "default";
status = "okay";
 
+   clocks = < CPG_MOD 724>,
+< CPG_MOD 723>,
+<_clk>;
+   clock-names = "du.0", "du.1", "dclkin.0";
+
ports {
port@0 {
endpoint {
-- 
2.7.4

[PATCH 1/5] drm: rcar-du: Add r8a77995 device support

[Ulrich Hecht]

From: Koji Matsuoka 

Add support for the R-Car D3 (R8A77995) SoC to the R-Car DU driver.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 05745e8..ba82842 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -266,6 +266,31 @@ static const struct rcar_du_device_info 
rcar_du_r8a77970_info = {
.num_lvds = 1,
 };
 
+static const struct rcar_du_device_info rcar_du_r8a77995_info = {
+   .gen = 3,
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
+   .num_crtcs = 2,
+   .routes = {
+   /* R8A77995 has two LVDS output and one RGB output.
+*/
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(0) | BIT(1),
+   .port = 0,
+   },
+   [RCAR_DU_OUTPUT_LVDS0] = {
+   .possible_crtcs = BIT(0),
+   .port = 1,
+   },
+   [RCAR_DU_OUTPUT_LVDS1] = {
+   .possible_crtcs = BIT(1),
+   .port = 2,
+   },
+   },
+   .num_lvds = 2,
+};
+
 static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
{ .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
@@ -278,6 +303,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
{ .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
{ .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
+   { .compatible = "renesas,du-r8a77995", .data = _du_r8a77995_info },
{ }
 };
 
-- 
2.7.4

[PATCH 0/5] R-Car D3 LVDS/HDMI support

[Ulrich Hecht]

Hi!

This adds D3 support to the DU and LVDS drivers, not including LVDS PLL
support.

It also adds LVDS encoders to the D3 device tree, and LVDS decoder, HDMI
encoder and HDMI output connector to the Draak device tree.

In theory that should be good enough to provide HDMI output on the Draak
board, but in practice the lack of LVDS PLL support prevents generation of
close-enough dot clock frequencies.

This series is based on renesas-drivers-2018-05-02-v4.17-rc3 and requires
Jacopo's "drm: bridge: Add thc63lvd1024 LVDS decoder driver" patch.

CU
Uli


Kieran Bingham (1):
  arm64: dts: renesas: r8a77995: Add LVDS support

Koji Matsuoka (1):
  drm: rcar-du: Add r8a77995 device support

Ulrich Hecht (3):
  drm: rcar-du: lvds: Add R8A77995 support
  arm64: dts: renesas: r8a77995-draak: add HDMI output
  arm64: dts: renesas: r8a77995-draak: add X12 input dot clock

 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 91 ++
 arch/arm64/boot/dts/renesas/r8a77995.dtsi  | 56 
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 26 
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  6 ++
 4 files changed, 179 insertions(+)

-- 
2.7.4

[PATCH v2 1/2] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

[Yoshihiro Shimoda]

From: Takeshi Kihara 

This patch adds Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
A2VC1 and 3DG-{A,B} power domain areas for the R8A77990 SoC.

Signed-off-by: Takeshi Kihara 
[shimoda: fix 3DG-{A,B} and add SPDX-License-Identifier]
Signed-off-by: Yoshihiro Shimoda 
---
 .../bindings/power/renesas,rcar-sysc.txt   |  1 +
 drivers/soc/renesas/Kconfig|  5 
 drivers/soc/renesas/Makefile   |  1 +
 drivers/soc/renesas/r8a77990-sysc.c| 33 ++
 drivers/soc/renesas/rcar-sysc.c|  3 ++
 drivers/soc/renesas/rcar-sysc.h|  1 +
 6 files changed, 44 insertions(+)
 create mode 100644 drivers/soc/renesas/r8a77990-sysc.c

diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt 
b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
index 3e91d20..180ae65 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
@@ -21,6 +21,7 @@ Required properties:
   - "renesas,r8a77965-sysc" (R-Car M3-N)
   - "renesas,r8a77970-sysc" (R-Car V3M)
   - "renesas,r8a77980-sysc" (R-Car V3H)
+  - "renesas,r8a77990-sysc" (R-Car E3)
   - "renesas,r8a77995-sysc" (R-Car D3)
   - reg: Address start and address range for the device.
   - #power-domain-cells: Must be 1.
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index c0e0286..1d824cb 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -19,6 +19,7 @@ config SOC_RENESAS
select SYSC_R8A77965 if ARCH_R8A77965
select SYSC_R8A77970 if ARCH_R8A77970
select SYSC_R8A77980 if ARCH_R8A77980
+   select SYSC_R8A77990 if ARCH_R8A77990
select SYSC_R8A77995 if ARCH_R8A77995
 
 if SOC_RENESAS
@@ -76,6 +77,10 @@ config SYSC_R8A77980
bool "R-Car V3H System Controller support" if COMPILE_TEST
select SYSC_RCAR
 
+config SYSC_R8A77990
+   bool "R-Car E3 System Controller support" if COMPILE_TEST
+   select SYSC_RCAR
+
 config SYSC_R8A77995
bool "R-Car D3 System Controller support" if COMPILE_TEST
select SYSC_RCAR
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index a86ece7..7dc0f20 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SYSC_R8A7796)+= r8a7796-sysc.o
 obj-$(CONFIG_SYSC_R8A77965)+= r8a77965-sysc.o
 obj-$(CONFIG_SYSC_R8A77970)+= r8a77970-sysc.o
 obj-$(CONFIG_SYSC_R8A77980)+= r8a77980-sysc.o
+obj-$(CONFIG_SYSC_R8A77990)+= r8a77990-sysc.o
 obj-$(CONFIG_SYSC_R8A77995)+= r8a77995-sysc.o
 
 # Family
diff --git a/drivers/soc/renesas/r8a77990-sysc.c 
b/drivers/soc/renesas/r8a77990-sysc.c
new file mode 100644
index 000..a8c6417
--- /dev/null
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas R-Car E3 System Controller
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "rcar-sysc.h"
+
+static const struct rcar_sysc_area r8a77990_areas[] __initconst = {
+   { "always-on",  0, 0, R8A77990_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
+   { "ca53-scu",   0x140, 0, R8A77990_PD_CA53_SCU,  R8A77990_PD_ALWAYS_ON,
+ PD_SCU },
+   { "ca53-cpu0",  0x200, 0, R8A77990_PD_CA53_CPU0, R8A77990_PD_CA53_SCU,
+ PD_CPU_NOCR },
+   { "ca53-cpu1",  0x200, 1, R8A77990_PD_CA53_CPU1, R8A77990_PD_CA53_SCU,
+ PD_CPU_NOCR },
+   { "cr7",0x240, 0, R8A77990_PD_CR7,  R8A77990_PD_ALWAYS_ON },
+   { "a3vc",   0x380, 0, R8A77990_PD_A3VC, R8A77990_PD_ALWAYS_ON },
+   { "a2vc1",  0x3c0, 1, R8A77990_PD_A2VC1,R8A77990_PD_A3VC },
+   { "3dg-a",  0x100, 0, R8A77990_PD_3DG_A,R8A77990_PD_ALWAYS_ON },
+   { "3dg-b",  0x100, 1, R8A77990_PD_3DG_B,R8A77990_PD_3DG_A },
+};
+
+const struct rcar_sysc_info r8a77990_sysc_info __initconst = {
+   .areas = r8a77990_areas,
+   .num_areas = ARRAY_SIZE(r8a77990_areas),
+};
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 99203bd..95120ac 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -296,6 +296,9 @@ static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd 
*pd)
 #ifdef CONFIG_SYSC_R8A77980
{ .compatible = "renesas,r8a77980-sysc", .data = _sysc_info },
 #endif
+#ifdef CONFIG_SYSC_R8A77990
+   { .compatible = "renesas,r8a77990-sysc", .data = _sysc_info },
+#endif
 #ifdef CONFIG_SYSC_R8A77995
{ .compatible = "renesas,r8a77995-sysc", .data = _sysc_info },
 #endif
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 9b24e3a..a22e7cf 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ 

[PATCH v2 0/2] soc: renesas: r8a77990-sysc: Add support for R-Car E3

[Yoshihiro Shimoda]

This patch is based on the renesas-devel-20180515-v4.17-rc5 tag of
renesas.git.

Changes from v1:
 - Rebase the latest kernel.
 - Modify r8a77990_areas[] as the specification in patch 1.
 - Use // instead of /* */ at the SPDX-License-Identifier line in patch 1.
 - Add workaround patch for 3DG-{A,B} of R-Car E3 ES1.0 as patch 2.

Takeshi Kihara (1):
  soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

Yoshihiro Shimoda (1):
  soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}

 .../bindings/power/renesas,rcar-sysc.txt   |  1 +
 drivers/soc/renesas/Kconfig|  5 ++
 drivers/soc/renesas/Makefile   |  1 +
 drivers/soc/renesas/r8a77990-sysc.c| 68 ++
 drivers/soc/renesas/rcar-sysc.c|  3 +
 drivers/soc/renesas/rcar-sysc.h|  1 +
 6 files changed, 79 insertions(+)
 create mode 100644 drivers/soc/renesas/r8a77990-sysc.c

-- 
1.9.1

[PATCH v2 2/2] soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}

[Yoshihiro Shimoda]

This patch adds workaround for 3DG-{A,B} of R-Car E3 ES1.0 because
the SoC has a restriction about the order.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/soc/renesas/r8a77990-sysc.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/renesas/r8a77990-sysc.c 
b/drivers/soc/renesas/r8a77990-sysc.c
index a8c6417..15579eb 100644
--- a/drivers/soc/renesas/r8a77990-sysc.c
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -7,12 +7,13 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
 #include "rcar-sysc.h"
 
-static const struct rcar_sysc_area r8a77990_areas[] __initconst = {
+static struct rcar_sysc_area r8a77990_areas[] __initdata = {
{ "always-on",  0, 0, R8A77990_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
{ "ca53-scu",   0x140, 0, R8A77990_PD_CA53_SCU,  R8A77990_PD_ALWAYS_ON,
  PD_SCU },
@@ -27,7 +28,41 @@
{ "3dg-b",  0x100, 1, R8A77990_PD_3DG_B,R8A77990_PD_3DG_A },
 };
 
+static void __init rcar_sysc_fix_parent(struct rcar_sysc_area *areas,
+   unsigned int num_areas, u8 id,
+   int new_parent)
+{
+   unsigned int i;
+
+   for (i = 0; i < num_areas; i++)
+   if (areas[i].isr_bit == id) {
+   areas[i].parent = new_parent;
+   return;
+   }
+}
+
+/* Fixups for R-Car E3 ES1.0 revision */
+static const struct soc_device_attribute r8a77990[] __initconst = {
+   { .soc_id = "r8a77990", .revision = "ES1.0" },
+   { /* sentinel */ }
+};
+
+static int __init r8a77990_sysc_init(void)
+{
+   if (soc_device_match(r8a77990)) {
+   rcar_sysc_fix_parent(r8a77990_areas,
+ARRAY_SIZE(r8a77990_areas),
+R8A77990_PD_3DG_A, R8A77990_PD_3DG_B);
+   rcar_sysc_fix_parent(r8a77990_areas,
+ARRAY_SIZE(r8a77990_areas),
+R8A77990_PD_3DG_B, R8A77990_PD_ALWAYS_ON);
+   }
+
+   return 0;
+}
+
 const struct rcar_sysc_info r8a77990_sysc_info __initconst = {
+   .init = r8a77990_sysc_init,
.areas = r8a77990_areas,
.num_areas = ARRAY_SIZE(r8a77990_areas),
 };
-- 
1.9.1

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Peter Rosin]

On 2018-05-15 12:22, Daniel Vetter wrote:
> On Mon, May 14, 2018 at 10:40 PM, Peter Rosin  wrote:
>> On 2018-05-14 18:28, Daniel Vetter wrote:
>>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
 On 2018-05-10 10:10, Andrzej Hajda wrote:
> On 04.05.2018 15:52, Peter Rosin wrote:
>> If the bridge supplier is unbound, this will bring the bridge consumer
>> down along with the bridge. Thus, there will no longer linger any
>> dangling pointers from the bridge consumer (the drm_device) to some
>> non-existent bridge supplier.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/drm_bridge.c | 18 ++
>>  include/drm/drm_bridge.h |  2 ++
>>  2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 78d186b6831b..0259f0a3ff27 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -26,6 +26,7 @@
>>  #include 
>>
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include "drm_crtc_internal.h"
>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
>> struct drm_bridge *bridge,
>>if (bridge->dev)
>>return -EBUSY;
>>
>> +  if (encoder->dev->dev != bridge->odev) {
>
> I wonder why device_link_add does not handle this case (self dependency)
> silently as noop, as it seems to be a correct behavior.

 It's kind-of a silly corner-case though, so perfectly understandable
 that it isn't handled.

>> +  bridge->link = device_link_add(encoder->dev->dev,
>> + bridge->odev, 0);
>> +  if (!bridge->link) {
>> +  dev_err(bridge->odev, "failed to link bridge to %s\n",
>> +  dev_name(encoder->dev->dev));
>> +  return -EINVAL;
>> +  }
>> +  }
>> +
>>bridge->dev = encoder->dev;
>>bridge->encoder = encoder;
>>
>>if (bridge->funcs->attach) {
>>ret = bridge->funcs->attach(bridge);
>>if (ret < 0) {
>> +  if (bridge->link)
>> +  device_link_del(bridge->link);
>> +  bridge->link = NULL;
>>bridge->dev = NULL;
>>bridge->encoder = NULL;
>>return ret;
>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>if (bridge->funcs->detach)
>>bridge->funcs->detach(bridge);
>>
>> +  if (bridge->link)
>> +  device_link_del(bridge->link);
>> +  bridge->link = NULL;
>> +
>>bridge->dev = NULL;
>>  }
>>
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index b656e505d11e..804189c63a4c 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>   * @list: to keep track of all added bridges
>>   * @timings: the timing specification for the bridge, if any (may
>>   * be NULL)
>> + * @link: drm consumer <-> bridge supplier
>
> Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
> to the bridge" would be better.

 I meant "<->" to indicate that the link is bidirectional, not that the
 relationship is in any way symmetric. I wasn't aware of any implication
 of a symmetric relationship when using "<->", do you have a reference?
 But I guess the different arrow notations in math are somewhat overloaded
 and that someone at some point must have used "<->" to indicate a
 symmetric relationship...
>>>
>>> Yeah I agree with Andrzej here, for me <-> implies a symmetric
>>> relationship. Spelling it out like Andrzej suggested sounds like the
>>> better idea.
>>> -Daniel
>>
>> Ok, I guess that means I have to do a v3 after all. Or can this
>> trivial documentation update be done by the committer? I hate to
>> spam everyone with another volley...
>>
>> Or perhaps I should squash patches 2-23 that are all rather similar
>> and mechanic? I separated them to allow for easier review from
>> individual driver maintainers, but that didn't seem to happen
>> anyway...
> 
> Do another volley of the full set, or in-reply-to to just replace the
> patch that needs to be respun (but some people don't like that).
> 
> When resending just make sure you're picking up all the acks/r-bs you
> have already.

Right, I always try to do that. One Ack that I did not include in v2
was the one you had on v1 24/24 (i.e. this patch). The reason I did
not add your Ack for v2 even on the patch where it obviously applied
was that I didn't know if you'd barf on the odev name.

But it was (and still is) a bit unclear if that was on 

RE: [PATCH/RFC v3 1/4] base: devcon: add a new API to find the graph

[Yoshihiro Shimoda]

Hi Heikki,

Thank you for the reply!

> From: Heikki Krogerus, Sent: Tuesday, May 15, 2018 5:29 PM
> 
> On Tue, May 15, 2018 at 02:19:14AM +, Yoshihiro Shimoda wrote:
> > Hi Heikki,
> >
> > > From: Heikki Krogerus, Sent: Monday, May 14, 2018 10:28 PM
> > >
> > > On Mon, May 14, 2018 at 06:15:57PM +0900, Yoshihiro Shimoda wrote:

> > > > +struct device *device_connection_find_by_graph(struct device *dev, u32 
> > > > port,
> > > > +  u32 endpoint)
> > > > +{
> > > > +   struct bus_type *bus;
> > > > +   struct fwnode_handle *remote;
> > > > +   struct device *conn;
> > > > +
> > > > +   remote = fwnode_graph_get_remote_node(dev_fwnode(dev), port, 
> > > > endpoint);
> > > > +   if (!remote)
> > > > +   return NULL;
> > > > +
> > > > +   for (bus = generic_match_buses[0]; bus; bus++) {
> > > > +   conn = bus_find_device(bus, NULL, remote, 
> > > > generic_graph_match);
> > > > +   if (conn)
> > > > +   return conn;
> > > > +   }
> > > > +
> > > > +   /*
> > > > +* We only get called if a connection was found, tell the 
> > > > caller to
> > > > +* wait for the other device to show up.
> > > > +*/
> > > > +   return ERR_PTR(-EPROBE_DEFER);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(device_connection_find_by_graph);
> > >
> > > Why do we need more API for walking through the graph?
> >
> > I thought there is difficult to find if a device has multiple ports or 
> > endpoints.
> > So, I'd like to use port and endpoint number for finding a device.
> >
> > > I'm not sure exactly sure what is going on here, I'll try to study
> > > your patches more when I have time, but the approach looks wrong. That
> > > function looks like a helper, but just not that useful one.
> > >
> > > We really should be able to use the existing functions. In practice
> > > device_connection_find_match() should eventually parse the graph, then
> > > fallback to build-in connections if no graph is found. Otherwise
> > > parsing graph here is not really useful at all.
> >
> > I think using device_connection_find_match() for finding the graph becomes 
> > complicated.
> > The current arguments of the function is the below:
> >
> > void *device_connection_find_match(struct device *dev, const char *con_id,
> >void *data,
> >void *(*match)(struct device_connection *con,
> >   int ep, void *data))
> >
> > If finding the graph, the following arguments will be not used.
> >  - con_id
> >  - *con and ep of "match" arguments.
> >
> > This is because these arguments are for the build-in connections.
> 
> No they're not. You do realize that we can build a temporary struct
> device_connection there and then (in stack) to be supplied for the
> ->match callback.

I understood it.

> > So, should I modify the arguments of the function for finding both
> > the graph and built-in connections somehow?
> 
> I don't see any need for that. We may need to modify struct
> device_connection, but there should not be any need to touch the API.
> 
> Your plan to use port and endpoint number is wrong, as they are just
> indexes, and therefore not reliable. Luckily it should be completely
> unnecessary to use them.
> 
> The way I see this working is that we parse all the endpoints the
> caller device has. If we can't take advantage of the con_id for
> identification (though ideally we can), we just need to call ->match
> with every one of them. The implementation for the ->match callback is
> then responsible of figuring out if the endpoint is the one we are
> looking for or not in that case.

I understood it. But, I need to investigate how to find a device.

> The only problem I see with that is that we may not have a reliable
> way to convert the fwnode pointing to the remote-endpoint parent into
> struct device (if one has already been enumerated) in order to get the
> device name and use it as the second endpoint name in struct
> device_connection. To solve that, we could consider for example just
> adding a new member, fwnode pointer perhaps, to the structure. Or
> perhaps use the endpoint members for something else than device names
> when graph is used, and add a member defining the type of match:
> graph, build-in, etc. There are many things we can consider.

I don't understand why adding such new member(s) can solve that.
Anyway, I will investigate this more...

> I don't know if I'm able to explain what I'm after with this, so if
> you like, I can propose something for this myself. Though that will
> have to wait for few weeks. Right now I'm too busy with other stuff.

Thank you for your proposal! However, I'd like to try to investigate
once more while you are too busy.

Best regards,
Yoshihiro Shimoda

> 
> Thanks,
> 
> --
> heikki

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Daniel Vetter]

On Mon, May 14, 2018 at 10:40 PM, Peter Rosin  wrote:
> On 2018-05-14 18:28, Daniel Vetter wrote:
>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
>>> On 2018-05-10 10:10, Andrzej Hajda wrote:
 On 04.05.2018 15:52, Peter Rosin wrote:
> If the bridge supplier is unbound, this will bring the bridge consumer
> down along with the bridge. Thus, there will no longer linger any
> dangling pointers from the bridge consumer (the drm_device) to some
> non-existent bridge supplier.
>
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/drm_bridge.c | 18 ++
>  include/drm/drm_bridge.h |  2 ++
>  2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 78d186b6831b..0259f0a3ff27 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -26,6 +26,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>  #include "drm_crtc_internal.h"
> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
> struct drm_bridge *bridge,
>if (bridge->dev)
>return -EBUSY;
>
> +  if (encoder->dev->dev != bridge->odev) {

 I wonder why device_link_add does not handle this case (self dependency)
 silently as noop, as it seems to be a correct behavior.
>>>
>>> It's kind-of a silly corner-case though, so perfectly understandable
>>> that it isn't handled.
>>>
> +  bridge->link = device_link_add(encoder->dev->dev,
> + bridge->odev, 0);
> +  if (!bridge->link) {
> +  dev_err(bridge->odev, "failed to link bridge to %s\n",
> +  dev_name(encoder->dev->dev));
> +  return -EINVAL;
> +  }
> +  }
> +
>bridge->dev = encoder->dev;
>bridge->encoder = encoder;
>
>if (bridge->funcs->attach) {
>ret = bridge->funcs->attach(bridge);
>if (ret < 0) {
> +  if (bridge->link)
> +  device_link_del(bridge->link);
> +  bridge->link = NULL;
>bridge->dev = NULL;
>bridge->encoder = NULL;
>return ret;
> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>if (bridge->funcs->detach)
>bridge->funcs->detach(bridge);
>
> +  if (bridge->link)
> +  device_link_del(bridge->link);
> +  bridge->link = NULL;
> +
>bridge->dev = NULL;
>  }
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index b656e505d11e..804189c63a4c 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>   * @list: to keep track of all added bridges
>   * @timings: the timing specification for the bridge, if any (may
>   * be NULL)
> + * @link: drm consumer <-> bridge supplier

 Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
 to the bridge" would be better.
>>>
>>> I meant "<->" to indicate that the link is bidirectional, not that the
>>> relationship is in any way symmetric. I wasn't aware of any implication
>>> of a symmetric relationship when using "<->", do you have a reference?
>>> But I guess the different arrow notations in math are somewhat overloaded
>>> and that someone at some point must have used "<->" to indicate a
>>> symmetric relationship...
>>
>> Yeah I agree with Andrzej here, for me <-> implies a symmetric
>> relationship. Spelling it out like Andrzej suggested sounds like the
>> better idea.
>> -Daniel
>
> Ok, I guess that means I have to do a v3 after all. Or can this
> trivial documentation update be done by the committer? I hate to
> spam everyone with another volley...
>
> Or perhaps I should squash patches 2-23 that are all rather similar
> and mechanic? I separated them to allow for easier review from
> individual driver maintainers, but that didn't seem to happen
> anyway...

Do another volley of the full set, or in-reply-to to just replace the
patch that needs to be respun (but some people don't like that).

When resending just make sure you're picking up all the acks/r-bs you
have already.
-Daniel
> Cheers,
> Peter
>
>>
>>>
 Anyway:
 Reviewed-by: Andrzej Hajda 
>>>
>>> Thanks!
>>>
>>> Cheers,
>>> Peter
>>>
  --
 Regards
 Andrzej

>   * @funcs: control functions
>   * @driver_private: pointer to the bridge driver's internal context
>   */
> @@ -271,6 +272,7 @@ struct drm_bridge {
>struct drm_bridge *next;
>struct list_head list;
>const struct drm_bridge_timings *timings;
> 

Re: [PATCH 26/61] media: platform: exynos4-is: simplify getting .drvdata

[Sylwester Nawrocki]

On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 

Acked-by: Sylwester Nawrocki 

Re: [PATCH 27/61] media: platform: s5p-mfc: simplify getting .drvdata

[Sylwester Nawrocki]

On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 

Acked-by: Sylwester Nawrocki 

Re: [PATCH] pinctrl: sh-pfc: r8a77965: Add I2C pin support

[Geert Uytterhoeven]

On Sun, May 13, 2018 at 1:35 PM, Niklas Söderlund
 wrote:
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.18...

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH v2 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

[Fabrizio Castro]

Thank you Simon.

Fab

> -Original Message-
> From: Simon Horman [mailto:ho...@verge.net.au]
> Sent: 13 May 2018 08:47
> To: Fabrizio Castro 
> Cc: Thomas Gleixner ; Daniel Lezcano 
> ; Geert Uytterhoeven
> ; devicet...@vger.kernel.org; Chris Paterson 
> ; Biju Das
> ; linux-renesas-soc@vger.kernel.org; Rob Herring 
> ; Mark Rutland
> 
> Subject: Re: [PATCH v2 1/3] dt-bindings: timer: renesas, cmt: Document 
> r8a774[35] CMT support
>
> On Tue, Apr 10, 2018 at 09:36:39AM +, Fabrizio Castro wrote:
> > Good morning gentlemen,
> >
> > I am very sorry to bother you again, but it seems this patch has no
> > master. Is anybody willing to take it?
>
> Patchwork tells me this has been Acked by Daniel Lezcano.
> So I have decided to take this one in from the cold and apply it to the
> renesas tree.



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

Re: [PATCH 05/61] clk: samsung: simplify getting .drvdata

[Sylwester Nawrocki]

On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 

Acked-by: Sylwester Nawrocki 

It seems to be the only clk/samsung patch in the v4.18 queue, please
feel free to apply it directly.

> ---
> 
> Build tested only. buildbot is happy. Please apply individually.
> 
>  drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-s3c2410-dclk.c 
> b/drivers/clk/samsung/clk-s3c2410-dclk.c
> index 077df3e539a7..f41d89cef0f1 100644
> --- a/drivers/clk/samsung/clk-s3c2410-dclk.c
> +++ b/drivers/clk/samsung/clk-s3c2410-dclk.c
> @@ -219,8 +219,7 @@ static int s3c24xx_dclk1_div_notify(struct notifier_block 
> *nb,
>  #ifdef CONFIG_PM_SLEEP
>  static int s3c24xx_dclk_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct s3c24xx_dclk *s3c24xx_dclk = platform_get_drvdata(pdev);
> + struct s3c24xx_dclk *s3c24xx_dclk = dev_get_drvdata(dev);
>  
>   s3c24xx_dclk->reg_save = readl_relaxed(s3c24xx_dclk->base);
>   return 0;
> @@ -228,8 +227,7 @@ static int s3c24xx_dclk_suspend(struct device *dev)
>  
>  static int s3c24xx_dclk_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct s3c24xx_dclk *s3c24xx_dclk = platform_get_drvdata(pdev);
> + struct s3c24xx_dclk *s3c24xx_dclk = dev_get_drvdata(dev);
>  
>   writel_relaxed(s3c24xx_dclk->reg_save, s3c24xx_dclk->base);
>   return 0;

-- 
Regards,
Sylwester

Re: [PATCH v2 1/2] Revert "media: rcar-vin: enable field toggle after a set number of lines for Gen3"

[Kieran Bingham]

Hi Niklas,

On 11/05/18 15:41, Niklas Söderlund wrote:
> The offending commit was an attempt to fix the issue of writing outside
> the capture buffer for VIN Gen3. Unfortunately it only fixed the symptom
> of the problem to such a degree I could no longer reproduce it. Revert
> the offending commit before a proper fix can be added in a follow-up
> patch.
> 
> This reverts commit 015060cb7795eac34454696cc9c9f8b76926a401.
> 
> Signed-off-by: Niklas Söderlund 

Acked-by: Kieran Bingham 

> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 20 +---
>  1 file changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index b41ba9a4a2b3ac90..ac07f99e3516a620 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -124,9 +124,7 @@
>  #define VNDMR2_VPS   (1 << 30)
>  #define VNDMR2_HPS   (1 << 29)
>  #define VNDMR2_FTEV  (1 << 17)
> -#define VNDMR2_FTEH  (1 << 16)
>  #define VNDMR2_VLV(n)((n & 0xf) << 12)
> -#define VNDMR2_HLV(n)((n) & 0xfff)
>  
>  /* Video n CSI2 Interface Mode Register (Gen3) */
>  #define VNCSI_IFMD_DES1  (1 << 26)
> @@ -614,9 +612,8 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
>  
>  static int rvin_setup(struct rvin_dev *vin)
>  {
> - u32 vnmc, dmr, dmr2, interrupts, lines;
> + u32 vnmc, dmr, dmr2, interrupts;
>   bool progressive = false, output_is_yuv = false, input_is_yuv = false;
> - bool halfsize = false;
>  
>   switch (vin->format.field) {
>   case V4L2_FIELD_TOP:
> @@ -631,15 +628,12 @@ static int rvin_setup(struct rvin_dev *vin)
>   /* Use BT if video standard can be read and is 60 Hz format */
>   if (!vin->info->use_mc && vin->std & V4L2_STD_525_60)
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
> - halfsize = true;
>   break;
>   case V4L2_FIELD_INTERLACED_TB:
>   vnmc = VNMC_IM_FULL;
> - halfsize = true;
>   break;
>   case V4L2_FIELD_INTERLACED_BT:
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
> - halfsize = true;
>   break;
>   case V4L2_FIELD_NONE:
>   vnmc = VNMC_IM_ODD_EVEN;
> @@ -682,15 +676,11 @@ static int rvin_setup(struct rvin_dev *vin)
>   break;
>   }
>  
> - if (vin->info->model == RCAR_GEN3) {
> - /* Enable HSYNC Field Toggle mode after height HSYNC inputs. */
> - lines = vin->format.height / (halfsize ? 2 : 1);
> - dmr2 = VNDMR2_FTEH | VNDMR2_HLV(lines);
> - vin_dbg(vin, "Field Toogle after %u lines\n", lines);
> - } else {
> - /* Enable VSYNC Field Toogle mode after one VSYNC input. */
> + /* Enable VSYNC Field Toogle mode after one VSYNC input */
> + if (vin->info->model == RCAR_GEN3)
> + dmr2 = VNDMR2_FTEV;
> + else
>   dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
> - }
>  
>   /* Hsync Signal Polarity Select */
>   if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
> 

Re: [PATCH v2 2/2] rcar-vin: fix crop and compose handling for Gen3

[Kieran Bingham]

Hi Niklas,

This looks like quite the improvement :D

On 11/05/18 15:41, Niklas Söderlund wrote:
> When refactoring the Gen3 enablement series crop and compose handling
> where broken. This went unnoticed but can result in writing out side the

As well as Sergei's 'where/were', 'out side' is one word in this context.

'outside of the capture buffer'

> capture buffer. Fix this by restoring the crop and compose to reflect
> the format dimensions as we have not yet enabled the scaler for Gen3.
> 
> Fixes: 5e7c623632fcf8f5 ("media: rcar-vin: use different v4l2 operations in 
> media controller mode")
> Reported-by: Jacopo Mondi 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 2fb8587116f25a4f..e78fba84d59028ef 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -702,6 +702,12 @@ static int rvin_mc_s_fmt_vid_cap(struct file *file, void 
> *priv,
>  
>   vin->format = f->fmt.pix;
>  
> + vin->crop.top = 0;
> + vin->crop.left = 0;
> + vin->crop.width = vin->format.width;
> + vin->crop.height = vin->format.height;
> + vin->compose = vin->crop;
> +
>   return 0;
>  }
>  
> 

Re: [PATCH v16 0/2] rcar-csi2: add Renesas R-Car MIPI CSI-2

[Sakari Ailus]

On Tue, May 15, 2018 at 07:50:45AM +0300, Laurent Pinchart wrote:
> Hi Niklas,
> 
> On Tuesday, 15 May 2018 03:56:33 EEST Niklas Söderlund wrote:
> > Hi,
> > 
> > This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's
> > based on top of the media-tree and are tested on Renesas Salvator-X and
> > Salvator-XS together with adv7482 and the now in tree rcar-vin driver :-)
> > 
> > I hope this is the last incarnation of this patch-set, I do think it is
> > ready for upstream consumption :-)
> 
> So do I. Even though you dropped Hans' reviewed-by tag due to changes in the 
> hardware initialization code, I think the part that Hans cares about the most 
> is the V4L2 API implementation, so I believe his review still applies. In my 
> opinion the series has received the necessary review.
> 
> Hans, would you like to take this through your tree, or should we send a pull 
> request directly to Mauro ? I'd like the two patches to be merged in v4.18 if 
> possible.

I've applied the patches to my tree as discussed with Hans previously.

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 6/6] pinctrl: sh-pfc: r8a77990: Add EthernetAVB pins, groups and functions

[Geert Uytterhoeven]

On Fri, May 11, 2018 at 5:22 AM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds group and function of AVB PHY, LINK, MAGIC, MII and PTP
> pins for the R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.18...

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/6] pinctrl: sh-pfc: r8a77990: Add I2C{1,2,4,5,6,7} pins, groups and functions

[Geert Uytterhoeven]

On Fri, May 11, 2018 at 5:22 AM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds I2C{1,2,4,5,6,7} pins, groups and functions to
> the R8A77990 SoC.
>
> NOTE: I2C0 and I2C3 are not pin multiplexed.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.18...

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/6] pinctrl: sh-pfc: r8a77990: Add SCIF pins, groups and functions

[Geert Uytterhoeven]

On Fri, May 11, 2018 at 5:22 AM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds SCIF{0,1,2,3,4,5} pins, groups and functions to R8A77990
> SoC.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.18...

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] dt-bindings: net: ravb: Add support for r8a77990 SoC

[Sergei Shtylyov]

On 5/13/2018 10:58 AM, Simon Horman wrote:


Add documentation for r8a77990 compatible string to renesas ravb device
tree bindings documentation.

Signed-off-by: Yoshihiro Shimoda 


I'm assuming this isn't targetted at one of my trees.  Just FYI.


Hi Dave,

I think this is appropriate for net-next but if not I can take it.


   There's also Rob, and IIRC he has taken alike patch recently...

[...]

MBR, Sergei

Re: [PATCH 3/6] pinctrl: sh-pfc: r8a77990: Add bias pinconf support

[Geert Uytterhoeven]

On Mon, May 14, 2018 at 10:13 PM, Geert Uytterhoeven
 wrote:
> On Fri, May 11, 2018 at 5:22 AM, Yoshihiro Shimoda
>  wrote:
>> From: Takeshi Kihara 
>>
>> This patch implements control of pull-up and pull-down. On this SoC there
>> is no simple mapping of GP pins to bias register bits, so we need a table.
>>
>> Signed-off-by: Takeshi Kihara 
>> Signed-off-by: Yoshihiro Shimoda 
>
> Thanks for your patch!
>
>> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
>> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
>
>> @@ -1227,10 +1248,55 @@ enum {
>>
>> PINMUX_IPSR_GPSR(IP15_31_28,USB30_OVC),
>> PINMUX_IPSR_MSEL(IP15_31_28,USB0_OVC_A, 
>> SEL_USB_20_CH0_0),
>> +
>> +/*
>> + * Static pins can not be muxed between different functions but
>> + * still needs a mark entry in the pinmux list. Add each static
>
> need mark entries
>
>> + * pin to the list without an associated function. The sh-pfc
>> + * core will do the right thing and skip trying to mux then pin
>
> mux the pin
>
>> + * while still applying configuration to it
>
> period
>
> I have just sent a patch to fix the other copies, in the hope these grammar
> atrocities will stop spreading ;-)
>
>> @@ -1708,8 +1774,263 @@ enum {
>> { },
>>  };
>>
>> +static const struct pinmux_bias_reg pinmux_bias_regs[] = {
>
> The register definitions look OK to me.
> I'll review the actual pin mappings later.

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.18 with the comments fixed.

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/3] dt-bindings: media: rcar-vin: Add R8A77995 support

[jacopo mondi]

Hi Simon,

On Fri, May 11, 2018 at 03:35:14PM +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 12:00:00PM +0200, Jacopo Mondi wrote:
> > Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by
> > rcar-vin driver.
> >
> > Signed-off-by: Jacopo Mondi 
>
> Reviewed-by: Simon Horman 
>

Does this goes in through your tree? I will send a v2, should I
include this one or you have collected it already?

Thanks
   j


signature.asc
Description: PGP signature

RE: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

[Yoshihiro Shimoda]

Hi Simon-san,

> From: Simon Horman, Sent: Tuesday, May 15, 2018 5:04 PM
> 
> On Tue, May 15, 2018 at 08:02:00AM +, Yoshihiro Shimoda wrote:
> > Hi Simon-san,
> >
> > Thank you for your review!
> >
> > > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> > > On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> > 
> > > >  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> > > >  {
> > > > -   _usb3_set_mode(usb3, host);
> > > > +   if (usb3->role_sw)
> > > > +   usb_role_switch_set_role(usb3->role_sw, host ?
> > > > +USB_ROLE_HOST : 
> > > > USB_ROLE_DEVICE);
> > > > +   else
> > > > +   _usb3_set_mode(usb3, host);
> > > >  }
> > > >
> > > >  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > > > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 
> > > > *usb3, bool host, bool a_dev)
> > > >  {
> > > > unsigned long flags;
> > > >
> > > > -   spin_lock_irqsave(>lock, flags);
> > > > usb3_set_mode(usb3, host);
> > > > +   spin_lock_irqsave(>lock, flags);
> > >
> > > Hi Shimoda-san,
> > >
> > > could you clarify why moving this lock is safe?
> >
> > The usb3_set_mode() is possible to call usb_role_switch_set_role() API
> > and usb_role_switch_set_role() calls mutex_lock().
> > So, this moving this lock (especially avoiding irqsave) needs.
> 
> Thanks, that make sense.
> 
> But usb3_set_mode() may also call _usb3_set_mode().
> It is safe to call _usb3_set_mode() without holding the lock?

Thank you for the pointed out. I am thinking it is possible to be
unsafe without holding the lock. So, I'd like to improve this patch somehow
(for example: Add new usb role switch APIs without mutex).

Best regards,
Yoshihiro Shimoda

Re: [PATCH/RFC v3 1/4] base: devcon: add a new API to find the graph

[Heikki Krogerus]

On Tue, May 15, 2018 at 02:19:14AM +, Yoshihiro Shimoda wrote:
> Hi Heikki,
> 
> > From: Heikki Krogerus, Sent: Monday, May 14, 2018 10:28 PM
> > 
> > On Mon, May 14, 2018 at 06:15:57PM +0900, Yoshihiro Shimoda wrote:
> 
> > > diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
> > > index d427e80..5a0da33 100644
> > > --- a/drivers/base/devcon.c
> > > +++ b/drivers/base/devcon.c
> 
> > > +static int generic_graph_match(struct device *dev, void *fwnode)
> > > +{
> > > + return dev->fwnode == fwnode;
> > > +}
> > > +
> > > +/**
> > > + * device_connection_find_by_graph - Find two devices connected together
> > > + * @dev: Device to find connected device
> > > + * @port: identifier of the @dev port node
> > > + * @endpoint: identifier of the @dev endpoint node
> > > + *
> > > + * Find a connection with @port and @endpoint by using graph between 
> > > @dev and
> > > + * another device. On success returns handle to the device that is 
> > > connected
> > > + * to @dev, with the reference count for the found device incremented. 
> > > Returns
> > > + * NULL if no matching connection was found, or ERR_PTR(-EPROBE_DEFER) 
> > > when
> > > + * a connection was found but the other device has not been enumerated 
> > > yet.
> > > + */
> > > +struct device *device_connection_find_by_graph(struct device *dev, u32 
> > > port,
> > > +u32 endpoint)
> > > +{
> > > + struct bus_type *bus;
> > > + struct fwnode_handle *remote;
> > > + struct device *conn;
> > > +
> > > + remote = fwnode_graph_get_remote_node(dev_fwnode(dev), port, endpoint);
> > > + if (!remote)
> > > + return NULL;
> > > +
> > > + for (bus = generic_match_buses[0]; bus; bus++) {
> > > + conn = bus_find_device(bus, NULL, remote, generic_graph_match);
> > > + if (conn)
> > > + return conn;
> > > + }
> > > +
> > > + /*
> > > +  * We only get called if a connection was found, tell the caller to
> > > +  * wait for the other device to show up.
> > > +  */
> > > + return ERR_PTR(-EPROBE_DEFER);
> > > +}
> > > +EXPORT_SYMBOL_GPL(device_connection_find_by_graph);
> > 
> > Why do we need more API for walking through the graph?
> 
> I thought there is difficult to find if a device has multiple ports or 
> endpoints.
> So, I'd like to use port and endpoint number for finding a device.
> 
> > I'm not sure exactly sure what is going on here, I'll try to study
> > your patches more when I have time, but the approach looks wrong. That
> > function looks like a helper, but just not that useful one.
> > 
> > We really should be able to use the existing functions. In practice
> > device_connection_find_match() should eventually parse the graph, then
> > fallback to build-in connections if no graph is found. Otherwise
> > parsing graph here is not really useful at all.
> 
> I think using device_connection_find_match() for finding the graph becomes 
> complicated.
> The current arguments of the function is the below:
> 
> void *device_connection_find_match(struct device *dev, const char *con_id,
>  void *data,
>  void *(*match)(struct device_connection *con,
> int ep, void *data))
> 
> If finding the graph, the following arguments will be not used.
>  - con_id
>  - *con and ep of "match" arguments.
> 
> This is because these arguments are for the build-in connections.

No they're not. You do realize that we can build a temporary struct
device_connection there and then (in stack) to be supplied for the
->match callback.

> So, should I modify the arguments of the function for finding both
> the graph and built-in connections somehow?

I don't see any need for that. We may need to modify struct
device_connection, but there should not be any need to touch the API.

Your plan to use port and endpoint number is wrong, as they are just
indexes, and therefore not reliable. Luckily it should be completely
unnecessary to use them.

The way I see this working is that we parse all the endpoints the
caller device has. If we can't take advantage of the con_id for
identification (though ideally we can), we just need to call ->match
with every one of them. The implementation for the ->match callback is
then responsible of figuring out if the endpoint is the one we are
looking for or not in that case.

The only problem I see with that is that we may not have a reliable
way to convert the fwnode pointing to the remote-endpoint parent into
struct device (if one has already been enumerated) in order to get the
device name and use it as the second endpoint name in struct
device_connection. To solve that, we could consider for example just
adding a new member, fwnode pointer perhaps, to the structure. Or
perhaps use the endpoint members for something else than device names
when graph is used, and add a member defining the type of match:
graph, build-in, etc. There are many things we can consider.

I don't 

Re: [PATCH v2] ARM: dts: r8a7740: Add CEU1

[jacopo mondi]

Hi Simon,

On Tue, May 15, 2018 at 10:00:38AM +0200, Simon Horman wrote:
> Describe CEU1 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Jacopo Mondi 

Thank you!
   j

> ---
> v2
> * Correct register range start address
>
>   Based on renesas-devel-20180514-v4.17-rc5
> ---
>  arch/arm/boot/dts/r8a7740.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index 508d93440ee8..35e2fc957458 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -77,6 +77,16 @@
>   status = "disabled";
>   };
>
> + ceu1: ceu@fe914000 {
> + reg = <0xfe914000 0x3000>;
> + compatible = "renesas,r8a7740-ceu";
> + interrupts = ;
> + clocks = <_clks R8A7740_CLK_CEU21>;
> + clock-names = "ceu21";
> + power-domains = <_a4r>;
> + status = "disabled";
> + };
> +
>   cmt1: timer@e6138000 {
>   compatible = "renesas,cmt-48-r8a7740", "renesas,cmt-48";
>   reg = <0xe6138000 0x170>;
> --
> 2.11.0
>


signature.asc
Description: PGP signature

Re: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

[Simon Horman]

On Tue, May 15, 2018 at 08:02:00AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> Thank you for your review!
> 
> > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> > On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> 
> > >  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> > >  {
> > > - _usb3_set_mode(usb3, host);
> > > + if (usb3->role_sw)
> > > + usb_role_switch_set_role(usb3->role_sw, host ?
> > > +  USB_ROLE_HOST : USB_ROLE_DEVICE);
> > > + else
> > > + _usb3_set_mode(usb3, host);
> > >  }
> > >
> > >  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 
> > > *usb3, bool host, bool a_dev)
> > >  {
> > >   unsigned long flags;
> > >
> > > - spin_lock_irqsave(>lock, flags);
> > >   usb3_set_mode(usb3, host);
> > > + spin_lock_irqsave(>lock, flags);
> > 
> > Hi Shimoda-san,
> > 
> > could you clarify why moving this lock is safe?
> 
> The usb3_set_mode() is possible to call usb_role_switch_set_role() API
> and usb_role_switch_set_role() calls mutex_lock().
> So, this moving this lock (especially avoiding irqsave) needs.

Thanks, that make sense.

But usb3_set_mode() may also call _usb3_set_mode().
It is safe to call _usb3_set_mode() without holding the lock?

> Best regards,
> Yoshihiro Shimoda
> 
> > >   usb3_vbus_out(usb3, a_dev);
> > >   /* for A-Peripheral or forced B-device mode */
> > >   if ((!host && a_dev) ||
> > > --
> > > 1.9.1
> > >
> 

RE: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

[Yoshihiro Shimoda]

Hi Simon-san,

Thank you for your review!

> From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:

> >  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> >  {
> > -   _usb3_set_mode(usb3, host);
> > +   if (usb3->role_sw)
> > +   usb_role_switch_set_role(usb3->role_sw, host ?
> > +USB_ROLE_HOST : USB_ROLE_DEVICE);
> > +   else
> > +   _usb3_set_mode(usb3, host);
> >  }
> >
> >  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
> > bool host, bool a_dev)
> >  {
> > unsigned long flags;
> >
> > -   spin_lock_irqsave(>lock, flags);
> > usb3_set_mode(usb3, host);
> > +   spin_lock_irqsave(>lock, flags);
> 
> Hi Shimoda-san,
> 
> could you clarify why moving this lock is safe?

The usb3_set_mode() is possible to call usb_role_switch_set_role() API
and usb_role_switch_set_role() calls mutex_lock().
So, this moving this lock (especially avoiding irqsave) needs.

Best regards,
Yoshihiro Shimoda

> > usb3_vbus_out(usb3, a_dev);
> > /* for A-Peripheral or forced B-device mode */
> > if ((!host && a_dev) ||
> > --
> > 1.9.1
> >

Re: [PATCH 0/2] Revert explicit support for Renesas R-Car Gen 3 r8a779[56] SoCs

[Rafael J. Wysocki]

On Tue, May 15, 2018 at 9:35 AM, Simon Horman  wrote:
> On Thu, May 10, 2018 at 11:51:38AM +0200, Rafael J. Wysocki wrote:
>> On Wednesday, May 2, 2018 11:58:04 AM CEST Simon Horman wrote:
>> > Revert commits that added explicit support for Renesas R-Car Gen 3
>> > r8a779[56] SoCs to the generic cpufreq driver.
>> >
>> > This is no longer needed since the flowing commit and to the best of my
>> > knowledge is not relied on by any upstream DTS: edeec420de24 ("cpufreq:
>> > dt-platdev: Automatically create cpufreq device with OPP v2")
>> >
>> > Simon Horman (2):
>> >   Revert "cpufreq: dt: Add r8a7796 support to to use generic cpufreq
>> > driver"
>> >   Revert "cpufreq: rcar: Add support for R8A7795 SoC"
>> >
>> >  drivers/cpufreq/cpufreq-dt-platdev.c | 2 --
>> >  1 file changed, 2 deletions(-)
>> >
>> >
>>
>> Am I expected to pick up this series?
>
> Hi Rafael,
>
> that would be ideal from my point of view.

OK, I'll queue them up, then.

Thanks!

Re: [PATCH v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

[Simon Horman]

On Tue, May 15, 2018 at 07:49:44AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> Thank you for your review!
> 
> > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:35 PM
> > 
> > On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> > > This patch fixes an issue that reconnection is possible to fail
> > > because unexpected state handling happens by the irqs. To fix the issue,
> > > the driver disables the controller's irqs when disconnected.
> > >
> > > Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> > > USB3.0 peripheral controller")
> > > Cc:  # v4.5+
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >
> > > Remarks:
> > >  - A new file in v2
> > >
> > >  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > > b/drivers/usb/gadget/udc/renesas_usb3.c
> > > index 0e70163..5caf78b 100644
> > > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > > @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 
> > > *usb3)
> > >   usb3_usb2_pullup(usb3, 0);
> > >   usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
> > >   usb3_reset_epc(usb3);
> > > + usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> > > +USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> > > +USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> > > +USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> > > +USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);
> > 
> > Hi Shimoda-san,
> > 
> > is it intentional that USB_INT_1_VBUS_CNG is not disabled above?
> 
> Yes, because the USB_INT_1_VBUS_CNG is enabled in usb3_init_epc_registers() 
> below.

Thanks for the clarification,

Reviewed-by: Simon Horman 

> 
> > > + usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> > > + usb3_init_epc_registers(usb3);
> 
> Best regards,
> Yoshihiro Shimoda
> 
> > >   if (usb3->driver)
> > >   usb3->driver->disconnect(>gadget);
> > > --
> > > 1.9.1
> > >
> 

Re: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

[Simon Horman]

On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> This patch uses usb role switch API if the register suceeeded.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/usb/gadget/udc/renesas_usb3.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index c878449..bfb5803 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -657,7 +657,11 @@ static void _usb3_set_mode(struct renesas_usb3 *usb3, 
> bool host)
>  
>  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
>  {
> - _usb3_set_mode(usb3, host);
> + if (usb3->role_sw)
> + usb_role_switch_set_role(usb3->role_sw, host ?
> +  USB_ROLE_HOST : USB_ROLE_DEVICE);
> + else
> + _usb3_set_mode(usb3, host);
>  }
>  
>  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
> bool host, bool a_dev)
>  {
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
>   usb3_set_mode(usb3, host);
> + spin_lock_irqsave(>lock, flags);

Hi Shimoda-san,

could you clarify why moving this lock is safe?

>   usb3_vbus_out(usb3, a_dev);
>   /* for A-Peripheral or forced B-device mode */
>   if ((!host && a_dev) ||
> -- 
> 1.9.1
> 

RE: [PATCH v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

[Yoshihiro Shimoda]

Hi Simon-san,

Thank you for your review!

> From: Simon Horman, Sent: Tuesday, May 15, 2018 4:35 PM
> 
> On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> > This patch fixes an issue that reconnection is possible to fail
> > because unexpected state handling happens by the irqs. To fix the issue,
> > the driver disables the controller's irqs when disconnected.
> >
> > Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> > USB3.0 peripheral controller")
> > Cc:  # v4.5+
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >
> > Remarks:
> >  - A new file in v2
> >
> >  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > b/drivers/usb/gadget/udc/renesas_usb3.c
> > index 0e70163..5caf78b 100644
> > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 *usb3)
> > usb3_usb2_pullup(usb3, 0);
> > usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
> > usb3_reset_epc(usb3);
> > +   usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> > +  USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> > +  USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> > +  USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> > +  USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);
> 
> Hi Shimoda-san,
> 
> is it intentional that USB_INT_1_VBUS_CNG is not disabled above?

Yes, because the USB_INT_1_VBUS_CNG is enabled in usb3_init_epc_registers() 
below.

> > +   usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> > +   usb3_init_epc_registers(usb3);

Best regards,
Yoshihiro Shimoda

> > if (usb3->driver)
> > usb3->driver->disconnect(>gadget);
> > --
> > 1.9.1
> >

Re: [PATCH] drm: rcar-du: disable dtc graph-endpoint warnings on DT overlays

[Simon Horman]

On Fri, May 11, 2018 at 09:33:23AM -0500, Rob Herring wrote:
> The rcar DT overlays are missing symetrical remote-endpoint properties
> in their graph nodes because the remote-endpoint is fixed up at
> run-time. Disable the dtc 'graph-endpoint' warnings when compiling these
> overlays. If this becomes a common problem for overlays, then perhaps
> this check needs to be disabled for all overlays.
> 
> Reported-by: Stephen Rothwell 
> Cc: Laurent Pinchart 
> Cc: David Airlie 
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-renesas-soc@vger.kernel.org
> Signed-off-by: Rob Herring 

Acked-by: Simon Horman 

> ---
> This needs to go thru my tree because it is dependent on the dtc update 
> that adds the warning (perhaps we're going to need to add option 
> checking for dtc).
> 
> Rob 
> 
>  drivers/gpu/drm/rcar-du/Makefile | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Makefile 
> b/drivers/gpu/drm/rcar-du/Makefile
> index 3e58ed93d5b1..2a3b8d7972b5 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -17,3 +17,10 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
>  obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
>  obj-$(CONFIG_DRM_RCAR_DW_HDMI)   += rcar_dw_hdmi.o
>  obj-$(CONFIG_DRM_RCAR_LVDS)  += rcar_lvds.o
> +
> +# 'remote-endpoint' is fixed up at run-time
> +DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7791 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7793 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7795 += -Wno-graph_endpoint
> +DTC_FLAGS_rcar_du_of_lvds_r8a7796 += -Wno-graph_endpoint
> -- 
> 2.17.0
> 

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

[Simon Horman]

On Fri, May 11, 2018 at 09:31:37AM +0100, Phil Edworthy wrote:
> The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> per GPIO in port A, but the driver currently only supports 1 interrupt.
> See the DesignWare DW_apb_gpio Databook description of the
> 'GPIO_INTR_IO' parameter.
> 
> This change allows the driver to work with up to 32 interrupts, it will
> get as many interrupts as specified in the DT 'interrupts' property.
> It doesn't do anything clever with the different interrupts, it just calls
> the same handler used for single interrupt hardware.
> 
> Signed-off-by: Phil Edworthy 
> Reviewed-by: Rob Herring 
> Acked-by: Lee Jones 
> ---
> One point to mention is that I have made it possible for users to have
> unconnected interrupts by specifying holes in the list of interrupts. This is
> done by supporting the interrupts-extended DT prop.
> However, I have no use for this and had to hack some test case for this.
> Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
> 
> v6:
>  - Treat DT and ACPI the same as much as possible. Note that we can't use
>platform_get_irq() to get the DT interrupts as they are in the port
>sub-node and hence do not have an associated platform device.
> v5:
>  - Rolled ACPI companion code provided by Hoan Tran into this patch.
> v4:
>  - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping()
> v3:
>  - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect 
> problems
> v2:
>  - Replaced interrupt-mask DT prop with support for the interrupts-extended
>prop. This means replacing the call to irq_of_parse_and_map() with calls
>to of_irq_parse_one() and irq_create_of_mapping().
> ---
>  .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 +++-
>  drivers/gpio/gpio-dwapb.c  | 49 
> +++---
>  drivers/mfd/intel_quark_i2c_gpio.c |  3 +-
>  include/linux/platform_data/gpio-dwapb.h   |  3 +-
>  4 files changed, 45 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
> b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> index 4a75da7..3c1118b 100644
> --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> @@ -26,8 +26,13 @@ controller.
>the second encodes the triger flags encoded as described in
>Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>  - interrupt-parent : The parent interrupt controller.
> -- interrupts : The interrupt to the parent controller raised when GPIOs
> -  generate the interrupts.
> +- interrupts : The interrupts to the parent controller raised when GPIOs
> +  generate the interrupts. If the controller provides one combined interrupt
> +  for all GPIOs, specify a single interrupt. If the controller provides one
> +  interrupt for each GPIO, provide a list of interrupts that correspond to 
> each
> +  of the GPIO pins. When specifying multiple interrupts, if any are 
> unconnected,
> +  use the interrupts-extended property to specify the interrupts and set the
> +  interrupt controller handle for unused interrupts to 0.
>  - snps,nr-gpios : The number of pins in the port, a single cell.
>  - resets : Reset line for the controller.

An enhanced example might be helpful.

That not withstanding:

Reviewed-by: Simon Horman 

Re: [PATCH 0/2] Revert explicit support for Renesas R-Car Gen 3 r8a779[56] SoCs

[Simon Horman]

On Thu, May 10, 2018 at 11:51:38AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, May 2, 2018 11:58:04 AM CEST Simon Horman wrote:
> > Revert commits that added explicit support for Renesas R-Car Gen 3
> > r8a779[56] SoCs to the generic cpufreq driver.
> > 
> > This is no longer needed since the flowing commit and to the best of my
> > knowledge is not relied on by any upstream DTS: edeec420de24 ("cpufreq:
> > dt-platdev: Automatically create cpufreq device with OPP v2")
> > 
> > Simon Horman (2):
> >   Revert "cpufreq: dt: Add r8a7796 support to to use generic cpufreq
> > driver"
> >   Revert "cpufreq: rcar: Add support for R8A7795 SoC"
> > 
> >  drivers/cpufreq/cpufreq-dt-platdev.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > 
> 
> Am I expected to pick up this series?

Hi Rafael,

that would be ideal from my point of view.

Re: [PATCH v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

[Simon Horman]

On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that reconnection is possible to fail
> because unexpected state handling happens by the irqs. To fix the issue,
> the driver disables the controller's irqs when disconnected.
> 
> Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> USB3.0 peripheral controller")
> Cc:  # v4.5+
> Signed-off-by: Yoshihiro Shimoda 
> ---
> 
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 0e70163..5caf78b 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 *usb3)
>   usb3_usb2_pullup(usb3, 0);
>   usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
>   usb3_reset_epc(usb3);
> + usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> +USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> +USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> +USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> +USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);

Hi Shimoda-san,

is it intentional that USB_INT_1_VBUS_CNG is not disabled above?

> + usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> + usb3_init_epc_registers(usb3);
>  
>   if (usb3->driver)
>   usb3->driver->disconnect(>gadget);
> -- 
> 1.9.1
> 

Re: [PATCH v2 5/6] usb: gadget: udc: renesas_usb3: should fail if devm_phy_get() returns error

[Simon Horman]

On Tue, Apr 10, 2018 at 02:38:53PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver ignores errors other than
> the non-existence of the device, f.e. a memory allocation failure
> in devm_phy_get(). So, this patch replaces devm_phy_get() with
> devm_phy_optional_get().
> 
> Reported-by: Simon Horman 
> Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic 
> phy")
> Cc:  # v4.15+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 233bc04..0e70163 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -2636,9 +2636,11 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>* This is optional. So, if this driver cannot get a phy,
>* this driver will not handle a phy anymore.
>*/
> - usb3->phy = devm_phy_get(>dev, "usb");
> - if (IS_ERR(usb3->phy))
> - usb3->phy = NULL;
> + usb3->phy = devm_phy_optional_get(>dev, "usb");
> + if (IS_ERR(usb3->phy)) {
> + ret = PTR_ERR(usb3->phy);
> + goto err_add_udc;
> + }
>  
>   pm_runtime_enable(>dev);
>   ret = usb_add_gadget_udc(>dev, >gadget);
> -- 
> 1.9.1
> 

Re: [PATCH/RFT v3 1/3] thermal: rcar_thermal: add r8a77995 support

[Simon Horman]

On Mon, May 14, 2018 at 06:11:59AM +0900, Yoshihiro Kaneko wrote:
> Hi Simon-san,
> 
> 2018年5月10日(木) 3:11 Simon Horman :
> 
> > On Tue, Apr 03, 2018 at 09:43:03PM +0900, Yoshihiro Kaneko wrote:
> > > Add support for R-Car D3 (r8a77995) thermal sensor.
> > >
> > > Signed-off-by: Yoshihiro Kaneko 
> > > ---
> > >  drivers/thermal/rcar_thermal.c | 154
> > -
> > >  1 file changed, 122 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/drivers/thermal/rcar_thermal.c
> > b/drivers/thermal/rcar_thermal.c
> > > index 73e5fee..5ec47a9 100644
> > > --- a/drivers/thermal/rcar_thermal.c
> > > +++ b/drivers/thermal/rcar_thermal.c
> > > @@ -58,10 +58,43 @@ struct rcar_thermal_common {
> > >   spinlock_t lock;
> > >  };
> > >
> > > +struct rcar_thermal_chip {
> > > + unsigned int use_of_thermal : 1;
> > > + unsigned int has_filonoff : 1;
> > > + unsigned int irq_per_ch : 1;
> > > + unsigned int needs_suspend_resume : 1;
> > > + unsigned int nirqs;
> > > +};
> > > +
> > > +static const struct rcar_thermal_chip rcar_thermal = {
> > > + .use_of_thermal = 0,
> > > + .has_filonoff = 1,
> > > + .irq_per_ch = 0,
> > > + .needs_suspend_resume = 0,
> > > + .nirqs = 1,
> > > +};
> > > +
> > > +static const struct rcar_thermal_chip rcar_gen2_thermal = {
> > > + .use_of_thermal = 1,
> > > + .has_filonoff = 1,
> > > + .irq_per_ch = 0,
> > > + .needs_suspend_resume = 0,
> > > + .nirqs = 1,
> > > +};
> > > +
> > > +static const struct rcar_thermal_chip rcar_gen3_thermal = {
> > > + .use_of_thermal = 1,
> > > + .has_filonoff = 0,
> > > + .irq_per_ch = 1,
> > > + .needs_suspend_resume = 1,
> > > + .nirqs = 2,
> > > +};
> >
> > The binding and dts patches in this series describe 3 interrupts
> > for R-Car D3. But the above specifies two. Am I missing something obvious?
> 
> 
> R-Car D3 has 3 interrupts, but this driver uses only 2 interrupts to detect
> a temperature change, rise or fall.

Thanks, that makes perfect sense.

Perhaps a comment above ".nirqs = 2" would make it more obvious to the casual
observer?

Re: [PATCH] ARM: dts: r8a7740: Add CEU1

[jacopo mondi]

Hi Simon,

On Tue, May 15, 2018 at 09:10:06AM +0200, Simon Horman wrote:
> On Mon, May 07, 2018 at 02:37:57PM +0200, Simon Horman wrote:
> > Describe CEU1 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
> >
> > Signed-off-by: Simon Horman 
>
> Would anyone care to review this change?

That would be me, as I've sent patches for CEU0 on R-Mobile A1, sorry
about that.

>
> > ---
> >  arch/arm/boot/dts/r8a7740.dtsi | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> >  Depends and based on:
> >  "[PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0"
> >
> > diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> > index 508d93440ee8..af4c071c9178 100644
> > --- a/arch/arm/boot/dts/r8a7740.dtsi
> > +++ b/arch/arm/boot/dts/r8a7740.dtsi
> > @@ -77,6 +77,16 @@
> > status = "disabled";
> > };
> >
> > +   ceu1: ceu@fe914000 {
> > +   reg = <0xfe91 0x3000>;

The reg property start address does not match the device node unit
address (which is the correct one according to documentation).

Thanks
   j

> > +   compatible = "renesas,r8a7740-ceu";
> > +   interrupts = ;
> > +   clocks = <_clks R8A7740_CLK_CEU21>;
> > +   clock-names = "ceu21";
> > +   power-domains = <_a4r>;
> > +   status = "disabled";
> > +   };
> > +
> > cmt1: timer@e6138000 {
> > compatible = "renesas,cmt-48-r8a7740", "renesas,cmt-48";
> > reg = <0xe6138000 0x170>;
> > --
> > 2.11.0
> >


signature.asc
Description: PGP signature

Re: [PATCH 1/2] dt-bindings: arm: document Renesas V3HSK board bindings

[Simon Horman]

On Mon, May 14, 2018 at 10:28:34PM +0200, Geert Uytterhoeven wrote:
> On Thu, May 10, 2018 at 8:09 PM, Sergei Shtylyov
>  wrote:
> > Document the V3H Starter Kit device tree bindings, listing it as
> > a supported board.
> >
> > This allows to use checkpatch.pl to validate .dts files referring to
> > the V3HSK board.
> >
> > Signed-off-by: Sergei Shtylyov 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH v16 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[jacopo mondi]

Hi Niklas,
   thanks fro the patch.

On Tue, May 15, 2018 at 02:56:35AM +0200, Niklas Söderlund wrote:
> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> supports the R-Car Gen3 SoCs where separate CSI-2 hardware blocks are
> connected between the video sources and the video grabbers (VIN).
>
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
>
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Laurent Pinchart 
> Reviewed-by: Maxime Ripard 

I forgot to add it to v15, as my comments there pointed to non
blocking issues.

Reviewed-by: Jacopo Mondi 

Thanks
  j

>
> ---
>
> * Changes since v15
> - Merge struct phtw_mbps and struct phypll_hsfreqrange into a new struct
>   which maps a mpbs value to a register value, struct rcsi2_mbps_reg.
> - Reduced number of loops and delay when waiting for LP-11 and
>   confirmation of PHTW write as suggested by Laurent.
> - Dropped dev_dbg() printouts of the requested link speed.
> - Fix small issues in comments.
> - Remove unneeded () in for-loop condition in rcsi2_phtw_write_array().
> - Remove __refdata from declaration of 'static struct platform_driver
>   rcar_csi2_pdrv'.
> - Update MODULE_DESCRIPTION to 'Renesas R-Car MIPI CSI-2 receiver
>   driver'.
> - Fixed two erroneous values in hsfreqrange_h3_v3h_m3n[]. Thanks Jacopo
>   for spotting this!
> - Max link speed for V3M and E3 are 1.125Gbps remove settings above that
>   limit in phtw_mbps_v3m_e3. This also changed in datasheet v1.0.
> - Add review tags from Laurent and Maxime.
>
> * Changes since v14
> - Data sheet update changed init sequence for PHY forcing a restructure
>   of the driver. The restructure was so big I felt compel to drop all
>   review tags :-(
> - The change was that the Renesas H3 procedure was aligned with other
>   SoC in the Gen3 family procedure. I had kept the rework as separate
>   patches and was planing to post once original driver with H3 and M3-W
>   support where merged. As review tags are dropped I chosen to squash
>   those patches into 2/2.
> - Add support for Gen3 V3M.
> - Add support for Gen3 M3-N.
> - Set PHTC_TESTCLR when stopping the PHY.
> - Revert back to the v12 and earlier phypll calculation as it turns out
>   it was correct after all.
>
> * Changes since v13
> - Change return rcar_csi2_formats + i to return _csi2_formats[i].
> - Add define for PHCLM_STOPSTATECKL.
> - Update spelling in comments.
> - Update calculation in rcar_csi2_calc_phypll() according to
>   https://linuxtv.org/downloads/v4l-dvb-apis/kapi/csi2.html. The one
>   before v14 did not take into account that 2 bits per sample is
>   transmitted.
> - Use Geert's suggestion of (1 << priv->lanes) - 1 instead of switch
>   statement to set correct number of lanes to enable.
> - Change hex constants in hsfreqrange_m3w_h3es1[] to lower case to match
>   style of rest of file.
> - Switch to %u instead of 0x%x when printing bus type.
> - Switch to %u instead of %d for priv->lanes which is unsigned.
> - Add MEDIA_BUS_FMT_YUYV8_1X16 to the list of supported formats in
>   rcar_csi2_formats[].
> - Fixed bps for MEDIA_BUS_FMT_YUYV10_2X10 to 20 and not 16.
> - Set INTSTATE after PL-11 is confirmed to match flow chart in
>   datasheet.
> - Change priv->notifier.subdevs == NULL to !priv->notifier.subdevs.
> - Add Maxime's and laurent's tags.
> ---
>  drivers/media/platform/rcar-vin/Kconfig |   12 +
>  drivers/media/platform/rcar-vin/Makefile|1 +
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 1084 +++
>  3 files changed, 1097 insertions(+)
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
>
> diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> b/drivers/media/platform/rcar-vin/Kconfig
> index 8fa7ee468c63afb9..d5835da6d4100d87 100644
> --- a/drivers/media/platform/rcar-vin/Kconfig
> +++ b/drivers/media/platform/rcar-vin/Kconfig
> @@ -1,3 +1,15 @@
> +config VIDEO_RCAR_CSI2
> + tristate "R-Car MIPI CSI-2 Receiver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> + depends on ARCH_RENESAS || COMPILE_TEST
> + select V4L2_FWNODE
> + help
> +   Support for Renesas R-Car MIPI CSI-2 receiver.
> +   Supports R-Car Gen3 SoCs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called rcar-csi2.
> +
>  config VIDEO_RCAR_VIN
>   tristate "R-Car Video Input (VIN) Driver"
>   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> MEDIA_CONTROLLER
> diff --git a/drivers/media/platform/rcar-vin/Makefile 
> b/drivers/media/platform/rcar-vin/Makefile
> index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> --- a/drivers/media/platform/rcar-vin/Makefile
> +++ b/drivers/media/platform/rcar-vin/Makefile
> @@ -1,3 +1,4 @@
>  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
>
> +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
>  

Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965

[Simon Horman]

On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote:
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Simon Horman 

Re: [PATCH] arm64: dts: renesas: r8a77990: Add GPIO device nodes

[Simon Horman]

On Mon, May 14, 2018 at 06:57:04PM +0300, Sergei Shtylyov wrote:
> On 05/14/2018 05:30 PM, Simon Horman wrote:
> 
> >>> The compat string renesas,gpio-rcar has been deprecated since v4.14,
> >>> the same release that r8a77990 SoC support was added. Thus
> >>> renesas,gpio-rcar can safely be removed without any risk of behaviour
> >>> changes between old and new mainline kernels and DTBs.
> >>
> >>This hardly matches the subject. :-)
> > 
> > Indeed, I will resubmit.
> 
>I'm seeing this patch merged on Sunday...

Yes, I saw that too. I dropped it yesterday.

Re: [PATCH] ARM: dts: r8a7740: Add CEU1

[Simon Horman]

On Mon, May 07, 2018 at 02:37:57PM +0200, Simon Horman wrote:
> Describe CEU1 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
> 
> Signed-off-by: Simon Horman 

Would anyone care to review this change?

> ---
>  arch/arm/boot/dts/r8a7740.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
>  Depends and based on:
>  "[PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0"
> 
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index 508d93440ee8..af4c071c9178 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -77,6 +77,16 @@
>   status = "disabled";
>   };
>  
> + ceu1: ceu@fe914000 {
> + reg = <0xfe91 0x3000>;
> + compatible = "renesas,r8a7740-ceu";
> + interrupts = ;
> + clocks = <_clks R8A7740_CLK_CEU21>;
> + clock-names = "ceu21";
> + power-domains = <_a4r>;
> + status = "disabled";
> + };
> +
>   cmt1: timer@e6138000 {
>   compatible = "renesas,cmt-48-r8a7740", "renesas,cmt-48";
>   reg = <0xe6138000 0x170>;
> -- 
> 2.11.0
> 

Re: [PATCH 0/3] arm64: dts: Draak: Enable HDMI input and VIN4

[Simon Horman]

On Mon, May 14, 2018 at 10:33:44PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Fri, May 11, 2018 at 11:59 AM, Jacopo Mondi
>  wrote:
> >this series enables HDMI input and VIN4 on R-Car D3 Draak board.
> >
> > The Draak board has an HDMI input connected to an HDMI decoder that feeds
> > the VIN capture interface through its parallel video interface.
> >
> > The series requires the just sent:
> > [PATCH 0/5] rcar-vin: Add support for digital input on Gen3
> >
> > and enables image capture operations on D3 Draak board.
> >
> > The series has been developed on top of media-master tree but applies 
> > cleanly
> > on top of latest renesas-driver.
> >
> > Geert: would you like a topic branch for this series to be included in
> > renesas-drivers?
> 
> It seems patch 2 has been applied by Simon already, but there is some
> discussion pending on patch 3?

Yes, that is correct.

Also, for extra fun, I moved the nodes when applying patch 2.

> > Patches for testing are available at:
> > git://jmondi.org/linux d3/media-master/driver
> > git://jmondi.org/linux d3/media-master/dts
> > git://jmondi.org/linux d3/media-master/test
> > git://jmondi.org/vin-tests d3
> >
> > Thanks
> > j
> >
> > Jacopo Mondi (3):
> >   dt-bindings: media: rcar-vin: Add R8A77995 support
> >   arm64: dts: renesas: r8a77995: Add VIN4
> >   arm64: dts: renesas: draak: Describe HDMI input
> >
> >  .../devicetree/bindings/media/rcar_vin.txt |  1 +
> >  arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 
> > ++
> >  arch/arm64/boot/dts/renesas/r8a77995.dtsi  | 11 
> >  3 files changed, 80 insertions(+)
> 
> 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/3] arm64: dts: renesas: r8a77995: Add VIN4

[Simon Horman]

On Mon, May 14, 2018 at 05:36:41AM +0300, Laurent Pinchart wrote:
> Hello,
> 
> On Friday, 11 May 2018 16:45:16 EEST Simon Horman wrote:
> > On Fri, May 11, 2018 at 01:25:23PM +0200, Niklas Söderlund wrote:
> > > Hi Jacopo,
> > > 
> > > Thanks for your work.
> > > 
> > > On 2018-05-11 12:00:01 +0200, Jacopo Mondi wrote:
> > > > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> > > > 
> > > > Signed-off-by: Jacopo Mondi 
> > > 
> > > Acked-by: Niklas Söderlund 
> > > 
> > >> ---
> > >> 
> > >>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++
> > >>  1 file changed, 11 insertions(+)
> > >> 
> > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index 82aed7e..bdf7017
> > >> 100644
> > >> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > >> @@ -783,6 +783,17 @@
> > >>  };
> > >>  };
> > >>  };
> > >> +
> > >> +vin4: video@e6ef4000 {
> > >> +compatible = "renesas,vin-r8a77995";
> > >> +reg = <0 0xe6ef4000 0 0x1000>;
> > >> +interrupts = ;
> > >> +clocks = < CPG_MOD 807>;
> > >> +power-domains = < R8A77995_PD_ALWAYS_ON>;
> > >> +resets = < 807>;
> > >> +renesas,id = <4>;
> > >> +status = "disabled";
> > >> +};
> > >>  };
> > 
> > Thanks, I have moved the new node to preserve sorting of nodes by bus
> > address and applied the result. It is as follows:
> > 
> > From: Jacopo Mondi 
> > Subject: [PATCH] arm64: dts: renesas: r8a77995: Add VIN4
> > 
> > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> > 
> > Signed-off-by: Jacopo Mondi 
> > Acked-by: Niklas Söderlund 
> > [simon: sorted node by bus address]
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Laurent Pinchart 

Thanks, tag added.