Re: [PATCH v4 2/5] dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock

[Rob Herring]

On Fri,  7 Dec 2018 11:27:43 +, Biju Das wrote:
> The pcf85263 RTC is compatible with the pcf85363 RTC.
> 
> The difference between the pcf85263 and pcf85363 RTC is that the latter has
> 64 bytes more RAM. This renders them incompatible from a DT point of view.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Geert Uytterhoeven 
> ---
> V1-->V2
>   * Incorporated Simon's review comment.
> V2-->V3
>   * No Change.
> V3-->V4
>   * No Change.
> ---
>  Documentation/devicetree/bindings/rtc/pcf85363.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH 1/2] dt-bindings: can: rcar_canfd: document r8a77965 support

[Rob Herring]

On Sun, Nov 18, 2018 at 06:32:00PM +0100, Marek Vasut wrote:
> Document the support for rcar_canfd on R8A77965 SoC devices.
> 
> Signed-off-by: Marek Vasut 
> Cc: Eugeniu Rosca 
> Cc: Geert Uytterhoeven 
> Cc: Marc Kleine-Budde 
> Cc: Rob Herring 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  .../devicetree/bindings/net/can/rcar_canfd.txt  | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt 
> b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
> index ac71daa46195..4720e916fbdd 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
> @@ -6,6 +6,7 @@ Required properties:
>- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
>- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
>- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller.
> +  - "renesas,r8a77965-canfd" for R8A77965 (R-Car M3-N) compatible controller.
>- "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller.
>- "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller.
>  
> @@ -26,12 +27,12 @@ The name of the child nodes are "channel0" and "channel1" 
> respectively. Each
>  child node supports the "status" property only, which is used to
>  enable/disable the respective channel.
>  
> -Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd"
> -compatible:
> -In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by 
> both
> -CAN and CAN FD controller at the same time. It needs to be scaled to maximum
> -frequency if any of these controllers use it. This is done using the below
> -properties:
> +Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and
> +"renesas,r8a77965-canfd" compatible:
> +In R8A7795, R8A7796 and R8A77965 SoCs, canfd clock is a div6 clock and can

Do we have to list the SoCs twice so that the paragraph has to be 
reformatted every time? Just the compatibles above should be enough.

> +be used by both CAN and CAN FD controller at the same time. It needs to be
> +scaled to maximum frequency if any of these controllers use it. This is done
> +using the below properties:
>  
>  - assigned-clocks: phandle of canfd clock.
>  - assigned-clock-rates: maximum frequency of this clock.
> -- 
> 2.18.0
> 

Re: [PATCH] dt-bindings: can: rcar_can: document r8a77990 support

[Rob Herring]

On Sun, 18 Nov 2018 18:30:56 +0100, Marek Vasut wrote:
> Document the support for rcar_can on R8A77990 SoC devices.
> Add R8A77990 to the list of SoCs which require the "assigned-clocks"
> and "assigned-clock-rates" properties.
> 
> Signed-off-by: Marek Vasut 
> Cc: Eugeniu Rosca 
> Cc: Geert Uytterhoeven 
> Cc: Marc Kleine-Budde 
> Cc: Rob Herring 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/net/can/rcar_can.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT support

[Rob Herring]

On Fri, 26 Oct 2018 09:36:13 +0100, Biju Das wrote:
> Document SoC specific compatible strings for r8a77470. No driver change
> is needed as the fallback strings will activate the right code.
> 
> Signed-off-by: Biju Das 
> ---
> This patch is tested against linux-next
> ---
>  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: watchdog: renesas-wdt: Document r8a77470 support

[Rob Herring]

On Fri, 26 Oct 2018 09:55:53 +0100, Biju Das wrote:
> RZ/G1C (R8A77470) watchdog implementation is compatible with R-Car
> Gen2, therefore add relevant documentation.
> 
> Signed-off-by: Biju Das 
> ---
> This patch is tested against linux-next
> ---
>  Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a7796 CMT support

[Rob Herring]

On Tue, Nov 06, 2018 at 09:54:52AM -0600, Rob Herring wrote:
> On Fri, Oct 26, 2018 at 09:01:44AM +0100, Biju Das wrote:
> > Document SoC specific bindings for R-Car M3-W (r8a7796) SoC.
> > 
> > Signed-off-by: Biju Das 
> > ---
> > This patch is tested against linu-next
> > ---
> >  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> Applied.

Nevermind. I see there's another timer patch. Daniel should apply.

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a7796 CMT support

[Rob Herring]

On Fri, Oct 26, 2018 at 09:01:44AM +0100, Biju Das wrote:
> Document SoC specific bindings for R-Car M3-W (r8a7796) SoC.
> 
> Signed-off-by: Biju Das 
> ---
> This patch is tested against linu-next
> ---
>  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++
>  1 file changed, 2 insertions(+)

Applied.

Re: [PATCH 1/2] dt-bindings: dmaengine: usb-dmac: Add binding for r8a77470

[Rob Herring]

On Thu, 25 Oct 2018 15:53:37 +0100, Biju Das wrote:
> This patch adds usb high-speed dmac binding for r8a77470 (RZ/G1C) SoC.
> 
> Signed-off-by: Biju Das 
> ---
> This patch tested against linux-next.
> ---
>  Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH 1/7] dt-bindings: phy: rcar-gen2: Add r8a77470 support

[Rob Herring]

On Thu, Oct 25, 2018 at 02:56:53PM +0100, Biju Das wrote:
> Add USB PHY support for r8a77470 SoC. Renesas RZ/G1C (R8A77470)
> USB PHY is similar to the R-Car Gen2 family, but has the below
> features compared to other RZ/G1 and R-Car Gen2/3 SoCs
> 
> It has a shared pll reset for usbphy0/usbphy1 and this register
> reside in usbphy0 block
> 
> Each USB2.0 host needs to deassert the pll reset of usbphy0 block.
> 
> Signed-off-by: Biju Das 
> ---
>  .../devicetree/bindings/phy/rcar-gen2-phy.txt  | 64 
> +++---
>  1 file changed, 55 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt 
> b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> index eeb9e18..0a59971 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> @@ -6,6 +6,7 @@ This file provides information on what the device node for 
> the R-Car generation
>  Required properties:
>  - compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 
> SoC.
> "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC.
> +   "renesas,usb-phy-r8a77470" if the device is a part of R8A77470 
> SoC.
> "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
> "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
> "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC.
> @@ -23,13 +24,23 @@ Required properties:
>  - clocks: clock phandle and specifier pair.
>  - clock-names: string, clock input name, must be "usbhs".
>  
> +Optional properties (r8a77470 SoC Only):
> +To use a USB channel as USB 2.0 Host, the device tree node should set below
> +optional properties. This is because USB2.0 Host needs to deassert pll reset,
> +apart from initializing interrupt enable, OVC detection timer and suspend/
> +resume timer register.
> +
> +- reg: offset and length of the partial USB2.0 Host register block.

USB host registers in the phy node? And somewhere else too? Don't create 
overlapping regions in DT. That's not a reflection of the h/w and also 
is an error in the kernel's resource handling code (which we work-around 
in the DT code).

> +- clocks: clock phandle and specifier pair for usb2.0 host.
> +- clk-names: string, clock input name, must be "usb20_host".

Same with clocks.

> +
>  The USB PHY device tree node should have the subnodes corresponding to the 
> USB
>  channels. These subnodes must contain the following properties:
>  - reg: the USB controller selector; see the table below for the values.
>  - #phy-cells: see phy-bindings.txt in the same directory, must be <1>.
>  
>  The phandle's argument in the PHY specifier is the USB controller selector 
> for
> -the USB channel; see the selector meanings below:
> +the USB channel other than r8a77470 SoC; see the selector meanings below:
>  
>  +---+---+---+
>  |\ Selector |   |   |
> @@ -40,22 +51,57 @@ the USB channel; see the selector meanings below:
>  | 2 | PCI EHCI/OHCI | xHCI  |
>  +---+---+---+
>  
> +For r8a77470 SoC see the selector meaning below:
> +
> ++---+---+---+
> +|\ Selector |   |   |
> ++ - +   0   |   1   |
> +| Channel  \|   |   |
> ++---+---+---+
> +| 0 | EHCI/OHCI | HS-USB|
> ++---+---+---+
> +
>  Example (Lager board):
>  
> - usb-phy@e6590100 {
> - compatible = "renesas,usb-phy-r8a7790", 
> "renesas,rcar-gen2-usb-phy";
> + usbphy: usb-phy@e6590100 {
> + compatible = "renesas,usb-phy-r8a7790",
> +  "renesas,rcar-gen2-usb-phy";

This change doesn't seem necessary.

>   reg = <0 0xe6590100 0 0x100>;
>   #address-cells = <1>;
>   #size-cells = <0>;
> - clocks = <_clks R8A7790_CLK_HSUSB>;
> + clocks = < CPG_MOD 704>;
>   clock-names = "usbhs";
> + power-domains = < R8A7790_PD_ALWAYS_ON>;
> + resets = < 704>;
> + status = "disabled";

Don't show status in examples.
>  
> - usb-channel@0 {
> - reg = <0>;
> - #phy-cells = <1>;
> + usb0: usb-channel@0 {
> + reg = <0>;
> + #phy-cells = <1>;
> + };
> + usb2: usb-channel@2 {
> + reg = <2>;
> + #phy-cells = <1>;
>   };
> - usb-channel@2 {
> - reg = <2>;
> + };
> +
> +Example (iWave RZ/G1C SBC):
> +
> + usbphy0: usb-phy0@e6590100 {
> + compatible = "renesas,usb-phy-r8a77470",
> +  

Re: [PATCH/RFT 1/2] dt-bindings: thermal: rcar-thermal: add R8A77990 support

[Rob Herring]

On Mon, 15 Oct 2018 23:11:58 +0900, Yoshihiro Kaneko wrote:
> Document the R-Car E3 (R8A77990) SoC bindings.
> 
> Signed-off-by: Yoshihiro Kaneko 
> ---
>  Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH v2 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO

[Rob Herring]

On Fri, 19 Oct 2018 08:40:30 -0500, Chris Brandt wrote:
> Add device tree binding documentation and header file for Renesas R7S9210
> (RZ/A2) SoCs.
> 
> Signed-off-by: Chris Brandt 
> ---
> v2:
>  * Moved gpio-controller to required
>  * Wrote a better description of what the sub-nodes are for
>  * Added pinmux property description
>  * Changed macro RZA2_PIN_ID to RZA2_PIN
> ---
>  .../bindings/pinctrl/renesas,rza2-pinctrl.txt  | 88 
> ++
>  include/dt-bindings/pinctrl/r7s9210-pinctrl.h  | 47 
>  2 files changed, 135 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
>  create mode 100644 include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> 

Reviewed-by: Rob Herring 

Re: [PATCH 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO

[Rob Herring]

On Tue, Oct 16, 2018 at 7:53 PM Chris Brandt  wrote:
>
> On Tuesday, October 16, 2018, Rob Herring wrote:
> > > +Optional properties:
> > > +  - gpio-controller
> > > +Include this in order to enable GPIO functionality. When included,
> > both
> > > +gpio_cells and gpio_ranges are then required.
> > > +  - #gpio-cells
> > > +Must be 2
> > > +  - gpio-ranges
> > > +Expresses the total number GPIO ports/pins in this SoC
> >
> > Are these really optional? I guess in theory a board could use no GPIOs,
> > but that seems unlikely.
>
> They are 'optional' in the sense that if you don't include them in the
> DT, the driver still loads (just without any GPIO, but pinctrl still
> works). So, I was just documenting that fact.
>
> If you think I should just move these to required, let me know an I'm
> fine with that. (as in, DT documents HW, not software)

I do. There's no implicit requirement that the s/w has to support it.

> > > +Sub-nodes
> > > +-
> > > +
> > > +The child nodes of the pin controller node describe a pin multiplexing
> > > +function or a GPIO controller alternatively.
> >
> > But the parent is already a GPIO controller. This needs to be fully
> > defined.
>
> Now that I read this, I think my wording was off (I was borrowing text
> for other files).
>
> How about this:
>
> The child nodes of the pin controller designate pins to be used for
> specific peripheral functions or as GPIO.

Sure.

Re: [PATCH 1/2] dt-bindings: thermal: rcar-gen3-thermal: document R8A77980 bindings

[Rob Herring]

On Tue, 9 Oct 2018 22:10:14 +0300, Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the Renesas R-Car gen3 thermal
> bindings.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO

[Rob Herring]

On Fri, Oct 05, 2018 at 10:09:51AM -0500, Chris Brandt wrote:
> Add device tree binding documentation and header file for Renesas R7S9210
> (RZ/A2) SoCs.
> 
> Signed-off-by: Chris Brandt 
> ---
>  .../bindings/pinctrl/renesas,rza2-pinctrl.txt  | 76 
> ++
>  include/dt-bindings/pinctrl/r7s9210-pinctrl.h  | 47 +
>  2 files changed, 123 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
>  create mode 100644 include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> 
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> new file mode 100644
> index ..5f338054f493
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> @@ -0,0 +1,76 @@
> +Renesas RZ/A2 combined Pin and GPIO controller
> +
> +The Renesas SoCs of the RZ/A2 series feature a combined Pin and GPIO 
> controller.
> +Pin multiplexing and GPIO configuration is performed on a per-pin basis.
> +Each port features up to 8 pins, each of them configurable for GPIO
> +function (port mode) or in alternate function mode.
> +Up to 8 different alternate function modes exist for each single pin.
> +
> +Pin controller node
> +---
> +
> +Required properties:
> +  - compatible: should be:
> +- "renesas,r7s9210-pinctrl": for RZ/A2M
> +
> +  - reg
> +address base and length of the memory area where the pin controller
> +hardware is mapped to.
> +
> +Optional properties:
> +  - gpio-controller
> +Include this in order to enable GPIO functionality. When included, both
> +gpio_cells and gpio_ranges are then required.
> +  - #gpio-cells
> +Must be 2
> +  - gpio-ranges
> +Expresses the total number GPIO ports/pins in this SoC

Are these really optional? I guess in theory a board could use no GPIOs, 
but that seems unlikely. 

> +
> +
> +Example: Pin controller node for RZ/A2M SoC (r7s9210)
> +
> + pinctrl: pin-controller@fcffe000 {
> + compatible = "renesas,r7s9210-pinctrl";
> + reg = <0xfcffe000 0x9D1>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = < 0 0 176>;
> + };
> +
> +Sub-nodes
> +-
> +
> +The child nodes of the pin controller node describe a pin multiplexing
> +function or a GPIO controller alternatively.

But the parent is already a GPIO controller. This needs to be fully 
defined.

> +
> +- Pin multiplexing sub-nodes:
> +  A pin multiplexing sub-node describes how to configure a set of
> +  (or a single) pin in some desired alternate function mode.
> +  The values for the pinmux properties are a combination of port name, pin
> +  number and the desired function index. Use the RZA2_PINMUX macro located
> +  in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily define these.
> +  For assigning GPIO pins, use the macro RZA2_PIN_ID also in 
> r7s9210-pinctrl.h
> +  to express the desired port pin.
> +
> +  Example: Board specific pins configuration
> +
> +  {
> + /* Serial Console */
> + scif4_pins: serial4 {
> + pinmux = ,   /* TxD4 */
> +  ;   /* RxD4 */
> + };
> + };
> +
> +  Example: Assigning a GPIO:
> +
> + leds {
> + status = "okay";
> + compatible = "gpio-leds";
> +
> + led0 {
> + /* P6_0 */
> + gpios = < RZA2_PIN_ID(P6, 0) GPIO_ACTIVE_HIGH>;
> + };
> + };

Re: [PATCH 1/2] dt-bindings: thermal: rcar-thermal: document R8A77970 bindings

[Rob Herring]

On Fri, 5 Oct 2018 00:01:38 +0300, Sergei Shtylyov wrote:
> Document  the R-Car V3M (R8A77970) SoC in the Renesas R-Car gen2 thermal
> bindings. The hardware is the same as  in the R-Car D3 (R8A77995) plus an
> extra status register.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  Documentation/devicetree/bindings/thermal/rcar-thermal.txt |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: arm: Fix RZ/G2E part number

[Rob Herring]

On Thu,  4 Oct 2018 09:53:10 +0100, Fabrizio Castro wrote:
> Fix RZ/G2E part number from its description.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: pwm: renesas: pwm-rcar: document R8A779{7|8}0 bindings

[Rob Herring]

On Fri, Oct 12, 2018 at 01:21:14PM +0200, Thierry Reding wrote:
> On Mon, Oct 01, 2018 at 10:57:39PM +0300, Sergei Shtylyov wrote:
> > Document the R-Car V3{M|H} (R8A779{7|8}0) SoC in the  Renesas R-Car PWM
> > bindings. R8A77970's hardware is a generic R-Car gen3 PWM, while R8A77980
> > has an extra error injection register...
> > 
> > Signed-off-by: Sergei Shtylyov 
> > 
> > ---
> > This patch is against the 'for-next' branch of Thierry Reding's 
> > 'linux-pwm.git'
> > repo.
> > 
> >  Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt |2 ++
> >  1 file changed, 2 insertions(+)
> 
> Applied, thanks.

Some reason your tree isn't updated for linux-next?

Rob

Re: [PATCH] dt-bindings: timer: ostm: Add R7S9210 support

[Rob Herring]

On Thu, Sep 27, 2018 at 09:12:58AM -0500, Chris Brandt wrote:
> The R7S9210 belongs to the RZ/A2 SoC series
> 
> Signed-off-by: Chris Brandt 
> ---
> FYI: No driver changes were needed
> ---
>  Documentation/devicetree/bindings/timer/renesas,ostm.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied.

Re: [PATCH] dt-bindings: phy: rcar-gen2: Add r8a7744 support

[Rob Herring]

On Thu, Sep 27, 2018 at 7:30 AM Biju Das  wrote:
>
> Add USB PHY support for r8a7744 SoC. Renesas RZ/G1N (R8A7744)
> USB PHY is identical to the R-Car Gen2 family.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 
> ---
> This patch is tested against linux-next next-20180927
> ---
>  Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied.

Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a7744 CMT support

[Rob Herring]

On Tue, Sep 25, 2018 at 06:18:16PM +0100, Biju Das wrote:
> Document SoC specific compatible strings for r8a7744. No driver change
> is needed as the fallback strings will activate the right code.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 
> ---
>  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++
>  1 file changed, 2 insertions(+)

Applied.

Re: [PATCH] dt-bindings: watchdog: renesas-wdt: Document r8a7744 support

[Rob Herring]

On Tue, Sep 25, 2018 at 06:07:21PM +0100, Biju Das wrote:
> RZ/G1N (R8A7744) watchdog implementation is compatible with R-Car
> Gen2, therefore add relevant documentation.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 
> ---
>  Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied.

Rob

Re: [PATCH] dt-bindings: thermal: rcar: Add device tree support for r8a7744

[Rob Herring]

On Tue, Sep 25, 2018 at 06:01:04PM +0100, Biju Das wrote:
> Add thermal sensor support for r8a7744 SoC. The Renesas RZ/G1N
> (r8a7744) thermal sensor module is identical to the R-Car Gen2 family.
> 
> No driver change is needed due to the fallback compatible value
> "renesas,rcar-gen2-thermal".
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 
> ---
>  Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied.

Rob

Re: [PATCH v3 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

[Rob Herring]

On Mon,  8 Oct 2018 09:51:47 +0100, Fabrizio Castro wrote:
> The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces,
> SDHI0 and SDHI2 are compatible with R-Car Gen2 SDHIs, and
> SDHI1 is compatible with R-Car Gen3 SDHIs, as it comes with an
> internal DMAC, therefore SDHI1 is fully compatible with driver
> renesas_sdhi_internal_dmac driver. As a result, the compatible
> strings for the R8A77470 SDHI interfaces are a little bit special.
> Document SDHI support for the RZ/G1C SoC.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> Reviewed-by: Geert Uytterhoeven 
> 
> ---
> v2->v3:
> * Incorporated comments from Geert
> 
> v1->v2:
> * Added "renesas,sdhi-mmc-r8a77470"
> * Using generic/fallback compatibilty only for SDHI[02]
> * Reworked changelog
> ---
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH v4 3/3] dt-bindings: mmc: tmio_mmc: Document Renesas R7S9210

[Rob Herring]

On Fri, 12 Oct 2018 07:29:24 -0500, Chris Brandt wrote:
> Document support for the RZ/A2 (R7S9210) SoC.
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v2:
>  * Documented that R7S9210 has 2 clocks
> ---
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH v6 1/3] dt-bindings: pinctrl: renesas,rzn1-pinctrl: documentation

[Rob Herring]

On Thu, Sep 27, 2018 at 05:15:54PM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 27, 2018 at 3:59 PM Phil Edworthy  
> wrote:
> > The Renesas RZ/N1 device family PINCTRL node description.
> >
> > Based on a patch originally written by Michel Pollet at Renesas.
> >
> > Signed-off-by: Phil Edworthy 
> > Reviewed-by: Jacopo Mondi 
> > ---
> > v6:
> >  - Instead of combining the pin nr and func into a single element, use
> >a pair of 8-bit elements.
> 
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt
> 
> > +- Pin multiplexing sub-nodes:
> > +  A pin multiplexing sub-node describes how to configure a set of
> > +  (or a single) pin in some desired alternate function mode.
> > +  A single sub-node may define several pin configurations.
> > +  Please refer to pinctrl-bindings.txt to get to know more on generic
> > +  pin properties usage.
> > +
> > +  The allowed generic formats for a pin multiplexing sub-node are the
> > +  following ones:
> > +
> > +  node-1 {
> > +  pinmux = /bits/ 8 , , ... ;
> > +  GENERIC_PINCONFIG;
> > +  };
> 
> and
> 
> > +  Example:
> > +  A serial communication interface with a TX output pin and an RX input 
> > pin.
> > +
> > +   {
> > +   pins_uart0: pins_uart0 {
> > +   pinmux = /bits/ 8 <
> > +   103 RZN1_FUNC_UART0_I   /* UART0_TXD */
> > +   104 RZN1_FUNC_UART0_I   /* UART0_RXD */
> > +   >;
> > +   };
> > +  };
> 
> So the above is in response to Rob's comment on v4:
> 
> | > +#define RZN1_MUX(_gpio, _func) \
> | > +   (((RZN1_FUNC_##_func) << 8) | (_gpio))
> |
> | I'm not a fan of token pasting and it also goes against kernel style.
> | If every other Renesas platform is doing this, then fine. Otherwise,
> | you can express it in pretty much the same (source) space:
> |
> | pinmux = ;
> |
> | Yes, this is 2 cells instead of 1, but if you care about space, you
> | can use 8 or 16 bit size.
> 
> I'm not so much impressed by the "/bits/ 8" part.
> No other pinctrl bindings uses this.
> We do have RZA1_PINMUX() and STM32_PINMUX() macros.

Yes, but those aren't doing token pasting which was my complaint here.

> Rob: Is this really what you intended?

Do whatever is most consistant. If you want a macro to shift fields, 
then fine.

Rob

Re: [PATCH v5 2/2] dt-bindings: watchdog: renesas-wdt: Add support for R7S9210

[Rob Herring]

On Mon, Sep 24, 2018 at 08:58:16AM -0500, Chris Brandt wrote:
> Document support for RZ/A2
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Guenter Roeck 
> ---
> v2:
>  * Added Reviewed-by
> ---
>  Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
>  1 file changed, 1 insertion(+)

I gave Reviewed-by on v3. Please add acks/reviewed-bys when posting new 
versions.

Rob

Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Rob Herring]

On Mon, Sep 10, 2018 at 12:20 PM Chris Brandt  wrote:
>
> On Monday, September 10, 2018, Rob Herring wrote:
> > > The current OSTM driver uses TIMER_OF_DECLARE and that basically means
> > > it will never work with my new SoC.
> > >
> > > For now, can I change the driver to register a standard platform driver
> > > in subsys_initcall like the other Renesas timer drivers?
> >
> > I'm confused how this can even work as an initcall. The whole reason
> > *_OF_DECLARE exists is for things that have to be setup before
> > initcalls.
>
> I wrote a long explanation of the issue, but the summary is:
>
> The timer (which is currently using TIMER_OF_DECLARE) can't start up
> until the clocks are set up because of_clk_get fails().
>
> But, the clock driver is a platform driver that is not started until
> subsys_initcall.
>
> So, unless you have a clock driver with CLK_OF_DECLARE, you can't use
> a timer driver with a TIMER_OF_DECLARE driver.
>
> And, there is no such thing as a deferred probe for timer drivers
> declared with IMER_OF_DECLARE.

Yes, I read the thread and understand all of this part.

Well before we get to initcalls, the kernel calls the arch specific
time_init() which (on ARM) calls of_clk_init (for all the reasons
above) and then timer_probe(). When timer_probe returns, it is
expected that you have setup a clocksource and clockevent. If you
haven't, then at some point before we get to initcalls we should hang
because we're not getting any timer interrupts and time is not
advancing. At least that's how it used to be and maybe something has
changed (It's been a while since I've looked at this area). Maybe you
just get lucky and it works as long as no thread blocks (e.g. on a
msleep). If things changed and you can setup a timer in an initcall,
then why are folks still trying to do things like early platform
drivers. Regular drivers would work and we should be able to
completely remove CLK_OF_DECLARE and TIMER_OF_DECLARE.

Rob

Re: [PATCH v3 2/2] dt-bindings: watchdog: renesas-wdt: Add support for R7S9210

[Rob Herring]

On Thu,  6 Sep 2018 20:22:43 -0500, Chris Brandt wrote:
> Document support for RZ/A2
> 
> Signed-off-by: Chris Brandt 
> ---
>  Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH v4] clk: renesas: cpg-mssr: Add R7S9210 support

[Rob Herring]

On Fri, Sep 07, 2018 at 11:58:49AM -0500, Chris Brandt wrote:
> Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> Standby.
> 
> The Module Standby HW in the RZ/A series is very close to R-Car HW, except
> for how the registers are laid out.
> The MSTP registers are only 8-bits wide, there is no status registers
> (MSTPSR), and the register offsets are a little different. Since the RZ/A
> hardware manuals refer to these registers as the Standby Control Registers,
> we'll use that name to distinguish the RZ/A type from the R-Car type.
> 
> Signed-off-by: Chris Brandt 
> ---
> v4:
>  * Preserved sort order of SoC listings
>  * Removed R7S9210_CLK_PLL from dt-binding since it's an internal clock
>  * ratio_tab is now a struct making it look a little nicer
>  * Removed CLK_I,...CLK_P0 because they are already defined in dt-bindings
>  * Sorted mod_clks by ascending MSTP number
>  * Removed cast from clk_get_rate(parent)
>  * Corrected register index of stbcr[1]
>  * Don't use MOD_CLK_PACK_10 for non priv->stbyctrl devices (bug fix)
> v3:
>  * Use actual register bit names and numbers from manual for both DT and
>tables ("36" instead of "306")
>  * Do not register reset controller for stbyctrl (RZ/A) SoCs
>  * Changed SPDX from "GPL-2.0+" to "GPL-2.0"
> v2:
>  * num_hw_mod_clks was wrong
>  * added ethernet clocks
> ---
>  .../devicetree/bindings/clock/renesas,cpg-mssr.txt |   5 +-
>  drivers/clk/renesas/Kconfig|   5 +
>  drivers/clk/renesas/Makefile   |   1 +
>  drivers/clk/renesas/r7s9210-cpg-mssr.c | 189 
> +
>  drivers/clk/renesas/renesas-cpg-mssr.c |  81 +++--
>  drivers/clk/renesas/renesas-cpg-mssr.h |  13 ++
>  include/dt-bindings/clock/r7s9210-cpg-mssr.h   |  20 +++

For DT bits,

Acked-by: Rob Herring 

>  7 files changed, 300 insertions(+), 14 deletions(-)
>  create mode 100644 drivers/clk/renesas/r7s9210-cpg-mssr.c
>  create mode 100644 include/dt-bindings/clock/r7s9210-cpg-mssr.h

Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Rob Herring]

On Fri, Sep 7, 2018 at 10:16 AM Chris Brandt  wrote:
>
> On Thursday, August 30, 2018, Daniel Lezcano wrote:
> > > AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE.
> > > IMHO it would be pointless, as it would be much easier to just switch to
> > real
> > > platform drivers.
> >
> > May be, may be not.
> >
> > From your point of view, the change is simple because it touches only a
> > single driver.
> >
> > From my point of view, the change implies a split in the approach while
> > I'm trying to unify the drivers little by little and there are hundred
> > of them.
> >
> > It is not the first time we face this situation and Bartosz Golaszewski
> > has a similar problem [1].
> >
> > We have all the frameworks we need to solve this properly but I would
> > like something we can propagate to all drivers (OF and !OF) so we end up
> > with unified code.
> >
> > It is time we clearly state the dependency issues and we find a proper
> > way to solve it.
>
>
> On Thursday, August 30, 2018, Bartosz Golaszewski wrote:
> > This was my latest proposal for early platform drivers:
> >
> > https://lkml.org/lkml/2018/5/11/488
> >
> > I still intend on continuing this work, I just don't have the time right
> > now.
>
> Daniel,
>
> So what is your final thought on this?
>
> The current OSTM driver uses TIMER_OF_DECLARE and that basically means
> it will never work with my new SoC.
>
> For now, can I change the driver to register a standard platform driver
> in subsys_initcall like the other Renesas timer drivers?

I'm confused how this can even work as an initcall. The whole reason
*_OF_DECLARE exists is for things that have to be setup before
initcalls.

Rob

Re: [PATCH v2] clk: renesas: cpg-mssr: Add R7S9210 support

[Rob Herring]

On Thu, Aug 30, 2018 at 3:05 AM Geert Uytterhoeven  wrote:
>
> Hi Rob,
>
> On Wed, Aug 29, 2018 at 2:52 AM Rob Herring  wrote:
> > On Mon, Aug 27, 2018 at 11:21:39AM -0500, Chris Brandt wrote:
> > > Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> > > Standby.
> > >
> > > The Module Standby HW in the RZ/A series is very close to R-Car HW, except
> > > for how the registers are laid out.
> > > The MSTP registers are only 8-bits wide, there is no status registers
> > > (MSTPST), and the register offsets are a little different. Since the RZ/A
> > > hardware manuals refer to these registers as the Standby Control 
> > > Registers,
> > > we'll use that name to distinguish the RZ/A type for the R-Car type.
> > >
> > > Signed-off-by: Chris Brandt 
> > > ---
> >
> > > +++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
> > > @@ -0,0 +1,192 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> >
> >
> > > +++ b/include/dt-bindings/clock/r7s9210-cpg-mssr.h
> > > @@ -0,0 +1,21 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+
> >
> > The proper identifier is GPL-2.0-or-later
>
> Documentation/process/license-rules.rst disagrees.

Indeed, but: https://spdx.org/licenses/GPL-2.0+.html

I think this changed about the time the kernel adopted SPDX. I guess
it is fine as-is until we change the documentation.

Rob

Re: [PATCH v2] clk: renesas: cpg-mssr: Add R7S9210 support

[Rob Herring]

On Mon, Aug 27, 2018 at 11:21:39AM -0500, Chris Brandt wrote:
> Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> Standby.
> 
> The Module Standby HW in the RZ/A series is very close to R-Car HW, except
> for how the registers are laid out.
> The MSTP registers are only 8-bits wide, there is no status registers
> (MSTPST), and the register offsets are a little different. Since the RZ/A
> hardware manuals refer to these registers as the Standby Control Registers,
> we'll use that name to distinguish the RZ/A type for the R-Car type.
> 
> Signed-off-by: Chris Brandt 
> ---

> +++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*


> +++ b/include/dt-bindings/clock/r7s9210-cpg-mssr.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0+

The proper identifier is GPL-2.0-or-later

Re: [PATCH] ASoC: rsnd: Add device tree binding for r8a77990

[Rob Herring]

On Fri, 17 Aug 2018 16:53:55 +0900, Yoshihiro Kaneko wrote:
> From: Hiroyuki Yokoyama 
> 
> This patch adds the device tree binding of the r8a77990 SoC.
> 
> Signed-off-by: Hiroyuki Yokoyama 
> Signed-off-by: Yoshihiro Kaneko 
> ---
> 
> This patch is based on the devel branch of Simon Horman's renesas tree.
> 
>  Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH 1/2] dt-bindings: pinctrl: sh-pfc: Document r8a774a1 PFC support

[Rob Herring]

On Mon, 13 Aug 2018 14:52:31 +0100, Biju Das wrote:
> Document PFC support for the R8A774A1 SoC.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 
> ---
>  Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: pwm: rcar: Add bindings for R-Car E3 support

[Rob Herring]

On Mon, Jul 30, 2018 at 08:49:51PM +0900, Yoshihiro Shimoda wrote:
> This patch adds bindings for R-Car E3. No driver update is needed.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v2 2/5] soc: renesas: rcar-sysc: Add r8a774a1 support

[Rob Herring]

On Fri, Aug 10, 2018 at 5:13 AM Simon Horman  wrote:
>
> On Fri, Aug 10, 2018 at 07:37:18AM +, Biju Das wrote:
> > Hi Rob,
> >
> > > Subject: Re: [PATCH v2 2/5] soc: renesas: rcar-sysc: Add r8a774a1 support
> > >
> > > Hi, this is an automated email from Rob's (experimental) review bot. I 
> > > found
> > > a couple of common problems with your patch. Please see below.
> >
> > Do I need to send another patch? The mail says " Rob's (experimental)
> > review bot".  Previously for RZ/G1C upstreaming I have submitted the
> > patches in similar fashion.  Is anything changed?
>
> Yes, indeed.
>
> At one point I was enforcing such a split but as it did not seem to be a
> universal practice I stopped doing so.  I'd like some clear guidance from
> Rob if he'd like this split to occur going forwards.

I've generally not asked for either of these on 1 (or few) line
changes or if I had no other comments on the patch. But for automated
checking I'm not going to try to make that distinction. So, still up
to whomever applies them.

BTW, I'm adding the splitting patches check to checkpatch.pl too.

Rob

Re: [PATCH v2 4/5] clk: renesas: Add r8a774a1 CPG Core Clock Definitions

[Rob Herring]

On Fri, Aug 10, 2018 at 1:35 AM Biju Das  wrote:
>
> Hi Rob,
>
>
> > Subject: Re: [PATCH v2 4/5] clk: renesas: Add r8a774a1 CPG Core Clock
> > Definitions
> >
> > Hi, this is an automated email from Rob's (experimental) review bot. I found
> > a couple of common problems with your patch. Please see below.
>
> Do I need to send another patch? The mail says " Rob's (experimental) review 
> bot".

"experimental" in the sense it may not work right. Such as they all
triggered spam filters. But I checked all these mails before they went
out, so the comments are correct.

> Previously for RZ/G1C upstreaming I have submitted the patches in similar 
> fashion.
> Is anything changed?

Yes, I'm tired of manually providing these comments. If there's no
other comments though, then it is fine to apply as is.

Rob

Re: [PATCH] ASoC: rsnd: Document R-Car M3-N support

[Rob Herring]

On Thu, Jul 26, 2018 at 05:40:15AM +0900, Yoshihiro Kaneko wrote:
> From: Hiroyuki Yokoyama 
> 
> Document support for the sound modules in the Renesas M3-N (r8a77965)
> SoC.
> 
> No driver update is needed.
> 
> Signed-off-by: Hiroyuki Yokoyama 
> Signed-off-by: Yoshihiro Kaneko 
> ---
> 
> This patch is based on the devel branch of Simon Horman's renesas tree.
> 
>  Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v3 2/5] dt-bindings: gpio: rcar: Add gpio-reserved-ranges support

[Rob Herring]

On Tue, Aug 07, 2018 at 08:57:03AM +0100, Biju Das wrote:
> Update the DT bindings documentation with the optional gpio-reserved-ranges
> properties.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 
> ---
> V2 --> V3
>   * Incorporated review comments.
> ---
>  .../devicetree/bindings/gpio/renesas,gpio-rcar.txt | 61 
> +-
>  1 file changed, 35 insertions(+), 26 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH 1/3] dt-bindings: arm: Document RZ/G2M SoC DT bindings

[Rob Herring]

On Tue, Jul 24, 2018 at 04:47:16PM +0100, Biju Das wrote:
> Add device tree bindings documentation for Renesas RZ/G2M (r8a774a1) SoC.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Rob Herring 

Re: [PATCH v3 1/4] serial: sh-sci: Improve interrupts description

[Rob Herring]

On Tue, Jul 31, 2018 at 05:41:36AM -0500, Chris Brandt wrote:
> Describe interrupts property in more detail, especially when there are
> more than one interrupt.
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
>  .../devicetree/bindings/serial/renesas,sci-serial.txt| 16 
> +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH v2 3/3] serial: sh-sci: Document r7s9210 bindings

[Rob Herring]

On Wed, Jul 25, 2018 at 09:38:50AM -0500, Chris Brandt wrote:
> Add R7S9210 (RZ/A2) support.
> Also describe interrupts property in more detail.
> 
> Signed-off-by: Chris Brandt 
> ---
> v2:
>  * Add more details to interrupts property
>  * Geert gave a Reviewed-by for V1, but then later said that was a
>mistake because it was missing the interrupts description, so
>I didn't include his Reviewed-by yet.
> ---
>  .../devicetree/bindings/serial/renesas,sci-serial.txt   | 17 
> -
>  1 file changed, 16 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH v3 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Rob Herring]

On Fri, Jul 27, 2018 at 11:53:33AM -0500, Chris Brandt wrote:
> Add device tree bindings documentation for Renesas RZ/A2 (r7s9210) SoC.
> Also document new option for "renesas,bsid"
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v3:
> * added "or Boundary Scan ID Register" to description
> v2:
>  * added Reviewed-by
>  * added renesas,bsid comment
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH] serial: sh-sci: Document that serial aliases became optional

[Rob Herring]

On Fri, Jul 20, 2018 at 02:19:40PM +0200, Geert Uytterhoeven wrote:
> Serial aliases are optional since commit 7678f4c20fa7670f ("serial:
> sh-sci: Add support for dynamic instances").
> Update the DT bindings to reflect this.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH] DT: irqchip: renesas-irqc: document R8A77980 support

[Rob Herring]

On Tue, Jul 17, 2018 at 10:23:17PM +0300, Sergei Shtylyov wrote:
> Document R-Car V3H (AKA R8A77980) SoC bindings.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt |
> 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

> 
> Index: 
> renesas/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
> ===
> --- 
> renesas.orig/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
> +++ 
> renesas/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt
> @@ -16,6 +16,7 @@ Required properties:
>  - "renesas,intc-ex-r8a7796" (R-Car M3-W)
>  - "renesas,intc-ex-r8a77965" (R-Car M3-N)
>  - "renesas,intc-ex-r8a77970" (R-Car V3M)
> +- "renesas,intc-ex-r8a77980" (R-Car V3H)
>  - "renesas,intc-ex-r8a77995" (R-Car D3)
>  - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined 
> in
>interrupts.txt in this directory

Re: [PATCH 2/2] clk: renesas: mstp: Document R7S9210 support

[Rob Herring]

On Wed, Jul 11, 2018 at 12:03:13PM -0500, Chris Brandt wrote:
> Renesas R7S9210 SoC also has the CPG MSTP clocks.
> 
> Signed-off-by: Chris Brandt 
> ---
>  Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v2 1/2] dt: serial: Add Renesas RZ/N1 binding documentation

[Rob Herring]

On Fri, Jul 13, 2018 at 10:33:48AM +0100, Phil Edworthy wrote:
> The RZ/N1 UART is a modified Synopsys DesignWare UART.
> The modifications only relate to DMA so you could actually use the
> controller with the Synopsys compatible string if you are not using
> DMA, but you should not do so.
> 
> Signed-off-by: Phil Edworthy 
> ---
> v2:
>  - Change "renesas,-" to
>"renesas,-"
> ---
>  Documentation/devicetree/bindings/serial/renesas,rzn1-uart.txt | 10 
> ++
>  1 file changed, 10 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/serial/renesas,rzn1-uart.txt

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: watchdog: renesas-wdt: Add support for the R8A77990 wdt

[Rob Herring]

On Tue, Jun 05, 2018 at 07:18:33PM +0200, Geert Uytterhoeven wrote:
> From: Masaharu Hayakawa 
> 
> Document support for the Watchdog Timer (WDT) Controller in the Renesas
> R-Car E3 (R8A77990) SoC.
> 
> No driver update is needed.
> 
> Signed-off-by: Masaharu Hayakawa 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

> 
> diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> index f24d802b8056f6c6..5d47a262474cfe0e 100644
> --- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> @@ -16,6 +16,7 @@ Required properties:
>- "renesas,r8a7796-wdt" (R-Car M3-W)
>- "renesas,r8a77965-wdt" (R-Car M3-N)
>- "renesas,r8a77970-wdt" (R-Car V3M)
> +  - "renesas,r8a77990-wdt" (R-Car E3)
>- "renesas,r8a77995-wdt" (R-Car D3)
>- "renesas,r7s72100-wdt" (RZ/A1)
>   The generic compatible string must be:
> -- 
> 2.7.4
> 

Re: [PATCH v2 1/2] dt-bindings: phy: Renesas R-Car Gen3 PCIe PHY bindings

[Rob Herring]

On Sun, Jun 10, 2018 at 09:22:46PM +0300, Sergei Shtylyov wrote:
> This PHY is  still  mostly undocumented --  the only documented registers
> exist on R-Car V3H (R8A77980) SoC.  Add the corresponding device tree
> bindings.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> Changes in version 2:
> - split from the big driver/bindings patch;
> - got rid of the generic R-Car gen3 "compatible" prop value.
> 
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt |   24 
> +++
>  1 file changed, 24 insertions(+)

Reviewed-by: Rob Herring 

Re: [PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties

[Rob Herring]

On Wed, May 23, 2018 at 2:38 PM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
> Hi Rob,
>
> On Wednesday, 23 May 2018 19:29:47 EEST Rob Herring wrote:
>> On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
>> > Describe the optional endpoint properties for endpoint nodes of port@0
>> > and port@1 of the R-Car VIN driver device tree bindings documentation.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
>> > ---
>> >
>> >  Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
>> >  1 file changed, 12 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > b/Documentation/devicetree/bindings/media/rcar_vin.txt index
>> > a19517e1..c53ce4e 100644
>> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on
>> > SoC.
>> >
>> >from external SoC pins described in video-interfaces.txt[1].
>> >Describing more then one endpoint in port 0 is invalid. Only VIN
>> >instances that are connected to external pins should have port 0.
>> >
>> > +
>> > +  - Optional properties for endpoint nodes of port@0:
>> > +- hsync-active: active state of the HSYNC signal, 0/1 for
>> > LOW/HIGH
>> > + respectively. Default is active high.
>> > +- vsync-active: active state of the VSYNC signal, 0/1 for
>> > LOW/HIGH
>> > + respectively. Default is active high.
>> > +
>> > +   If both HSYNC and VSYNC polarities are not specified, embedded
>> > +   synchronization is selected.
>>
>> No need to copy-n-paste from video-interfaces.txt. Just "see
>> video-interfaces.txt" for the description is fine.
>
> I would still explicitly list the properties that apply to this binding. I
> agree that there's no need to copy & paste the description of those properties
> though.

Yes, that's what I meant. List each property with "see
video-interfaces.txt" for the description of each.

Rob

Re: [PATCH] iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings

[Rob Herring]

On Mon, May 21, 2018 at 11:41:33PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+rene...@opensource.se>
> 
> Update the IPMMU DT binding documentation to include the compat strings
> for the IPMMU devices included in the R-Car V3H and E3 SoCs.
> 
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
> ---
> 
>  Developed on top of renesas-drivers-2018-05-15-v4.17-rc5
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Rob Herring <r...@kernel.org>

Re: [PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints

[Rob Herring]

On Thu, May 17, 2018 at 01:32:12AM +0200, Niklas Söderlund wrote:
> The style for referring to ports and endpoint are wrong. Refer to them
> using lowercase and a unit address, port@x and endpoint@x.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> Reported-by: Geert Uytterhoeven <ge...@linux-m68k.org>
> ---
>  .../devicetree/bindings/media/rcar_vin.txt| 20 +--
>  1 file changed, 10 insertions(+), 10 deletions(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active

[Rob Herring]

On Wed, May 16, 2018 at 06:32:28PM +0200, Jacopo Mondi wrote:
> Document 'data-active' property in R-Car VIN device tree bindings.
> The property is optional when running with explicit synchronization
> (eg. BT.601) but mandatory when embedded synchronization is in use (eg.
> BT.656) as specified by the hardware manual.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index c53ce4e..17eac8a 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -63,6 +63,11 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>   If both HSYNC and VSYNC polarities are not specified, embedded
>   synchronization is selected.
> 
> +- data-active: active state of data enable signal (CLOCKENB pin).
> +  0/1 for LOW/HIGH respectively. If not specified, use HSYNC as
> +  data enable signal. When using embedded synchronization this
> +  property is mandatory.

This doesn't match the common property's definition which AIUI is for 
the data lines' polarity. You need a new property. Perhaps a common one.

> +
>  - port 1 - sub-nodes describing one or more endpoints connected to
>the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>use the following schema.
> --
> 2.7.4
> 

Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties

[Rob Herring]

On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
> 
> Thanks for your work.
> 
> On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > driver and only confuse users. Remove them in all Gen2 SoC that used
> > them.
> > 
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  arch/arm/boot/dts/r8a7790-lager.dts   | 3 ---
> >  arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> >  arch/arm/boot/dts/r8a7791-porter.dts  | 1 -
> >  arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
> >  arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> >  arch/arm/boot/dts/r8a7794-silk.dts| 1 -
> >  6 files changed, 12 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> > b/arch/arm/boot/dts/r8a7790-lager.dts
> > index 063fdb6..b56b309 100644
> > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > @@ -873,10 +873,8 @@
> > port {
> > vin0ep2: endpoint {
> > remote-endpoint = <_out>;
> > -   bus-width = <24>;
> 
> I can't really make up my mind if this is a good thing or not. Device 
> tree describes the hardware and not what the drivers make use of. And 
> the fact is that this bus is 24 bits wide. So I'm not sure we should 
> remove these properties. But I would love to hear what others think 
> about this.

IMO, this property should only be present when all the pins are not 
connected. And by "all", I mean the minimum of what each end of the 
graph can support.

Rob

Re: [PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties

[Rob Herring]

On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
> Describe the optional endpoint properties for endpoint nodes of port@0
> and port@1 of the R-Car VIN driver device tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1..c53ce4e 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>from external SoC pins described in video-interfaces.txt[1].
>Describing more then one endpoint in port 0 is invalid. Only VIN
>instances that are connected to external pins should have port 0.
> +
> +  - Optional properties for endpoint nodes of port@0:
> +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> +   respectively. Default is active high.
> +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> +   respectively. Default is active high.
> +
> + If both HSYNC and VSYNC polarities are not specified, embedded
> + synchronization is selected.

No need to copy-n-paste from video-interfaces.txt. Just "see 
video-interfaces.txt" for the description is fine.

> +
>  - port 1 - sub-nodes describing one or more endpoints connected to
>the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>use the following schema.
> @@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>  - Endpoint 2 - sub-node describing the endpoint connected to CSI40
>  - Endpoint 3 - sub-node describing the endpoint connected to CSI41
> 
> +  Endpoint nodes of port@1 do not support any optional endpoint property.
> +
>  Device node example for Gen2 platforms
>  --
> 
> @@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite 
> video input)
> 
>  vin1ep0: endpoint {
>  remote-endpoint = <>;
> -bus-width = <8>;
>  };
>  };
>  };
> --
> 2.7.4
> 

Re: [PATCH V2] mfd: dt: Add bindings for DA9063L

[Rob Herring]

On Wed, May 23, 2018 at 02:21:40PM +0200, Marek Vasut wrote:
> Add device tree bindings for the Dialog DA9063L. This is a
> variant of the DA9063 chip with smaller package, with less
> LDO regulators and without RTC block. The other properties
> of the chip are the same, including the content of the chip
> ID register.
> 
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Lee Jones <lee.jo...@linaro.org>
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Steve Twiss <stwiss.opensou...@diasemi.com>
> Cc: Wolfram Sang <wsa+rene...@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Merge the DA9063/DA9063L regulator lists and mark DA9063-only
> regulators in that single list
> ---
>  Documentation/devicetree/bindings/mfd/da9063.txt | 32 
> +++++++++---
>  1 file changed, 17 insertions(+), 15 deletions(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver

[Rob Herring]

On Wed, May 23, 2018 at 1:52 AM, M P <buser...@gmail.com> wrote:
> Hi Rob,
>
> On Tue, 22 May 2018 at 17:09, Rob Herring <r...@kernel.org> wrote:
>
>> On Tue, May 22, 2018 at 11:01:23AM +0100, Michel Pollet wrote:
>> > The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
>> > to provide the SoC clock infrastructure for Linux.
>> >
>> > This documents the driver bindings.
>> >
>> > Signed-off-by: Michel Pollet <michel.pol...@bp.renesas.com>
>> > ---
>> >  .../bindings/clock/renesas,rzn1-clocks.txt | 44
> ++
>> >  1 file changed, 44 insertions(+)
>> >  create mode 100644
> Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> >
>> > diff --git
> a/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> > new file mode 100644
>> > index 000..0c41137
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> > @@ -0,0 +1,44 @@
>> > +* Renesas RZ/N1 Clock Driver
>> > +
>> > +This driver provides the clock infrastructure used by all the other
> drivers.
>
>> Bindings document h/w not drivers.
>
>> > +
>> > +One of the 'special' feature of this infrastructure is that Linux
> doesn't
>
>> Bindings are not just for Linux.
>
>> > +necessary 'own' all the clocks on the SoC, some other OS runs on
>> > +the Cortex-M3 core and that OS can access and claim it's own clocks.
>
>> How is this relevant to the binding?
>
> Well you just said it, if the binding is not just for linux, it's probably
> a good idea to mention it somewhere since I can promise you it's *not*
> documented in the hardware manual. Whatever this binding is for, it's
> relevant to point out it is different from the other clock drivers in the
> same directory... ?

That's not an uncommon issue (sometimes it's secure world that owns
the clocks, not even a different processor). I'm just not sure what I
do with this information. It doesn't tell me which clocks are owned by
the M3 or not.

>> > +
>> > +Required Properties:
>> > +
>> > +  - compatible: Must be
>> > +- "renesas,r9a06g032-clocks" for the RZ/N1D
>> > +and "renesas,rzn1-clocks" as a fallback.
>
>> Is "clocks" how the chip reference manual refers to this block?
>
> No, the block is called 'sysctrl' and has tons of other stuff in there.
> I've tried multiple times to get a 'sysctrl' driver in the previous
> versions of the patch, in various shape or form, and I can't because I'd be
> supposed to 'document' binding for stuff that has no code, no purpose, no
> testing, and have all wildly different topics. So, after some more
> lengthily discussion with Geert, we've decided to make the 'primary'
> feature of that block (clocks) as a driver, and see from there onward.

If you are referring to Geert's reply on v4, then this is not how I
interpreted it. I understood it as make the clock driver bind to the
sysctrl node and the clock driver can register other functions like
reset. Then later if you need multiple drivers, you can make an MFD
driver that binds to the sysctrl node and creates child devices to
bind sub-drivers (like clocks) to. But the DT doesn't change in the
process wrt clocks.

You don't have to have a driver for everything, but the binding should
be as complete as possible and done in an extendable way. The way you
have done it now is not. I can already see that at some point you will
want to break things and do something like this:

{
  compatible = "renesas,r9a06g032-sysctrl";
  ...
  {
compatible = "renesas,r9a06g032-clocks";
...
  };
};

Which is likely wrong because there's no need to have a child node
like that. The parent node can be the clock provider (and any other
provider). There are cases when child nodes do make sense, but we need
a more complete binding to make that decision. Evolving it one feature
at a time doesn't work.

Rob

Re: [PATCH/RFC v4 2/4] usb: gadget: udc: renesas_usb3: Add register of usb role switch

[Rob Herring]

On Wed, May 23, 2018 at 1:52 AM, Yoshihiro Shimoda
<yoshihiro.shimoda...@renesas.com> wrote:
> Hi Rob,
>
> Thank you for the review!
>
>> From: Rob Herring, Sent: Wednesday, May 23, 2018 2:13 AM
>>
>> On Tue, May 22, 2018 at 09:01:07PM +0900, Yoshihiro Shimoda wrote:
>> > This patch adds role switch support for R-Car SoCs into the USB 3.0
>> > peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0
>> > dual-role device controller which has the USB 3.0 xHCI host and
>> > Renesas USB 3.0 peripheral.
>> >
>> > Unfortunately, the mode change register contains the USB 3.0 peripheral
>> > controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
>> > manages this register now. However, in peripheral mode, the host
>> > should stop. Also the host hardware needs to reinitialize its own
>> > registers when the mode changes from peripheral to host mode.
>> > Otherwise, the host cannot work correctly (e.g. detect a device as
>> > high-speed).
>> >
>> > To achieve this by a driver, this role switch driver manages
>> > the mode change register and attach/release the xhci-plat driver.
>> >
>> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
>> > ---
>> >  .../devicetree/bindings/usb/renesas_usb3.txt   | 15 
>>
>> Please split bindings to a separate patch.
>
> Oops. I got it.
>
>> >  drivers/usb/gadget/udc/Kconfig |  1 +
>> >  drivers/usb/gadget/udc/renesas_usb3.c  | 82 
>> > ++
>> >  3 files changed, 98 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > index 2c071bb5..f6105aa 100644
>> > --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > @@ -19,6 +19,9 @@ Required properties:
>> >  Optional properties:
>> >- phys: phandle + phy specifier pair
>> >- phy-names: must be "usb"
>> > +  - The connection to a usb3.0 host node needs by using OF graph bindings 
>> > for
>> > +usb role switch.
>> > +   - port@0 = USB3.0 host port.
>>
>> On the host side, this might conflict with the USB connector binding.
>>
>> I would either make sure this can work with the connector binding by
>> having 2 endpoints on the HS or SS port or just use the 'companion'
>> property defined in usb-generic.txt.
>
> I don't understand the first one now... This means the renesas_usb3 should 
> follow
> USB connector binding and have 2 endpoints for the usb role switch to avoid
> the conflict like below?
>  - port1@0: Super Speed (SS), present in SS capable connectors (from 
> usb-connector.txt).
>  - port1@1: USB3.0 host port.

I'm confused, SS and USB3.0 are the same essentially. It would be:

port@1/endpoint@0: SS host port
port@1/endpoint@1: SS device port

> About the 'companion' in usb-generic.txt, the property intends to be used for 
> EHCI or host side
> like the commit log [1]. If there is accept to use 'companion' for this 
> patch, I think it will
> be simple to achieve this role switch feature. However, in last month, I 
> submitted a similar patch [2]
> that has "renesas,host" property, but I got reply from Andy [3] and Heikki 
> [4]. So, I'm
> trying to improve the device connection framework [5] now.

I think this case is rare enough that we don't need a general solution
using OF graph, so I'm fine with a simple, single property to link the
2 nodes. Either reusing "companion" or "renesas,host" is fine by me.

Rob

>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/usb/generic.txt?h=v4.17-rc6=5095cb89c62acc78b4cfaeb9a4072979d010510a
>
> [2]
> https://www.spinics.net/lists/linux-usb/msg167773.html
>
> [3]
> https://www.spinics.net/lists/linux-usb/msg167780.html
>
> [4]
> https://www.spinics.net/lists/linux-usb/msg167806.html
>
> [5]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/device_connection.rst
>
> Best regards,
> Yoshihiro Shimoda
>
>> Rob

Re: [PATCH 2/2] dmaengine: rcar-dmac: Document R8A77990 bindings

[Rob Herring]

On Wed, May 16, 2018 at 03:06:19PM +0200, Ulrich Hecht wrote:
> From: Hiroyuki Yokoyama <hiroyuki.yokoyama...@renesas.com>
> 
> Renesas R-Car E3 (R8A77990) SoC also has the R-Car gen2/3 compatible DMA
> controllers, so document the SoC specific binding.
> 
> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama...@renesas.com>
> Signed-off-by: Ulrich Hecht <ulrich.hecht+rene...@gmail.com>
> ---
>  Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <r...@kernel.org>

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

[Rob Herring]

On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote:
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <r...@kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669eb35..c2c57dcf73f4851b 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 platforms to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> +   - "renesas,vin-r8a77965" for the R8A77965 device
> - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
>   device.
> -- 
> 2.17.0
> 

Re: [PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port

[Rob Herring]

On Wed, May 09, 2018 at 08:45:58PM +0200, Simon Horman wrote:
> The example vin port node does not have an address and thus does not
> need address-cells or address size-properties.
> 
> Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 3 ---
>  1 file changed, 3 deletions(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH/RFC v4 2/4] usb: gadget: udc: renesas_usb3: Add register of usb role switch

[Rob Herring]

On Tue, May 22, 2018 at 09:01:07PM +0900, Yoshihiro Shimoda wrote:
> This patch adds role switch support for R-Car SoCs into the USB 3.0
> peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0
> dual-role device controller which has the USB 3.0 xHCI host and
> Renesas USB 3.0 peripheral.
> 
> Unfortunately, the mode change register contains the USB 3.0 peripheral
> controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
> manages this register now. However, in peripheral mode, the host
> should stop. Also the host hardware needs to reinitialize its own
> registers when the mode changes from peripheral to host mode.
> Otherwise, the host cannot work correctly (e.g. detect a device as
> high-speed).
> 
> To achieve this by a driver, this role switch driver manages
> the mode change register and attach/release the xhci-plat driver.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../devicetree/bindings/usb/renesas_usb3.txt   | 15 

Please split bindings to a separate patch.

>  drivers/usb/gadget/udc/Kconfig |  1 +
>  drivers/usb/gadget/udc/renesas_usb3.c  | 82 
> ++
>  3 files changed, 98 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt 
> b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> index 2c071bb5..f6105aa 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> @@ -19,6 +19,9 @@ Required properties:
>  Optional properties:
>- phys: phandle + phy specifier pair
>- phy-names: must be "usb"
> +  - The connection to a usb3.0 host node needs by using OF graph bindings for
> +usb role switch.
> +   - port@0 = USB3.0 host port.

On the host side, this might conflict with the USB connector binding. 

I would either make sure this can work with the connector binding by 
having 2 endpoints on the HS or SS port or just use the 'companion' 
property defined in usb-generic.txt.

Rob

Re: [PATCH v4 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support

[Rob Herring]

On Mon, May 21, 2018 at 04:45:40PM +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 <jacopo+rene...@jmondi.org>
> Acked-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Reviewed-by: Simon Horman <horms+rene...@verge.net.au>
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <r...@kernel.org>

Re: [PATCH v4 2/3] dt-bindings: thermal: rcar-thermal: add R8A77995 support

[Rob Herring]

On Sun, May 20, 2018 at 06:26:18PM +0900, Yoshihiro Kaneko wrote:
> Signed-off-by: Yoshihiro Kaneko <ykaneko0...@gmail.com>
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
>  Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver

[Rob Herring]

On Tue, May 22, 2018 at 11:01:23AM +0100, Michel Pollet wrote:
> The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
> to provide the SoC clock infrastructure for Linux.
> 
> This documents the driver bindings.
> 
> Signed-off-by: Michel Pollet 
> ---
>  .../bindings/clock/renesas,rzn1-clocks.txt | 44 
> ++
>  1 file changed, 44 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt 
> b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> new file mode 100644
> index 000..0c41137
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> @@ -0,0 +1,44 @@
> +* Renesas RZ/N1 Clock Driver
> +
> +This driver provides the clock infrastructure used by all the other drivers.

Bindings document h/w not drivers.

> +
> +One of the 'special' feature of this infrastructure is that Linux doesn't

Bindings are not just for Linux.

> +necessary 'own' all the clocks on the SoC, some other OS runs on
> +the Cortex-M3 core and that OS can access and claim it's own clocks.

How is this relevant to the binding?

> +
> +Required Properties:
> +
> +  - compatible: Must be
> +- "renesas,r9a06g032-clocks" for the RZ/N1D
> +and "renesas,rzn1-clocks" as a fallback.

Is "clocks" how the chip reference manual refers to this block?

> +  - reg: Base address and length of the memory resource used by the driver
> +  - #clock-cells: Must be 1
> +
> +Examples
> +
> +
> +  - Clock driver device node:
> +
> + clock: clocks@4000c000 {

clock-controller@...

> + compatible = "renesas,r9a06g032-clocks",
> + "renesas,rzn1-clocks";
> + reg = <0x4000c000 0x1000>;
> + status = "okay";

Don't show status in examples. (Plus, I doubt you ever want to have this 
disabled, so you don't need the property in your dts files either).

> + #clock-cells = <1>;
> + };
> +
> +
> +  - Other drivers can use the clocks as in:

s/drivers/nodes/

> +
> + uart0: serial@4006 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x4006 0x400>;
> + interrupts = ;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = < RZN1_CLK_UART0>;
> + clock-names = "baudclk";
> + };
> +Note the use of RZN1_CLK_UART0 -- these constants are declared in
> +the rzn1-clocks.h header file. These are not hardware based constants
> +and are Linux specific.

No, they are not Linux specific. They are part of the DT ABI. 

While it is not a requirement to base them on some h/w numbering, it is 
preferred if you can. That usually only works if you can base them on 
bit positions or register offsets.

Rob

Re: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file

[Rob Herring]

On Tue, May 22, 2018 at 11:01:22AM +0100, Michel Pollet wrote:
> This adds the constants necessary to use the renesas,rzn1-clocks driver.
> 
> Signed-off-by: Michel Pollet <michel.pol...@bp.renesas.com>
> ---
>  include/dt-bindings/clock/rzn1-clocks.h | 187 
> 
>  1 file changed, 187 insertions(+)
>  create mode 100644 include/dt-bindings/clock/rzn1-clocks.h

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH/RFC v2 1/6] dt-bindings: usb: add Renesas R-Car USB 3.0 role switch

[Rob Herring]

On Mon, May 7, 2018 at 9:43 PM, Yoshihiro Shimoda
<yoshihiro.shimoda...@renesas.com> wrote:
> Hi Rob,
>
> Sorry for the delayed response. I had a vacation in last week.
>
>> From: Rob Herring, Sent: Saturday, April 28, 2018 5:06 AM
>>
>> On Thu, Apr 26, 2018 at 08:26:41PM +0900, Yoshihiro Shimoda wrote:
>> > This patch adds a new documentation for Renesas R-Car USB 3.0 role
>> > switch that can change the USB 3.0 role to either host or peripheral
>> > by a hardware register that is included in USB3.0 peripheral module.
>> >
>> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
>> > ---
>> >  .../bindings/usb/renesas,rcar-usb3-role-sw.txt | 47 
>> > ++
>> >  1 file changed, 47 insertions(+)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
>> >
>> > diff --git 
>> > a/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
>> b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
>> > new file mode 100644
>> > index 000..e074c03
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
>> > @@ -0,0 +1,47 @@
>> > +Renesas Electronics R-Car USB 3.0 role switch
>> > +
>> > +A renesas_usb3's node can contain this node.
>> > +
>> > +Required properties:
>> > + - compatible: Must contain "renesas,rcar-usb3-role-switch".
>> > +
>> > +Required nodes:
>> > + - The connection to a usb3.0 host node needs by using OF graph bindings.
>> > +  - port@0 = USB 3.0 host port
>> > +  - port@1 = USB 3.0 peripheral port
>> > +
>> > +Example of R-Car H3 ES2.0:
>> > +   usb3_peri0: usb@ee02 {
>> > +   compatible = "renesas,r8a7795-usb3-peri",
>> > +"renesas,rcar-gen3-usb3-peri";
>> > +   reg = <0 0xee02 0 0x400>;
>> > +   interrupts = ;
>> > +   clocks = < CPG_MOD 328>;
>> > +   power-domains = < R8A7795_PD_ALWAYS_ON>;
>> > +   resets = < 328>;
>> > +
>> > +   usb3-role-sw {
>> > +   compatible = "renesas,rcar-usb3-role-switch";
>>
>> You don't define any h/w resources. How is this device accessed?
>
> This device accesses one of registers in the usb3_peri0.
> In the detail, the usb3-role-sw uses 0xee020218 (32-bit register) only.
> (Unfortunately, the hardware design is not good...)
>
> In this case, should I describe the following in the usb3-role-sw node?
>
> reg = <0 0xee020218 0 4>;
>
> Or, shouldn't I add the usb3-role-sw node and a driver for usb3_peri0 should
> take care for it?

IMO, the driver should take care of it.

Rob

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

[Rob Herring]

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 <s...@canb.auug.org.au>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: David Airlie <airl...@linux.ie>
Cc: dri-de...@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Signed-off-by: Rob Herring <r...@kernel.org>
---
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 3/5] tty: serial: sh-sci: Hide earlycon config question

[Rob Herring]

On Sun, Apr 15, 2018 at 2:09 PM, Rich Felker  wrote:
> On Sun, Apr 15, 2018 at 08:58:42PM +0200, Geert Uytterhoeven wrote:
>> Hi Rich,
>>
>> On Sun, Apr 15, 2018 at 2:34 AM, Rich Felker  wrote:
>> > On Thu, Nov 30, 2017 at 02:12:00PM +0100, Geert Uytterhoeven wrote:
>> >> Renesas H8/300 and ARM platforms use DT and support earlycon, so most
>> >> users want earlycon support to be enabled.
>> >>
>> >> On SuperH platforms, earlycon is not yet supported.
>> >>
>> >> Hence follow the above rationale to configure the default, unless
>> >> CONFIG_EXPERT is enabled.
>> >>
>> >> Signed-off-by: Geert Uytterhoeven 
>> >> ---
>> >>  drivers/tty/serial/Kconfig | 3 ++-
>> >>  1 file changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>> >> index 0c75562d620feb82..952a2c6a9da08fdd 100644
>> >> --- a/drivers/tty/serial/Kconfig
>> >> +++ b/drivers/tty/serial/Kconfig
>> >> @@ -774,10 +774,11 @@ config SERIAL_SH_SCI_CONSOLE
>> >>   default y
>> >>
>> >>  config SERIAL_SH_SCI_EARLYCON
>> >> - bool "Support for early console on SuperH SCI(F)"
>> >> + bool "Support for early console on SuperH SCI(F)" if EXPERT
>> >>   depends on SERIAL_SH_SCI=y
>> >>   select SERIAL_CORE_CONSOLE
>> >>   select SERIAL_EARLYCON
>> >> + default ARCH_RENESAS || H8300
>> >>
>> >>  config SERIAL_SH_SCI_DMA
>> >>   bool "DMA support"
>> >> --
>> >
>> > Can you clarify what the claim that SuperH does not support earlycon
>> > is based on? My understanding is that users were successfully using
>> > this option on Renesas SH systems, and I'm using it on J2 with the
>> > uartlite earlycon support which I added in 7cdcc29e49. I think if you
>> > want to omit the question it should always default to enabled.
>>
>> This is a patch for a Kconfig option for the Renesas sh-sci driver, which
>> supports the SCI, SCIF, SCIFA, SCIFB, and HSCIF uarts found on various
>> Renesas SoCs.
>>
>> Earlycon is used with DT only. While you are using earlycon on J2, you do
>> use it with a different uart (uartlite). Currently there's no upstream 
>> support
>> for using DT on Renesas SuperH SoCs. If this changes, the default for
>> SERIAL_SH_SCI_EARLYCON has to be changed.
>>
>> So none of my patch applies to the current state of SuperH Linux support.
>
> OK, I was under the impression (from users) that it worked on Renesas
> SH devices without DT. If it really doesn't then it doesn't matter
> until DT support for them is added. I've got some hardware to
> experiment with now so I'll see what can be done.

Yes, it works without DT (but maybe that is UART specific). It was
originally an x86 8250 thing.

The main thing you need is either fixmap support or ioremap has to
work before paging_init when early_params are processed.

Rob

Re: [PATCH] rcar-vin: remove generic gen3 compatible string

[Rob Herring]

On Wed, Apr 25, 2018 at 01:43:21AM +0200, Niklas Söderlund wrote:
> The compatible string "renesas,rcar-gen3-vin" was added before the
> Gen3 driver code was added but it's not possible to use. Each SoC in the
> Gen3 series require SoC specific knowledge in the driver to function.
> Remove it before it is added to any device tree descriptions.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH] dt-bindings: arm: consistently name r8a77965 as M3-N

[Rob Herring]

On Tue, Apr 24, 2018 at 07:54:42AM +0200, Simon Horman wrote:
> There is an inconsistency between the use of M3N and M3-N.
> This patch resolves this by consistently using the latter.
> 
> Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
> ---
> Based on renesas-devel-20180423-v4.17-rc2
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH] irqchip: Add support for Renesas RZ/N1 GPIO interrupt multiplexer

[Rob Herring]

On Mon, Apr 23, 2018 at 02:33:06PM +0100, Phil Edworthy wrote:
> On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks each
> configured to have 32 interrupt outputs, so we have a total of 96 GPIO
> interrupts. All of these are passed to the GPIO IRQ Muxer, which selects
> 8 of the GPIO interrupts to pass onto the GIC. The interrupt signals
> aren't latched, so there is nothing to do in this driver when an interrupt
> is received, other than tell the corresponding GPIO block.
> 
> Signed-off-by: Phil Edworthy 
> ---
>  .../interrupt-controller/renesas,rzn1-mux.txt  |  85 ++

Please split bindings to a separate patch.

>  drivers/irqchip/Kconfig|  10 ++
>  drivers/irqchip/Makefile   |   1 +
>  drivers/irqchip/irq-rzn1-irq-mux.c | 178 
> +
>  4 files changed, 274 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/renesas,rzn1-mux.txt
>  create mode 100644 drivers/irqchip/irq-rzn1-irq-mux.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzn1-mux.txt 
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzn1-mux.txt
> new file mode 100644
> index 000..f28a365
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzn1-mux.txt
> @@ -0,0 +1,85 @@
> +* Renesas RZ/N1 GPIO Interrupt Multiplexer
> +
> +On Renesas RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks each
> +configured to have 32 interrupt outputs, so we have a total of 96 GPIO
> +interrupts. All of these are passed to the GPIO IRQ Muxer, which selects
> +8 of the GPIO interrupts to pass onto the GIC.
> +
> +A single node in the device tree is used to describe the GPIO IRQ Muxer.
> +
> +Required properties:
> +- compatible: the SoC specific name, i.e. "renesas,r9a06g032-gpioirq"
> +   or "renesas,r9a06g033-gpioirq" followed by the SoC family name, i.e.
> +   "renesas,rzn1-gpioirq".
> +- interrupt-controller: Identifies the node as an interrupt controller.
> +- #interrupt-cells: should be <1>. The meaning of the cells is the input
> +   interrupt index, 0 to 95.
> +- reg: Base address and size of GPIO IRQ Muxer registers.
> +- interrupts: The list of interrupts generated by the muxer which are then
> +   connected to a parent interrupt controller. The format of the interrupt
> +   specifier depends in the interrupt parent controller.
> +- gpioirq-#N: One property for each interrupt output from the GPIO IRQ Muxer
> +   that specifies the input interrupt to use, #N is from 0 to 7.

Why do you need this in DT? Can't the driver handle this dynamically? 
When you request an interrupt on a GPIO line, then connect that GPIO 
line to a free IRQ line. 

If you really need this in DT, then interrupt-map can be used here.

> +
> +Optional properties:
> +- interrupt-parent: pHandle of the parent interrupt controller, if not
> +   inherited from the parent node.
> +
> +
> +Example:
> +
> + The following is an example for the RZ/N1D SoC.
> +
> + gpioirq: gpioirq@51000480 {
> + compatible = "renesas,r9a06g032-gpioirq",
> + "renesas,rzn1-gpioirq";
> + reg = <0x51000480 0x20>;
> + interrupts =
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + status = "disabled";

Don't show status in examples.

> + };
> +
> + gpio0: gpio@5000b000 {
> + compatible = "snps,dw-apb-gpio";
> + reg = <0x5000b000 0x80>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-names = "bus";
> + clocks = <_gpio0>;
> + status = "disabled";
> +
> + gpio0a: gpio-controller@0 {
> + compatible = "snps,dw-apb-gpio-port";
> + bank-name = "gpio0a";
> + gpio-controller;
> + #gpio-cells = <2>;
> + snps,nr-gpios = <32>;
> + reg = <0>;
> +
> + interrupt-controller;
> + interrupt-parent = <>;
> + interrupts =   < 0  1  2  3  4  5  6  7
> +  8  9 10 11 12 13 14 15
> + 16 17 18 19 20 21 22 23
> + 24 25 26 27 28 29 30 31 >;
> + #interrupt-cells = <2>;
> + };
> + };
> +
> +
> + The following is an example for a board using this.

Don't show the soc/board split. This is convention, but not part of the 
binding.

> +
> +  {
> + status = "okay";
> + gpioirq-0 = <24>;  

Re: [PATCH v2 1/2] dt-bindings: media: renesas-ceu: Add R-Mobile R8A7740

[Rob Herring]

On Thu, Apr 26, 2018 at 08:24:42PM +0200, Jacopo Mondi wrote:
> Add R-Mobile A1 R8A7740 SoC to the list of compatible values for the CEU
> unit.
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> ---
>  Documentation/devicetree/bindings/media/renesas,ceu.txt | 7 ---
>  drivers/media/platform/renesas-ceu.c| 1 +
>  2 files changed, 5 insertions(+), 3 deletions(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH/RFC v2 1/6] dt-bindings: usb: add Renesas R-Car USB 3.0 role switch

[Rob Herring]

On Thu, Apr 26, 2018 at 08:26:41PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new documentation for Renesas R-Car USB 3.0 role
> switch that can change the USB 3.0 role to either host or peripheral
> by a hardware register that is included in USB3.0 peripheral module.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../bindings/usb/renesas,rcar-usb3-role-sw.txt | 47 
> ++
>  1 file changed, 47 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt 
> b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
> new file mode 100644
> index 000..e074c03
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
> @@ -0,0 +1,47 @@
> +Renesas Electronics R-Car USB 3.0 role switch
> +
> +A renesas_usb3's node can contain this node.
> +
> +Required properties:
> + - compatible: Must contain "renesas,rcar-usb3-role-switch".
> +
> +Required nodes:
> + - The connection to a usb3.0 host node needs by using OF graph bindings.
> +  - port@0 = USB 3.0 host port
> +  - port@1 = USB 3.0 peripheral port
> +
> +Example of R-Car H3 ES2.0:
> + usb3_peri0: usb@ee02 {
> + compatible = "renesas,r8a7795-usb3-peri",
> +  "renesas,rcar-gen3-usb3-peri";
> + reg = <0 0xee02 0 0x400>;
> + interrupts = ;
> + clocks = < CPG_MOD 328>;
> + power-domains = < R8A7795_PD_ALWAYS_ON>;
> + resets = < 328>;
> +
> + usb3-role-sw {
> + compatible = "renesas,rcar-usb3-role-switch";

You don't define any h/w resources. How is this device accessed?


> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb3_host_sw: endpoint {
> + remote-endpoint = 
> <_host_ep>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb3_peri_sw: endpoint {
> + remote-endpoint = 
> <_peri_ep>;
> + };
> + };
> + };
> + };
> + };
> -- 
> 1.9.1
> 

Re: [PATCH v4] dmaengine: rcar-dmac: Document R-Car D3 bindings

[Rob Herring]

On Tue, Apr 24, 2018 at 10:51:06AM +0200, Simon Horman wrote:
> From: Ulrich Hecht <ulrich.hecht+rene...@gmail.com>
> 
> R8A77995's SYS-DMAC is R-Car Gen3-compatible.
> 
> Signed-off-by: Ulrich Hecht <ulrich.hecht+rene...@gmail.com>
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
> Reviewed-by: Simon Horman <horms+rene...@verge.net.au>
> [simon: rebased]
> Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
> ---
> Based on v4.17-rc1
> ---
>  Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH v2 1/2] clk: renesas: Add r8a77990 CPG Core Clock Definitions

[Rob Herring]

On Fri, Apr 20, 2018 at 09:27:43PM +0900, Yoshihiro Shimoda wrote:
> From: Takeshi Kihara <takeshi.kihara...@renesas.com>
> 
> This patch adds all R-Car E3 Clock Pulse Generator Core Clock Outputs.
> 
> Note that internal CPG clocks (S0, S1, S2, S3, SDSRC) are not included,
> as they are used as internal clock sources only, and never referenced
> from DT.
> 
> Signed-off-by: Takeshi Kihara <takeshi.kihara...@renesas.com>
> [shimoda: add SPDX-License-Identifier]
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> ---
>  include/dt-bindings/clock/r8a77990-cpg-mssr.h | 62 
> +++
>  1 file changed, 62 insertions(+)
>  create mode 100644 include/dt-bindings/clock/r8a77990-cpg-mssr.h

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property

[Rob Herring]

On Thu, Apr 19, 2018 at 11:31:03AM +0200, Jacopo Mondi wrote:
> The THC63LVD1024 LVDS to RGB bridge supports two different input mapping
> modes, selectable by means of an external pin.
> 
> Describe the LVDS mode map through a newly defined mandatory property in
> device tree bindings.
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> ---
>  .../devicetree/bindings/display/bridge/thine,thc63lvd1024.txt  | 3 
> +++
>  1 file changed, 3 insertions(+)

+1 for what Laurent said.

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH/RFC 02/11] dt-bindings: usb: add usb role switch driver

[Rob Herring]

On Wed, Apr 18, 2018 at 05:09:56PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new documentation for a usb role switch driver.
> The usb role switch framework will parse this to get each device
> pointer by using each remote-endpoint.

Bindings describe h/w, not drivers. This doesn't look like a h/w device.

> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../devicetree/bindings/usb/usb-role-switch.txt| 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-role-switch.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-role-switch.txt 
> b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
> new file mode 100644
> index 000..941d582
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
> @@ -0,0 +1,42 @@
> +USB role switch driver
> +
> +Optional nodes:
> +- If a role switch driver has OF graph ports, the usb role switch framework
> +  will parse the remote-endpoints in usb_role_switch_register(). The OF graph
> +  port number as follows:
> +0: USB 2.0 host port
> +1: USB 3.0 host port
> +2: UDC port
> +
> +For example:
> + usb-role-sw {
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb2_host_sw0: endpoint {
> + remote-endpoint = <_host_ep0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb3_host_sw0: endpoint {
> + remote-endpoint = <_host_ep0>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + udc_sw0: endpoint {
> + remote-endpoint = <_ep0>;
> + };
> + };
> + };
> + };
> -- 
> 1.9.1
> 

Re: [PATCH/RFC 01/11] Documentation: of: Add device-connection-id property

[Rob Herring]

On Wed, Apr 18, 2018 at 05:09:55PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new property for device connection framework.

What's the "device connection framework" and what does it have to do 
with DT?

> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/graph.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/graph.txt 
> b/Documentation/devicetree/bindings/graph.txt
> index 0415e2c..fca0030 100644
> --- a/Documentation/devicetree/bindings/graph.txt
> +++ b/Documentation/devicetree/bindings/graph.txt
> @@ -125,4 +125,4 @@ Optional endpoint properties
>  
>  
>  - remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
> -
> +- device-connection-id: string for device connection.

Why do we need this?

> -- 
> 1.9.1
> 

Re: [PATCH 1/2] dt-bindings: thermal: rcar-gen3-thermal: add r8a77965

[Rob Herring]

On Tue, Apr 17, 2018 at 11:00:44PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> 
> Based on previous work by Ryo Kataoka <ryo.kataoka...@renesas.com>.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  .../devicetree/bindings/thermal/rcar-gen3-thermal.txt  | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH] dt-bindings: thermal: rcar-gen3-thermal: update register size in example

[Rob Herring]

On Tue, Apr 17, 2018 at 10:49:58PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund 
> 
> The datasheet have been expanded with more registers and the DT files
> have been updated with the new size. This change updates the example so
> writing new DT files can use the enchanted driver which uses the new
> registers.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../devicetree/bindings/thermal/rcar-gen3-thermal.txt   | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Applied with Simon's comments addressed.

Rob

Re: [PATCH v5 3/6] dt-bindings: arm: Document the RZN1D-DB board

[Rob Herring]

On Tue, Apr 17, 2018 at 12:04:18PM +0100, Michel Pollet wrote:
> This documents the RZ/N1 bindings for the RZN1D-DB board.
> 
> Signed-off-by: Michel Pollet 
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Please add acks/reviewed-bys when posting new versions.

Rob

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

[Rob Herring]

On Tue, Apr 17, 2018 at 7:42 AM, Phil Edworthy
<phil.edwor...@renesas.com> 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 <phil.edwor...@renesas.com>
> ---
> One point to mention is that I have made it possible for users to have
> unconncted 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?
>
> 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().
>
> Note: There are a few *code* lines over 80 chars, but this is just guidance,
>right? Especially as there are already some lines over 80 chars.
>
> snps:gpio fix
>
> Signed-off-by: Phil Edworthy <phil.edwor...@renesas.com>
> ---
>  .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 +++--
>  drivers/gpio/gpio-dwapb.c  | 42 
> +-
>  drivers/mfd/intel_quark_i2c_gpio.c |  3 +-
>  include/linux/platform_data/gpio-dwapb.h   |  3 +-
>  4 files changed, 44 insertions(+), 13 deletions(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH] DT: mmc: tmio_mmc: document R8A77980 bindings

[Rob Herring]

On Mon, Apr 16, 2018 at 09:30:02PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the Renesas SDHI bindings.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> 
> ---
> This patch is against the 'next' branch of Ulf Hansson's 'mmc.git' repo.
> 
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt |1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [RFC 1/3] dt-bindings: cpu: Add Renesas RZ/N1D SMP enable method.

[Rob Herring]

On Mon, Apr 16, 2018 at 10:34:57AM +0100, Michel Pollet wrote:
> Add a special enable method for second CA8 of the Renesas RZ/N1D
> (R9A06G032).
> 
> Signed-off-by: Michel Pollet <michel.pol...@bp.renesas.com>
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring <r...@kernel.org>

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

[Rob Herring]

On Fri, Apr 13, 2018 at 09:51:12AM +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 
> ---
> One point to mention is that I have made it possible for users to have
> unconncted 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?
> 
> 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().
> 
> Note: There are a few *code* lines over 80 chars, but this is just guidance,
>right? Especially as there are already some lines over 80 chars.
> ---
>  .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 -
>  drivers/gpio/gpio-dwapb.c  | 43 
> +-
>  drivers/mfd/intel_quark_i2c_gpio.c |  3 +-
>  include/linux/platform_data/gpio-dwapb.h   |  3 +-
>  4 files changed, 45 insertions(+), 13 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.
>  
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> index 226977f..3273504 100644
> --- a/drivers/gpio/gpio-dwapb.c
> +++ b/drivers/gpio/gpio-dwapb.c
> @@ -441,14 +441,19 @@ static void dwapb_configure_irqs(struct dwapb_gpio 
> *gpio,
>   irq_gc->chip_types[1].handler = handle_edge_irq;
>  
>   if (!pp->irq_shared) {
> - irq_set_chained_handler_and_data(pp->irq, dwapb_irq_handler,
> -  gpio);
> + int i;
> +
> + for (i = 0; i < pp->ngpio; i++) {
> + if (pp->irq[i])
> + irq_set_chained_handler_and_data(pp->irq[i],
> + dwapb_irq_handler, gpio);
> + }
>   } else {
>   /*
>* Request a shared IRQ since where MFD would have devices
>* using the same irq pin
>*/
> - err = devm_request_irq(gpio->dev, pp->irq,
> + err = devm_request_irq(gpio->dev, pp->irq[0],
>  dwapb_irq_handler_mfd,
>  IRQF_SHARED, "gpio-dwapb-mfd", gpio);
>   if (err) {
> @@ -524,7 +529,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
>   if (pp->idx == 0)
>   port->gc.set_config = dwapb_gpio_set_config;
>  
> - if (pp->irq)
> + if (pp->has_irq)
>   dwapb_configure_irqs(gpio, port, pp);
>  
>   err = gpiochip_add_data(>gc, port);
> @@ -535,7 +540,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
>   port->is_registered = true;
>  
>   /* Add GPIO-signaled ACPI event support */
> - if (pp->irq)
> + if (pp->has_irq)
>   acpi_gpiochip_request_interrupts(>gc);
>  
>   return err;
> @@ -601,13 +606,33 @@ 

Re: [PATCH] dt-bindings: dmaengine: rcar-dmac: document R8A77965 support

[Rob Herring]

On Mon, Apr 16, 2018 at 03:56:08PM +0200, Jacopo Mondi wrote:
> Add documentation for r8a77965 compatible string to rcar-dmac device
> tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 
> ---
> 
> Renesas R-Car M3-N support has been merged for v4.17.
> Document the missing device tree bindings.
> 
> ---
>  Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied.

Rob

Re: [PATCH] dt-bindings: serial: sh-sci: Add support for r8a77965 (H)SCIF

[Rob Herring]

On Mon, Apr 16, 2018 at 03:55:28PM +0200, Jacopo Mondi wrote:
> Add documentation for r8a77965 compatible string to Renesas sci-serial
> device tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi 
> ---
> 
> Renesas R-Car M3-N support has been merged for v4.17.
> Document the missing device tree bindings.
> 
> ---
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
>  1 file changed, 2 insertions(+)

Applied.

Rob

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

[Rob Herring]

On Mon, Apr 16, 2018 at 03:55:17PM +0200, Jacopo Mondi wrote:
> Add documentation for r8a77965 compatible string to renesas ravb device
> tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 
> Acked-by: Sergei Shtylyov 
> ---
> 
> Renesas R-Car M3-N support has been merged for v4.17.
> Document the missing device tree bindings.
> 
> ---
>  Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied.

Rob

Re: [PATCH] dt-bindings: gpio: Add support for r8a77965

[Rob Herring]

On Mon, Apr 16, 2018 at 03:55:04PM +0200, Jacopo Mondi wrote:
> Add compatible string for R-Car M3-N (r8a77965) in gpio-rcar.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> ---

You missed Simon's and my R-by's on v2.

> 
> Renesas R-Car M3-N support has been merged for v4.17.
> Document the missing device tree bindings.
> 
> ---
>  Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt 
> b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> index 9474138..f2af897 100644
> --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> @@ -14,6 +14,7 @@ Required Properties:
>  - "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO 
> controller.
>  - "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO 
> controller.
>  - "renesas,gpio-r8a7796": for R8A7796 (R-Car M3-W) compatible GPIO 
> controller.
> +- "renesas,gpio-r8a77965": for R8A77965 (R-Car M3-N) compatible GPIO 
> controller.
>  - "renesas,gpio-r8a77970": for R8A77970 (R-Car V3M) compatible GPIO 
> controller.
>  - "renesas,gpio-r8a77995": for R8A77995 (R-Car D3) compatible GPIO 
> controller.
>  - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller.
> --
> 2.7.4
> 

Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Rob Herring]

On Tue, Apr 10, 2018 at 12:53:09PM +0200, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH v4 5/8] dt-bindings: arm: Document the RZN1D-DB board

[Rob Herring]

On Tue, Apr 10, 2018 at 09:30:05AM +0100, Michel Pollet wrote:
> This documents the RZ/N1 bindings for the RZN1D-DB board.
> 
> Signed-off-by: Michel Pollet <michel.pol...@bp.renesas.com>
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node

[Rob Herring]

On Tue, Apr 10, 2018 at 09:30:03AM +0100, Michel Pollet wrote:
> The Renesas RZ/N1 Family (Part #R9A06G0xx) has a multi-function
> system controller. This documents the node used to encapsulate
> it's sub drivers.
> 
> Signed-off-by: Michel Pollet 
> ---
>  .../bindings/mfd/renesas,rzn1-sysctrl.txt  | 23 
> ++
>  1 file changed, 23 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt 
> b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
> new file mode 100644
> index 000..9897f8f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
> @@ -0,0 +1,23 @@
> +DT bindings for the Renesas RZ/N1 System Controller
> +
> +== System Controller Node ==
> +
> +The system controller node currently only hosts a single sub-node to handle
> +the rebooting of the CPU. Eventually it will host the clock driver, SMP
> +start handler, watchdog etc.

Please submit a complete binding for the h/w block.

Again, if the only reason you have sub nodes is to define compatible 
strings and in turn enumerate drivers, then you don't need the nodes in 
DT. DT is not the only way to instantiate drivers.

Rob

Re: [RESEND PATCH] serial: sh-sci: Document r8a77470 bindings

[Rob Herring]

On Mon, Apr 09, 2018 at 01:20:00PM +0100, Biju Das wrote:
> RZ/G1C (R8A77470) SoC also has the R-Car gen2 compatible SCIF and HSCIF
> ports, so document the SoC specific bindings.
> 
> Signed-off-by: Biju Das <biju@bp.renesas.com>
> Reviewed-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
> Reviewed-by: Simon Horman <horms+rene...@verge.net.au>
> ---
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH v2 5/5] DT: pci: rcar-pci: document R8A77980 bindings

[Rob Herring]

On Sun, Apr 08, 2018 at 09:10:43PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the R-Car PCIe bindings.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> 
> ---
> Changes in version 2:
> - new patch.
> 
>  Documentation/devicetree/bindings/pci/rcar-pci.txt |1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH v2 3/5] pcie-rcar: add R-Car gen3 PHY support

[Rob Herring]

On Sun, Apr 08, 2018 at 09:05:10PM +0300, Sergei Shtylyov wrote:
> On R-Car gen3 SoCs the PCIe PHY has its own register region -- and I have
> written  a generic PHY driver for it, thus we need to add the corresponding
> code in  rcar_pcie_hw_init_gen3() and call devm_phy_optional_get() at the
> driver's probing time,  so that the existing R-Car gen3 device trees (not
> having a PHY node) would still work (we only need  to power up the PHY on
> R-Car V3H).

Spurious spaces, again...

> 
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> 
> ---
> Changes in version 2:
> - updated the bindings.
> 
>  Documentation/devicetree/bindings/pci/rcar-pci.txt |5 +++

Otherwise,

Reviewed-by: Rob Herring <r...@kernel.org>

>  drivers/pci/host/pcie-rcar.c   |   27 
> +++--
>  2 files changed, 30 insertions(+), 2 deletions(-)

Re: [PATCH] phy: Renesas R-Car gen3 PCIe PHY driver

[Rob Herring]

On Wed, Apr 04, 2018 at 10:31:26PM +0300, Sergei Shtylyov wrote:
> This PHY is still mostly undocumented -- the only documented registers
> exist on R-Car V3H (R8A77980) SoC  where this PHY stays in a powered-down
> state after a reset and thus  we must power it on for PCIe to work...
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against the 'next' branch of Kishon's 'linux-phy.git' repo.
> 
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt |   32 ++

Separate patch please.

>  drivers/phy/renesas/Kconfig  |7 
>  drivers/phy/renesas/Makefile |1 
>  drivers/phy/renesas/phy-rcar-gen3-pcie.c |  158 
> +++
>  4 files changed, 198 insertions(+)
> 
> Index: linux-phy/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt
> ===
> --- /dev/null
> +++ linux-phy/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt
> @@ -0,0 +1,32 @@
> +* Renesas R-Car generation 3 PCIe PHY
> +
> +This file provides information on what the device node for the R-Car
> +generation 3 PCIe PHY contains.
> +
> +Required properties:
> +- compatible: "renesas,r8a77980-pcie-phy" if the device is a part of R8A77980
> +   SoC.
> +   "renesas,rcar-gen3-pcie-phy" for a generic R-Car Gen3 compatible
> +   device.
> +
> +   When compatible with the generic version, nodes must list the
> +   SoC-specific version corresponding to the platform first
> +   followed by the generic version.
> +
> +- reg: offset and length of the register block.
> +- clocks: clock phandle and specifier pair.
> +- power-domains: power domain phandle and specifier pair.
> +- resets: reset phandle and specifier pair.
> +- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
> +
> +Example (R-Car V3H):
> +
> + pcie-phy@e65d {
> + compatible = "renesas,r8a77980-pcie-phy",
> +  "renesas,rcar-gen3-pcie-phy";
> + reg = <0 0xe65d 0 0x8000>;
> + #phy-cells = <0>;
> + clocks = < CPG_MOD 319>;
> + power-domains = < 32>;
> + resets = < 319>;
> + };

Re: [PATCH v2 2/2] dt-bindings: pinctrl: sh-pfc: Document r8a77470 PFC support

[Rob Herring]

On Wed, Apr 04, 2018 at 04:22:57PM +0100, Biju Das wrote:
> Document PFC support for the R8A77470 SoC.
> 
> Signed-off-by: Biju Das <biju@bp.renesas.com>
> Reviewed-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
> ---
> V1->V2:
> * Incorporated sergie's review comment.
> 
>  Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring <r...@kernel.org>

Re: [PATCH/RFT v3 2/3] dt-bindings: thermal: rcar-thermal: add R8A77995 support

[Rob Herring]

On Tue, Apr 03, 2018 at 09:43:04PM +0900, Yoshihiro Kaneko wrote:
> Signed-off-by: Yoshihiro Kaneko 
> Reviewed-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> index 349e635..5ab5fcd 100644
> --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> @@ -3,7 +3,8 @@
>  Required properties:
>  - compatible : "renesas,thermal-",
>  "renesas,rcar-gen2-thermal" (with thermal-zone) or
> -"renesas,rcar-thermal" (without thermal-zone) as 
> fallback.
> +"renesas,rcar-thermal" (without thermal-zone) as
> +   fallback except R-Car D3.
> Examples with soctypes are:
>   - "renesas,thermal-r8a73a4" (R-Mobile APE6)
>   - "renesas,thermal-r8a7743" (RZ/G1M)
> @@ -12,13 +13,15 @@ Required properties:
>   - "renesas,thermal-r8a7791" (R-Car M2-W)
>   - "renesas,thermal-r8a7792" (R-Car V2H)
>   - "renesas,thermal-r8a7793" (R-Car M2-N)
> + - "renesas,thermal-r8a77995" (R-Car D3)
>  - reg: Address range of the thermal registers.
> The 1st reg will be recognized as common register
> if it has "interrupts".
>  
>  Option properties:
>  
> -- interrupts : use interrupt
> +- interrupts : use interrupt.
> +  Should contain 3 interrupts for R-Car D3.

And how many for other chips?

>  
>  Example (non interrupt support):
>  
> -- 
> 1.9.1
> 

Re: [PATCH v3 2/8] DT: reset: renesas,rzn1-reboot: document RZ/N1 reboot driver

[Rob Herring]

On Thu, Mar 29, 2018 at 08:46:58AM +0100, Michel Pollet wrote:
> The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
> as part of the sysctrl MFD to handle rebooting the CA7 cores.
> This documents the driver bindings.
> 
> Signed-off-by: Michel Pollet 
> ---
>  .../bindings/power/renesas,rzn1-reboot.txt   | 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt 
> b/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
> new file mode 100644
> index 000..f592769
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
> @@ -0,0 +1,20 @@
> +DT bindings for the Renesas RZ/N1 Reboot Driver
> +
> +== Reboot Driver Node ==
> +
> +The reboot driver is always a subnode of the system controller node, see
> +renesas,rzn1-sysctrl.txt for details.
> +
> +Bindings:
> ++ Required:
> + compatible = "renesas,rzn1-reboot";
> +
> +Example:
> + sysctrl: sysctrl@4000c000 {
> + compatible = "renesas,rzn1-sysctrl", "syscon", "simple-mfd";

Are there other functions for this block? If so, please define a 
complete binding for the block.

> + reg = <0x4000c000 0x1000>;
> +
> + reboot {
> + compatible = "renesas,rzn1-reboot";

Why is this node needed? The driver for "renesas,rzn1-sysctrl" should 
be able to register as a reboot handler/driver/provider.

Rob