Re: [PATCH] DT: dma: rcar-dmac: document R8A7743/5 support

[Vinod Koul]

On Thu, Sep 29, 2016 at 01:25:48AM +0300, Sergei Shtylyov wrote:
> Renesas  RZ/G SoC also have the R-Car gen2/3 compatible DMA controllers.
> Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dma-debug: fix ia64 build, use PHYS_PFN

[Vinod Koul]

On Thu, Sep 29, 2016 at 09:59:15PM +0200, Niklas Söderlund wrote:
> kbuild test robot reports:
> 
>lib/dma-debug.c: In function 'debug_dma_map_resource':
> >> lib/dma-debug.c:1541:16: error: implicit declaration of function 
> >> '__phys_to_pfn' [-Werror=implicit-function-declaration]
>  entry->pfn  = __phys_to_pfn(addr);
>^
> 
> ia64 does not provide __phys_to_pfn(), use the PHYS_PFN() alias.

Applied, thanks

-- 
~Vinod

Re: RGB LVDS BRIDGE SUPPORT IN RCAR E2

[Laurent Pinchart]

Hello Jithin,

Could you please reply to e-mails instead of sending unrelated new e-mails, in 
order to keep all mails related to the subject grouped in a single thread ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] sh-sci: add R8A7743/5 support

[Sergei Shtylyov]

On 09/30/2016 11:38 AM, Geert Uytterhoeven wrote:


Renesas  RZ/G SoC also have the SCIF, SCIFA, SCIFB, and HSCIF ports.
Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings along with
the RZ/G family bindings.  The driver itself also needs to recognize
the latter binding for the SCIF ports, so teach it...

Signed-off-by: Sergei Shtylyov 

[...]


===
--- tty.orig/drivers/tty/serial/sh-sci.c
+++ tty/drivers/tty/serial/sh-sci.c
@@ -2950,6 +2950,9 @@ static const struct of_device_id of_sci_
}, {
.compatible = "renesas,rcar-gen3-scif",
.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+   }, {
+   .compatible = "renesas,rzg-scif",
+   .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
},
/* Generic types */
{


However, I wouldn't bother adding RZ/G family-specific DT bindings, as
RZ/G is a derivative of R-Car Gen2.


   Then we shouldn't have added gen2/3 bindings too since they resolve to the 
same register mapping as gen1. :-)



Gr{oetje,eeting}s,

Geert


MBR, Sergei

Re: RGB LVDS BRIDGE SUPPORT IN RCAR E2

[Geert Uytterhoeven]

On Fri, Sep 30, 2016 at 3:46 PM, Jithin T Raj  wrote:
>   I would like to give support to RGB LVDS BRIDGE  RCAR E2
>
>   I am attaching the patch file..can you please review it and let me know the 
> status.is it correct or not?

Please don't attach patches, but inline them, so we can easily add review
comments.

> diff --git a/a/r8a7794-alt.dts b/b/r8a7779-marzen.dts

This doesn't look like a patch generated by "git diff"...

> index 383ad79..b795da6 100644
> --- a/a/r8a7794-alt.dts
> +++ b/b/r8a7779-marzen.dts
> @@ -1,7 +1,8 @@
>  /*
> - * Device Tree Source for the Alt board
> + * Device Tree Source for the Marzen board

Are you trying to replace arch/arm/boot/dts/r8a7794-alt.dts by
arch/arm/boot/dts/r8a7779-marzen.dts? That won't work...

Please try adding an "lvds-encoder" block to arch/arm/boot/dts/r8a7794-alt.dts,
as exists in arch/arm/boot/dts/r8a7779-marzen.dts.
You want to replace "thc63lvdm83d" by "thc63lvdm87", though.

You said you added  "thc63lvdm87" in "drivers/gpu/drm/rcar-du/rcar_du_kms.c",
so that part should be fine.

Good luck!

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

RGB LVDS BRIDGE SUPPORT IN RCAR E2

[Jithin T Raj]

hi,
  I would like to give support to RGB LVDS BRIDGE  RCAR E2 

  I am attaching the patch file..can you please review it and let me know the 
status.is it correct or not?





 
Best Regards
 Jithin T Raj
 
   diff --git a/a/r8a7794-alt.dts b/b/r8a7779-marzen.dts
index 383ad79..b795da6 100644
--- a/a/r8a7794-alt.dts
+++ b/b/r8a7779-marzen.dts
@@ -1,7 +1,8 @@
 /*
- * Device Tree Source for the Alt board
+ * Device Tree Source for the Marzen board
  *
- * Copyright (C) 2014 Renesas Electronics Corporation
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2.  This program is licensed "as is" without any warranty of any
@@ -9,29 +10,64 @@
  */
 
 /dts-v1/;
-#include "r8a7794.dtsi"
+#include "r8a7779.dtsi"
+#include 
+#include 
 
 / {
-	model = "Alt";
-	compatible = "renesas,alt", "renesas,r8a7794";
+	model = "marzen";
+	compatible = "renesas,marzen", "renesas,r8a7779";
 
 	aliases {
 		serial0 = 
+		serial1 = 
 	};
 
 	chosen {
-		bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
-		stdout-path = "serial0:115200n8";
+		bootargs = "ignore_loglevel root=/dev/nfs ip=on";
+		stdout-path = 
 	};
 
-	memory@4000 {
+	memory {
 		device_type = "memory";
-		reg = <0 0x4000 0 0x4000>;
+		reg = <0x6000 0x4000>;
 	};
 
-	lbsc {
-		#address-cells = <1>;
-		#size-cells = <1>;
+	fixedregulator3v3: fixedregulator@0 {
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-3.3V";
+		regulator-min-microvolt = <330>;
+		regulator-max-microvolt = <330>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+	ethernet@1800 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0x1800 0x100>;
+		pinctrl-0 = <_pins>;
+		pinctrl-names = "default";
+
+		phy-mode = "mii";
+		interrupt-parent = <>;
+		interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+		smsc,irq-push-pull;
+		reg-io-width = <4>;
+		vddvario-supply = <>;
+		vdd33a-supply = <>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		led2 {
+			gpios = < 29 GPIO_ACTIVE_HIGH>;
+		};
+		led3 {
+			gpios = < 30 GPIO_ACTIVE_HIGH>;
+		};
+		led4 {
+			gpios = < 31 GPIO_ACTIVE_HIGH>;
+		};
 	};
 
 	vga-encoder {
@@ -43,13 +79,13 @@
 
 			port@0 {
 reg = <0>;
-adv7123_in: endpoint {
-	remote-endpoint = <_out_rgb1>;
+vga_enc_in: endpoint {
+	remote-endpoint = <_out_rgb0>;
 };
 			};
 			port@1 {
 reg = <1>;
-adv7123_out: endpoint {
+vga_enc_out: endpoint {
 	remote-endpoint = <_in>;
 };
 			};
@@ -61,21 +97,36 @@
 
 		port {
 			vga_in: endpoint {
-remote-endpoint = <_out>;
+remote-endpoint = <_enc_out>;
 			};
 		};
 	};
 
-	x2_clk: x2-clock {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <7425>;
+	lvds-encoder {
+		compatible = "thine,thc63lvdm83d";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+reg = <0>;
+lvds_enc_in: endpoint {
+	remote-endpoint = <_out_rgb1>;
+};
+			};
+			port@1 {
+reg = <1>;
+lvds_connector: endpoint {
+};
+			};
+		};
 	};
 
-	x13_clk: x13-clock {
+	x3_clk: x3-clock {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
-		clock-frequency = <14850>;
+		clock-frequency = <6500>;
 	};
 };
 
@@ -84,22 +135,33 @@
 	pinctrl-names = "default";
 	status = "okay";
 
-	clocks = <_clks R8A7794_CLK_DU0>,
-		 <_clks R8A7794_CLK_DU0>,
-		 <_clk>, <_clk>;
-	clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
+	clocks = <_clks R8A7779_CLK_DU>, <_clk>;
+	clock-names = "du", "dclkin.0";
 
 	ports {
+		port@0 {
+			endpoint {
+remote-endpoint = <_enc_in>;
+			};
+		};
 		port@1 {
 			endpoint {
-remote-endpoint = <_in>;
+remote-endpoint = <_enc_in>;
 			};
 		};
 	};
 };
 
+ {
+	status = "okay";
+};
+
 _clk {
-	clock-frequency = <2000>;
+	clock-frequency = <3125>;
+};
+
+ {
+	status = "okay";
 };
 
  {
@@ -107,152 +169,83 @@
 	pinctrl-names = "default";
 
 	du_pins: du {
-		groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_dotclkout0";
-		function = "du";
-	};
-
-	scif2_pins: serial2 {
-		groups = "scif2_data";
-		function = "scif2";
+		du0 {
+			groups = "du0_rgb888", "du0_sync_1", "du0_clk_out_0";
+			function = "du0";
+		};
+		du1 {
+			groups = "du1_rgb666", "du1_sync_1", "du1_clk_out";
+			function = "du1";
+		};
 	};
 
 	scif_clk_pins: scif_clk {
-		groups = "scif_clk";
+		groups = "scif_clk_b";
 		function = "scif_clk";
 	};
 
-	ether_pins: ether {
-		groups = "eth_link", "eth_mdio", "eth_rmii";
-		function = "eth";
+	ethernet_pins: ethernet {
+		intc {
+			groups = "intc_irq1_b";
+			function = "intc";
+		};
+		lbsc {
+			groups = "lbsc_ex_cs0";
+			function = "lbsc";
+		};
 	};
 
-	phy1_pins: phy1 {
-		groups = "intc_irq8";
-		function = "intc";
+	scif2_pins: serial2 {
+		groups = "scif2_data_c";
+		function = "scif2";
 	};
 
-	i2c1_pins: i2c1 {
-		groups = "i2c1";
-		function = "i2c1";
+	scif4_pins: serial4 {
+		groups = 

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

[Laurent Pinchart]

On Friday 30 Sep 2016 15:00:59 Geert Uytterhoeven wrote:
> On Fri, Sep 30, 2016 at 2:40 PM, Laurent Pinchart wrote:
> >> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> >> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> >> @@ -374,6 +374,11 @@
> >>   groups = "audio_clk_a";
> >>   function = "audio_clk";
> >>   };
> >> +
> >> + vin0_pins: vin0 {
> >> + groups = "vin0_data24", "vin0_sync", "vin0_clkenb",
> >> "vin0_clk";
> >> + function = "vin0";
> >> + };
> >>  };
> >>  
> >>   {
> >> @@ -531,6 +536,21 @@
> >>   };
> >>   };
> >> 
> >> + hdmi-in@4c {
> >> + compatible = "adi,adv7612";
> >> + reg = <0x4c>;
> >> + interrupt-parent = <>;
> >> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> > 
> > Isn't the interrupt signal connected to GP4_2 ?
> 
> No idea about Gose, but on Koelsch it is (hence koelsch DTS is wrong??)

I believe so. I don't have a Koelsch board anymore so I can't test that. 
Niklas, do you have a Koelsch on which you could confirm the IRQ number ?

-- 
Regards,

Laurent Pinchart

RGB-LVDS BRIDGE SUPPORT RCAR

[Jithin T Raj]

Hi,
  This is my diff file,



diff --git a/a/r8a7794-alt.dts b/b/r8a7779-marzen.dts
index 383ad79..b795da6 100644
--- a/a/r8a7794-alt.dts
+++ b/b/r8a7779-marzen.dts
@@ -1,7 +1,8 @@
 /*
- * Device Tree Source for the Alt board
+ * Device Tree Source for the Marzen board
  *
- * Copyright (C) 2014 Renesas Electronics Corporation
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2.  This program is licensed "as is" without any warranty of any
@@ -9,29 +10,64 @@
  */
 
 /dts-v1/;
-#include "r8a7794.dtsi"
+#include "r8a7779.dtsi"
+#include 
+#include 
:




i just done this command "git diff a/r8a7794-alt.dts b/r8a7779-marzen.dts "
i have kept "r8a7794-alt.dts" in "a" and "r8a7779-marzen.dts" in "b"

sorry if it is not good





 
Best Regards
 Jithin T Raj
 
 
   

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

[Geert Uytterhoeven]

On Fri, Sep 30, 2016 at 2:40 PM, Laurent Pinchart
 wrote:
>> --- a/arch/arm/boot/dts/r8a7793-gose.dts
>> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
>> @@ -374,6 +374,11 @@
>>   groups = "audio_clk_a";
>>   function = "audio_clk";
>>   };
>> +
>> + vin0_pins: vin0 {
>> + groups = "vin0_data24", "vin0_sync", "vin0_clkenb",
> "vin0_clk";
>> + function = "vin0";
>> + };
>>  };
>>
>>   {
>> @@ -531,6 +536,21 @@
>>   };
>>   };
>>
>> + hdmi-in@4c {
>> + compatible = "adi,adv7612";
>> + reg = <0x4c>;
>> + interrupt-parent = <>;
>> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
>
> Isn't the interrupt signal connected to GP4_2 ?

No idea about Gose, but on Koelsch it is (hence koelsch DTS is wrong??)

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: RGB-LVDS BRIDGE SUPPORT RCAR E2

[Laurent Pinchart]

Hi Jithin,

On Friday 30 Sep 2016 11:38:09 Jithin T Raj wrote:
>  Thank you so much for the information.
> 
> Now i compared "arch/arm/boot/dts/r8a7779-marzen.dts" against 
> "arch/arm/boot/dts/r8a7794-alt.dts" and modified r8a7794-alt.dts a little..
> also added  "thc63lvdm87"in "drivers/gpu/drm/rcar-du/rcar_du_kms.c"..here i
> am attaching the modified r8a7794-alt.dts file..I am a newby in this field
> so that I am asking very basics..hope you don't feel bore.. I also build
> image file and .dtb file successfully but don't deployed it.. if you don't
> mind can you please give me a feedback of my work..My source tree is v4.7.5

Could you please send your changes as an inline diff (which you can generate 
with git diff) instead of as a source file attachment ? That will let us 
reviewing it easily and replying inline.

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Friday 16 Sep 2016 15:09:35 Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm/boot/dts/r8a7793-gose.dts | 36 ++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
> b/arch/arm/boot/dts/r8a7793-gose.dts index e22d63c..981f0fe 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -379,6 +379,11 @@
>   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", 
"vin0_clk";
>   function = "vin0";
>   };
> +
> + vin1_pins: vin1 {
> + groups = "vin1_data8", "vin1_clk";
> + function = "vin1";
> + };
>  };
> 
>   {
> @@ -504,6 +509,19 @@
>   reg = <0x12>;
>   };
> 
> + composite-in@20 {
> + compatible = "adi,adv7180";
> + reg = <0x20>;
> + remote = <>;
> +
> + port {
> + adv7180: endpoint {
> + bus-width = <8>;

Is this needed ?

> + remote-endpoint = <>;
> + };
> + };

The ADV7180 DT bindings need to be updated with port nodes (that will be quite 
a challenge).

> + };
> +
>   hdmi@39 {
>   compatible = "adi,adv7511w";
>   reg = <0x39>;
> @@ -599,3 +617,21 @@
>   };
>   };
>  };
> +
> +/* composite video input */
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin1ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <8>;
> + };
> + };
> +};

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Friday 16 Sep 2016 15:09:34 Ulrich Hecht wrote:
> Identical to the setup on Lager.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm/boot/dts/r8a7793-gose.dts | 41 +++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
> b/arch/arm/boot/dts/r8a7793-gose.dts index 90af186..e22d63c 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -374,6 +374,11 @@
>   groups = "audio_clk_a";
>   function = "audio_clk";
>   };
> +
> + vin0_pins: vin0 {
> + groups = "vin0_data24", "vin0_sync", "vin0_clkenb", 
"vin0_clk";
> + function = "vin0";
> + };
>  };
> 
>   {
> @@ -531,6 +536,21 @@
>   };
>   };
> 
> + hdmi-in@4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + interrupt-parent = <>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;

Isn't the interrupt signal connected to GP4_2 ?

> + remote = <>;

What is this for ?

> + default-input = <0>;
> +
> + port {
> + adv7612: endpoint {
> + remote-endpoint = <>;
> + };
> + };

The ADV7612 has three ports. Ports 0 and 1 correspond to the HDMI inputs, and 
port 2 to the digital output. You can leave port 1 out as it's not used on the 
board, but you should specify both ports 0 and 2, and add an HDMI connector DT 
node connected to port 0 of the ADV7612.

> + };
> +
>   eeprom@50 {
>   compatible = "renesas,r1ex24002", "atmel,24c02";
>   reg = <0x50>;
> @@ -558,3 +578,24 @@
>   {
>   shared-pin;
>  };
> +
> +/* HDMI video input */
> + {
> + status = "okay";
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin0ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <24>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};

-- 
Regards,

Laurent Pinchart

RGB-LVDS BRIDGE SUPPORT RCAR E2

[Jithin T Raj]

 Thank you so much for the information.

Now i compared "arch/arm/boot/dts/r8a7779-marzen.dts" against  
"arch/arm/boot/dts/r8a7794-alt.dts" and modified r8a7794-alt.dts a little..
also added  "thc63lvdm87"in "drivers/gpu/drm/rcar-du/rcar_du_kms.c"..here i am 
attaching the modified 
r8a7794-alt.dts file..I am a newby in this field so that I am asking very 
basics..hope you don't feel bore..
I also build image file and .dtb file successfully but don't deployed it..
if you don't mind can you please give me a feedback of my work..My source tree 
is v4.7.5

PFA

Best Regards
Jithin T Raj

  

r8a7794-alt.dts
Description: r8a7794-alt.dts

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

[Laurent Pinchart]

Hi Ulrich,

On Friday 30 Sep 2016 13:55:50 Laurent Pinchart wrote:
> On Friday 16 Sep 2016 15:09:33 Ulrich Hecht wrote:
> > Signed-off-by: Ulrich Hecht 
> > ---
> > 
> >  arch/arm/boot/dts/r8a7793.dtsi | 20 
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/r8a7793.dtsi
> > b/arch/arm/boot/dts/r8a7793.dtsi index 8d02aac..0898668 100644
> > --- a/arch/arm/boot/dts/r8a7793.dtsi
> > +++ b/arch/arm/boot/dts/r8a7793.dtsi
> > @@ -30,6 +30,8 @@
> > i2c7 = 
> > i2c8 = 
> > spi0 = 
> > +   vin0 = 
> > +   vin1 = 
> 
> Why is this needed ?
> 
> > };
> > 
> > cpus {
> > @@ -852,6 +854,24 @@
> > status = "disabled";
> > };
> > 
> > +   vin0: video@e6ef {
> > +   compatible = "renesas,vin-r8a7793";

Additionally, should this be

compatiable = "renesas,vin-r8a7793", "renesas,rcar-gen2-vin";

?

> > +   reg = <0 0xe6ef 0 0x1000>;
> > +   interrupts = ;
> > +   clocks = <_clks R8A7793_CLK_VIN0>;
> > +   power-domains = < R8A7793_PD_ALWAYS_ON>;
> > +   status = "disabled";
> > +   };
> > +
> > +   vin1: video@e6ef1000 {
> > +   compatible = "renesas,vin-r8a7793";
> > +   reg = <0 0xe6ef1000 0 0x1000>;
> > +   interrupts = ;
> > +   clocks = <_clks R8A7793_CLK_VIN1>;
> > +   power-domains = < R8A7793_PD_ALWAYS_ON>;
> > +   status = "disabled";
> > +   };
> > +
> 
> As Geert mentioned, you should add vin2 here.
> 
> > qspi: spi@e6b1 {
> > 
> > compatible = "renesas,qspi-r8a7793", "renesas,qspi";
> > reg = <0 0xe6b1 0 0x2c>;

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi Ulrich,

Thanks for the patch.

On Friday 16 Sep 2016 15:09:33 Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm/boot/dts/r8a7793.dtsi | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
> index 8d02aac..0898668 100644
> --- a/arch/arm/boot/dts/r8a7793.dtsi
> +++ b/arch/arm/boot/dts/r8a7793.dtsi
> @@ -30,6 +30,8 @@
>   i2c7 = 
>   i2c8 = 
>   spi0 = 
> + vin0 = 
> + vin1 = 

Why is this needed ?

>   };
> 
>   cpus {
> @@ -852,6 +854,24 @@
>   status = "disabled";
>   };
> 
> + vin0: video@e6ef {
> + compatible = "renesas,vin-r8a7793";
> + reg = <0 0xe6ef 0 0x1000>;
> + interrupts = ;
> + clocks = <_clks R8A7793_CLK_VIN0>;
> + power-domains = < R8A7793_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
> +
> + vin1: video@e6ef1000 {
> + compatible = "renesas,vin-r8a7793";
> + reg = <0 0xe6ef1000 0 0x1000>;
> + interrupts = ;
> + clocks = <_clks R8A7793_CLK_VIN1>;
> + power-domains = < R8A7793_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
> +

As Geert mentioned, you should add vin2 here.

>   qspi: spi@e6b1 {
>   compatible = "renesas,qspi-r8a7793", "renesas,qspi";
>   reg = <0 0xe6b1 0 0x2c>;

-- 
Regards,

Laurent Pinchart

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Hiep Cao Minh]

Hi Geert,



The issue you're seeing is due to a combination of commits
5f3bca0db8ac01a7
("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").

When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs
may
lock up the system after a cold boot, depending of boot load version.
Hence
we explicitly prohibit that. BTW, this has been the case on Koelsch since
commit
277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").

Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting
secondary CPU cores in debug mode" (included in all renesas-drivers
releases
during September) fix it for you?

Thanks for your series patches.
I have had some problems of receiving post mail from Linux-Renesas Mailing
List recently.

Could you please forward these series patches to me?

They're included in renesas-drivers.
You can also get them from gitweb at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/rcar-secondary-booting-in-debug-mode-v1

Thanks, I'll confirm these patches on my board.


Thank you.
Hiep.

Re: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Geert Uytterhoeven]

Hi Hiep,

On Fri, Sep 30, 2016 at 11:55 AM, Hiep Cao Minh  wrote:
> On 09/29/2016 10:40 PM, Geert Uytterhoeven wrote:
>> On Thu, Sep 29, 2016 at 1:03 PM, Hiep Cao Minh 
>> wrote:
>>> I'd like to report the issue of the CPU operation.
>>> We tested and found it on Lager board at linux-v4.8-rcx.
>>>
>>> The test procedure is the following:
>>>
>>> Confirmation command:
>>>
>>> # cat /proc/interrupts
>>> CPU0
>>> 19: 2509 GIC-0 27 Level arch_timer
>>> 21: 0 GIC-0 36 Level e605.gpio
>>> 22: 0 GIC-0 37 Level e6051000.gpio
>>> 23: 0 GIC-0 38 Level e6052000.gpio
>>> 24: 0 GIC-0 39 Level e6053000.gpio
>>> 25: 0 GIC-0 40 Level e6054000.gpio
>>> 26: 0 GIC-0 41 Level e6055000.gpio
>>> 27: 23 GIC-0 101 Level e61f.thermal
>>> …”
>>>
>>> This issue appears when we changed the SW8-PIN4 of Lager board.
>>>
>>> SW8-PIN4: ON
>>>
>>> + At linux-v4.7: OK (4 cores work together normally).
>>> + At linux-v4.8-rc2: OK (4 cores work together normally).
>>>
>>> SW8-PIN4: OFF
>>>
>>> + At linux-v4.7: -> OK(4 cores work together normally).
>>> + At linux-v4.8-rc2: -> NG(Only 1 core works).
>>
>> And the kernel prints "Unable to boot CPU%u when MD21 is set", right?
>>
>>> We tried to find out the issued patch and we realize that it happens from
>>> the following patch:
>>> " 043248c Merge tag 'armsoc-dt' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc"
>>
>> The issue you're seeing is due to a combination of commits
>> 5f3bca0db8ac01a7
>> ("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
>> dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").
>>
>> When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs
>> may
>> lock up the system after a cold boot, depending of boot load version.
>> Hence
>> we explicitly prohibit that. BTW, this has been the case on Koelsch since
>> commit
>> 277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").
>>
>> Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting
>> secondary CPU cores in debug mode" (included in all renesas-drivers
>> releases
>> during September) fix it for you?
>
> Thanks for your series patches.
> I have had some problems of receiving post mail from Linux-Renesas Mailing
> List recently.
>
> Could you please forward these series patches to me?

They're included in renesas-drivers.
You can also get them from gitweb at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/rcar-secondary-booting-in-debug-mode-v1

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: GEN2:Lager: Only 1 core works when turning off the SW8-PIN4

[Hiep Cao Minh]

Hi Geert,

Thanks for your reply!

On 09/29/2016 10:40 PM, Geert Uytterhoeven wrote:

Hi Hiep,

On Thu, Sep 29, 2016 at 1:03 PM, Hiep Cao Minh  wrote:

I'd like to report the issue of the CPU operation.
We tested and found it on Lager board at linux-v4.8-rcx.

The test procedure is the following:

Confirmation command:

# cat /proc/interrupts
CPU0
19: 2509 GIC-0 27 Level arch_timer
21: 0 GIC-0 36 Level e605.gpio
22: 0 GIC-0 37 Level e6051000.gpio
23: 0 GIC-0 38 Level e6052000.gpio
24: 0 GIC-0 39 Level e6053000.gpio
25: 0 GIC-0 40 Level e6054000.gpio
26: 0 GIC-0 41 Level e6055000.gpio
27: 23 GIC-0 101 Level e61f.thermal
…”

This issue appears when we changed the SW8-PIN4 of Lager board.

SW8-PIN4: ON

+ At linux-v4.7: OK (4 cores work together normally).
+ At linux-v4.8-rc2: OK (4 cores work together normally).

SW8-PIN4: OFF

+ At linux-v4.7: -> OK(4 cores work together normally).
+ At linux-v4.8-rc2: -> NG(Only 1 core works).

And the kernel prints "Unable to boot CPU%u when MD21 is set", right?


We tried to find out the issued patch and we realize that it happens from
the following patch:
" 043248c Merge tag 'armsoc-dt' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc"

The issue you're seeing is due to a combination of commits 5f3bca0db8ac01a7
("ARM: shmobile: apmu: Add APMU DT support via Enable method") and
dc378795156d980c ("ARM: dts: r8a7790: Add APMU nodes").

When debug mode is enabled (SW8-4 = OFF), trying to boot secondary CPUs may
lock up the system after a cold boot, depending of boot load version.  Hence
we explicitly prohibit that. BTW, this has been the case on Koelsch since commit
277efd30cfc72ec2 ("ARM: shmobile: Check r8a7791 MD21 at SMP boot").

Now, does series "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting
secondary CPU cores in debug mode" (included in all renesas-drivers releases
during September) fix it for you?

Thanks for your series patches.
I have had some problems of receiving post mail from Linux-Renesas 
Mailing List recently.


Could you please forward these series patches to me?

Thank you!.
Jinso/Linux-Team
Hiep.

Re: LVDS IF connector (R-Car E2) RTPORC7794SEB00011S ALT Board

[Geert Uytterhoeven]

Hi Jithin,

On Fri, Sep 30, 2016 at 10:46 AM, Jithin T Raj  wrote:
>I have an  (R-Car E2) RTPORC7794SEB00011S ALT Board with me ..On that I
> can see a "LVDS IF" Output at the back side..is it same as LVDS?then how

IF = Interface, so I assume yes ;-)

> can i make it work on that Board

As Laurent already told you, please look how it's handled on Marzen.
Marzen uses a thc63lvdm83d RGB-LVDS bridge, while ALT uses a
thc63lvdm87.

References:
  - arch/arm/boot/dts/r8a7779-marzen.dts
  - drivers/gpu/drm/rcar-du/rcar_du_kms.c

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

LVDS IF connector (R-Car E2) RTPORC7794SEB00011S ALT Board

[Jithin T Raj]

Hi,
   I have an  (R-Car E2) RTPORC7794SEB00011S ALT Board with me ..On that I can 
see a "LVDS IF" Output at the back side..is it same as LVDS?then how can i make 
it work on that Board





 
Best Regards
 Jithin T Raj
 Engineer - Transport Business Unit
 
   

Re: [PATCH] sh-sci: add R8A7743/5 support

[Geert Uytterhoeven]

Hi Sergei,

On Thu, Sep 29, 2016 at 11:37 PM, Sergei Shtylyov
 wrote:
> Renesas  RZ/G SoC also have the SCIF, SCIFA, SCIFB, and HSCIF ports.
> Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings along with
> the RZ/G family bindings.  The driver itself also needs to recognize
> the latter binding for the SCIF ports, so teach it...
>
> Signed-off-by: Sergei Shtylyov 
>
> ---
> This patch is against the 'tty-next' branch of GregKH's 'tty.git' repo.
>
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt |   12 
> ++
>  drivers/tty/serial/sh-sci.c |3 ++
>  2 files changed, 15 insertions(+)
>
> Index: tty/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> ===
> --- tty.orig/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> +++ tty/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> @@ -9,6 +9,14 @@ Required properties:
>  - "renesas,scifb-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFB compatible 
> UART.
>  - "renesas,scifa-r8a7740" for R8A7740 (R-Mobile A1) SCIFA compatible 
> UART.
>  - "renesas,scifb-r8a7740" for R8A7740 (R-Mobile A1) SCIFB compatible 
> UART.
> +- "renesas,scif-r8a7743" for R8A7743 (RZ/G1M) SCIF compatible UART.
> +- "renesas,scifa-r8a7743" for R8A7743 (RZ/G1M) SCIFA compatible UART.
> +- "renesas,scifb-r8a7743" for R8A7743 (RZ/G1M) SCIFB compatible UART.
> +- "renesas,hscif-r8a7743" for R8A7743 (RZ/G1M) HSCIF compatible UART.
> +- "renesas,scif-r8a7745" for R8A7745 (RZ/G1E) SCIF compatible UART.
> +- "renesas,scifa-r8a7745" for R8A7745 (RZ/G1E) SCIFA compatible UART.
> +- "renesas,scifb-r8a7745" for R8A7745 (RZ/G1E) SCIFB compatible UART.
> +- "renesas,hscif-r8a7745" for R8A7745 (RZ/G1E) HSCIF compatible UART.
>  - "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
>  - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
>  - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.

For the part above:
Acked-by: Geert Uytterhoeven 

> @@ -38,11 +46,15 @@ Required properties:
>  - "renesas,rcar-gen1-scif" for R-Car Gen1 SCIF compatible UART,
>  - "renesas,rcar-gen2-scif" for R-Car Gen2 SCIF compatible UART,
>  - "renesas,rcar-gen3-scif" for R-Car Gen3 SCIF compatible UART,
> +- "renesas,rzg-scif" for RZ/G SCIF compatible UART.
>  - "renesas,rcar-gen2-scifa" for R-Car Gen2 SCIFA compatible UART,
> +- "renesas,rzg-scifa" for RZ/G SCIFA compatible UART.
>  - "renesas,rcar-gen2-scifb" for R-Car Gen2 SCIFB compatible UART,
> +- "renesas,rzg-scifb" for RZ/G SCIFB compatible UART.
>  - "renesas,rcar-gen1-hscif" for R-Car Gen1 HSCIF compatible UART,
>  - "renesas,rcar-gen2-hscif" for R-Car Gen2 HSCIF compatible UART,
>  - "renesas,rcar-gen3-hscif" for R-Car Gen3 HSCIF compatible UART,
> +- "renesas,rzg-hscif" for RZ/G HSCIF compatible UART.
>  - "renesas,scif" for generic SCIF compatible UART.
>  - "renesas,scifa" for generic SCIFA compatible UART.
>  - "renesas,scifb" for generic SCIFB compatible UART.
> Index: tty/drivers/tty/serial/sh-sci.c
> ===
> --- tty.orig/drivers/tty/serial/sh-sci.c
> +++ tty/drivers/tty/serial/sh-sci.c
> @@ -2950,6 +2950,9 @@ static const struct of_device_id of_sci_
> }, {
> .compatible = "renesas,rcar-gen3-scif",
> .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +   }, {
> +   .compatible = "renesas,rzg-scif",
> +   .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> },
> /* Generic types */
> {

However, I wouldn't bother adding RZ/G family-specific DT bindings, as
RZ/G is a derivative of R-Car Gen2.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH RFC v2 10/12] DT: arm: shmobile: document SK-RZG1M board

[Geert Uytterhoeven]

On Fri, Sep 30, 2016 at 12:32 AM, Sergei Shtylyov
 wrote:
> Document the SK-RZG1M device tree bindings, listing it as a supported board.
>
> This allows to use checkpatch.pl to validate .dts files referring to the
> SK-RZG1M board.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] DT: irqchip: renesas-irqc: document R8A7743/5 support

[Geert Uytterhoeven]

On Thu, Sep 29, 2016 at 11:25 PM, Sergei Shtylyov
 wrote:
> Renesas  RZ/G SoC have the R-Car gen2 compatible IRQC interrupt controllers.
> Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings.
>
> Signed-off-by: Sergei Shtylyov 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Jon Hunter]

Hi PM posse!

On 23/09/16 15:27, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Fri, Sep 23, 2016 at 2:57 PM, Jon Hunter  wrote:
>> On 21/09/16 15:57, Geert Uytterhoeven wrote:
>>> On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter  wrote:
 On 21/09/16 09:53, Geert Uytterhoeven wrote:
> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter  wrote:
>> Some devices may require more than one PM domain to operate and this is
>> not currently by the PM domain framework. Furthermore, the current Linux
>> 'device' structure only allows devices to be associated with a single PM
>> domain and so cannot easily be associated with more than one. To allow
>> devices to be associated with more than one PM domain, if multiple
>> domains are defined for a given device (eg. via device-tree), then:
>> 1. Create a new PM domain for this device. The name of the new PM domain
>>created matches the device name for which it was created for.
>> 2. Register the new PM domain as a sub-domain for all PM domains
>>required by the device.
>> 3. Attach the device to the new PM domain.
>
> This looks a suboptimal to me: if you have n devices sharing the same PM
> domains, you would add n new subdomains?

 BTW, would this be the case today for some renesas devices or are you
 just pointing this out as something that could be optimised/improved?
>>>
>>> This is the case for all Renesas SoCs that have power areas: devices belong
>>> to both the PM domain for the power area, and to the PM domain for the clock
>>> domain.
>>
>> To quantify this a bit, for the Renesas case, how many of these
>> duplicated domains would there be if you were to use this approach as-is?
> 
> for i in $(git grep -l renesas, -- "*dts*") ; do echo --- $i ---; git
> grep -w power-domains $i | sort | uniq -c | sort -n;done
> 
> tells you how many (supported) devices are (currently) present in each
> PM domain.
> Most of these (all but devices in CPU/SCU power areas) are also part of a
> clock domain.
> The synthetic R8A779*_PD_ALWAYS_ON domains could be dropped again,
> as we could just refer to the CPG/MSSR node for the clock domain instead.
> 
> For older SH/R-Mobile SoCs with lots of hierarchical domains, that gives us,
> after removing the above:
> 
>   1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_a4mp>;
>   1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_d4>;
>   2 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_c5>;
>   3 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_a4r>;
>   6 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_a4s>;
>  15 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <_a3sp>;
> 
> R-Car Gen1/Gen2 have all devices in the "always on" PM domain, so they're
> not affected.
> 
> R-Car Gen3 again has devices in power areas, mostly for graphics related
> purposes:
> 
>  16 arch/arm64/boot/dts/renesas/r8a7795.dtsi:
>  power-domains = < R8A7795_PD_A3VP>;

Does anyone have any more inputs comments on this? Does it look complete
bonkers or should I forge ahead with this?

Cheers
Jon

-- 
nvpublic

Re: [PATCH] clocksource: sh_cmt: Document r8a779[34] SoC specific bindings

[Magnus Damm]

Hi Geert,

On Fri, Sep 30, 2016 at 4:20 PM, Geert Uytterhoeven
 wrote:
> Hi Magnus,
>
> On Fri, Sep 30, 2016 at 9:07 AM, Magnus Damm  wrote:
>> On Fri, Sep 23, 2016 at 6:03 PM, Simon Horman  wrote:
>>> On Fri, Sep 23, 2016 at 10:35:06AM +0200, Geert Uytterhoeven wrote:
 And these are planned to be removed again with Magnus'
 "devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings"
 (https://patchwork.kernel.org/patch/8579481/)?
>>>
>>> Sorry, that slipped my mind.
>>>
>>> Magnus, what is the status of that work?
>>
>> Banged my head against DT bindings too long, and I felt it never got
>> picked up so I gave up. =)
>>
>> It would make sense to update and resend, I do however wonder how to
>> improve our chances to get it merged?
>
> Looking in email history, the only comment you got on v4 was an accidental
> word duplicate. As you already had plenty of acks, resending with that
> fixed (and the code included again :-) should be enough.
>
> Note that I've been running that code since the first half of 2015 ;-)

Will fix up and resend. I recall that some more effort is needed to
clean up other parts of the bindings too, but that can be done
incrementally.

Cheers,

/ magnus

Re: [PATCH] clocksource: sh_cmt: Document r8a779[34] SoC specific bindings

[Geert Uytterhoeven]

Hi Magnus,

On Fri, Sep 30, 2016 at 9:07 AM, Magnus Damm  wrote:
> On Fri, Sep 23, 2016 at 6:03 PM, Simon Horman  wrote:
>> On Fri, Sep 23, 2016 at 10:35:06AM +0200, Geert Uytterhoeven wrote:
>>> And these are planned to be removed again with Magnus'
>>> "devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings"
>>> (https://patchwork.kernel.org/patch/8579481/)?
>>
>> Sorry, that slipped my mind.
>>
>> Magnus, what is the status of that work?
>
> Banged my head against DT bindings too long, and I felt it never got
> picked up so I gave up. =)
>
> It would make sense to update and resend, I do however wonder how to
> improve our chances to get it merged?

Looking in email history, the only comment you got on v4 was an accidental
word duplicate. As you already had plenty of acks, resending with that
fixed (and the code included again :-) should be enough.

Note that I've been running that code since the first half of 2015 ;-)

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/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode

[Magnus Damm]

Hi Geert,

On Fri, Sep 30, 2016 at 4:09 PM, Geert Uytterhoeven
 wrote:
> Hi Magnus,
>
> On Fri, Sep 30, 2016 at 9:04 AM, Magnus Damm  wrote:
>> On Tue, Sep 27, 2016 at 9:37 PM, Geert Uytterhoeven
>>  wrote:
>>> On Mon, Aug 22, 2016 at 4:44 PM, Geert Uytterhoeven
>>>  wrote:
 This patch series is an attempt to allow booting secondary CPU cores on
 R-Car Gen2 when hardware debug mode is enabled. In this mode, reset
 requests derived from power-shutoff to the AP-system CPU cores must be
 enabled before the AP-system cores first resume from power-shutoff. Else
 resume may fail, causing the system to hang during boot. Currently we
 avoid the hang by prohibiting booting secondary CPU cores when hardware
 debug mode is enabled.

 On all R-Car Gen2 SoCs, hardware debug mode is enabled by setting
 MD21=1.  On both Koelsch and Lager, this is done by setting mode switch
 SW8-4 to OFF.

 Unfortunately the hang is not easy to reproduce: I only saw it (on
 Koelsch) during real cold boot (power off during the night), and even
 then it's not guaranteed to trigger. Pressing the reset button
 afterwards recovers the system, and a subsequent boot will succeed
 (incl. secondary CPU core boot).

 This series configures the reset requests as documented in the R-Car
 Gen2 datasheet, and removes the check for MD21 during secondary CPU
 bringup.  It was inspired by CPU-specific patches in the BSP by
 Nakamura-san.

 This series has been boot-tested on r8a7791/koelsch (both debug mode and
 normal mode), on r8a7790/lager and r8a7793/gose (normal mode only), and
 on r8a7794/alt (normal mode UP only).
>>>
>>> Any comments?
>>> Any objection to applying this series?
>>>
>>> I've been running my Koelsch with MD21=1 since I posted this series,
>>> and it has been included in renesas-drivers since the beginning of 
>>> September.
>>>
>>> My main motivation to push this is that it removes two more users of
>>> rcar_gen2_read_mode_pins(). After this, the only remaining user is the
>>> clock driver, invoked from rcar_gen2_timer_init().
>>
>> I have no objections, but I'm curious if the series received enough
>> testing (with debug mode enabled) on earlier R-Car Gen2 platforms like
>> r8a7790/lager?
>
> Let's see what Hiep has to say, who tests Lager with both debug mode
> enabled and disabled...

Good idea! We probably want to know about ES version too.

Cheers,

/ magnus

Re: [PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode

[Geert Uytterhoeven]

Hi Magnus,

On Fri, Sep 30, 2016 at 9:04 AM, Magnus Damm  wrote:
> On Tue, Sep 27, 2016 at 9:37 PM, Geert Uytterhoeven
>  wrote:
>> On Mon, Aug 22, 2016 at 4:44 PM, Geert Uytterhoeven
>>  wrote:
>>> This patch series is an attempt to allow booting secondary CPU cores on
>>> R-Car Gen2 when hardware debug mode is enabled. In this mode, reset
>>> requests derived from power-shutoff to the AP-system CPU cores must be
>>> enabled before the AP-system cores first resume from power-shutoff. Else
>>> resume may fail, causing the system to hang during boot. Currently we
>>> avoid the hang by prohibiting booting secondary CPU cores when hardware
>>> debug mode is enabled.
>>>
>>> On all R-Car Gen2 SoCs, hardware debug mode is enabled by setting
>>> MD21=1.  On both Koelsch and Lager, this is done by setting mode switch
>>> SW8-4 to OFF.
>>>
>>> Unfortunately the hang is not easy to reproduce: I only saw it (on
>>> Koelsch) during real cold boot (power off during the night), and even
>>> then it's not guaranteed to trigger. Pressing the reset button
>>> afterwards recovers the system, and a subsequent boot will succeed
>>> (incl. secondary CPU core boot).
>>>
>>> This series configures the reset requests as documented in the R-Car
>>> Gen2 datasheet, and removes the check for MD21 during secondary CPU
>>> bringup.  It was inspired by CPU-specific patches in the BSP by
>>> Nakamura-san.
>>>
>>> This series has been boot-tested on r8a7791/koelsch (both debug mode and
>>> normal mode), on r8a7790/lager and r8a7793/gose (normal mode only), and
>>> on r8a7794/alt (normal mode UP only).
>>
>> Any comments?
>> Any objection to applying this series?
>>
>> I've been running my Koelsch with MD21=1 since I posted this series,
>> and it has been included in renesas-drivers since the beginning of September.
>>
>> My main motivation to push this is that it removes two more users of
>> rcar_gen2_read_mode_pins(). After this, the only remaining user is the
>> clock driver, invoked from rcar_gen2_timer_init().
>
> I have no objections, but I'm curious if the series received enough
> testing (with debug mode enabled) on earlier R-Car Gen2 platforms like
> r8a7790/lager?

Let's see what Hiep has to say, who tests Lager with both debug mode
enabled and disabled...

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] clocksource: sh_cmt: Document r8a779[34] SoC specific bindings

[Magnus Damm]

On Fri, Sep 23, 2016 at 6:03 PM, Simon Horman  wrote:
> On Fri, Sep 23, 2016 at 10:35:06AM +0200, Geert Uytterhoeven wrote:
>> Hi Simon, Magnus,
>>
>> On Fri, Sep 23, 2016 at 10:20 AM, Simon Horman
>>  wrote:
>> > This documents the SoC specific binding for the r8a779[34] SoCs.
>> > This is in keeping with the documentation of other R-Car Gen2 SoCs.
>> >
>> > Signed-off-by: Simon Horman 
>> > ---
>> >  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 9 +++--
>> >  1 file changed, 7 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
>> > b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> > index 1a05c1b243c1..566fb599ea39 100644
>> > --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> > +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> > @@ -48,10 +48,15 @@ Required Properties:
>> > (CMT[01])
>> >  - "renesas,cmt-48-r8a7791" for the r8a7791 48-bit CMT
>> > (CMT[01])
>> > +- "renesas,cmt-48-r8a7793" for the r8a7793 48-bit CMT
>> > +   (CMT[01])
>> > +- "renesas,cmt-48-r8a7794" for the r8a7793 48-bit CMT
>> > +   (CMT[01])
>> >  - "renesas,cmt-48-gen2" for all second generation 48-bit CMT
>> > -   (CMT[01] on r8a73a4, r8a7790 and r8a7791)
>> > +   (CMT[01] on r8a73a4, r8a7790, r8a7791, r8a7793, r8a7794)
>> > This is a fallback for the renesas,cmt-48-r8a73a4,
>> > -   renesas,cmt-48-r8a7790 and renesas,cmt-48-r8a7791 entries.
>> > +   renesas,cmt-48-r8a7790, renesas,cmt-48-r8a7791,
>> > +   renesas,cmt-48-r8a7793 and renesas,cmt-48-r8a7794 entries.
>> >
>> >- reg: base address and length of the registers block for the timer 
>> > module.
>> >- interrupts: interrupt-specifier for the timer, one per channel.
>>
>> And these are planned to be removed again with Magnus'
>> "devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings"
>> (https://patchwork.kernel.org/patch/8579481/)?
>
> Sorry, that slipped my mind.
>
> Magnus, what is the status of that work?

Banged my head against DT bindings too long, and I felt it never got
picked up so I gave up. =)

It would make sense to update and resend, I do however wonder how to
improve our chances to get it merged?

Cheers,

/ magnus

Re: [PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode

[Magnus Damm]

Hi Geert,

On Tue, Sep 27, 2016 at 9:37 PM, Geert Uytterhoeven
 wrote:
> Hi Simon, Magnus,
>
> On Mon, Aug 22, 2016 at 4:44 PM, Geert Uytterhoeven
>  wrote:
>> This patch series is an attempt to allow booting secondary CPU cores on
>> R-Car Gen2 when hardware debug mode is enabled. In this mode, reset
>> requests derived from power-shutoff to the AP-system CPU cores must be
>> enabled before the AP-system cores first resume from power-shutoff. Else
>> resume may fail, causing the system to hang during boot. Currently we
>> avoid the hang by prohibiting booting secondary CPU cores when hardware
>> debug mode is enabled.
>>
>> On all R-Car Gen2 SoCs, hardware debug mode is enabled by setting
>> MD21=1.  On both Koelsch and Lager, this is done by setting mode switch
>> SW8-4 to OFF.
>>
>> Unfortunately the hang is not easy to reproduce: I only saw it (on
>> Koelsch) during real cold boot (power off during the night), and even
>> then it's not guaranteed to trigger. Pressing the reset button
>> afterwards recovers the system, and a subsequent boot will succeed
>> (incl. secondary CPU core boot).
>>
>> This series configures the reset requests as documented in the R-Car
>> Gen2 datasheet, and removes the check for MD21 during secondary CPU
>> bringup.  It was inspired by CPU-specific patches in the BSP by
>> Nakamura-san.
>>
>> This series has been boot-tested on r8a7791/koelsch (both debug mode and
>> normal mode), on r8a7790/lager and r8a7793/gose (normal mode only), and
>> on r8a7794/alt (normal mode UP only).
>
> Any comments?
> Any objection to applying this series?
>
> I've been running my Koelsch with MD21=1 since I posted this series,
> and it has been included in renesas-drivers since the beginning of September.
>
> My main motivation to push this is that it removes two more users of
> rcar_gen2_read_mode_pins(). After this, the only remaining user is the
> clock driver, invoked from rcar_gen2_timer_init().

I have no objections, but I'm curious if the series received enough
testing (with debug mode enabled) on earlier R-Car Gen2 platforms like
r8a7790/lager?

Cheers,

/ magnus

Re: [PATCH] sh-sci: add R8A7743/5 support

[Simon Horman]

On Fri, Sep 30, 2016 at 12:37:13AM +0300, Sergei Shtylyov wrote:
> Renesas  RZ/G SoC also have the SCIF, SCIFA, SCIFB, and HSCIF ports.
> Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings along with
> the RZ/G family bindings.  The driver itself also needs to recognize
> the latter binding for the SCIF ports, so teach it...
> 
> Signed-off-by: Sergei Shtylyov 

Acked-by: Simon Horman