[PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

	Hi,

This patch series adds support to the Renesas SCI serial driver for
  - the optional external clock on (H)SCI(F) and some SCIFA, where this
    pin can serve as a clock input,
  - the optional clock sources for the Baud Rate Generator for External
    Clock (BRG), as found on some SCIF variants and on HSCIF.
Using external clocks increases the range and accuracy of supported baud
rates. Please see the descriptions of the DTS patches for more detailed
information regarding the impact on the supported platforms.

For now this supports r8a7791/koelsch and r8a7795/salvator-x only, which
have an external SCIF_CLK running at 14.7456 MHz.
Support for other R-Car platforms will be added later.

Testing:
  - The Baud Rate Generator for External Clock (BRG) was tested with
    SCIF and HSCIF on r8a7791/koelsch and r8a7795/salvator-x,
  - The external clock input on (H)SCK was tested on r8a7795/salvator-x
    by feeding an external clock signal to (H)SCIF1,
  - Various bit rates were monitored using a SmartScope,
  - Regression testing was done on Renesas ARM platforms that use SCIFA
    as the console (r8a73a4/ape6evm, r8a7740/armadillo, and
    sh73a0/kzm9g).
	      
Dependencies:
  - This series depends on the series "[PATCH v2 00/16] serial: sh-sci:
    Clock Cleanups",
  - The SH patch 25 depends on the "serial: sh-sci" patches in this
    series,
  - The DTS patches 21-24 can be applied independently, once the DT
    binding patches 1-2 are accepted,
  - r8a7791/r8a7795 has a runtime dependency on series "[PATCH 0/2]
    pinctrl: sh-pfc: r8a7791/r8a7795: Add SCIF_CLK support",
  - r8a7795 also depends on
       - platform support in e.g. renesas-drivers-2015-11-17-v4.4-rc1,
       - "[PATCH] pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups, and
	 functions",
       - "[PATCH] arm64: renesas: r8a7795 dtsi: Add all HSCIF nodes".
  - Legacy SH has a runtime dependency on:
      - series "[PATCH 0/2] drivers: sh: clk: Cleanup clock API",

Thanks for your comments!

Geert Uytterhoeven (25):
  serial: sh-sci: Update DT binding documentation for external clock
    input
  serial: sh-sci: Update DT binding documentation for BRG support
  serial: sh-sci: Drop useless check for zero sampling_rate
  serial: sh-sci: Grammar s/Get ... for/Get ... from/
  serial: sh-sci: Drop unused frame_len parameter for
    sci_baud_calc_hscif()
  serial: sh-sci: Don't overwrite clock selection in
    serial_console_write()
  serial: sh-sci: Convert from clk_get() to devm_clk_get()
  serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned
  serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()
  serial: sh-sci: Improve bit rate error calculation for HSCIF
  serial: sh-sci: Avoid calculating the receive margin for HSCIF
  serial: sh-sci: Merge sci_scbrr_calc() and sci_baud_calc_hscif()
  serial: sh-sci: Take into account sampling rate for max baud rate
  serial: sh-sci: Add BRG register definitions
  serial: sh-sci: Replace struct sci_port_info by type/regtype encoding
  serial: sh-sci: Correct SCIF type on RZ/A1H
  serial: sh-sci: Correct SCIF type on R-Car for BRG
  serial: sh-sci: Prepare for multiple clocks and baud rate generators
  serial: sh-sci: Add support for optional external (H)SCK input
  serial: sh-sci: Add support for optional BRG on (H)SCIF
  ARM: shmobile: r8a7791 dtsi: Add BRG support for (H)SCIF
  ARM: shmobile: koelsch dts: Enable SCIF_CLK frequency and pins
  arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF
  arm64: renesas: salvator-x dts: Enable SCIF_CLK frequency and pins
  sh: sh7734: Correct SCIF type for BRG

 .../bindings/serial/renesas,sci-serial.txt         |   9 +
 arch/arm/boot/dts/r8a7791-koelsch.dts              |  13 +
 arch/arm/boot/dts/r8a7791.dtsi                     |  54 ++-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  12 +
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           |  74 ++-
 arch/sh/kernel/cpu/sh4a/setup-sh7734.c             |  12 +-
 drivers/tty/serial/sh-sci.c                        | 530 +++++++++++++++------
 drivers/tty/serial/sh-sci.h                        |   5 +
 include/linux/serial_sci.h                         |   1 +
 9 files changed, 508 insertions(+), 202 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

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

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

[PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

	Hi,

This patch series adds support to the Renesas SCI serial driver for
  - the optional external clock on (H)SCI(F) and some SCIFA, where this
    pin can serve as a clock input,
  - the optional clock sources for the Baud Rate Generator for External
    Clock (BRG), as found on some SCIF variants and on HSCIF.
Using external clocks increases the range and accuracy of supported baud
rates. Please see the descriptions of the DTS patches for more detailed
information regarding the impact on the supported platforms.

For now this supports r8a7791/koelsch and r8a7795/salvator-x only, which
have an external SCIF_CLK running at 14.7456 MHz.
Support for other R-Car platforms will be added later.

Testing:
  - The Baud Rate Generator for External Clock (BRG) was tested with
    SCIF and HSCIF on r8a7791/koelsch and r8a7795/salvator-x,
  - The external clock input on (H)SCK was tested on r8a7795/salvator-x
    by feeding an external clock signal to (H)SCIF1,
  - Various bit rates were monitored using a SmartScope,
  - Regression testing was done on Renesas ARM platforms that use SCIFA
    as the console (r8a73a4/ape6evm, r8a7740/armadillo, and
    sh73a0/kzm9g).
	      
Dependencies:
  - This series depends on the series "[PATCH v2 00/16] serial: sh-sci:
    Clock Cleanups",
  - The SH patch 25 depends on the "serial: sh-sci" patches in this
    series,
  - The DTS patches 21-24 can be applied independently, once the DT
    binding patches 1-2 are accepted,
  - r8a7791/r8a7795 has a runtime dependency on series "[PATCH 0/2]
    pinctrl: sh-pfc: r8a7791/r8a7795: Add SCIF_CLK support",
  - r8a7795 also depends on
       - platform support in e.g. renesas-drivers-2015-11-17-v4.4-rc1,
       - "[PATCH] pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups, and
	 functions",
       - "[PATCH] arm64: renesas: r8a7795 dtsi: Add all HSCIF nodes".
  - Legacy SH has a runtime dependency on:
      - series "[PATCH 0/2] drivers: sh: clk: Cleanup clock API",

Thanks for your comments!

Geert Uytterhoeven (25):
  serial: sh-sci: Update DT binding documentation for external clock
    input
  serial: sh-sci: Update DT binding documentation for BRG support
  serial: sh-sci: Drop useless check for zero sampling_rate
  serial: sh-sci: Grammar s/Get ... for/Get ... from/
  serial: sh-sci: Drop unused frame_len parameter for
    sci_baud_calc_hscif()
  serial: sh-sci: Don't overwrite clock selection in
    serial_console_write()
  serial: sh-sci: Convert from clk_get() to devm_clk_get()
  serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned
  serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()
  serial: sh-sci: Improve bit rate error calculation for HSCIF
  serial: sh-sci: Avoid calculating the receive margin for HSCIF
  serial: sh-sci: Merge sci_scbrr_calc() and sci_baud_calc_hscif()
  serial: sh-sci: Take into account sampling rate for max baud rate
  serial: sh-sci: Add BRG register definitions
  serial: sh-sci: Replace struct sci_port_info by type/regtype encoding
  serial: sh-sci: Correct SCIF type on RZ/A1H
  serial: sh-sci: Correct SCIF type on R-Car for BRG
  serial: sh-sci: Prepare for multiple clocks and baud rate generators
  serial: sh-sci: Add support for optional external (H)SCK input
  serial: sh-sci: Add support for optional BRG on (H)SCIF
  ARM: shmobile: r8a7791 dtsi: Add BRG support for (H)SCIF
  ARM: shmobile: koelsch dts: Enable SCIF_CLK frequency and pins
  arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF
  arm64: renesas: salvator-x dts: Enable SCIF_CLK frequency and pins
  sh: sh7734: Correct SCIF type for BRG

 .../bindings/serial/renesas,sci-serial.txt         |   9 +
 arch/arm/boot/dts/r8a7791-koelsch.dts              |  13 +
 arch/arm/boot/dts/r8a7791.dtsi                     |  54 ++-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  12 +
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           |  74 ++-
 arch/sh/kernel/cpu/sh4a/setup-sh7734.c             |  12 +-
 drivers/tty/serial/sh-sci.c                        | 530 +++++++++++++++------
 drivers/tty/serial/sh-sci.h                        |   5 +
 include/linux/serial_sci.h                         |   1 +
 9 files changed, 508 insertions(+), 202 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

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

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

[PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

Amend the DT bindings to include the optional external clock on
(H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
depending on board wiring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: devicetree@vger.kernel.org
---
 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 2c9e6b8477e92792..8efc9b6f35637fbb 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -43,6 +43,9 @@ Required properties:
   - clocks: Must contain a phandle and clock-specifier pair for each entry
     in clock-names.
   - clock-names: Must contain "fck" for the SCIx UART functional clock.
+    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
+      - "hsck" for the optional external clock input (on HSCIF),
+      - "sck" for the optional external clock input (on other variants).
 
 Note: Each enabled SCIx UART should have an alias correctly numbered in the
 "aliases" node.
-- 
1.9.1

[PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

Amend the DT bindings to include the optional external clock on
(H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
depending on board wiring.

Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 2c9e6b8477e92792..8efc9b6f35637fbb 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -43,6 +43,9 @@ Required properties:
   - clocks: Must contain a phandle and clock-specifier pair for each entry
     in clock-names.
   - clock-names: Must contain "fck" for the SCIx UART functional clock.
+    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
+      - "hsck" for the optional external clock input (on HSCIF),
+      - "sck" for the optional external clock input (on other variants).
 
 Note: Each enabled SCIx UART should have an alias correctly numbered in the
 "aliases" node.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

Amend the DT bindings to include the optional external clock on
(H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
depending on board wiring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: devicetree@vger.kernel.org
---
 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 2c9e6b8477e92792..8efc9b6f35637fbb 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -43,6 +43,9 @@ Required properties:
   - clocks: Must contain a phandle and clock-specifier pair for each entry
     in clock-names.
   - clock-names: Must contain "fck" for the SCIx UART functional clock.
+    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
+      - "hsck" for the optional external clock input (on HSCIF),
+      - "sck" for the optional external clock input (on other variants).
 
 Note: Each enabled SCIx UART should have an alias correctly numbered in the
 "aliases" node.
-- 
1.9.1

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
> Amend the DT bindings to include the optional external clock on
> (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
> depending on board wiring.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: devicetree@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> @@ -43,6 +43,9 @@ Required properties:
>    - clocks: Must contain a phandle and clock-specifier pair for each entry
>      in clock-names.
>    - clock-names: Must contain "fck" for the SCIx UART functional clock.
> +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:

Could you list the SCIFA variants that support external clocks ?

> +      - "hsck" for the optional external clock input (on HSCIF),
> +      - "sck" for the optional external clock input (on other variants).
> 
>  Note: Each enabled SCIx UART should have an alias correctly numbered in the
> "aliases" node.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
> Amend the DT bindings to include the optional external clock on
> (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
> depending on board wiring.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> @@ -43,6 +43,9 @@ Required properties:
>    - clocks: Must contain a phandle and clock-specifier pair for each entry
>      in clock-names.
>    - clock-names: Must contain "fck" for the SCIx UART functional clock.
> +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:

Could you list the SCIFA variants that support external clocks ?

> +      - "hsck" for the optional external clock input (on HSCIF),
> +      - "sck" for the optional external clock input (on other variants).
> 
>  Note: Each enabled SCIx UART should have an alias correctly numbered in the
> "aliases" node.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
> Amend the DT bindings to include the optional external clock on
> (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
> depending on board wiring.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: devicetree@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> @@ -43,6 +43,9 @@ Required properties:
>    - clocks: Must contain a phandle and clock-specifier pair for each entry
>      in clock-names.
>    - clock-names: Must contain "fck" for the SCIx UART functional clock.
> +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:

Could you list the SCIFA variants that support external clocks ?

> +      - "hsck" for the optional external clock input (on HSCIF),
> +      - "sck" for the optional external clock input (on other variants).
> 
>  Note: Each enabled SCIx UART should have an alias correctly numbered in the
> "aliases" node.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Laurent Pinchart]

Hi Geert,

On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
> > Amend the DT bindings to include the optional external clock on
> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
> > depending on board wiring.
> > 
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: devicetree@vger.kernel.org
> > ---
> > 
> >  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> > b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
> > 2c9e6b8477e92792..8efc9b6f35637fbb 100644
> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> > 
> > @@ -43,6 +43,9 @@ Required properties:
> >    - clocks: Must contain a phandle and clock-specifier pair for each
> >    entry
> >    
> >      in clock-names.
> >    
> >    - clock-names: Must contain "fck" for the SCIx UART functional clock.
> > 
> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
> Could you list the SCIFA variants that support external clocks ?
> 
> > +      - "hsck" for the optional external clock input (on HSCIF),
> > +      - "sck" for the optional external clock input (on other variants).

Additionally, those clocks are used as inputs to the baud rate generator for 
external clocks, as the ones listed in patch 02/25 in this series. I'd merge 
the two patches and clarify the wording.

> >  Note: Each enabled SCIx UART should have an alias correctly numbered in
> >  the "aliases" node.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Laurent Pinchart]

Hi Geert,

On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
> > Amend the DT bindings to include the optional external clock on
> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
> > depending on board wiring.
> > 
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: devicetree@vger.kernel.org
> > ---
> > 
> >  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> > b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
> > 2c9e6b8477e92792..8efc9b6f35637fbb 100644
> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> > 
> > @@ -43,6 +43,9 @@ Required properties:
> >    - clocks: Must contain a phandle and clock-specifier pair for each
> >    entry
> >    
> >      in clock-names.
> >    
> >    - clock-names: Must contain "fck" for the SCIx UART functional clock.
> > 
> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
> Could you list the SCIFA variants that support external clocks ?
> 
> > +      - "hsck" for the optional external clock input (on HSCIF),
> > +      - "sck" for the optional external clock input (on other variants).

Additionally, those clocks are used as inputs to the baud rate generator for 
external clocks, as the ones listed in patch 02/25 in this series. I'd merge 
the two patches and clarify the wording.

> >  Note: Each enabled SCIx UART should have an alias correctly numbered in
> >  the "aliases" node.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
>> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>> > Amend the DT bindings to include the optional external clock on
>> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
>> > depending on board wiring.

>> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >
>> > @@ -43,6 +43,9 @@ Required properties:
>> >    - clocks: Must contain a phandle and clock-specifier pair for each
>> >    entry
>> >
>> >      in clock-names.
>> >
>> >    - clock-names: Must contain "fck" for the SCIx UART functional clock.
>> >
>> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>> Could you list the SCIFA variants that support external clocks ?
>>
>> > +      - "hsck" for the optional external clock input (on HSCIF),
>> > +      - "sck" for the optional external clock input (on other variants).
>
> Additionally, those clocks are used as inputs to the baud rate generator for
> external clocks, as the ones listed in patch 02/25 in this series. I'd merge
> the two patches and clarify the wording.

"SCK" predates the BRG, it even exists on SCI in H8/300.

That SCK is used as input to the BRG is just an artefact of how the BRG was
added to the SCIF. The BRG is just muxed with the existing SCK to form a clock
input, which is muxed with the BRR clock through the SCSCR.CKEx bits.
And the BRG itself can choose between SCIF_CLK and INT_CLK.

Hence that's why I split it in two parts.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
>> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>> > Amend the DT bindings to include the optional external clock on
>> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
>> > depending on board wiring.

>> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >
>> > @@ -43,6 +43,9 @@ Required properties:
>> >    - clocks: Must contain a phandle and clock-specifier pair for each
>> >    entry
>> >
>> >      in clock-names.
>> >
>> >    - clock-names: Must contain "fck" for the SCIx UART functional clock.
>> >
>> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>> Could you list the SCIFA variants that support external clocks ?
>>
>> > +      - "hsck" for the optional external clock input (on HSCIF),
>> > +      - "sck" for the optional external clock input (on other variants).
>
> Additionally, those clocks are used as inputs to the baud rate generator for
> external clocks, as the ones listed in patch 02/25 in this series. I'd merge
> the two patches and clarify the wording.

"SCK" predates the BRG, it even exists on SCI in H8/300.

That SCK is used as input to the BRG is just an artefact of how the BRG was
added to the SCIF. The BRG is just muxed with the existing SCK to form a clock
input, which is muxed with the BRR clock through the SCSCR.CKEx bits.
And the BRG itself can choose between SCIF_CLK and INT_CLK.

Hence that's why I split it in two parts.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
>> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>> > Amend the DT bindings to include the optional external clock on
>> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
>> > depending on board wiring.

>> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >
>> > @@ -43,6 +43,9 @@ Required properties:
>> >    - clocks: Must contain a phandle and clock-specifier pair for each
>> >    entry
>> >
>> >      in clock-names.
>> >
>> >    - clock-names: Must contain "fck" for the SCIx UART functional clock.
>> >
>> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>> Could you list the SCIFA variants that support external clocks ?
>>
>> > +      - "hsck" for the optional external clock input (on HSCIF),
>> > +      - "sck" for the optional external clock input (on other variants).
>
> Additionally, those clocks are used as inputs to the baud rate generator for
> external clocks, as the ones listed in patch 02/25 in this series. I'd merge
> the two patches and clarify the wording.

"SCK" predates the BRG, it even exists on SCI in H8/300.

That SCK is used as input to the BRG is just an artefact of how the BRG was
added to the SCIF. The BRG is just muxed with the existing SCK to form a clock
input, which is muxed with the BRR clock through the SCSCR.CKEx bits.
And the BRG itself can choose between SCIF_CLK and INT_CLK.

Hence that's why I split it in two parts.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Laurent Pinchart]

Hi Geert,

On Thursday 19 November 2015 21:39:50 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
> >> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
> >> > Amend the DT bindings to include the optional external clock on
> >> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
> >> > depending on board wiring.
> >> > 
> >> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> > 
> >> > @@ -43,6 +43,9 @@ Required properties:
> >> >    - clocks: Must contain a phandle and clock-specifier pair for each
> >> >      entry in clock-names.
> >> >    - clock-names: Must contain "fck" for the SCIx UART functional
> >> >    clock.
> >> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
> >>
> >> Could you list the SCIFA variants that support external clocks ?
> >> 
> >> > +      - "hsck" for the optional external clock input (on HSCIF),
> >> > +      - "sck" for the optional external clock input (on other
> >> > variants).
> > 
> > Additionally, those clocks are used as inputs to the baud rate generator
> > for external clocks, as the ones listed in patch 02/25 in this series.
> > I'd merge the two patches and clarify the wording.
> 
> "SCK" predates the BRG, it even exists on SCI in H8/300.
> 
> That SCK is used as input to the BRG is just an artefact of how the BRG was
> added to the SCIF. The BRG is just muxed with the existing SCK to form a
> clock input, which is muxed with the BRR clock through the SCSCR.CKEx bits.
> And the BRG itself can choose between SCIF_CLK and INT_CLK.
> 
> Hence that's why I split it in two parts.

It makes sense with the explanation.

I think some of the patches should be clarified to mention BRG-EC (or whatever 
you want to call it) instead of just BRG, as otherwise it's very easy to 
confuse the two BRGs. The (H)SCK clock is an input to the internal BRG, while 
the SCIF_CLK and INT_CLK are inputs to the BRG-EC. Without clarification the 
DT bindings and the code can be hard to understand.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Laurent Pinchart]

Hi Geert,

On Thursday 19 November 2015 21:39:50 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
> >> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
> >> > Amend the DT bindings to include the optional external clock on
> >> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
> >> > depending on board wiring.
> >> > 
> >> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> > 
> >> > @@ -43,6 +43,9 @@ Required properties:
> >> >    - clocks: Must contain a phandle and clock-specifier pair for each
> >> >      entry in clock-names.
> >> >    - clock-names: Must contain "fck" for the SCIx UART functional
> >> >    clock.
> >> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
> >>
> >> Could you list the SCIFA variants that support external clocks ?
> >> 
> >> > +      - "hsck" for the optional external clock input (on HSCIF),
> >> > +      - "sck" for the optional external clock input (on other
> >> > variants).
> > 
> > Additionally, those clocks are used as inputs to the baud rate generator
> > for external clocks, as the ones listed in patch 02/25 in this series.
> > I'd merge the two patches and clarify the wording.
> 
> "SCK" predates the BRG, it even exists on SCI in H8/300.
> 
> That SCK is used as input to the BRG is just an artefact of how the BRG was
> added to the SCIF. The BRG is just muxed with the existing SCK to form a
> clock input, which is muxed with the BRR clock through the SCSCR.CKEx bits.
> And the BRG itself can choose between SCIF_CLK and INT_CLK.
> 
> Hence that's why I split it in two parts.

It makes sense with the explanation.

I think some of the patches should be clarified to mention BRG-EC (or whatever 
you want to call it) instead of just BRG, as otherwise it's very easy to 
confuse the two BRGs. The (H)SCK clock is an input to the internal BRG, while 
the SCIF_CLK and INT_CLK are inputs to the BRG-EC. Without clarification the 
DT bindings and the code can be hard to understand.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Laurent Pinchart]

Hi Geert,

On Thursday 19 November 2015 21:39:50 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
> >> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
> >> > Amend the DT bindings to include the optional external clock on
> >> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
> >> > depending on board wiring.
> >> > 
> >> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> > 
> >> > @@ -43,6 +43,9 @@ Required properties:
> >> >    - clocks: Must contain a phandle and clock-specifier pair for each
> >> >      entry in clock-names.
> >> >    - clock-names: Must contain "fck" for the SCIx UART functional
> >> >    clock.
> >> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
> >>
> >> Could you list the SCIFA variants that support external clocks ?
> >> 
> >> > +      - "hsck" for the optional external clock input (on HSCIF),
> >> > +      - "sck" for the optional external clock input (on other
> >> > variants).
> > 
> > Additionally, those clocks are used as inputs to the baud rate generator
> > for external clocks, as the ones listed in patch 02/25 in this series.
> > I'd merge the two patches and clarify the wording.
> 
> "SCK" predates the BRG, it even exists on SCI in H8/300.
> 
> That SCK is used as input to the BRG is just an artefact of how the BRG was
> added to the SCIF. The BRG is just muxed with the existing SCK to form a
> clock input, which is muxed with the BRR clock through the SCSCR.CKEx bits.
> And the BRG itself can choose between SCIF_CLK and INT_CLK.
> 
> Hence that's why I split it in two parts.

It makes sense with the explanation.

I think some of the patches should be clarified to mention BRG-EC (or whatever 
you want to call it) instead of just BRG, as otherwise it's very easy to 
confuse the two BRGs. The (H)SCK clock is an input to the internal BRG, while 
the SCIF_CLK and INT_CLK are inputs to the BRG-EC. Without clarification the 
DT bindings and the code can be hard to understand.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:17 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 21:39:50 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
>> >> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>> >> > Amend the DT bindings to include the optional external clock on
>> >> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
>> >> > depending on board wiring.
>> >> >
>> >> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >> >
>> >> > @@ -43,6 +43,9 @@ Required properties:
>> >> >    - clocks: Must contain a phandle and clock-specifier pair for each
>> >> >      entry in clock-names.
>> >> >    - clock-names: Must contain "fck" for the SCIx UART functional
>> >> >    clock.
>> >> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>> >>
>> >> Could you list the SCIFA variants that support external clocks ?
>> >>
>> >> > +      - "hsck" for the optional external clock input (on HSCIF),
>> >> > +      - "sck" for the optional external clock input (on other
>> >> > variants).
>> >
>> > Additionally, those clocks are used as inputs to the baud rate generator
>> > for external clocks, as the ones listed in patch 02/25 in this series.
>> > I'd merge the two patches and clarify the wording.
>>
>> "SCK" predates the BRG, it even exists on SCI in H8/300.
>>
>> That SCK is used as input to the BRG is just an artefact of how the BRG was
>> added to the SCIF. The BRG is just muxed with the existing SCK to form a
>> clock input, which is muxed with the BRR clock through the SCSCR.CKEx bits.
>> And the BRG itself can choose between SCIF_CLK and INT_CLK.
>>
>> Hence that's why I split it in two parts.
>
> It makes sense with the explanation.
>
> I think some of the patches should be clarified to mention BRG-EC (or whatever
> you want to call it) instead of just BRG, as otherwise it's very easy to
> confuse the two BRGs. The (H)SCK clock is an input to the internal BRG, while
> the SCIF_CLK and INT_CLK are inputs to the BRG-EC. Without clarification the
> DT bindings and the code can be hard to understand.

The (H)SCK clock is not an input to the internal BRG: it's used directly as the
sampling clock.

I'll add more clarification...

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:17 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 21:39:50 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote:
>> >> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>> >> > Amend the DT bindings to include the optional external clock on
>> >> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input,
>> >> > depending on board wiring.
>> >> >
>> >> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >> >
>> >> > @@ -43,6 +43,9 @@ Required properties:
>> >> >    - clocks: Must contain a phandle and clock-specifier pair for each
>> >> >      entry in clock-names.
>> >> >    - clock-names: Must contain "fck" for the SCIx UART functional
>> >> >    clock.
>> >> > +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>> >>
>> >> Could you list the SCIFA variants that support external clocks ?
>> >>
>> >> > +      - "hsck" for the optional external clock input (on HSCIF),
>> >> > +      - "sck" for the optional external clock input (on other
>> >> > variants).
>> >
>> > Additionally, those clocks are used as inputs to the baud rate generator
>> > for external clocks, as the ones listed in patch 02/25 in this series.
>> > I'd merge the two patches and clarify the wording.
>>
>> "SCK" predates the BRG, it even exists on SCI in H8/300.
>>
>> That SCK is used as input to the BRG is just an artefact of how the BRG was
>> added to the SCIF. The BRG is just muxed with the existing SCK to form a
>> clock input, which is muxed with the BRR clock through the SCSCR.CKEx bits.
>> And the BRG itself can choose between SCIF_CLK and INT_CLK.
>>
>> Hence that's why I split it in two parts.
>
> It makes sense with the explanation.
>
> I think some of the patches should be clarified to mention BRG-EC (or whatever
> you want to call it) instead of just BRG, as otherwise it's very easy to
> confuse the two BRGs. The (H)SCK clock is an input to the internal BRG, while
> the SCIF_CLK and INT_CLK are inputs to the BRG-EC. Without clarification the
> DT bindings and the code can be hard to understand.

The (H)SCK clock is not an input to the internal BRG: it's used directly as the
sampling clock.

I'll add more clarification...

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:19 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
>> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
>> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> @@ -43,6 +43,9 @@ Required properties:
>>    - clocks: Must contain a phandle and clock-specifier pair for each entry
>>      in clock-names.
>>    - clock-names: Must contain "fck" for the SCIx UART functional clock.
>> +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>
> Could you list the SCIFA variants that support external clocks ?

The list is in the commit description of "[PATCH 19/25] serial: sh-sci: Add
support for optional external (H)SCK input": sh7723, sh7724, and r8a7740.

Note that the list is probably incomplete, so I don't know if it's that useful
to have it in the binding docs. Especially as I haven't verified yet that it
actually works ;-)

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:19 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
>> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
>> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> @@ -43,6 +43,9 @@ Required properties:
>>    - clocks: Must contain a phandle and clock-specifier pair for each entry
>>      in clock-names.
>>    - clock-names: Must contain "fck" for the SCIx UART functional clock.
>> +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>
> Could you list the SCIFA variants that support external clocks ?

The list is in the commit description of "[PATCH 19/25] serial: sh-sci: Add
support for optional external (H)SCK input": sh7723, sh7724, and r8a7740.

Note that the list is probably incomplete, so I don't know if it's that useful
to have it in the binding docs. Especially as I haven't verified yet that it
actually works ;-)

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:33 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Nov 19, 2015 at 9:19 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>>> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
>>> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
>>> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> @@ -43,6 +43,9 @@ Required properties:
>>>    - clocks: Must contain a phandle and clock-specifier pair for each entry
>>>      in clock-names.
>>>    - clock-names: Must contain "fck" for the SCIx UART functional clock.
>>> +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>>
>> Could you list the SCIFA variants that support external clocks ?
>
> The list is in the commit description of "[PATCH 19/25] serial: sh-sci: Add
> support for optional external (H)SCK input": sh7723, sh7724, and r8a7740.
>
> Note that the list is probably incomplete, so I don't know if it's that useful
> to have it in the binding docs. Especially as I haven't verified yet that it
> actually works ;-)

For the record: on r8a7740, this feature is not available on SCIFA instances
2-7. The sole pins providing access to SCIFA_SCK[01] are muxed for Ethernet use
on r8a7740/armadillo. So it's unlikely I'll be able to support and test this.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:33 PM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> On Thu, Nov 19, 2015 at 9:19 PM, Laurent Pinchart
> <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
>> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>>> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
>>> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
>>> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> @@ -43,6 +43,9 @@ Required properties:
>>>    - clocks: Must contain a phandle and clock-specifier pair for each entry
>>>      in clock-names.
>>>    - clock-names: Must contain "fck" for the SCIx UART functional clock.
>>> +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>>
>> Could you list the SCIFA variants that support external clocks ?
>
> The list is in the commit description of "[PATCH 19/25] serial: sh-sci: Add
> support for optional external (H)SCK input": sh7723, sh7724, and r8a7740.
>
> Note that the list is probably incomplete, so I don't know if it's that useful
> to have it in the binding docs. Especially as I haven't verified yet that it
> actually works ;-)

For the record: on r8a7740, this feature is not available on SCIFA instances
2-7. The sole pins providing access to SCIFA_SCK[01] are muxed for Ethernet use
on r8a7740/armadillo. So it's unlikely I'll be able to support and test this.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/25] serial: sh-sci: Update DT binding documentation for external clock input

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:33 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Nov 19, 2015 at 9:19 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote:
>>> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
>>> 2c9e6b8477e92792..8efc9b6f35637fbb 100644
>>> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> @@ -43,6 +43,9 @@ Required properties:
>>>    - clocks: Must contain a phandle and clock-specifier pair for each entry
>>>      in clock-names.
>>>    - clock-names: Must contain "fck" for the SCIx UART functional clock.
>>> +    On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>>
>> Could you list the SCIFA variants that support external clocks ?
>
> The list is in the commit description of "[PATCH 19/25] serial: sh-sci: Add
> support for optional external (H)SCK input": sh7723, sh7724, and r8a7740.
>
> Note that the list is probably incomplete, so I don't know if it's that useful
> to have it in the binding docs. Especially as I haven't verified yet that it
> actually works ;-)

For the record: on r8a7740, this feature is not available on SCIFA instances
2-7. The sole pins providing access to SCIFA_SCK[01] are muxed for Ethernet use
on r8a7740/armadillo. So it's unlikely I'll be able to support and test this.

Gr{oetje,eeting}s,

                        Geert

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

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

[PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Geert Uytterhoeven]

Amend the DT bindings to include the optional clock sources for the Baud
Rate Generator for External Clock (BRG), as found on some SCIF variants
and on HSCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: devicetree@vger.kernel.org
---
 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 8efc9b6f35637fbb..ae907e39b11c2a5a 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -46,6 +46,12 @@ Required properties:
     On (H)SCI(F) and some SCIFA, an additional clock may be specified:
       - "hsck" for the optional external clock input (on HSCIF),
       - "sck" for the optional external clock input (on other variants).
+    On UARTs equipped with a Baud Rate Generator for External Clock (BRG)
+    (some SCIF and HSCIF), additional clocks may be specified:
+      - "int_clk" for the optional internal clock source for the frequency
+	divider (typically the (AXI or SHwy) bus clock),
+      - "scif_clk" for the optional external clock source for the frequency
+	divider (SCIF_CLK).
 
 Note: Each enabled SCIx UART should have an alias correctly numbered in the
 "aliases" node.
-- 
1.9.1

[PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Geert Uytterhoeven]

Amend the DT bindings to include the optional clock sources for the Baud
Rate Generator for External Clock (BRG), as found on some SCIF variants
and on HSCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 8efc9b6f35637fbb..ae907e39b11c2a5a 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -46,6 +46,12 @@ Required properties:
     On (H)SCI(F) and some SCIFA, an additional clock may be specified:
       - "hsck" for the optional external clock input (on HSCIF),
       - "sck" for the optional external clock input (on other variants).
+    On UARTs equipped with a Baud Rate Generator for External Clock (BRG)
+    (some SCIF and HSCIF), additional clocks may be specified:
+      - "int_clk" for the optional internal clock source for the frequency
+	divider (typically the (AXI or SHwy) bus clock),
+      - "scif_clk" for the optional external clock source for the frequency
+	divider (SCIF_CLK).
 
 Note: Each enabled SCIx UART should have an alias correctly numbered in the
 "aliases" node.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Geert Uytterhoeven]

Amend the DT bindings to include the optional clock sources for the Baud
Rate Generator for External Clock (BRG), as found on some SCIF variants
and on HSCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: devicetree@vger.kernel.org
---
 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 8efc9b6f35637fbb..ae907e39b11c2a5a 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -46,6 +46,12 @@ Required properties:
     On (H)SCI(F) and some SCIFA, an additional clock may be specified:
       - "hsck" for the optional external clock input (on HSCIF),
       - "sck" for the optional external clock input (on other variants).
+    On UARTs equipped with a Baud Rate Generator for External Clock (BRG)
+    (some SCIF and HSCIF), additional clocks may be specified:
+      - "int_clk" for the optional internal clock source for the frequency
+	divider (typically the (AXI or SHwy) bus clock),
+      - "scif_clk" for the optional external clock source for the frequency
+	divider (SCIF_CLK).
 
 Note: Each enabled SCIx UART should have an alias correctly numbered in the
 "aliases" node.
-- 
1.9.1

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
> Amend the DT bindings to include the optional clock sources for the Baud
> Rate Generator for External Clock (BRG), as found on some SCIF variants
> and on HSCIF.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: devicetree@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
> 8efc9b6f35637fbb..ae907e39b11c2a5a 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> @@ -46,6 +46,12 @@ Required properties:
>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>        - "hsck" for the optional external clock input (on HSCIF),
>        - "sck" for the optional external clock input (on other variants).
> +    On UARTs equipped with a Baud Rate Generator for External Clock (BRG)
> +    (some SCIF and HSCIF), additional clocks may be specified:
> +      - "int_clk" for the optional internal clock source for the frequency
> +	divider (typically the (AXI or SHwy) bus clock),

Isn't this always the same clock as the SCIF functional clock ?

> +      - "scif_clk" for the optional external clock source for the frequency
> +	divider (SCIF_CLK).
> 
>  Note: Each enabled SCIx UART should have an alias correctly numbered in the
> "aliases" node.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
> Amend the DT bindings to include the optional clock sources for the Baud
> Rate Generator for External Clock (BRG), as found on some SCIF variants
> and on HSCIF.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: devicetree@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index
> 8efc9b6f35637fbb..ae907e39b11c2a5a 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> @@ -46,6 +46,12 @@ Required properties:
>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>        - "hsck" for the optional external clock input (on HSCIF),
>        - "sck" for the optional external clock input (on other variants).
> +    On UARTs equipped with a Baud Rate Generator for External Clock (BRG)
> +    (some SCIF and HSCIF), additional clocks may be specified:
> +      - "int_clk" for the optional internal clock source for the frequency
> +	divider (typically the (AXI or SHwy) bus clock),

Isn't this always the same clock as the SCIF functional clock ?

> +      - "scif_clk" for the optional external clock source for the frequency
> +	divider (SCIF_CLK).
> 
>  Note: Each enabled SCIx UART should have an alias correctly numbered in the
> "aliases" node.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
>> Amend the DT bindings to include the optional clock sources for the Baud
>> Rate Generator for External Clock (BRG), as found on some SCIF variants
>> and on HSCIF.

>> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> @@ -46,6 +46,12 @@ Required properties:
>>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>>        - "hsck" for the optional external clock input (on HSCIF),
>>        - "sck" for the optional external clock input (on other variants).
>> +    On UARTs equipped with a Baud Rate Generator for External Clock (BRG)
>> +    (some SCIF and HSCIF), additional clocks may be specified:
>> +      - "int_clk" for the optional internal clock source for the frequency
>> +     divider (typically the (AXI or SHwy) bus clock),
>
> Isn't this always the same clock as the SCIF functional clock ?

(On R-Car Gen2/3)

No, SCIF uses different parents for fck (p) and int_clk (zs).
HSCIF uses the same parents though (zs).

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
>> Amend the DT bindings to include the optional clock sources for the Baud
>> Rate Generator for External Clock (BRG), as found on some SCIF variants
>> and on HSCIF.

>> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> @@ -46,6 +46,12 @@ Required properties:
>>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>>        - "hsck" for the optional external clock input (on HSCIF),
>>        - "sck" for the optional external clock input (on other variants).
>> +    On UARTs equipped with a Baud Rate Generator for External Clock (BRG)
>> +    (some SCIF and HSCIF), additional clocks may be specified:
>> +      - "int_clk" for the optional internal clock source for the frequency
>> +     divider (typically the (AXI or SHwy) bus clock),
>
> Isn't this always the same clock as the SCIF functional clock ?

(On R-Car Gen2/3)

No, SCIF uses different parents for fck (p) and int_clk (zs).
HSCIF uses the same parents though (zs).

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Laurent Pinchart]

Hi Geert,

On Thursday 19 November 2015 21:44:27 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
> >> Amend the DT bindings to include the optional clock sources for the Baud
> >> Rate Generator for External Clock (BRG), as found on some SCIF variants
> >> and on HSCIF.
> >> 
> >> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> 
> >> @@ -46,6 +46,12 @@ Required properties:
> >>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
> >>        - "hsck" for the optional external clock input (on HSCIF),
> >>        - "sck" for the optional external clock input (on other variants).
> >> 
> >> +    On UARTs equipped with a Baud Rate Generator for External Clock
> >> (BRG)
> >> +    (some SCIF and HSCIF), additional clocks may be specified:
> >> +      - "int_clk" for the optional internal clock source for the
> >> frequency
> >> +     divider (typically the (AXI or SHwy) bus clock),
> > 
> > Isn't this always the same clock as the SCIF functional clock ?
> 
> (On R-Car Gen2/3)
> 
> No, SCIF uses different parents for fck (p) and int_clk (zs).

Right, my bad.

Should we rename "int_clk" to something that makes it explicit that the clock 
is used as the BRG-EC input ? Maybe brg_clk, int_brg, int_brg_clk ? We 
probably don't need to keep the _clk suffix as it's quite evident that a clock 
name refers to a clock.

> HSCIF uses the same parents though (zs).

-- 
Regards,

Laurent Pinchart

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Laurent Pinchart]

Hi Geert,

On Thursday 19 November 2015 21:44:27 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
> >> Amend the DT bindings to include the optional clock sources for the Baud
> >> Rate Generator for External Clock (BRG), as found on some SCIF variants
> >> and on HSCIF.
> >> 
> >> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> 
> >> @@ -46,6 +46,12 @@ Required properties:
> >>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
> >>        - "hsck" for the optional external clock input (on HSCIF),
> >>        - "sck" for the optional external clock input (on other variants).
> >> 
> >> +    On UARTs equipped with a Baud Rate Generator for External Clock
> >> (BRG)
> >> +    (some SCIF and HSCIF), additional clocks may be specified:
> >> +      - "int_clk" for the optional internal clock source for the
> >> frequency
> >> +     divider (typically the (AXI or SHwy) bus clock),
> > 
> > Isn't this always the same clock as the SCIF functional clock ?
> 
> (On R-Car Gen2/3)
> 
> No, SCIF uses different parents for fck (p) and int_clk (zs).

Right, my bad.

Should we rename "int_clk" to something that makes it explicit that the clock 
is used as the BRG-EC input ? Maybe brg_clk, int_brg, int_brg_clk ? We 
probably don't need to keep the _clk suffix as it's quite evident that a clock 
name refers to a clock.

> HSCIF uses the same parents though (zs).

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Laurent Pinchart]

Hi Geert,

On Thursday 19 November 2015 21:44:27 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
> >> Amend the DT bindings to include the optional clock sources for the Baud
> >> Rate Generator for External Clock (BRG), as found on some SCIF variants
> >> and on HSCIF.
> >> 
> >> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
> >> 
> >> @@ -46,6 +46,12 @@ Required properties:
> >>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
> >>        - "hsck" for the optional external clock input (on HSCIF),
> >>        - "sck" for the optional external clock input (on other variants).
> >> 
> >> +    On UARTs equipped with a Baud Rate Generator for External Clock
> >> (BRG)
> >> +    (some SCIF and HSCIF), additional clocks may be specified:
> >> +      - "int_clk" for the optional internal clock source for the
> >> frequency
> >> +     divider (typically the (AXI or SHwy) bus clock),
> > 
> > Isn't this always the same clock as the SCIF functional clock ?
> 
> (On R-Car Gen2/3)
> 
> No, SCIF uses different parents for fck (p) and int_clk (zs).

Right, my bad.

Should we rename "int_clk" to something that makes it explicit that the clock 
is used as the BRG-EC input ? Maybe brg_clk, int_brg, int_brg_clk ? We 
probably don't need to keep the _clk suffix as it's quite evident that a clock 
name refers to a clock.

> HSCIF uses the same parents though (zs).

-- 
Regards,

Laurent Pinchart

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:13 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 21:44:27 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
>> >> Amend the DT bindings to include the optional clock sources for the Baud
>> >> Rate Generator for External Clock (BRG), as found on some SCIF variants
>> >> and on HSCIF.
>> >>
>> >> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >>
>> >> @@ -46,6 +46,12 @@ Required properties:
>> >>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>> >>        - "hsck" for the optional external clock input (on HSCIF),
>> >>        - "sck" for the optional external clock input (on other variants).
>> >>
>> >> +    On UARTs equipped with a Baud Rate Generator for External Clock
>> >> (BRG)
>> >> +    (some SCIF and HSCIF), additional clocks may be specified:
>> >> +      - "int_clk" for the optional internal clock source for the
>> >> frequency
>> >> +     divider (typically the (AXI or SHwy) bus clock),
>> >
>> > Isn't this always the same clock as the SCIF functional clock ?
>>
>> (On R-Car Gen2/3)
>>
>> No, SCIF uses different parents for fck (p) and int_clk (zs).
>
> Right, my bad.
>
> Should we rename "int_clk" to something that makes it explicit that the clock
> is used as the BRG-EC input ? Maybe brg_clk, int_brg, int_brg_clk ? We
> probably don't need to keep the _clk suffix as it's quite evident that a clock
> name refers to a clock.

The documentation always uses the SoC-specific explicit clock name (e.g. zs
s3d1, or clks), or just "internal clock", so I used "int_clk".

But I agree "int_brg" sounds better.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 02/25] serial: sh-sci: Update DT binding documentation for BRG support

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:13 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 21:44:27 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote:
>> >> Amend the DT bindings to include the optional clock sources for the Baud
>> >> Rate Generator for External Clock (BRG), as found on some SCIF variants
>> >> and on HSCIF.
>> >>
>> >> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>> >>
>> >> @@ -46,6 +46,12 @@ Required properties:
>> >>      On (H)SCI(F) and some SCIFA, an additional clock may be specified:
>> >>        - "hsck" for the optional external clock input (on HSCIF),
>> >>        - "sck" for the optional external clock input (on other variants).
>> >>
>> >> +    On UARTs equipped with a Baud Rate Generator for External Clock
>> >> (BRG)
>> >> +    (some SCIF and HSCIF), additional clocks may be specified:
>> >> +      - "int_clk" for the optional internal clock source for the
>> >> frequency
>> >> +     divider (typically the (AXI or SHwy) bus clock),
>> >
>> > Isn't this always the same clock as the SCIF functional clock ?
>>
>> (On R-Car Gen2/3)
>>
>> No, SCIF uses different parents for fck (p) and int_clk (zs).
>
> Right, my bad.
>
> Should we rename "int_clk" to something that makes it explicit that the clock
> is used as the BRG-EC input ? Maybe brg_clk, int_brg, int_brg_clk ? We
> probably don't need to keep the _clk suffix as it's quite evident that a clock
> name refers to a clock.

The documentation always uses the SoC-specific explicit clock name (e.g. zs
s3d1, or clks), or just "internal clock", so I used "int_clk".

But I agree "int_brg" sounds better.

Gr{oetje,eeting}s,

                        Geert

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

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

[PATCH 03/25] serial: sh-sci: Drop useless check for zero sampling_rate

[Geert Uytterhoeven]

sci_port.sampling_rate is always non-zero, except for HSCIF, which uses
sci_baud_calc_hscif() instead of sci_scbrr_calc().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index bee5b7025adf45a2..ae136a1632e6298d 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1863,13 +1863,7 @@ static void sci_shutdown(struct uart_port *port)
 static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 				   unsigned long freq)
 {
-	if (s->sampling_rate)
-		return DIV_ROUND_CLOSEST(freq, s->sampling_rate * bps) - 1;
-
-	/* Warn, but use a safe default */
-	WARN_ON(1);
-
-	return ((freq + 16 * bps) / (32 * bps) - 1);
+	return DIV_ROUND_CLOSEST(freq, s->sampling_rate * bps) - 1;
 }
 
 /* calculate frame length from SMR */
-- 
1.9.1

[PATCH 03/25] serial: sh-sci: Drop useless check for zero sampling_rate

[Geert Uytterhoeven]

sci_port.sampling_rate is always non-zero, except for HSCIF, which uses
sci_baud_calc_hscif() instead of sci_scbrr_calc().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index bee5b7025adf45a2..ae136a1632e6298d 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1863,13 +1863,7 @@ static void sci_shutdown(struct uart_port *port)
 static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 				   unsigned long freq)
 {
-	if (s->sampling_rate)
-		return DIV_ROUND_CLOSEST(freq, s->sampling_rate * bps) - 1;
-
-	/* Warn, but use a safe default */
-	WARN_ON(1);
-
-	return ((freq + 16 * bps) / (32 * bps) - 1);
+	return DIV_ROUND_CLOSEST(freq, s->sampling_rate * bps) - 1;
 }
 
 /* calculate frame length from SMR */
-- 
1.9.1

[PATCH 04/25] serial: sh-sci: Grammar s/Get ... for/Get ... from/

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index ae136a1632e6298d..676f9d1354943a1b 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2640,7 +2640,7 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
 	if (!p)
 		return NULL;
 
-	/* Get the line number for the aliases node. */
+	/* Get the line number from the aliases node. */
 	id = of_alias_get_id(np, "serial");
 	if (id < 0) {
 		dev_err(&pdev->dev, "failed to get alias id (%d)\n", id);
-- 
1.9.1

[PATCH 04/25] serial: sh-sci: Grammar s/Get ... for/Get ... from/

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index ae136a1632e6298d..676f9d1354943a1b 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2640,7 +2640,7 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
 	if (!p)
 		return NULL;
 
-	/* Get the line number for the aliases node. */
+	/* Get the line number from the aliases node. */
 	id = of_alias_get_id(np, "serial");
 	if (id < 0) {
 		dev_err(&pdev->dev, "failed to get alias id (%d)\n", id);
-- 
1.9.1

[PATCH 05/25] serial: sh-sci: Drop unused frame_len parameter for sci_baud_calc_hscif()

[Geert Uytterhoeven]

As F is assumed to be zero in the receive margin formula, frame_len is
not used. Remove it, together with the sci_baud_calc_frame_len() helper
function.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 24 +++---------------------
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 676f9d1354943a1b..7c7dfbce54ed9c19 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1866,26 +1866,9 @@ static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 	return DIV_ROUND_CLOSEST(freq, s->sampling_rate * bps) - 1;
 }
 
-/* calculate frame length from SMR */
-static int sci_baud_calc_frame_len(unsigned int smr_val)
-{
-	int len = 10;
-
-	if (smr_val & SCSMR_CHR)
-		len--;
-	if (smr_val & SCSMR_PE)
-		len++;
-	if (smr_val & SCSMR_STOP)
-		len++;
-
-	return len;
-}
-
-
 /* calculate sample rate, BRR, and clock select for HSCIF */
-static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq,
-				int *brr, unsigned int *srr,
-				unsigned int *cks, int frame_len)
+static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
+				unsigned int *srr, unsigned int *cks)
 {
 	int sr, c, br, err, recv_margin;
 	int min_err = 1000; /* 100% */
@@ -1987,9 +1970,8 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
 	if (likely(baud && port->uartclk)) {
 		if (s->cfg->type = PORT_HSCIF) {
-			int frame_len = sci_baud_calc_frame_len(smr_val);
 			sci_baud_calc_hscif(baud, port->uartclk, &t, &srr,
-					    &cks, frame_len);
+					    &cks);
 		} else {
 			t = sci_scbrr_calc(s, baud, port->uartclk);
 			for (cks = 0; t >= 256 && cks <= 3; cks++)
-- 
1.9.1

[PATCH 05/25] serial: sh-sci: Drop unused frame_len parameter for sci_baud_calc_hscif()

[Geert Uytterhoeven]

As F is assumed to be zero in the receive margin formula, frame_len is
not used. Remove it, together with the sci_baud_calc_frame_len() helper
function.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 24 +++---------------------
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 676f9d1354943a1b..7c7dfbce54ed9c19 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1866,26 +1866,9 @@ static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 	return DIV_ROUND_CLOSEST(freq, s->sampling_rate * bps) - 1;
 }
 
-/* calculate frame length from SMR */
-static int sci_baud_calc_frame_len(unsigned int smr_val)
-{
-	int len = 10;
-
-	if (smr_val & SCSMR_CHR)
-		len--;
-	if (smr_val & SCSMR_PE)
-		len++;
-	if (smr_val & SCSMR_STOP)
-		len++;
-
-	return len;
-}
-
-
 /* calculate sample rate, BRR, and clock select for HSCIF */
-static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq,
-				int *brr, unsigned int *srr,
-				unsigned int *cks, int frame_len)
+static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
+				unsigned int *srr, unsigned int *cks)
 {
 	int sr, c, br, err, recv_margin;
 	int min_err = 1000; /* 100% */
@@ -1987,9 +1970,8 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
 	if (likely(baud && port->uartclk)) {
 		if (s->cfg->type == PORT_HSCIF) {
-			int frame_len = sci_baud_calc_frame_len(smr_val);
 			sci_baud_calc_hscif(baud, port->uartclk, &t, &srr,
-					    &cks, frame_len);
+					    &cks);
 		} else {
 			t = sci_scbrr_calc(s, baud, port->uartclk);
 			for (cks = 0; t >= 256 && cks <= 3; cks++)
-- 
1.9.1

[PATCH 06/25] serial: sh-sci: Don't overwrite clock selection in serial_console_write()

[Geert Uytterhoeven]

Blindly writing the default configuration value into the SCSCR register
may change the clock selection bits, breaking the serial console if the
current driver settings differ from the default settings.

Keep the current clock selection bits to prevent this from happening
on e.g. r8a7791/koelsch when support for the BRG will be added.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 7c7dfbce54ed9c19..cba51da604253db6 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2415,7 +2415,7 @@ static void serial_console_write(struct console *co, const char *s,
 {
 	struct sci_port *sci_port = &sci_ports[co->index];
 	struct uart_port *port = &sci_port->port;
-	unsigned short bits, ctrl;
+	unsigned short bits, ctrl, ctrl_temp;
 	unsigned long flags;
 	int locked = 1;
 
@@ -2427,9 +2427,11 @@ static void serial_console_write(struct console *co, const char *s,
 	else
 		spin_lock(&port->lock);
 
-	/* first save the SCSCR then disable the interrupts */
+	/* first save SCSCR then disable interrupts, keep clock source */
 	ctrl = serial_port_in(port, SCSCR);
-	serial_port_out(port, SCSCR, sci_port->cfg->scscr);
+	ctrl_temp = (sci_port->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0)) |
+		    (ctrl & (SCSCR_CKE1 | SCSCR_CKE0));
+	serial_port_out(port, SCSCR, ctrl_temp);
 
 	uart_console_write(port, s, count, serial_console_putchar);
 
-- 
1.9.1

[PATCH 06/25] serial: sh-sci: Don't overwrite clock selection in serial_console_write()

[Geert Uytterhoeven]

Blindly writing the default configuration value into the SCSCR register
may change the clock selection bits, breaking the serial console if the
current driver settings differ from the default settings.

Keep the current clock selection bits to prevent this from happening
on e.g. r8a7791/koelsch when support for the BRG will be added.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 7c7dfbce54ed9c19..cba51da604253db6 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2415,7 +2415,7 @@ static void serial_console_write(struct console *co, const char *s,
 {
 	struct sci_port *sci_port = &sci_ports[co->index];
 	struct uart_port *port = &sci_port->port;
-	unsigned short bits, ctrl;
+	unsigned short bits, ctrl, ctrl_temp;
 	unsigned long flags;
 	int locked = 1;
 
@@ -2427,9 +2427,11 @@ static void serial_console_write(struct console *co, const char *s,
 	else
 		spin_lock(&port->lock);
 
-	/* first save the SCSCR then disable the interrupts */
+	/* first save SCSCR then disable interrupts, keep clock source */
 	ctrl = serial_port_in(port, SCSCR);
-	serial_port_out(port, SCSCR, sci_port->cfg->scscr);
+	ctrl_temp = (sci_port->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0)) |
+		    (ctrl & (SCSCR_CKE1 | SCSCR_CKE0));
+	serial_port_out(port, SCSCR, ctrl_temp);
 
 	uart_console_write(port, s, count, serial_console_putchar);
 
-- 
1.9.1

[PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Geert Uytterhoeven]

Transfer clock cleanup handling to the core device management code.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index cba51da604253db6..9442961a198378c7 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
 static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 {
 	/* Get the SCI functional clock. It's called "fck" on ARM. */
-	sci_port->fclk = clk_get(dev, "fck");
+	sci_port->fclk = devm_clk_get(dev, "fck");
 	if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
 		return -EPROBE_DEFER;
 	if (!IS_ERR(sci_port->fclk))
@@ -2226,7 +2226,7 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 	 * But it used to be called "sci_ick", and we need to maintain DT
 	 * backward compatibility.
 	 */
-	sci_port->fclk = clk_get(dev, "sci_ick");
+	sci_port->fclk = devm_clk_get(dev, "sci_ick");
 	if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
 		return -EPROBE_DEFER;
 	if (!IS_ERR(sci_port->fclk))
@@ -2236,7 +2236,7 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 	 * Not all SH platforms declare a clock lookup entry for SCI devices,
 	 * in which case we need to get the global "peripheral_clk" clock.
 	 */
-	sci_port->fclk = clk_get(dev, "peripheral_clk");
+	sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
 	if (!IS_ERR(sci_port->fclk))
 		return 0;
 
@@ -2395,8 +2395,6 @@ static int sci_init_single(struct platform_device *dev,
 
 static void sci_cleanup_single(struct sci_port *port)
 {
-	clk_put(port->fclk);
-
 	pm_runtime_disable(port->port.dev);
 }
 
-- 
1.9.1

[PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Geert Uytterhoeven]

Transfer clock cleanup handling to the core device management code.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index cba51da604253db6..9442961a198378c7 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
 static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 {
 	/* Get the SCI functional clock. It's called "fck" on ARM. */
-	sci_port->fclk = clk_get(dev, "fck");
+	sci_port->fclk = devm_clk_get(dev, "fck");
 	if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
 		return -EPROBE_DEFER;
 	if (!IS_ERR(sci_port->fclk))
@@ -2226,7 +2226,7 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 	 * But it used to be called "sci_ick", and we need to maintain DT
 	 * backward compatibility.
 	 */
-	sci_port->fclk = clk_get(dev, "sci_ick");
+	sci_port->fclk = devm_clk_get(dev, "sci_ick");
 	if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
 		return -EPROBE_DEFER;
 	if (!IS_ERR(sci_port->fclk))
@@ -2236,7 +2236,7 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 	 * Not all SH platforms declare a clock lookup entry for SCI devices,
 	 * in which case we need to get the global "peripheral_clk" clock.
 	 */
-	sci_port->fclk = clk_get(dev, "peripheral_clk");
+	sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
 	if (!IS_ERR(sci_port->fclk))
 		return 0;
 
@@ -2395,8 +2395,6 @@ static int sci_init_single(struct platform_device *dev,
 
 static void sci_cleanup_single(struct sci_port *port)
 {
-	clk_put(port->fclk);
-
 	pm_runtime_disable(port->port.dev);
 }
 
-- 
1.9.1

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Laurent Pinchart]

Hi Geert,

Thank for the patch.

On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
> Transfer clock cleanup handling to the core device management code.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index cba51da604253db6..9442961a198378c7 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>  {
>  	/* Get the SCI functional clock. It's called "fck" on ARM. */
> -	sci_port->fclk = clk_get(dev, "fck");
> +	sci_port->fclk = devm_clk_get(dev, "fck");

Have you tested what happens if you unbind the device from the driver while 
userspace has the serial port open ?

>  	if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
>  		return -EPROBE_DEFER;
>  	if (!IS_ERR(sci_port->fclk))
> @@ -2226,7 +2226,7 @@ static int sci_init_clocks(struct sci_port *sci_port,
> struct device *dev) * But it used to be called "sci_ick", and we need to
> maintain DT * backward compatibility.
>  	 */
> -	sci_port->fclk = clk_get(dev, "sci_ick");
> +	sci_port->fclk = devm_clk_get(dev, "sci_ick");
>  	if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
>  		return -EPROBE_DEFER;
>  	if (!IS_ERR(sci_port->fclk))
> @@ -2236,7 +2236,7 @@ static int sci_init_clocks(struct sci_port *sci_port,
> struct device *dev) * Not all SH platforms declare a clock lookup entry for
> SCI devices, * in which case we need to get the global "peripheral_clk"
> clock. */
> -	sci_port->fclk = clk_get(dev, "peripheral_clk");
> +	sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
>  	if (!IS_ERR(sci_port->fclk))
>  		return 0;
> 
> @@ -2395,8 +2395,6 @@ static int sci_init_single(struct platform_device
> *dev,
> 
>  static void sci_cleanup_single(struct sci_port *port)
>  {
> -	clk_put(port->fclk);
> -
>  	pm_runtime_disable(port->port.dev);
>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Laurent Pinchart]

Hi Geert,

Thank for the patch.

On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
> Transfer clock cleanup handling to the core device management code.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index cba51da604253db6..9442961a198378c7 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>  {
>  	/* Get the SCI functional clock. It's called "fck" on ARM. */
> -	sci_port->fclk = clk_get(dev, "fck");
> +	sci_port->fclk = devm_clk_get(dev, "fck");

Have you tested what happens if you unbind the device from the driver while 
userspace has the serial port open ?

>  	if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
>  		return -EPROBE_DEFER;
>  	if (!IS_ERR(sci_port->fclk))
> @@ -2226,7 +2226,7 @@ static int sci_init_clocks(struct sci_port *sci_port,
> struct device *dev) * But it used to be called "sci_ick", and we need to
> maintain DT * backward compatibility.
>  	 */
> -	sci_port->fclk = clk_get(dev, "sci_ick");
> +	sci_port->fclk = devm_clk_get(dev, "sci_ick");
>  	if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
>  		return -EPROBE_DEFER;
>  	if (!IS_ERR(sci_port->fclk))
> @@ -2236,7 +2236,7 @@ static int sci_init_clocks(struct sci_port *sci_port,
> struct device *dev) * Not all SH platforms declare a clock lookup entry for
> SCI devices, * in which case we need to get the global "peripheral_clk"
> clock. */
> -	sci_port->fclk = clk_get(dev, "peripheral_clk");
> +	sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
>  	if (!IS_ERR(sci_port->fclk))
>  		return 0;
> 
> @@ -2395,8 +2395,6 @@ static int sci_init_single(struct platform_device
> *dev,
> 
>  static void sci_cleanup_single(struct sci_port *port)
>  {
> -	clk_put(port->fclk);
> -
>  	pm_runtime_disable(port->port.dev);
>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:38 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
>> Transfer clock cleanup handling to the core device management code.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>>  drivers/tty/serial/sh-sci.c | 8 +++-----
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> index cba51da604253db6..9442961a198378c7 100644
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c
>> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
>>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>>  {
>>       /* Get the SCI functional clock. It's called "fck" on ARM. */
>> -     sci_port->fclk = clk_get(dev, "fck");
>> +     sci_port->fclk = devm_clk_get(dev, "fck");
>
> Have you tested what happens if you unbind the device from the driver while
> userspace has the serial port open ?

Yes I have. And I didn't notice any user-visible behavioral differences.

There is a small ordering difference, though: with clk_get() and clk_put(), the
explicit clk_put() is done before removing the device from its PM Domain
(which involces another call to clk_put() on the module clock):

    device_release_driver
        __device_release_driver
            platform_drv_remove
                sci_remove
                    sci_cleanup_single
                        __clk_put
                genpd_dev_pm_detach
                    pm_genpd_remove_device
                        pm_clk_destroy
                            __pm_clk_remove
                                __clk_put

When using devm_clk_get(), the managed cleanup is done after the device has
been removed from its PM Domain:

    device_release_driver
        __device_release_driver
            platform_drv_remove
                genpd_dev_pm_detach
                    pm_genpd_remove_device
                        pm_clk_destroy
                            __pm_clk_remove
                                __clk_put
            release_nodes
                __clk_put

This shouldn't make a difference, and applies to all other drivers using
devm_*(), and devices that are part of a PM Domain.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:38 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
>> Transfer clock cleanup handling to the core device management code.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>>  drivers/tty/serial/sh-sci.c | 8 +++-----
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> index cba51da604253db6..9442961a198378c7 100644
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c
>> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
>>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>>  {
>>       /* Get the SCI functional clock. It's called "fck" on ARM. */
>> -     sci_port->fclk = clk_get(dev, "fck");
>> +     sci_port->fclk = devm_clk_get(dev, "fck");
>
> Have you tested what happens if you unbind the device from the driver while
> userspace has the serial port open ?

Yes I have. And I didn't notice any user-visible behavioral differences.

There is a small ordering difference, though: with clk_get() and clk_put(), the
explicit clk_put() is done before removing the device from its PM Domain
(which involces another call to clk_put() on the module clock):

    device_release_driver
        __device_release_driver
            platform_drv_remove
                sci_remove
                    sci_cleanup_single
                        __clk_put
                genpd_dev_pm_detach
                    pm_genpd_remove_device
                        pm_clk_destroy
                            __pm_clk_remove
                                __clk_put

When using devm_clk_get(), the managed cleanup is done after the device has
been removed from its PM Domain:

    device_release_driver
        __device_release_driver
            platform_drv_remove
                genpd_dev_pm_detach
                    pm_genpd_remove_device
                        pm_clk_destroy
                            __pm_clk_remove
                                __clk_put
            release_nodes
                __clk_put

This shouldn't make a difference, and applies to all other drivers using
devm_*(), and devices that are part of a PM Domain.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Laurent Pinchart]

Hi Geert,

On Thursday 10 December 2015 13:30:18 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:38 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
> >> Transfer clock cleanup handling to the core device management code.
> >> 
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> ---
> >> 
> >>  drivers/tty/serial/sh-sci.c | 8 +++-----
> >>  1 file changed, 3 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> index cba51da604253db6..9442961a198378c7 100644
> >> --- a/drivers/tty/serial/sh-sci.c
> >> +++ b/drivers/tty/serial/sh-sci.c
> >> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
> >> 
> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
> >>  *dev)
> >>  {
> >>  
> >>       /* Get the SCI functional clock. It's called "fck" on ARM. */
> >> 
> >> -     sci_port->fclk = clk_get(dev, "fck");
> >> +     sci_port->fclk = devm_clk_get(dev, "fck");
> > 
> > Have you tested what happens if you unbind the device from the driver
> > while userspace has the serial port open ?
> 
> Yes I have. And I didn't notice any user-visible behavioral differences.
> 
> There is a small ordering difference, though: with clk_get() and clk_put(),
> the explicit clk_put() is done before removing the device from its PM
> Domain (which involces another call to clk_put() on the module clock):
> 
>     device_release_driver
>         __device_release_driver
>             platform_drv_remove
>                 sci_remove
>                     sci_cleanup_single
>                         __clk_put
>                 genpd_dev_pm_detach
>                     pm_genpd_remove_device
>                         pm_clk_destroy
>                             __pm_clk_remove
>                                 __clk_put
> 
> When using devm_clk_get(), the managed cleanup is done after the device has
> been removed from its PM Domain:
> 
>     device_release_driver
>         __device_release_driver
>             platform_drv_remove
>                 genpd_dev_pm_detach
>                     pm_genpd_remove_device
>                         pm_clk_destroy
>                             __pm_clk_remove
>                                 __clk_put
>             release_nodes
>                 __clk_put
> 
> This shouldn't make a difference, and applies to all other drivers using
> devm_*(), and devices that are part of a PM Domain.

I was more concerned about the clk_disable_unprepare() calls. The function is 
called through the uart pm handler which is called when closing the uart 
(uart_close()). It's a bit difficult to follow the dynamic code paths as I'm 
not very familiar with the framework, but I was concerned that the would end 
up calling clk_disable_unprepare() on a clock for which we have no reference 
anymore. What prevents clk_disable_unprepare() from being called in the close 
path after the device has been unbound ? And what ensures that the clocks get 
unprepared when unbinding the device if the port is held open by a userspace 
process ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Laurent Pinchart]

Hi Geert,

On Thursday 10 December 2015 13:30:18 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:38 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
> >> Transfer clock cleanup handling to the core device management code.
> >> 
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> ---
> >> 
> >>  drivers/tty/serial/sh-sci.c | 8 +++-----
> >>  1 file changed, 3 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> index cba51da604253db6..9442961a198378c7 100644
> >> --- a/drivers/tty/serial/sh-sci.c
> >> +++ b/drivers/tty/serial/sh-sci.c
> >> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
> >> 
> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
> >>  *dev)
> >>  {
> >>  
> >>       /* Get the SCI functional clock. It's called "fck" on ARM. */
> >> 
> >> -     sci_port->fclk = clk_get(dev, "fck");
> >> +     sci_port->fclk = devm_clk_get(dev, "fck");
> > 
> > Have you tested what happens if you unbind the device from the driver
> > while userspace has the serial port open ?
> 
> Yes I have. And I didn't notice any user-visible behavioral differences.
> 
> There is a small ordering difference, though: with clk_get() and clk_put(),
> the explicit clk_put() is done before removing the device from its PM
> Domain (which involces another call to clk_put() on the module clock):
> 
>     device_release_driver
>         __device_release_driver
>             platform_drv_remove
>                 sci_remove
>                     sci_cleanup_single
>                         __clk_put
>                 genpd_dev_pm_detach
>                     pm_genpd_remove_device
>                         pm_clk_destroy
>                             __pm_clk_remove
>                                 __clk_put
> 
> When using devm_clk_get(), the managed cleanup is done after the device has
> been removed from its PM Domain:
> 
>     device_release_driver
>         __device_release_driver
>             platform_drv_remove
>                 genpd_dev_pm_detach
>                     pm_genpd_remove_device
>                         pm_clk_destroy
>                             __pm_clk_remove
>                                 __clk_put
>             release_nodes
>                 __clk_put
> 
> This shouldn't make a difference, and applies to all other drivers using
> devm_*(), and devices that are part of a PM Domain.

I was more concerned about the clk_disable_unprepare() calls. The function is 
called through the uart pm handler which is called when closing the uart 
(uart_close()). It's a bit difficult to follow the dynamic code paths as I'm 
not very familiar with the framework, but I was concerned that the would end 
up calling clk_disable_unprepare() on a clock for which we have no reference 
anymore. What prevents clk_disable_unprepare() from being called in the close 
path after the device has been unbound ? And what ensures that the clocks get 
unprepared when unbinding the device if the port is held open by a userspace 
process ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Geert Uytterhoeven]

Hi Laurent,

On Sun, Dec 13, 2015 at 8:39 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 10 December 2015 13:30:18 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:38 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
>> >> Transfer clock cleanup handling to the core device management code.
>> >>
>> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> ---
>> >>
>> >>  drivers/tty/serial/sh-sci.c | 8 +++-----
>> >>  1 file changed, 3 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> >> index cba51da604253db6..9442961a198378c7 100644
>> >> --- a/drivers/tty/serial/sh-sci.c
>> >> +++ b/drivers/tty/serial/sh-sci.c
>> >> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
>> >>
>> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
>> >>  *dev)
>> >>  {
>> >>
>> >>       /* Get the SCI functional clock. It's called "fck" on ARM. */
>> >>
>> >> -     sci_port->fclk = clk_get(dev, "fck");
>> >> +     sci_port->fclk = devm_clk_get(dev, "fck");
>> >
>> > Have you tested what happens if you unbind the device from the driver
>> > while userspace has the serial port open ?
>>
>> Yes I have. And I didn't notice any user-visible behavioral differences.
>>
>> There is a small ordering difference, though: with clk_get() and clk_put(),
>> the explicit clk_put() is done before removing the device from its PM
>> Domain (which involces another call to clk_put() on the module clock):
>>
>>     device_release_driver
>>         __device_release_driver
>>             platform_drv_remove
>>                 sci_remove
>>                     sci_cleanup_single
>>                         __clk_put
>>                 genpd_dev_pm_detach
>>                     pm_genpd_remove_device
>>                         pm_clk_destroy
>>                             __pm_clk_remove
>>                                 __clk_put
>>
>> When using devm_clk_get(), the managed cleanup is done after the device has
>> been removed from its PM Domain:
>>
>>     device_release_driver
>>         __device_release_driver
>>             platform_drv_remove
>>                 genpd_dev_pm_detach
>>                     pm_genpd_remove_device
>>                         pm_clk_destroy
>>                             __pm_clk_remove
>>                                 __clk_put
>>             release_nodes
>>                 __clk_put
>>
>> This shouldn't make a difference, and applies to all other drivers using
>> devm_*(), and devices that are part of a PM Domain.
>
> I was more concerned about the clk_disable_unprepare() calls. The function is
> called through the uart pm handler which is called when closing the uart
> (uart_close()). It's a bit difficult to follow the dynamic code paths as I'm
> not very familiar with the framework, but I was concerned that the would end
> up calling clk_disable_unprepare() on a clock for which we have no reference
> anymore. What prevents clk_disable_unprepare() from being called in the close
> path after the device has been unbound ? And what ensures that the clocks get
> unprepared when unbinding the device if the port is held open by a userspace
> process ?

Both questions are answered by uart_hangup():
  - uart_hangup() sets port->count to zero, hence uart_close() returns early
    (second return statement), long before it would call the uart pm handler.
  - uart_hangup() calls uart_change_pm(state, UART_PM_STATE_OFF);

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Geert Uytterhoeven]

Hi Laurent,

On Sun, Dec 13, 2015 at 8:39 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 10 December 2015 13:30:18 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:38 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
>> >> Transfer clock cleanup handling to the core device management code.
>> >>
>> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> ---
>> >>
>> >>  drivers/tty/serial/sh-sci.c | 8 +++-----
>> >>  1 file changed, 3 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> >> index cba51da604253db6..9442961a198378c7 100644
>> >> --- a/drivers/tty/serial/sh-sci.c
>> >> +++ b/drivers/tty/serial/sh-sci.c
>> >> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
>> >>
>> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
>> >>  *dev)
>> >>  {
>> >>
>> >>       /* Get the SCI functional clock. It's called "fck" on ARM. */
>> >>
>> >> -     sci_port->fclk = clk_get(dev, "fck");
>> >> +     sci_port->fclk = devm_clk_get(dev, "fck");
>> >
>> > Have you tested what happens if you unbind the device from the driver
>> > while userspace has the serial port open ?
>>
>> Yes I have. And I didn't notice any user-visible behavioral differences.
>>
>> There is a small ordering difference, though: with clk_get() and clk_put(),
>> the explicit clk_put() is done before removing the device from its PM
>> Domain (which involces another call to clk_put() on the module clock):
>>
>>     device_release_driver
>>         __device_release_driver
>>             platform_drv_remove
>>                 sci_remove
>>                     sci_cleanup_single
>>                         __clk_put
>>                 genpd_dev_pm_detach
>>                     pm_genpd_remove_device
>>                         pm_clk_destroy
>>                             __pm_clk_remove
>>                                 __clk_put
>>
>> When using devm_clk_get(), the managed cleanup is done after the device has
>> been removed from its PM Domain:
>>
>>     device_release_driver
>>         __device_release_driver
>>             platform_drv_remove
>>                 genpd_dev_pm_detach
>>                     pm_genpd_remove_device
>>                         pm_clk_destroy
>>                             __pm_clk_remove
>>                                 __clk_put
>>             release_nodes
>>                 __clk_put
>>
>> This shouldn't make a difference, and applies to all other drivers using
>> devm_*(), and devices that are part of a PM Domain.
>
> I was more concerned about the clk_disable_unprepare() calls. The function is
> called through the uart pm handler which is called when closing the uart
> (uart_close()). It's a bit difficult to follow the dynamic code paths as I'm
> not very familiar with the framework, but I was concerned that the would end
> up calling clk_disable_unprepare() on a clock for which we have no reference
> anymore. What prevents clk_disable_unprepare() from being called in the close
> path after the device has been unbound ? And what ensures that the clocks get
> unprepared when unbinding the device if the port is held open by a userspace
> process ?

Both questions are answered by uart_hangup():
  - uart_hangup() sets port->count to zero, hence uart_close() returns early
    (second return statement), long before it would call the uart pm handler.
  - uart_hangup() calls uart_change_pm(state, UART_PM_STATE_OFF);

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Laurent Pinchart]

Hi Geert,

On Monday 14 December 2015 11:34:11 Geert Uytterhoeven wrote:
> On Sun, Dec 13, 2015 at 8:39 PM, Laurent Pinchart wrote:
> > On Thursday 10 December 2015 13:30:18 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 9:38 PM, Laurent Pinchart wrote:
> >> > On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
> >> >> Transfer clock cleanup handling to the core device management code.
> >> >> 
> >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> >> ---
> >> >> 
> >> >>  drivers/tty/serial/sh-sci.c | 8 +++-----
> >> >>  1 file changed, 3 insertions(+), 5 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> >> index cba51da604253db6..9442961a198378c7 100644
> >> >> --- a/drivers/tty/serial/sh-sci.c
> >> >> +++ b/drivers/tty/serial/sh-sci.c
> >> >> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
> >> >> 
> >> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
> >> >>  *dev)
> >> >>  {
> >> >>       /* Get the SCI functional clock. It's called "fck" on ARM. */
> >> >> -     sci_port->fclk = clk_get(dev, "fck");
> >> >> +     sci_port->fclk = devm_clk_get(dev, "fck");
> >> > 
> >> > Have you tested what happens if you unbind the device from the driver
> >> > while userspace has the serial port open ?
> >> 
> >> Yes I have. And I didn't notice any user-visible behavioral differences.
> >> 
> >> There is a small ordering difference, though: with clk_get() and
> >> clk_put(), the explicit clk_put() is done before removing the device from
> >> its PM
> >> 
> >> Domain (which involces another call to clk_put() on the module clock):
> >>     device_release_driver
> >>         __device_release_driver
> >>             platform_drv_remove
> >>                 sci_remove
> >>                     sci_cleanup_single
> >>                         __clk_put
> >>                 genpd_dev_pm_detach
> >>                     pm_genpd_remove_device
> >>                         pm_clk_destroy
> >>                             __pm_clk_remove
> >>                                 __clk_put
> >> 
> >> When using devm_clk_get(), the managed cleanup is done after the device
> >> has been removed from its PM Domain:
> >>     device_release_driver
> >>         __device_release_driver
> >>             platform_drv_remove
> >>                 genpd_dev_pm_detach
> >>                     pm_genpd_remove_device
> >>                         pm_clk_destroy
> >>                             __pm_clk_remove
> >>                                 __clk_put
> >>             release_nodes
> >>                 __clk_put
> >> 
> >> This shouldn't make a difference, and applies to all other drivers using
> >> devm_*(), and devices that are part of a PM Domain.
> > 
> > I was more concerned about the clk_disable_unprepare() calls. The function
> > is called through the uart pm handler which is called when closing the
> > uart (uart_close()). It's a bit difficult to follow the dynamic code
> > paths as I'm not very familiar with the framework, but I was concerned
> > that the would end up calling clk_disable_unprepare() on a clock for
> > which we have no reference anymore. What prevents clk_disable_unprepare()
> > from being called in the close path after the device has been unbound ?
> > And what ensures that the clocks get unprepared when unbinding the device
> > if the port is held open by a userspace process ?
> 
> Both questions are answered by uart_hangup():
>   - uart_hangup() sets port->count to zero, hence uart_close() returns early
> (second return statement), long before it would call the uart pm handler.
> - uart_hangup() calls uart_change_pm(state, UART_PM_STATE_OFF);

Thank you for making me slightly wiser :-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 07/25] serial: sh-sci: Convert from clk_get() to devm_clk_get()

[Laurent Pinchart]

Hi Geert,

On Monday 14 December 2015 11:34:11 Geert Uytterhoeven wrote:
> On Sun, Dec 13, 2015 at 8:39 PM, Laurent Pinchart wrote:
> > On Thursday 10 December 2015 13:30:18 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 9:38 PM, Laurent Pinchart wrote:
> >> > On Thursday 19 November 2015 19:38:46 Geert Uytterhoeven wrote:
> >> >> Transfer clock cleanup handling to the core device management code.
> >> >> 
> >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> >> ---
> >> >> 
> >> >>  drivers/tty/serial/sh-sci.c | 8 +++-----
> >> >>  1 file changed, 3 insertions(+), 5 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> >> index cba51da604253db6..9442961a198378c7 100644
> >> >> --- a/drivers/tty/serial/sh-sci.c
> >> >> +++ b/drivers/tty/serial/sh-sci.c
> >> >> @@ -2216,7 +2216,7 @@ static struct uart_ops sci_uart_ops = {
> >> >> 
> >> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
> >> >>  *dev)
> >> >>  {
> >> >>       /* Get the SCI functional clock. It's called "fck" on ARM. */
> >> >> -     sci_port->fclk = clk_get(dev, "fck");
> >> >> +     sci_port->fclk = devm_clk_get(dev, "fck");
> >> > 
> >> > Have you tested what happens if you unbind the device from the driver
> >> > while userspace has the serial port open ?
> >> 
> >> Yes I have. And I didn't notice any user-visible behavioral differences.
> >> 
> >> There is a small ordering difference, though: with clk_get() and
> >> clk_put(), the explicit clk_put() is done before removing the device from
> >> its PM
> >> 
> >> Domain (which involces another call to clk_put() on the module clock):
> >>     device_release_driver
> >>         __device_release_driver
> >>             platform_drv_remove
> >>                 sci_remove
> >>                     sci_cleanup_single
> >>                         __clk_put
> >>                 genpd_dev_pm_detach
> >>                     pm_genpd_remove_device
> >>                         pm_clk_destroy
> >>                             __pm_clk_remove
> >>                                 __clk_put
> >> 
> >> When using devm_clk_get(), the managed cleanup is done after the device
> >> has been removed from its PM Domain:
> >>     device_release_driver
> >>         __device_release_driver
> >>             platform_drv_remove
> >>                 genpd_dev_pm_detach
> >>                     pm_genpd_remove_device
> >>                         pm_clk_destroy
> >>                             __pm_clk_remove
> >>                                 __clk_put
> >>             release_nodes
> >>                 __clk_put
> >> 
> >> This shouldn't make a difference, and applies to all other drivers using
> >> devm_*(), and devices that are part of a PM Domain.
> > 
> > I was more concerned about the clk_disable_unprepare() calls. The function
> > is called through the uart pm handler which is called when closing the
> > uart (uart_close()). It's a bit difficult to follow the dynamic code
> > paths as I'm not very familiar with the framework, but I was concerned
> > that the would end up calling clk_disable_unprepare() on a clock for
> > which we have no reference anymore. What prevents clk_disable_unprepare()
> > from being called in the close path after the device has been unbound ?
> > And what ensures that the clocks get unprepared when unbinding the device
> > if the port is held open by a userspace process ?
> 
> Both questions are answered by uart_hangup():
>   - uart_hangup() sets port->count to zero, hence uart_close() returns early
> (second return statement), long before it would call the uart pm handler.
> - uart_hangup() calls uart_change_pm(state, UART_PM_STATE_OFF);

Thank you for making me slightly wiser :-)

-- 
Regards,

Laurent Pinchart

[PATCH 08/25] serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned

[Geert Uytterhoeven]

Move the -1 offset of br to the assignment to *brr, so br cannot become
negative anymore, and update the clamp() call. Now all unsigned values
in sci_baud_calc_hscif() can become unsigned.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 9442961a198378c7..fba1e1eea15dc3a1 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1870,7 +1870,8 @@ static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 				unsigned int *srr, unsigned int *cks)
 {
-	int sr, c, br, err, recv_margin;
+	unsigned int sr, br, c;
+	int err, recv_margin;
 	int min_err = 1000; /* 100% */
 	int recv_max_margin = 0;
 
@@ -1880,9 +1881,9 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 		for (c = 0; c <= 3; c++) {
 			/* integerized formulas from HSCIF documentation */
 			br = DIV_ROUND_CLOSEST(freq, (sr *
-					      (1 << (2 * c + 1)) * bps)) - 1;
-			br = clamp(br, 0, 255);
-			err = DIV_ROUND_CLOSEST(freq, ((br + 1) * bps * sr *
+					      (1 << (2 * c + 1)) * bps));
+			br = clamp(br, 1U, 256U);
+			err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
 					       (1 << (2 * c + 1)) / 1000)) -
 					       1000;
 			/* Calc recv margin
@@ -1908,7 +1909,7 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 			else
 				continue;
 
-			*brr = br;
+			*brr = br - 1;
 			*srr = sr - 1;
 			*cks = c;
 		}
-- 
1.9.1

[PATCH 08/25] serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned

[Geert Uytterhoeven]

Move the -1 offset of br to the assignment to *brr, so br cannot become
negative anymore, and update the clamp() call. Now all unsigned values
in sci_baud_calc_hscif() can become unsigned.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 9442961a198378c7..fba1e1eea15dc3a1 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1870,7 +1870,8 @@ static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 				unsigned int *srr, unsigned int *cks)
 {
-	int sr, c, br, err, recv_margin;
+	unsigned int sr, br, c;
+	int err, recv_margin;
 	int min_err = 1000; /* 100% */
 	int recv_max_margin = 0;
 
@@ -1880,9 +1881,9 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 		for (c = 0; c <= 3; c++) {
 			/* integerized formulas from HSCIF documentation */
 			br = DIV_ROUND_CLOSEST(freq, (sr *
-					      (1 << (2 * c + 1)) * bps)) - 1;
-			br = clamp(br, 0, 255);
-			err = DIV_ROUND_CLOSEST(freq, ((br + 1) * bps * sr *
+					      (1 << (2 * c + 1)) * bps));
+			br = clamp(br, 1U, 256U);
+			err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
 					       (1 << (2 * c + 1)) / 1000)) -
 					       1000;
 			/* Calc recv margin
@@ -1908,7 +1909,7 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 			else
 				continue;
 
-			*brr = br;
+			*brr = br - 1;
 			*srr = sr - 1;
 			*cks = c;
 		}
-- 
1.9.1

Re: [PATCH 08/25] serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:47 Geert Uytterhoeven wrote:
> Move the -1 offset of br to the assignment to *brr, so br cannot become
> negative anymore, and update the clamp() call. Now all unsigned values
> in sci_baud_calc_hscif() can become unsigned.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 9442961a198378c7..fba1e1eea15dc3a1 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1870,7 +1870,8 @@ static unsigned int sci_scbrr_calc(struct sci_port *s,
> unsigned int bps, static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, unsigned int *srr, unsigned int *cks)
>  {
> -	int sr, c, br, err, recv_margin;
> +	unsigned int sr, br, c;
> +	int err, recv_margin;
>  	int min_err = 1000; /* 100% */
>  	int recv_max_margin = 0;
> 
> @@ -1880,9 +1881,9 @@ static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, for (c = 0; c <= 3; c++) {
>  			/* integerized formulas from HSCIF documentation */
>  			br = DIV_ROUND_CLOSEST(freq, (sr *
> -					      (1 << (2 * c + 1)) * bps)) - 1;
> -			br = clamp(br, 0, 255);
> -			err = DIV_ROUND_CLOSEST(freq, ((br + 1) * bps * sr *
> +					      (1 << (2 * c + 1)) * bps));
> +			br = clamp(br, 1U, 256U);
> +			err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
>  					       (1 << (2 * c + 1)) / 1000)) -
>  					       1000;

While you're at it you can remove the parentheses around the second argument 
to DIV_ROUND_CLOSEST, they're not needed.

>  			/* Calc recv margin
> @@ -1908,7 +1909,7 @@ static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, else
>  				continue;
> 
> -			*brr = br;
> +			*brr = br - 1;
>  			*srr = sr - 1;
>  			*cks = c;
>  		}

-- 
Regards,

Laurent Pinchart

Re: [PATCH 08/25] serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:47 Geert Uytterhoeven wrote:
> Move the -1 offset of br to the assignment to *brr, so br cannot become
> negative anymore, and update the clamp() call. Now all unsigned values
> in sci_baud_calc_hscif() can become unsigned.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 9442961a198378c7..fba1e1eea15dc3a1 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1870,7 +1870,8 @@ static unsigned int sci_scbrr_calc(struct sci_port *s,
> unsigned int bps, static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, unsigned int *srr, unsigned int *cks)
>  {
> -	int sr, c, br, err, recv_margin;
> +	unsigned int sr, br, c;
> +	int err, recv_margin;
>  	int min_err = 1000; /* 100% */
>  	int recv_max_margin = 0;
> 
> @@ -1880,9 +1881,9 @@ static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, for (c = 0; c <= 3; c++) {
>  			/* integerized formulas from HSCIF documentation */
>  			br = DIV_ROUND_CLOSEST(freq, (sr *
> -					      (1 << (2 * c + 1)) * bps)) - 1;
> -			br = clamp(br, 0, 255);
> -			err = DIV_ROUND_CLOSEST(freq, ((br + 1) * bps * sr *
> +					      (1 << (2 * c + 1)) * bps));
> +			br = clamp(br, 1U, 256U);
> +			err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
>  					       (1 << (2 * c + 1)) / 1000)) -
>  					       1000;

While you're at it you can remove the parentheses around the second argument 
to DIV_ROUND_CLOSEST, they're not needed.

>  			/* Calc recv margin
> @@ -1908,7 +1909,7 @@ static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, else
>  				continue;
> 
> -			*brr = br;
> +			*brr = br - 1;
>  			*srr = sr - 1;
>  			*cks = c;
>  		}

-- 
Regards,

Laurent Pinchart

Re: [PATCH 08/25] serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:36 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c

>> @@ -1880,9 +1881,9 @@ static void sci_baud_calc_hscif(unsigned int bps,
>> unsigned long freq, int *brr, for (c = 0; c <= 3; c++) {
>>                       /* integerized formulas from HSCIF documentation */
>>                       br = DIV_ROUND_CLOSEST(freq, (sr *
>> -                                           (1 << (2 * c + 1)) * bps)) - 1;
>> -                     br = clamp(br, 0, 255);
>> -                     err = DIV_ROUND_CLOSEST(freq, ((br + 1) * bps * sr *
>> +                                           (1 << (2 * c + 1)) * bps));
>> +                     br = clamp(br, 1U, 256U);
>> +                     err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
>>                                              (1 << (2 * c + 1)) / 1000)) -
>>                                              1000;
>
> While you're at it you can remove the parentheses around the second argument
> to DIV_ROUND_CLOSEST, they're not needed.

The factor between parentheses is removed in the next patch.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 08/25] serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:36 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c

>> @@ -1880,9 +1881,9 @@ static void sci_baud_calc_hscif(unsigned int bps,
>> unsigned long freq, int *brr, for (c = 0; c <= 3; c++) {
>>                       /* integerized formulas from HSCIF documentation */
>>                       br = DIV_ROUND_CLOSEST(freq, (sr *
>> -                                           (1 << (2 * c + 1)) * bps)) - 1;
>> -                     br = clamp(br, 0, 255);
>> -                     err = DIV_ROUND_CLOSEST(freq, ((br + 1) * bps * sr *
>> +                                           (1 << (2 * c + 1)) * bps));
>> +                     br = clamp(br, 1U, 256U);
>> +                     err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
>>                                              (1 << (2 * c + 1)) / 1000)) -
>>                                              1000;
>
> While you're at it you can remove the parentheses around the second argument
> to DIV_ROUND_CLOSEST, they're not needed.

The factor between parentheses is removed in the next patch.

Gr{oetje,eeting}s,

                        Geert

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

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

[PATCH 09/25] serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()

[Geert Uytterhoeven]

If bps >= 1048576, the multiplication of "(sr * (1 << (2 * c + 1))" and
"bps" will overflow, and both br and err will contain bogus values.
Skip the current and all higher clock select predividers when overflow
is detected.  Simplify the calculations using intermediates while we're
at it.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index fba1e1eea15dc3a1..97a0f8ef5adc55a2 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1870,7 +1870,7 @@ static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 				unsigned int *srr, unsigned int *cks)
 {
-	unsigned int sr, br, c;
+	unsigned int sr, br, a, b, c;
 	int err, recv_margin;
 	int min_err = 1000; /* 100% */
 	int recv_max_margin = 0;
@@ -1880,12 +1880,14 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 	for (sr = 8; sr <= 32; sr++) {
 		for (c = 0; c <= 3; c++) {
 			/* integerized formulas from HSCIF documentation */
-			br = DIV_ROUND_CLOSEST(freq, (sr *
-					      (1 << (2 * c + 1)) * bps));
+			a = sr * (1 << (2 * c + 1));
+			if (bps > UINT_MAX / a)
+				break;
+
+			b = a * bps;
+			br = DIV_ROUND_CLOSEST(freq, b);
 			br = clamp(br, 1U, 256U);
-			err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
-					       (1 << (2 * c + 1)) / 1000)) -
-					       1000;
+			err = DIV_ROUND_CLOSEST(freq, (br * b) / 1000) - 1000;
 			/* Calc recv margin
 			 * M: Receive margin (%)
 			 * N: Ratio of bit rate to clock (N = sampling rate)
-- 
1.9.1

[PATCH 09/25] serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()

[Geert Uytterhoeven]

If bps >= 1048576, the multiplication of "(sr * (1 << (2 * c + 1))" and
"bps" will overflow, and both br and err will contain bogus values.
Skip the current and all higher clock select predividers when overflow
is detected.  Simplify the calculations using intermediates while we're
at it.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index fba1e1eea15dc3a1..97a0f8ef5adc55a2 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1870,7 +1870,7 @@ static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 				unsigned int *srr, unsigned int *cks)
 {
-	unsigned int sr, br, c;
+	unsigned int sr, br, a, b, c;
 	int err, recv_margin;
 	int min_err = 1000; /* 100% */
 	int recv_max_margin = 0;
@@ -1880,12 +1880,14 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 	for (sr = 8; sr <= 32; sr++) {
 		for (c = 0; c <= 3; c++) {
 			/* integerized formulas from HSCIF documentation */
-			br = DIV_ROUND_CLOSEST(freq, (sr *
-					      (1 << (2 * c + 1)) * bps));
+			a = sr * (1 << (2 * c + 1));
+			if (bps > UINT_MAX / a)
+				break;
+
+			b = a * bps;
+			br = DIV_ROUND_CLOSEST(freq, b);
 			br = clamp(br, 1U, 256U);
-			err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
-					       (1 << (2 * c + 1)) / 1000)) -
-					       1000;
+			err = DIV_ROUND_CLOSEST(freq, (br * b) / 1000) - 1000;
 			/* Calc recv margin
 			 * M: Receive margin (%)
 			 * N: Ratio of bit rate to clock (N = sampling rate)
-- 
1.9.1

Re: [PATCH 09/25] serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:48 Geert Uytterhoeven wrote:
> If bps >= 1048576, the multiplication of "(sr * (1 << (2 * c + 1))" and
> "bps" will overflow, and both br and err will contain bogus values.
> Skip the current and all higher clock select predividers when overflow
> is detected.  Simplify the calculations using intermediates while we're
> at it.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index fba1e1eea15dc3a1..97a0f8ef5adc55a2 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1870,7 +1870,7 @@ static unsigned int sci_scbrr_calc(struct sci_port *s,
> unsigned int bps, static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, unsigned int *srr, unsigned int *cks)
>  {
> -	unsigned int sr, br, c;
> +	unsigned int sr, br, a, b, c;
>  	int err, recv_margin;
>  	int min_err = 1000; /* 100% */
>  	int recv_max_margin = 0;
> @@ -1880,12 +1880,14 @@ static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, for (sr = 8; sr <= 32; sr++) {
>  		for (c = 0; c <= 3; c++) {
>  			/* integerized formulas from HSCIF documentation */
> -			br = DIV_ROUND_CLOSEST(freq, (sr *
> -					      (1 << (2 * c + 1)) * bps));
> +			a = sr * (1 << (2 * c + 1));
> +			if (bps > UINT_MAX / a)
> +				break;
> +
> +			b = a * bps;

This is becoming unreadable. Could you please use proper variable names ? A 
comment that explains the calculation would also be useful.

> +			br = DIV_ROUND_CLOSEST(freq, b);
>  			br = clamp(br, 1U, 256U);
> -			err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
> -					       (1 << (2 * c + 1)) / 1000)) -
> -					       1000;
> +			err = DIV_ROUND_CLOSEST(freq, (br * b) / 1000) - 1000;
>  			/* Calc recv margin
>  			 * M: Receive margin (%)
>  			 * N: Ratio of bit rate to clock (N = sampling rate)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 09/25] serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:48 Geert Uytterhoeven wrote:
> If bps >= 1048576, the multiplication of "(sr * (1 << (2 * c + 1))" and
> "bps" will overflow, and both br and err will contain bogus values.
> Skip the current and all higher clock select predividers when overflow
> is detected.  Simplify the calculations using intermediates while we're
> at it.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index fba1e1eea15dc3a1..97a0f8ef5adc55a2 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1870,7 +1870,7 @@ static unsigned int sci_scbrr_calc(struct sci_port *s,
> unsigned int bps, static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, unsigned int *srr, unsigned int *cks)
>  {
> -	unsigned int sr, br, c;
> +	unsigned int sr, br, a, b, c;
>  	int err, recv_margin;
>  	int min_err = 1000; /* 100% */
>  	int recv_max_margin = 0;
> @@ -1880,12 +1880,14 @@ static void sci_baud_calc_hscif(unsigned int bps,
> unsigned long freq, int *brr, for (sr = 8; sr <= 32; sr++) {
>  		for (c = 0; c <= 3; c++) {
>  			/* integerized formulas from HSCIF documentation */
> -			br = DIV_ROUND_CLOSEST(freq, (sr *
> -					      (1 << (2 * c + 1)) * bps));
> +			a = sr * (1 << (2 * c + 1));
> +			if (bps > UINT_MAX / a)
> +				break;
> +
> +			b = a * bps;

This is becoming unreadable. Could you please use proper variable names ? A 
comment that explains the calculation would also be useful.

> +			br = DIV_ROUND_CLOSEST(freq, b);
>  			br = clamp(br, 1U, 256U);
> -			err = DIV_ROUND_CLOSEST(freq, (br * bps * sr *
> -					       (1 << (2 * c + 1)) / 1000)) -
> -					       1000;
> +			err = DIV_ROUND_CLOSEST(freq, (br * b) / 1000) - 1000;
>  			/* Calc recv margin
>  			 * M: Receive margin (%)
>  			 * N: Ratio of bit rate to clock (N = sampling rate)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 09/25] serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:37 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c
>> @@ -1870,7 +1870,7 @@ static unsigned int sci_scbrr_calc(struct sci_port *s,
>> unsigned int bps, static void sci_baud_calc_hscif(unsigned int bps,
>> unsigned long freq, int *brr, unsigned int *srr, unsigned int *cks)
>>  {
>> -     unsigned int sr, br, c;
>> +     unsigned int sr, br, a, b, c;
>>       int err, recv_margin;
>>       int min_err = 1000; /* 100% */
>>       int recv_max_margin = 0;
>> @@ -1880,12 +1880,14 @@ static void sci_baud_calc_hscif(unsigned int bps,
>> unsigned long freq, int *brr, for (sr = 8; sr <= 32; sr++) {
>>               for (c = 0; c <= 3; c++) {
>>                       /* integerized formulas from HSCIF documentation */
>> -                     br = DIV_ROUND_CLOSEST(freq, (sr *
>> -                                           (1 << (2 * c + 1)) * bps));
>> +                     a = sr * (1 << (2 * c + 1));
>> +                     if (bps > UINT_MAX / a)
>> +                             break;
>> +
>> +                     b = a * bps;
>
> This is becoming unreadable. Could you please use proper variable names ? A

Sometimes it's different to find good variable names ("t1" and "t2"?).

> comment that explains the calculation would also be useful.

Thanks, that would indeed help.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 09/25] serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 9:37 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c
>> @@ -1870,7 +1870,7 @@ static unsigned int sci_scbrr_calc(struct sci_port *s,
>> unsigned int bps, static void sci_baud_calc_hscif(unsigned int bps,
>> unsigned long freq, int *brr, unsigned int *srr, unsigned int *cks)
>>  {
>> -     unsigned int sr, br, c;
>> +     unsigned int sr, br, a, b, c;
>>       int err, recv_margin;
>>       int min_err = 1000; /* 100% */
>>       int recv_max_margin = 0;
>> @@ -1880,12 +1880,14 @@ static void sci_baud_calc_hscif(unsigned int bps,
>> unsigned long freq, int *brr, for (sr = 8; sr <= 32; sr++) {
>>               for (c = 0; c <= 3; c++) {
>>                       /* integerized formulas from HSCIF documentation */
>> -                     br = DIV_ROUND_CLOSEST(freq, (sr *
>> -                                           (1 << (2 * c + 1)) * bps));
>> +                     a = sr * (1 << (2 * c + 1));
>> +                     if (bps > UINT_MAX / a)
>> +                             break;
>> +
>> +                     b = a * bps;
>
> This is becoming unreadable. Could you please use proper variable names ? A

Sometimes it's different to find good variable names ("t1" and "t2"?).

> comment that explains the calculation would also be useful.

Thanks, that would indeed help.

Gr{oetje,eeting}s,

                        Geert

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

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

[PATCH 10/25] serial: sh-sci: Improve bit rate error calculation for HSCIF

[Geert Uytterhoeven]

The algorithm to find the best parameters for the requested bit rate
calculates the relative bit rate error, using "(br * b) / 1000".
For small "br * b", this has two problems:
  - The quotient may be zero, leading to a division by zero error,
  - This may introduce a large rounding error.
Switch from relative to absolute bit rate error calculation to fix this.

The default baud rate generator values can be removed, as there will
always be one set of values that gives the smallest absolute error.

Print the best set of values when debugging.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 97a0f8ef5adc55a2..f35c209afd127c02 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1867,12 +1867,13 @@ static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 }
 
 /* calculate sample rate, BRR, and clock select for HSCIF */
-static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
+static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
+				unsigned long freq, int *brr,
 				unsigned int *srr, unsigned int *cks)
 {
 	unsigned int sr, br, a, b, c;
 	int err, recv_margin;
-	int min_err = 1000; /* 100% */
+	int min_err = INT_MAX;
 	int recv_max_margin = 0;
 
 	/* Find the combination of sample rate and clock select with the
@@ -1887,7 +1888,7 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 			b = a * bps;
 			br = DIV_ROUND_CLOSEST(freq, b);
 			br = clamp(br, 1U, 256U);
-			err = DIV_ROUND_CLOSEST(freq, (br * b) / 1000) - 1000;
+			err = DIV_ROUND_CLOSEST(freq, br * a) - bps;
 			/* Calc recv margin
 			 * M: Receive margin (%)
 			 * N: Ratio of bit rate to clock (N = sampling rate)
@@ -1917,13 +1918,8 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 		}
 	}
 
-	if (min_err = 1000) {
-		WARN_ON(1);
-		/* use defaults */
-		*brr = 255;
-		*srr = 15;
-		*cks = 0;
-	}
+	dev_dbg(s->port.dev, "BRR: %u%+d bps using N %u SR %u cks %u\n", bps,
+		min_err, *brr, *srr + 1, *cks);
 }
 
 static void sci_reset(struct uart_port *port)
@@ -1973,7 +1969,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
 	if (likely(baud && port->uartclk)) {
 		if (s->cfg->type = PORT_HSCIF) {
-			sci_baud_calc_hscif(baud, port->uartclk, &t, &srr,
+			sci_baud_calc_hscif(s, baud, port->uartclk, &t, &srr,
 					    &cks);
 		} else {
 			t = sci_scbrr_calc(s, baud, port->uartclk);
-- 
1.9.1

[PATCH 10/25] serial: sh-sci: Improve bit rate error calculation for HSCIF

[Geert Uytterhoeven]

The algorithm to find the best parameters for the requested bit rate
calculates the relative bit rate error, using "(br * b) / 1000".
For small "br * b", this has two problems:
  - The quotient may be zero, leading to a division by zero error,
  - This may introduce a large rounding error.
Switch from relative to absolute bit rate error calculation to fix this.

The default baud rate generator values can be removed, as there will
always be one set of values that gives the smallest absolute error.

Print the best set of values when debugging.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 97a0f8ef5adc55a2..f35c209afd127c02 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1867,12 +1867,13 @@ static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 }
 
 /* calculate sample rate, BRR, and clock select for HSCIF */
-static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
+static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
+				unsigned long freq, int *brr,
 				unsigned int *srr, unsigned int *cks)
 {
 	unsigned int sr, br, a, b, c;
 	int err, recv_margin;
-	int min_err = 1000; /* 100% */
+	int min_err = INT_MAX;
 	int recv_max_margin = 0;
 
 	/* Find the combination of sample rate and clock select with the
@@ -1887,7 +1888,7 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 			b = a * bps;
 			br = DIV_ROUND_CLOSEST(freq, b);
 			br = clamp(br, 1U, 256U);
-			err = DIV_ROUND_CLOSEST(freq, (br * b) / 1000) - 1000;
+			err = DIV_ROUND_CLOSEST(freq, br * a) - bps;
 			/* Calc recv margin
 			 * M: Receive margin (%)
 			 * N: Ratio of bit rate to clock (N = sampling rate)
@@ -1917,13 +1918,8 @@ static void sci_baud_calc_hscif(unsigned int bps, unsigned long freq, int *brr,
 		}
 	}
 
-	if (min_err == 1000) {
-		WARN_ON(1);
-		/* use defaults */
-		*brr = 255;
-		*srr = 15;
-		*cks = 0;
-	}
+	dev_dbg(s->port.dev, "BRR: %u%+d bps using N %u SR %u cks %u\n", bps,
+		min_err, *brr, *srr + 1, *cks);
 }
 
 static void sci_reset(struct uart_port *port)
@@ -1973,7 +1969,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
 	if (likely(baud && port->uartclk)) {
 		if (s->cfg->type == PORT_HSCIF) {
-			sci_baud_calc_hscif(baud, port->uartclk, &t, &srr,
+			sci_baud_calc_hscif(s, baud, port->uartclk, &t, &srr,
 					    &cks);
 		} else {
 			t = sci_scbrr_calc(s, baud, port->uartclk);
-- 
1.9.1

[PATCH 11/25] serial: sh-sci: Avoid calculating the receive margin for HSCIF

[Geert Uytterhoeven]

When assuming D = 0.5 and F = 0, maximizing the receive margin M is
equivalent to maximizing the sample rate N.

Hence there's no need to calculate the receive margin, as we can obtain
the same result by iterating over all possible sample rates in reverse
order, and skipping parameter sets that don't provide a lower bit rate
error.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 47 +++++++++++++++++++--------------------------
 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index f35c209afd127c02..c2ab29ddedbc26a2 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1872,13 +1872,24 @@ static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
 				unsigned int *srr, unsigned int *cks)
 {
 	unsigned int sr, br, a, b, c;
-	int err, recv_margin;
-	int min_err = INT_MAX;
-	int recv_max_margin = 0;
+	int err, min_err = INT_MAX;
 
-	/* Find the combination of sample rate and clock select with the
-	   smallest deviation from the desired baud rate. */
-	for (sr = 8; sr <= 32; sr++) {
+	/*
+	 * Find the combination of sample rate and clock select with the
+	 * smallest deviation from the desired baud rate.
+	 * Prefer high sample rates to maximise the receive margin.
+	 *
+	 * M: Receive margin (%)
+	 * N: Ratio of bit rate to clock (N = sampling rate)
+	 * D: Clock duty (D = 0 to 1.0)
+	 * L: Frame length (L = 9 to 12)
+	 * F: Absolute value of clock frequency deviation
+	 *
+	 *  M = |(0.5 - 1 / 2 * N) - ((L - 0.5) * F) -
+	 *      (|D - 0.5| / N * (1 + F))|
+	 *  NOTE: Usually, treat D for 0.5, F is 0 by this calculation.
+	 */
+	for (sr = 32; sr >= 8; sr--) {
 		for (c = 0; c <= 3; c++) {
 			/* integerized formulas from HSCIF documentation */
 			a = sr * (1 << (2 * c + 1));
@@ -1888,30 +1899,12 @@ static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
 			b = a * bps;
 			br = DIV_ROUND_CLOSEST(freq, b);
 			br = clamp(br, 1U, 256U);
+
 			err = DIV_ROUND_CLOSEST(freq, br * a) - bps;
-			/* Calc recv margin
-			 * M: Receive margin (%)
-			 * N: Ratio of bit rate to clock (N = sampling rate)
-			 * D: Clock duty (D = 0 to 1.0)
-			 * L: Frame length (L = 9 to 12)
-			 * F: Absolute value of clock frequency deviation
-			 *
-			 *  M = |(0.5 - 1 / 2 * N) - ((L - 0.5) * F) -
-			 *      (|D - 0.5| / N * (1 + F))|
-			 *  NOTE: Usually, treat D for 0.5, F is 0 by this
-			 *        calculation.
-			 */
-			recv_margin = abs((500 -
-					DIV_ROUND_CLOSEST(1000, sr << 1)) / 10);
-			if (abs(min_err) > abs(err)) {
-				min_err = err;
-				recv_max_margin = recv_margin;
-			} else if ((min_err = err) &&
-				   (recv_margin > recv_max_margin))
-				recv_max_margin = recv_margin;
-			else
+			if (abs(err) >= abs(min_err))
 				continue;
 
+			min_err = err;
 			*brr = br - 1;
 			*srr = sr - 1;
 			*cks = c;
-- 
1.9.1

[PATCH 11/25] serial: sh-sci: Avoid calculating the receive margin for HSCIF

[Geert Uytterhoeven]

When assuming D = 0.5 and F = 0, maximizing the receive margin M is
equivalent to maximizing the sample rate N.

Hence there's no need to calculate the receive margin, as we can obtain
the same result by iterating over all possible sample rates in reverse
order, and skipping parameter sets that don't provide a lower bit rate
error.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 47 +++++++++++++++++++--------------------------
 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index f35c209afd127c02..c2ab29ddedbc26a2 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1872,13 +1872,24 @@ static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
 				unsigned int *srr, unsigned int *cks)
 {
 	unsigned int sr, br, a, b, c;
-	int err, recv_margin;
-	int min_err = INT_MAX;
-	int recv_max_margin = 0;
+	int err, min_err = INT_MAX;
 
-	/* Find the combination of sample rate and clock select with the
-	   smallest deviation from the desired baud rate. */
-	for (sr = 8; sr <= 32; sr++) {
+	/*
+	 * Find the combination of sample rate and clock select with the
+	 * smallest deviation from the desired baud rate.
+	 * Prefer high sample rates to maximise the receive margin.
+	 *
+	 * M: Receive margin (%)
+	 * N: Ratio of bit rate to clock (N = sampling rate)
+	 * D: Clock duty (D = 0 to 1.0)
+	 * L: Frame length (L = 9 to 12)
+	 * F: Absolute value of clock frequency deviation
+	 *
+	 *  M = |(0.5 - 1 / 2 * N) - ((L - 0.5) * F) -
+	 *      (|D - 0.5| / N * (1 + F))|
+	 *  NOTE: Usually, treat D for 0.5, F is 0 by this calculation.
+	 */
+	for (sr = 32; sr >= 8; sr--) {
 		for (c = 0; c <= 3; c++) {
 			/* integerized formulas from HSCIF documentation */
 			a = sr * (1 << (2 * c + 1));
@@ -1888,30 +1899,12 @@ static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
 			b = a * bps;
 			br = DIV_ROUND_CLOSEST(freq, b);
 			br = clamp(br, 1U, 256U);
+
 			err = DIV_ROUND_CLOSEST(freq, br * a) - bps;
-			/* Calc recv margin
-			 * M: Receive margin (%)
-			 * N: Ratio of bit rate to clock (N = sampling rate)
-			 * D: Clock duty (D = 0 to 1.0)
-			 * L: Frame length (L = 9 to 12)
-			 * F: Absolute value of clock frequency deviation
-			 *
-			 *  M = |(0.5 - 1 / 2 * N) - ((L - 0.5) * F) -
-			 *      (|D - 0.5| / N * (1 + F))|
-			 *  NOTE: Usually, treat D for 0.5, F is 0 by this
-			 *        calculation.
-			 */
-			recv_margin = abs((500 -
-					DIV_ROUND_CLOSEST(1000, sr << 1)) / 10);
-			if (abs(min_err) > abs(err)) {
-				min_err = err;
-				recv_max_margin = recv_margin;
-			} else if ((min_err == err) &&
-				   (recv_margin > recv_max_margin))
-				recv_max_margin = recv_margin;
-			else
+			if (abs(err) >= abs(min_err))
 				continue;
 
+			min_err = err;
 			*brr = br - 1;
 			*srr = sr - 1;
 			*cks = c;
-- 
1.9.1

[PATCH 12/25] serial: sh-sci: Merge sci_scbrr_calc() and sci_baud_calc_hscif()

[Geert Uytterhoeven]

For low bit rates, the for-loop that reduces the divider returned by
sci_scbrr_calc() and picks the clock select value may terminate without
finding suitable values, leading to out-of-range divider and clock
select values.
sci_baud_calc_hscif() doesn't suffer from this problem, as it correctly
uses clamp().

Since there are only two relevant differences between HSCIF and other
variants w.r.t. bit rate configuration (fixed vs. variable sample rate,
and an additional factor of two), sci_scbrr_calc() and
sci_baud_calc_hscif() can be merged, fixing the issue with out-of-range
values.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 42 +++++++++++++++++++-----------------------
 1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index c2ab29ddedbc26a2..dccea5df5355076a 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1860,20 +1860,24 @@ static void sci_shutdown(struct uart_port *port)
 	sci_free_irq(s);
 }
 
-static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
-				   unsigned long freq)
+/* calculate sample rate, BRR, and clock select */
+static void sci_scbrr_calc(struct sci_port *s, unsigned int bps,
+			   unsigned long freq, int *brr, unsigned int *srr,
+			   unsigned int *cks)
 {
-	return DIV_ROUND_CLOSEST(freq, s->sampling_rate * bps) - 1;
-}
-
-/* calculate sample rate, BRR, and clock select for HSCIF */
-static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
-				unsigned long freq, int *brr,
-				unsigned int *srr, unsigned int *cks)
-{
-	unsigned int sr, br, a, b, c;
+	unsigned int min_sr, max_sr, shift, sr, br, a, b, c;
 	int err, min_err = INT_MAX;
 
+	if (s->sampling_rate) {
+		min_sr = max_sr = s->sampling_rate;
+		shift = 0;
+	} else {
+		/* HSCIF has a variable sample rate */
+		min_sr = 8;
+		max_sr = 32;
+		shift = 1;
+	}
+
 	/*
 	 * Find the combination of sample rate and clock select with the
 	 * smallest deviation from the desired baud rate.
@@ -1889,10 +1893,10 @@ static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
 	 *      (|D - 0.5| / N * (1 + F))|
 	 *  NOTE: Usually, treat D for 0.5, F is 0 by this calculation.
 	 */
-	for (sr = 32; sr >= 8; sr--) {
+	for (sr = max_sr; sr >= min_sr; sr--) {
 		for (c = 0; c <= 3; c++) {
 			/* integerized formulas from HSCIF documentation */
-			a = sr * (1 << (2 * c + 1));
+			a = sr * (1 << (2 * c + shift));
 			if (bps > UINT_MAX / a)
 				break;
 
@@ -1960,16 +1964,8 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	max_baud = port->uartclk ? port->uartclk / 16 : 115200;
 
 	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
-	if (likely(baud && port->uartclk)) {
-		if (s->cfg->type = PORT_HSCIF) {
-			sci_baud_calc_hscif(s, baud, port->uartclk, &t, &srr,
-					    &cks);
-		} else {
-			t = sci_scbrr_calc(s, baud, port->uartclk);
-			for (cks = 0; t >= 256 && cks <= 3; cks++)
-				t >>= 2;
-		}
-	}
+	if (likely(baud && port->uartclk))
+		sci_scbrr_calc(s, baud, port->uartclk, &t, &srr, &cks);
 
 	sci_port_enable(s);
 
-- 
1.9.1

[PATCH 12/25] serial: sh-sci: Merge sci_scbrr_calc() and sci_baud_calc_hscif()

[Geert Uytterhoeven]

For low bit rates, the for-loop that reduces the divider returned by
sci_scbrr_calc() and picks the clock select value may terminate without
finding suitable values, leading to out-of-range divider and clock
select values.
sci_baud_calc_hscif() doesn't suffer from this problem, as it correctly
uses clamp().

Since there are only two relevant differences between HSCIF and other
variants w.r.t. bit rate configuration (fixed vs. variable sample rate,
and an additional factor of two), sci_scbrr_calc() and
sci_baud_calc_hscif() can be merged, fixing the issue with out-of-range
values.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 42 +++++++++++++++++++-----------------------
 1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index c2ab29ddedbc26a2..dccea5df5355076a 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1860,20 +1860,24 @@ static void sci_shutdown(struct uart_port *port)
 	sci_free_irq(s);
 }
 
-static unsigned int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
-				   unsigned long freq)
+/* calculate sample rate, BRR, and clock select */
+static void sci_scbrr_calc(struct sci_port *s, unsigned int bps,
+			   unsigned long freq, int *brr, unsigned int *srr,
+			   unsigned int *cks)
 {
-	return DIV_ROUND_CLOSEST(freq, s->sampling_rate * bps) - 1;
-}
-
-/* calculate sample rate, BRR, and clock select for HSCIF */
-static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
-				unsigned long freq, int *brr,
-				unsigned int *srr, unsigned int *cks)
-{
-	unsigned int sr, br, a, b, c;
+	unsigned int min_sr, max_sr, shift, sr, br, a, b, c;
 	int err, min_err = INT_MAX;
 
+	if (s->sampling_rate) {
+		min_sr = max_sr = s->sampling_rate;
+		shift = 0;
+	} else {
+		/* HSCIF has a variable sample rate */
+		min_sr = 8;
+		max_sr = 32;
+		shift = 1;
+	}
+
 	/*
 	 * Find the combination of sample rate and clock select with the
 	 * smallest deviation from the desired baud rate.
@@ -1889,10 +1893,10 @@ static void sci_baud_calc_hscif(struct sci_port *s, unsigned int bps,
 	 *      (|D - 0.5| / N * (1 + F))|
 	 *  NOTE: Usually, treat D for 0.5, F is 0 by this calculation.
 	 */
-	for (sr = 32; sr >= 8; sr--) {
+	for (sr = max_sr; sr >= min_sr; sr--) {
 		for (c = 0; c <= 3; c++) {
 			/* integerized formulas from HSCIF documentation */
-			a = sr * (1 << (2 * c + 1));
+			a = sr * (1 << (2 * c + shift));
 			if (bps > UINT_MAX / a)
 				break;
 
@@ -1960,16 +1964,8 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	max_baud = port->uartclk ? port->uartclk / 16 : 115200;
 
 	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
-	if (likely(baud && port->uartclk)) {
-		if (s->cfg->type == PORT_HSCIF) {
-			sci_baud_calc_hscif(s, baud, port->uartclk, &t, &srr,
-					    &cks);
-		} else {
-			t = sci_scbrr_calc(s, baud, port->uartclk);
-			for (cks = 0; t >= 256 && cks <= 3; cks++)
-				t >>= 2;
-		}
-	}
+	if (likely(baud && port->uartclk))
+		sci_scbrr_calc(s, baud, port->uartclk, &t, &srr, &cks);
 
 	sci_port_enable(s);
 
-- 
1.9.1

[PATCH 13/25] serial: sh-sci: Take into account sampling rate for max baud rate

[Geert Uytterhoeven]

The maximum baud rate depends on the sampling rate.
HSCIF has a variable sampling rate and sets s->sampling_rate to zero,
hence use the minimum sampling rate of 8.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index dccea5df5355076a..d82735dd62ae38d8 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1961,7 +1961,10 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	 * that the previous boot loader has enabled required clocks and
 	 * setup the baud rate generator hardware for us already.
 	 */
-	max_baud = port->uartclk ? port->uartclk / 16 : 115200;
+	if (port->uartclk)
+		max_baud = port->uartclk / max(s->sampling_rate, 8U);
+	else
+		max_baud = 115200;
 
 	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
 	if (likely(baud && port->uartclk))
-- 
1.9.1

[PATCH 13/25] serial: sh-sci: Take into account sampling rate for max baud rate

[Geert Uytterhoeven]

The maximum baud rate depends on the sampling rate.
HSCIF has a variable sampling rate and sets s->sampling_rate to zero,
hence use the minimum sampling rate of 8.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index dccea5df5355076a..d82735dd62ae38d8 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1961,7 +1961,10 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	 * that the previous boot loader has enabled required clocks and
 	 * setup the baud rate generator hardware for us already.
 	 */
-	max_baud = port->uartclk ? port->uartclk / 16 : 115200;
+	if (port->uartclk)
+		max_baud = port->uartclk / max(s->sampling_rate, 8U);
+	else
+		max_baud = 115200;
 
 	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
 	if (likely(baud && port->uartclk))
-- 
1.9.1

[PATCH 14/25] serial: sh-sci: Add BRG register definitions

[Geert Uytterhoeven]

Add register definitions for the Baud Rate Generator for External Clock
(BRG), as found in some SCIF and in HSCIF, including a new regtype for
the "SH-4(A)"-derived SCIF variant with BRG.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 46 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/tty/serial/sh-sci.h |  5 +++++
 include/linux/serial_sci.h  |  1 +
 3 files changed, 52 insertions(+)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index d82735dd62ae38d8..76738c9918885764 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -161,6 +161,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -183,6 +185,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -204,6 +208,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= { 0x30, 16 },
 		[SCPDR]		= { 0x34, 16 },
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -225,6 +231,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= { 0x30, 16 },
 		[SCPDR]		= { 0x34, 16 },
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -247,6 +255,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -268,6 +278,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -289,6 +301,32 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
+	},
+
+	/*
+	 * Common SCIF definitions for ports with a Baud Rate Generator for
+	 * External Clock (BRG).
+	 */
+	[SCIx_SH4_SCIF_BRG_REGTYPE] = {
+		[SCSMR]		= { 0x00, 16 },
+		[SCBRR]		= { 0x04,  8 },
+		[SCSCR]		= { 0x08, 16 },
+		[SCxTDR]	= { 0x0c,  8 },
+		[SCxSR]		= { 0x10, 16 },
+		[SCxRDR]	= { 0x14,  8 },
+		[SCFCR]		= { 0x18, 16 },
+		[SCFDR]		= { 0x1c, 16 },
+		[SCTFDR]	= sci_reg_invalid,
+		[SCRFDR]	= sci_reg_invalid,
+		[SCSPTR]	= { 0x20, 16 },
+		[SCLSR]		= { 0x24, 16 },
+		[HSSRR]		= sci_reg_invalid,
+		[SCPCR]		= sci_reg_invalid,
+		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= { 0x30, 16 },
+		[SCCKS]		= { 0x34, 16 },
 	},
 
 	/*
@@ -310,6 +348,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= { 0x40, 16 },
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= { 0x30, 16 },
+		[SCCKS]		= { 0x34, 16 },
 	},
 
 	/*
@@ -332,6 +372,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -354,6 +396,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -376,6 +420,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 };
 
diff --git a/drivers/tty/serial/sh-sci.h b/drivers/tty/serial/sh-sci.h
index bf69bbdcc1f9aa39..54994f0bfafdbe12 100644
--- a/drivers/tty/serial/sh-sci.h
+++ b/drivers/tty/serial/sh-sci.h
@@ -27,6 +27,8 @@ enum {
 	HSSRR,				/* Sampling Rate Register */
 	SCPCR,				/* Serial Port Control Register */
 	SCPDR,				/* Serial Port Data Register */
+	SCDL,				/* BRG Frequency Division Register */
+	SCCKS,				/* BRG Clock Select Register */
 
 	SCIx_NR_REGS,
 };
@@ -109,6 +111,9 @@ enum {
 #define SCPDR_RTSD	BIT(4)	/* Serial Port RTS Output Pin Data */
 #define SCPDR_CTSD	BIT(3)	/* Serial Port CTS Input Pin Data */
 
+/* BRG Clock Select Register (Some SCIF and HSCIF) */
+#define SCCKS_CKS	BIT(15)	/* Select SCK (1) or SC_CLK (0) */
+#define SCCKS_XIN	BIT(14)	/* SC_CLK uses bus clock (1) or SCIF_CLK (0) */
 
 #define SCxSR_TEND(port)	(((port)->type = PORT_SCI) ? SCI_TEND   : SCIF_TEND)
 #define SCxSR_RDxF(port)	(((port)->type = PORT_SCI) ? SCI_RDRF   : SCIF_RDF)
diff --git a/include/linux/serial_sci.h b/include/linux/serial_sci.h
index 7c536ac5be05d3aa..9f2bfd0557429ac3 100644
--- a/include/linux/serial_sci.h
+++ b/include/linux/serial_sci.h
@@ -32,6 +32,7 @@ enum {
 	SCIx_SH2_SCIF_FIFODATA_REGTYPE,
 	SCIx_SH3_SCIF_REGTYPE,
 	SCIx_SH4_SCIF_REGTYPE,
+	SCIx_SH4_SCIF_BRG_REGTYPE,
 	SCIx_SH4_SCIF_NO_SCSPTR_REGTYPE,
 	SCIx_SH4_SCIF_FIFODATA_REGTYPE,
 	SCIx_SH7705_SCIF_REGTYPE,
-- 
1.9.1

[PATCH 14/25] serial: sh-sci: Add BRG register definitions

[Geert Uytterhoeven]

Add register definitions for the Baud Rate Generator for External Clock
(BRG), as found in some SCIF and in HSCIF, including a new regtype for
the "SH-4(A)"-derived SCIF variant with BRG.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 46 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/tty/serial/sh-sci.h |  5 +++++
 include/linux/serial_sci.h  |  1 +
 3 files changed, 52 insertions(+)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index d82735dd62ae38d8..76738c9918885764 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -161,6 +161,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -183,6 +185,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -204,6 +208,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= { 0x30, 16 },
 		[SCPDR]		= { 0x34, 16 },
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -225,6 +231,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= { 0x30, 16 },
 		[SCPDR]		= { 0x34, 16 },
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -247,6 +255,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -268,6 +278,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -289,6 +301,32 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
+	},
+
+	/*
+	 * Common SCIF definitions for ports with a Baud Rate Generator for
+	 * External Clock (BRG).
+	 */
+	[SCIx_SH4_SCIF_BRG_REGTYPE] = {
+		[SCSMR]		= { 0x00, 16 },
+		[SCBRR]		= { 0x04,  8 },
+		[SCSCR]		= { 0x08, 16 },
+		[SCxTDR]	= { 0x0c,  8 },
+		[SCxSR]		= { 0x10, 16 },
+		[SCxRDR]	= { 0x14,  8 },
+		[SCFCR]		= { 0x18, 16 },
+		[SCFDR]		= { 0x1c, 16 },
+		[SCTFDR]	= sci_reg_invalid,
+		[SCRFDR]	= sci_reg_invalid,
+		[SCSPTR]	= { 0x20, 16 },
+		[SCLSR]		= { 0x24, 16 },
+		[HSSRR]		= sci_reg_invalid,
+		[SCPCR]		= sci_reg_invalid,
+		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= { 0x30, 16 },
+		[SCCKS]		= { 0x34, 16 },
 	},
 
 	/*
@@ -310,6 +348,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= { 0x40, 16 },
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= { 0x30, 16 },
+		[SCCKS]		= { 0x34, 16 },
 	},
 
 	/*
@@ -332,6 +372,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -354,6 +396,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 
 	/*
@@ -376,6 +420,8 @@ static const struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
 		[HSSRR]		= sci_reg_invalid,
 		[SCPCR]		= sci_reg_invalid,
 		[SCPDR]		= sci_reg_invalid,
+		[SCDL]		= sci_reg_invalid,
+		[SCCKS]		= sci_reg_invalid,
 	},
 };
 
diff --git a/drivers/tty/serial/sh-sci.h b/drivers/tty/serial/sh-sci.h
index bf69bbdcc1f9aa39..54994f0bfafdbe12 100644
--- a/drivers/tty/serial/sh-sci.h
+++ b/drivers/tty/serial/sh-sci.h
@@ -27,6 +27,8 @@ enum {
 	HSSRR,				/* Sampling Rate Register */
 	SCPCR,				/* Serial Port Control Register */
 	SCPDR,				/* Serial Port Data Register */
+	SCDL,				/* BRG Frequency Division Register */
+	SCCKS,				/* BRG Clock Select Register */
 
 	SCIx_NR_REGS,
 };
@@ -109,6 +111,9 @@ enum {
 #define SCPDR_RTSD	BIT(4)	/* Serial Port RTS Output Pin Data */
 #define SCPDR_CTSD	BIT(3)	/* Serial Port CTS Input Pin Data */
 
+/* BRG Clock Select Register (Some SCIF and HSCIF) */
+#define SCCKS_CKS	BIT(15)	/* Select SCK (1) or SC_CLK (0) */
+#define SCCKS_XIN	BIT(14)	/* SC_CLK uses bus clock (1) or SCIF_CLK (0) */
 
 #define SCxSR_TEND(port)	(((port)->type == PORT_SCI) ? SCI_TEND   : SCIF_TEND)
 #define SCxSR_RDxF(port)	(((port)->type == PORT_SCI) ? SCI_RDRF   : SCIF_RDF)
diff --git a/include/linux/serial_sci.h b/include/linux/serial_sci.h
index 7c536ac5be05d3aa..9f2bfd0557429ac3 100644
--- a/include/linux/serial_sci.h
+++ b/include/linux/serial_sci.h
@@ -32,6 +32,7 @@ enum {
 	SCIx_SH2_SCIF_FIFODATA_REGTYPE,
 	SCIx_SH3_SCIF_REGTYPE,
 	SCIx_SH4_SCIF_REGTYPE,
+	SCIx_SH4_SCIF_BRG_REGTYPE,
 	SCIx_SH4_SCIF_NO_SCSPTR_REGTYPE,
 	SCIx_SH4_SCIF_FIFODATA_REGTYPE,
 	SCIx_SH7705_SCIF_REGTYPE,
-- 
1.9.1

Re: [PATCH 14/25] serial: sh-sci: Add BRG register definitions

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:53 Geert Uytterhoeven wrote:
> Add register definitions for the Baud Rate Generator for External Clock
> (BRG), as found in some SCIF and in HSCIF, including a new regtype for
> the "SH-4(A)"-derived SCIF variant with BRG.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 46 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/tty/serial/sh-sci.h |  5 +++++
>  include/linux/serial_sci.h  |  1 +
>  3 files changed, 52 insertions(+)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index d82735dd62ae38d8..76738c9918885764 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -161,6 +161,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -183,6 +185,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -204,6 +208,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= { 0x30, 16 },
>  		[SCPDR]		= { 0x34, 16 },
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -225,6 +231,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= { 0x30, 16 },
>  		[SCPDR]		= { 0x34, 16 },
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -247,6 +255,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -268,6 +278,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -289,6 +301,32 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
> +	},
> +
> +	/*
> +	 * Common SCIF definitions for ports with a Baud Rate Generator for
> +	 * External Clock (BRG).
> +	 */
> +	[SCIx_SH4_SCIF_BRG_REGTYPE] = {
> +		[SCSMR]		= { 0x00, 16 },
> +		[SCBRR]		= { 0x04,  8 },
> +		[SCSCR]		= { 0x08, 16 },
> +		[SCxTDR]	= { 0x0c,  8 },
> +		[SCxSR]		= { 0x10, 16 },
> +		[SCxRDR]	= { 0x14,  8 },
> +		[SCFCR]		= { 0x18, 16 },
> +		[SCFDR]		= { 0x1c, 16 },
> +		[SCTFDR]	= sci_reg_invalid,
> +		[SCRFDR]	= sci_reg_invalid,
> +		[SCSPTR]	= { 0x20, 16 },
> +		[SCLSR]		= { 0x24, 16 },
> +		[HSSRR]		= sci_reg_invalid,
> +		[SCPCR]		= sci_reg_invalid,
> +		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= { 0x30, 16 },
> +		[SCCKS]		= { 0x34, 16 },
>  	},
> 
>  	/*
> @@ -310,6 +348,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= { 0x40, 16 },
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= { 0x30, 16 },
> +		[SCCKS]		= { 0x34, 16 },
>  	},
> 
>  	/*
> @@ -332,6 +372,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -354,6 +396,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -376,6 +420,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
>  };
> 
> diff --git a/drivers/tty/serial/sh-sci.h b/drivers/tty/serial/sh-sci.h
> index bf69bbdcc1f9aa39..54994f0bfafdbe12 100644
> --- a/drivers/tty/serial/sh-sci.h
> +++ b/drivers/tty/serial/sh-sci.h
> @@ -27,6 +27,8 @@ enum {
>  	HSSRR,				/* Sampling Rate Register */
>  	SCPCR,				/* Serial Port Control Register */
>  	SCPDR,				/* Serial Port Data Register */
> +	SCDL,				/* BRG Frequency Division Register */
> +	SCCKS,				/* BRG Clock Select Register */
> 
>  	SCIx_NR_REGS,
>  };
> @@ -109,6 +111,9 @@ enum {
>  #define SCPDR_RTSD	BIT(4)	/* Serial Port RTS Output Pin Data */
>  #define SCPDR_CTSD	BIT(3)	/* Serial Port CTS Input Pin Data */
> 
> +/* BRG Clock Select Register (Some SCIF and HSCIF) */
> +#define SCCKS_CKS	BIT(15)	/* Select SCK (1) or SC_CLK (0) */

This is slightly confusing. SC_CLK is defined as the external clock selectable 
between the bus clock and SCIF_CLK. The CKS bit selects the output of the baud 
rate generator for external clock as being the divided SC_CLK or the undivided 
(H)SCK. The comment, and I know it comes from the datasheet, seems to imply 
that the bit selects the input of the BRG-EC. Speaking of which it would be 
good to have a comment somewhere in the code to explain that we have two 
chained BRGs.

> +#define SCCKS_XIN	BIT(14)	/* SC_CLK uses bus clock (1) or SCIF_CLK (0) 
*/
> 
>  #define SCxSR_TEND(port)	(((port)->type = PORT_SCI) ? SCI_TEND   :
> SCIF_TEND) #define SCxSR_RDxF(port)	(((port)->type = PORT_SCI) ? 
SCI_RDRF 
>  : SCIF_RDF) diff --git a/include/linux/serial_sci.h
> b/include/linux/serial_sci.h index 7c536ac5be05d3aa..9f2bfd0557429ac3
> 100644
> --- a/include/linux/serial_sci.h
> +++ b/include/linux/serial_sci.h
> @@ -32,6 +32,7 @@ enum {
>  	SCIx_SH2_SCIF_FIFODATA_REGTYPE,
>  	SCIx_SH3_SCIF_REGTYPE,
>  	SCIx_SH4_SCIF_REGTYPE,
> +	SCIx_SH4_SCIF_BRG_REGTYPE,
>  	SCIx_SH4_SCIF_NO_SCSPTR_REGTYPE,
>  	SCIx_SH4_SCIF_FIFODATA_REGTYPE,
>  	SCIx_SH7705_SCIF_REGTYPE,

-- 
Regards,

Laurent Pinchart

Re: [PATCH 14/25] serial: sh-sci: Add BRG register definitions

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:53 Geert Uytterhoeven wrote:
> Add register definitions for the Baud Rate Generator for External Clock
> (BRG), as found in some SCIF and in HSCIF, including a new regtype for
> the "SH-4(A)"-derived SCIF variant with BRG.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 46 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/tty/serial/sh-sci.h |  5 +++++
>  include/linux/serial_sci.h  |  1 +
>  3 files changed, 52 insertions(+)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index d82735dd62ae38d8..76738c9918885764 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -161,6 +161,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -183,6 +185,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -204,6 +208,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= { 0x30, 16 },
>  		[SCPDR]		= { 0x34, 16 },
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -225,6 +231,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= { 0x30, 16 },
>  		[SCPDR]		= { 0x34, 16 },
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -247,6 +255,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -268,6 +278,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -289,6 +301,32 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
> +	},
> +
> +	/*
> +	 * Common SCIF definitions for ports with a Baud Rate Generator for
> +	 * External Clock (BRG).
> +	 */
> +	[SCIx_SH4_SCIF_BRG_REGTYPE] = {
> +		[SCSMR]		= { 0x00, 16 },
> +		[SCBRR]		= { 0x04,  8 },
> +		[SCSCR]		= { 0x08, 16 },
> +		[SCxTDR]	= { 0x0c,  8 },
> +		[SCxSR]		= { 0x10, 16 },
> +		[SCxRDR]	= { 0x14,  8 },
> +		[SCFCR]		= { 0x18, 16 },
> +		[SCFDR]		= { 0x1c, 16 },
> +		[SCTFDR]	= sci_reg_invalid,
> +		[SCRFDR]	= sci_reg_invalid,
> +		[SCSPTR]	= { 0x20, 16 },
> +		[SCLSR]		= { 0x24, 16 },
> +		[HSSRR]		= sci_reg_invalid,
> +		[SCPCR]		= sci_reg_invalid,
> +		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= { 0x30, 16 },
> +		[SCCKS]		= { 0x34, 16 },
>  	},
> 
>  	/*
> @@ -310,6 +348,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= { 0x40, 16 },
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= { 0x30, 16 },
> +		[SCCKS]		= { 0x34, 16 },
>  	},
> 
>  	/*
> @@ -332,6 +372,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -354,6 +396,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
> 
>  	/*
> @@ -376,6 +420,8 @@ static const struct plat_sci_reg
> sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = { [HSSRR]		= 
sci_reg_invalid,
>  		[SCPCR]		= sci_reg_invalid,
>  		[SCPDR]		= sci_reg_invalid,
> +		[SCDL]		= sci_reg_invalid,
> +		[SCCKS]		= sci_reg_invalid,
>  	},
>  };
> 
> diff --git a/drivers/tty/serial/sh-sci.h b/drivers/tty/serial/sh-sci.h
> index bf69bbdcc1f9aa39..54994f0bfafdbe12 100644
> --- a/drivers/tty/serial/sh-sci.h
> +++ b/drivers/tty/serial/sh-sci.h
> @@ -27,6 +27,8 @@ enum {
>  	HSSRR,				/* Sampling Rate Register */
>  	SCPCR,				/* Serial Port Control Register */
>  	SCPDR,				/* Serial Port Data Register */
> +	SCDL,				/* BRG Frequency Division Register */
> +	SCCKS,				/* BRG Clock Select Register */
> 
>  	SCIx_NR_REGS,
>  };
> @@ -109,6 +111,9 @@ enum {
>  #define SCPDR_RTSD	BIT(4)	/* Serial Port RTS Output Pin Data */
>  #define SCPDR_CTSD	BIT(3)	/* Serial Port CTS Input Pin Data */
> 
> +/* BRG Clock Select Register (Some SCIF and HSCIF) */
> +#define SCCKS_CKS	BIT(15)	/* Select SCK (1) or SC_CLK (0) */

This is slightly confusing. SC_CLK is defined as the external clock selectable 
between the bus clock and SCIF_CLK. The CKS bit selects the output of the baud 
rate generator for external clock as being the divided SC_CLK or the undivided 
(H)SCK. The comment, and I know it comes from the datasheet, seems to imply 
that the bit selects the input of the BRG-EC. Speaking of which it would be 
good to have a comment somewhere in the code to explain that we have two 
chained BRGs.

> +#define SCCKS_XIN	BIT(14)	/* SC_CLK uses bus clock (1) or SCIF_CLK (0) 
*/
> 
>  #define SCxSR_TEND(port)	(((port)->type == PORT_SCI) ? SCI_TEND   :
> SCIF_TEND) #define SCxSR_RDxF(port)	(((port)->type == PORT_SCI) ? 
SCI_RDRF 
>  : SCIF_RDF) diff --git a/include/linux/serial_sci.h
> b/include/linux/serial_sci.h index 7c536ac5be05d3aa..9f2bfd0557429ac3
> 100644
> --- a/include/linux/serial_sci.h
> +++ b/include/linux/serial_sci.h
> @@ -32,6 +32,7 @@ enum {
>  	SCIx_SH2_SCIF_FIFODATA_REGTYPE,
>  	SCIx_SH3_SCIF_REGTYPE,
>  	SCIx_SH4_SCIF_REGTYPE,
> +	SCIx_SH4_SCIF_BRG_REGTYPE,
>  	SCIx_SH4_SCIF_NO_SCSPTR_REGTYPE,
>  	SCIx_SH4_SCIF_FIFODATA_REGTYPE,
>  	SCIx_SH7705_SCIF_REGTYPE,

-- 
Regards,

Laurent Pinchart

[PATCH 15/25] serial: sh-sci: Replace struct sci_port_info by type/regtype encoding

[Geert Uytterhoeven]

Store the encoded port and register types directly in of_device_id.data,
instead of using a pointer to a structure.
This saves memory and simplifies the source code, especially when adding
more compatible entries later.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 40 +++++++++++-----------------------------
 1 file changed, 11 insertions(+), 29 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 76738c9918885764..41351ae055de661f 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2595,42 +2595,27 @@ static int sci_remove(struct platform_device *dev)
 	return 0;
 }
 
-struct sci_port_info {
-	unsigned int type;
-	unsigned int regtype;
-};
+
+#define SCI_OF_DATA(type, regtype)	(void *)((type) << 16 | (regtype))
+#define SCI_OF_TYPE(data)		((unsigned long)(data) >> 16)
+#define SCI_OF_REGTYPE(data)		((unsigned long)(data) & 0xffff)
 
 static const struct of_device_id of_sci_match[] = {
 	{
 		.compatible = "renesas,scif",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_SCIF,
-			.regtype = SCIx_SH4_SCIF_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_REGTYPE),
 	}, {
 		.compatible = "renesas,scifa",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_SCIFA,
-			.regtype = SCIx_SCIFA_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_SCIFA, SCIx_SCIFA_REGTYPE),
 	}, {
 		.compatible = "renesas,scifb",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_SCIFB,
-			.regtype = SCIx_SCIFB_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_SCIFB, SCIx_SCIFB_REGTYPE),
 	}, {
 		.compatible = "renesas,hscif",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_HSCIF,
-			.regtype = SCIx_HSCIF_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_HSCIF, SCIx_HSCIF_REGTYPE),
 	}, {
 		.compatible = "renesas,sci",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_SCI,
-			.regtype = SCIx_SCI_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_SCI, SCIx_SCI_REGTYPE),
 	}, {
 		/* Terminator */
 	},
@@ -2642,7 +2627,6 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
 {
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *match;
-	const struct sci_port_info *info;
 	struct plat_sci_port *p;
 	int id;
 
@@ -2653,8 +2637,6 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
 	if (!match)
 		return NULL;
 
-	info = match->data;
-
 	p = devm_kzalloc(&pdev->dev, sizeof(struct plat_sci_port), GFP_KERNEL);
 	if (!p)
 		return NULL;
@@ -2669,8 +2651,8 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
 	*dev_id = id;
 
 	p->flags = UPF_IOREMAP | UPF_BOOT_AUTOCONF;
-	p->type = info->type;
-	p->regtype = info->regtype;
+	p->type = SCI_OF_TYPE(match->data);
+	p->regtype = SCI_OF_REGTYPE(match->data);
 	p->scscr = SCSCR_RE | SCSCR_TE;
 
 	return p;
-- 
1.9.1

[PATCH 15/25] serial: sh-sci: Replace struct sci_port_info by type/regtype encoding

[Geert Uytterhoeven]

Store the encoded port and register types directly in of_device_id.data,
instead of using a pointer to a structure.
This saves memory and simplifies the source code, especially when adding
more compatible entries later.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 40 +++++++++++-----------------------------
 1 file changed, 11 insertions(+), 29 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 76738c9918885764..41351ae055de661f 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2595,42 +2595,27 @@ static int sci_remove(struct platform_device *dev)
 	return 0;
 }
 
-struct sci_port_info {
-	unsigned int type;
-	unsigned int regtype;
-};
+
+#define SCI_OF_DATA(type, regtype)	(void *)((type) << 16 | (regtype))
+#define SCI_OF_TYPE(data)		((unsigned long)(data) >> 16)
+#define SCI_OF_REGTYPE(data)		((unsigned long)(data) & 0xffff)
 
 static const struct of_device_id of_sci_match[] = {
 	{
 		.compatible = "renesas,scif",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_SCIF,
-			.regtype = SCIx_SH4_SCIF_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_REGTYPE),
 	}, {
 		.compatible = "renesas,scifa",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_SCIFA,
-			.regtype = SCIx_SCIFA_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_SCIFA, SCIx_SCIFA_REGTYPE),
 	}, {
 		.compatible = "renesas,scifb",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_SCIFB,
-			.regtype = SCIx_SCIFB_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_SCIFB, SCIx_SCIFB_REGTYPE),
 	}, {
 		.compatible = "renesas,hscif",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_HSCIF,
-			.regtype = SCIx_HSCIF_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_HSCIF, SCIx_HSCIF_REGTYPE),
 	}, {
 		.compatible = "renesas,sci",
-		.data = &(const struct sci_port_info) {
-			.type = PORT_SCI,
-			.regtype = SCIx_SCI_REGTYPE,
-		},
+		.data = SCI_OF_DATA(PORT_SCI, SCIx_SCI_REGTYPE),
 	}, {
 		/* Terminator */
 	},
@@ -2642,7 +2627,6 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
 {
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *match;
-	const struct sci_port_info *info;
 	struct plat_sci_port *p;
 	int id;
 
@@ -2653,8 +2637,6 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
 	if (!match)
 		return NULL;
 
-	info = match->data;
-
 	p = devm_kzalloc(&pdev->dev, sizeof(struct plat_sci_port), GFP_KERNEL);
 	if (!p)
 		return NULL;
@@ -2669,8 +2651,8 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id)
 	*dev_id = id;
 
 	p->flags = UPF_IOREMAP | UPF_BOOT_AUTOCONF;
-	p->type = info->type;
-	p->regtype = info->regtype;
+	p->type = SCI_OF_TYPE(match->data);
+	p->regtype = SCI_OF_REGTYPE(match->data);
 	p->scscr = SCSCR_RE | SCSCR_TE;
 
 	return p;
-- 
1.9.1

[PATCH 16/25] serial: sh-sci: Correct SCIF type on RZ/A1H

[Geert Uytterhoeven]

The "renesas,scif" compatible value is currently used for the SCIF
variant in all Renesas SoCs of the R-Car and RZ families.  However, the
variant used in the RZ family is not the common "SH-4(A)" variant, but
the "SH-2(A) with FIFO data count register" variant, as it has the
"Serial Extension Mode Register" (SCEMR), just like on sh7203, sh7263,
sh7264, and sh7269.

Use the (already documented) SoC-specific "renesas,scif-r7s72100"
compatible value to differentiate.  The "renesas,scif" compatible value
can still be used as a common denominator for SCIF variants with the
"SH-4(A)" register layout (i.e. ignoring the SCEMR register).
Note that currently both variants are treated the same, but this may
change if support for the SCEMR register is ever added.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 41351ae055de661f..b0127f38af744fcf 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2601,6 +2601,12 @@ static int sci_remove(struct platform_device *dev)
 #define SCI_OF_REGTYPE(data)		((unsigned long)(data) & 0xffff)
 
 static const struct of_device_id of_sci_match[] = {
+	/* SoC-specific types */
+	{
+		.compatible = "renesas,scif-r7s72100",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE),
+	},
+	/* Generic types */
 	{
 		.compatible = "renesas,scif",
 		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_REGTYPE),
-- 
1.9.1

[PATCH 16/25] serial: sh-sci: Correct SCIF type on RZ/A1H

[Geert Uytterhoeven]

The "renesas,scif" compatible value is currently used for the SCIF
variant in all Renesas SoCs of the R-Car and RZ families.  However, the
variant used in the RZ family is not the common "SH-4(A)" variant, but
the "SH-2(A) with FIFO data count register" variant, as it has the
"Serial Extension Mode Register" (SCEMR), just like on sh7203, sh7263,
sh7264, and sh7269.

Use the (already documented) SoC-specific "renesas,scif-r7s72100"
compatible value to differentiate.  The "renesas,scif" compatible value
can still be used as a common denominator for SCIF variants with the
"SH-4(A)" register layout (i.e. ignoring the SCEMR register).
Note that currently both variants are treated the same, but this may
change if support for the SCEMR register is ever added.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 41351ae055de661f..b0127f38af744fcf 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2601,6 +2601,12 @@ static int sci_remove(struct platform_device *dev)
 #define SCI_OF_REGTYPE(data)		((unsigned long)(data) & 0xffff)
 
 static const struct of_device_id of_sci_match[] = {
+	/* SoC-specific types */
+	{
+		.compatible = "renesas,scif-r7s72100",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE),
+	},
+	/* Generic types */
 	{
 		.compatible = "renesas,scif",
 		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_REGTYPE),
-- 
1.9.1

[PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

The "renesas,scif" compatible value is currently used for the SCIF
variant in all Renesas SoCs of the R-Car family.  However, the variant
used in the R-Car family is not the common "SH-4(A)" variant, but a
derivative with added "Baud Rate Generator for External Clock" (BRG),
which is also present in sh7734.

Use the (already documented) SoC-specific SCIF compatible values for all
supported R-Car Gen1, Gen2, and Gen3 SoCs to differentiate.  The
"renesas,scif" compatible value can still be used as a common
denominator for SCIF variants with the "SH-4(A)" register layout (i.e.
ignoring the "Serial Extension Mode Register" (SCEMR) and the new
BRG-specific registers).

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index b0127f38af744fcf..726c96d5a511c222 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2605,6 +2605,30 @@ static const struct of_device_id of_sci_match[] = {
 	{
 		.compatible = "renesas,scif-r7s72100",
 		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7778",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7779",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7790",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7791",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7792",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7793",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7794",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7795",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
 	},
 	/* Generic types */
 	{
-- 
1.9.1

[PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

The "renesas,scif" compatible value is currently used for the SCIF
variant in all Renesas SoCs of the R-Car family.  However, the variant
used in the R-Car family is not the common "SH-4(A)" variant, but a
derivative with added "Baud Rate Generator for External Clock" (BRG),
which is also present in sh7734.

Use the (already documented) SoC-specific SCIF compatible values for all
supported R-Car Gen1, Gen2, and Gen3 SoCs to differentiate.  The
"renesas,scif" compatible value can still be used as a common
denominator for SCIF variants with the "SH-4(A)" register layout (i.e.
ignoring the "Serial Extension Mode Register" (SCEMR) and the new
BRG-specific registers).

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index b0127f38af744fcf..726c96d5a511c222 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2605,6 +2605,30 @@ static const struct of_device_id of_sci_match[] = {
 	{
 		.compatible = "renesas,scif-r7s72100",
 		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7778",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7779",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7790",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7791",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7792",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7793",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7794",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7795",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
 	},
 	/* Generic types */
 	{
-- 
1.9.1

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> The "renesas,scif" compatible value is currently used for the SCIF
> variant in all Renesas SoCs of the R-Car family.  However, the variant
> used in the R-Car family is not the common "SH-4(A)" variant, but a
> derivative with added "Baud Rate Generator for External Clock" (BRG),
> which is also present in sh7734.

Time to introduce a "renesas,scif-rcar" compatible string ? ;-)

As the only DT-enabled platform to have a different SCIF type is r7s72100 we 
could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE 
for the generic "renesas,scif" entry as it's listed after the "renesas,scif-
r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh 
though, but even if that happens due to the J-Core processors I'd be surprised 
to see the old Renesas SH platforms being moved to DT.

> Use the (already documented) SoC-specific SCIF compatible values for all
> supported R-Car Gen1, Gen2, and Gen3 SoCs to differentiate.  The
> "renesas,scif" compatible value can still be used as a common
> denominator for SCIF variants with the "SH-4(A)" register layout (i.e.
> ignoring the "Serial Extension Mode Register" (SCEMR) and the new
> BRG-specific registers).
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index b0127f38af744fcf..726c96d5a511c222 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2605,6 +2605,30 @@ static const struct of_device_id of_sci_match[] = {
>  	{
>  		.compatible = "renesas,scif-r7s72100",
>  		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7778",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7779",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7790",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7791",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7792",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7793",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7794",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7795",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
>  	},
>  	/* Generic types */
>  	{

-- 
Regards,

Laurent Pinchart

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> The "renesas,scif" compatible value is currently used for the SCIF
> variant in all Renesas SoCs of the R-Car family.  However, the variant
> used in the R-Car family is not the common "SH-4(A)" variant, but a
> derivative with added "Baud Rate Generator for External Clock" (BRG),
> which is also present in sh7734.

Time to introduce a "renesas,scif-rcar" compatible string ? ;-)

As the only DT-enabled platform to have a different SCIF type is r7s72100 we 
could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE 
for the generic "renesas,scif" entry as it's listed after the "renesas,scif-
r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh 
though, but even if that happens due to the J-Core processors I'd be surprised 
to see the old Renesas SH platforms being moved to DT.

> Use the (already documented) SoC-specific SCIF compatible values for all
> supported R-Car Gen1, Gen2, and Gen3 SoCs to differentiate.  The
> "renesas,scif" compatible value can still be used as a common
> denominator for SCIF variants with the "SH-4(A)" register layout (i.e.
> ignoring the "Serial Extension Mode Register" (SCEMR) and the new
> BRG-specific registers).
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index b0127f38af744fcf..726c96d5a511c222 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2605,6 +2605,30 @@ static const struct of_device_id of_sci_match[] = {
>  	{
>  		.compatible = "renesas,scif-r7s72100",
>  		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7778",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7779",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7790",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7791",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7792",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7793",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7794",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7795",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
>  	},
>  	/* Generic types */
>  	{

-- 
Regards,

Laurent Pinchart

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> The "renesas,scif" compatible value is currently used for the SCIF
>> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> which is also present in sh7734.
>
> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>
> As the only DT-enabled platform to have a different SCIF type is r7s72100 we
> could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE
> for the generic "renesas,scif" entry as it's listed after the "renesas,scif-
> r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh
> though, but even if that happens due to the J-Core processors I'd be surprised
> to see the old Renesas SH platforms being moved to DT.

I thought about that, but you never know in which out-of-tree BSP it ended up
being used, too. So better safe than sorry.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> The "renesas,scif" compatible value is currently used for the SCIF
>> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> which is also present in sh7734.
>
> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>
> As the only DT-enabled platform to have a different SCIF type is r7s72100 we
> could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE
> for the generic "renesas,scif" entry as it's listed after the "renesas,scif-
> r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh
> though, but even if that happens due to the J-Core processors I'd be surprised
> to see the old Renesas SH platforms being moved to DT.

I thought about that, but you never know in which out-of-tree BSP it ended up
being used, too. So better safe than sorry.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >> The "renesas,scif" compatible value is currently used for the SCIF
> >> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >> which is also present in sh7734.
> > 
> > Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> > 
> > As the only DT-enabled platform to have a different SCIF type is r7s72100
> > we could also consider just switching the regtype to
> > SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> > listed after the "renesas,scif- r7s72100" entry. That might cause an
> > issue if we want to enable DT on arch/sh though, but even if that happens
> > due to the J-Core processors I'd be surprised to see the old Renesas SH
> > platforms being moved to DT.
> 
> I thought about that, but you never know in which out-of-tree BSP it ended
> up being used, too. So better safe than sorry.

Out-of-tree should be banned :-)

More seriously, I suppose you wouldn't be thrilled by the idea of a 
"renesas,scif-rcar-gen2" ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >> The "renesas,scif" compatible value is currently used for the SCIF
> >> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >> which is also present in sh7734.
> > 
> > Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> > 
> > As the only DT-enabled platform to have a different SCIF type is r7s72100
> > we could also consider just switching the regtype to
> > SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> > listed after the "renesas,scif- r7s72100" entry. That might cause an
> > issue if we want to enable DT on arch/sh though, but even if that happens
> > due to the J-Core processors I'd be surprised to see the old Renesas SH
> > platforms being moved to DT.
> 
> I thought about that, but you never know in which out-of-tree BSP it ended
> up being used, too. So better safe than sorry.

Out-of-tree should be banned :-)

More seriously, I suppose you wouldn't be thrilled by the idea of a 
"renesas,scif-rcar-gen2" ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> >> The "renesas,scif" compatible value is currently used for the SCIF
>> >> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> >> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> >> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> >> which is also present in sh7734.
>> >
>> > Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>> >
>> > As the only DT-enabled platform to have a different SCIF type is r7s72100
>> > we could also consider just switching the regtype to
>> > SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
>> > listed after the "renesas,scif- r7s72100" entry. That might cause an
>> > issue if we want to enable DT on arch/sh though, but even if that happens
>> > due to the J-Core processors I'd be surprised to see the old Renesas SH
>> > platforms being moved to DT.
>>
>> I thought about that, but you never know in which out-of-tree BSP it ended
>> up being used, too. So better safe than sorry.
>
> Out-of-tree should be banned :-)
>
> More seriously, I suppose you wouldn't be thrilled by the idea of a
> "renesas,scif-rcar-gen2" ?

Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> >> The "renesas,scif" compatible value is currently used for the SCIF
>> >> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> >> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> >> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> >> which is also present in sh7734.
>> >
>> > Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>> >
>> > As the only DT-enabled platform to have a different SCIF type is r7s72100
>> > we could also consider just switching the regtype to
>> > SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
>> > listed after the "renesas,scif- r7s72100" entry. That might cause an
>> > issue if we want to enable DT on arch/sh though, but even if that happens
>> > due to the J-Core processors I'd be surprised to see the old Renesas SH
>> > platforms being moved to DT.
>>
>> I thought about that, but you never know in which out-of-tree BSP it ended
>> up being used, too. So better safe than sorry.
>
> Out-of-tree should be banned :-)
>
> More seriously, I suppose you wouldn't be thrilled by the idea of a
> "renesas,scif-rcar-gen2" ?

Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >>>> The "renesas,scif" compatible value is currently used for the SCIF
> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >>>> which is also present in sh7734.
> >>> 
> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >>> 
> >>> As the only DT-enabled platform to have a different SCIF type is
> >>> r7s72100 we could also consider just switching the regtype to
> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
> >>> issue if we want to enable DT on arch/sh though, but even if that
> >>> happens due to the J-Core processors I'd be surprised to see the old
> >>> Renesas SH platforms being moved to DT.
> >> 
> >> I thought about that, but you never know in which out-of-tree BSP it
> >> ended up being used, too. So better safe than sorry.
> > 
> > Out-of-tree should be banned :-)
> > 
> > More seriously, I suppose you wouldn't be thrilled by the idea of a
> > "renesas,scif-rcar-gen2" ?
> 
> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.

Yes, but it would at least cover the whole Gen2 family that behaves the same 
way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat 
strings only.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >>>> The "renesas,scif" compatible value is currently used for the SCIF
> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >>>> which is also present in sh7734.
> >>> 
> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >>> 
> >>> As the only DT-enabled platform to have a different SCIF type is
> >>> r7s72100 we could also consider just switching the regtype to
> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
> >>> issue if we want to enable DT on arch/sh though, but even if that
> >>> happens due to the J-Core processors I'd be surprised to see the old
> >>> Renesas SH platforms being moved to DT.
> >> 
> >> I thought about that, but you never know in which out-of-tree BSP it
> >> ended up being used, too. So better safe than sorry.
> > 
> > Out-of-tree should be banned :-)
> > 
> > More seriously, I suppose you wouldn't be thrilled by the idea of a
> > "renesas,scif-rcar-gen2" ?
> 
> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.

Yes, but it would at least cover the whole Gen2 family that behaves the same 
way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat 
strings only.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
>> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
>> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
>> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
>> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> >>>> The "renesas,scif" compatible value is currently used for the SCIF
>> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> >>>> which is also present in sh7734.
>> >>>
>> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>> >>>
>> >>> As the only DT-enabled platform to have a different SCIF type is
>> >>> r7s72100 we could also consider just switching the regtype to
>> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
>> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
>> >>> issue if we want to enable DT on arch/sh though, but even if that
>> >>> happens due to the J-Core processors I'd be surprised to see the old
>> >>> Renesas SH platforms being moved to DT.
>> >>
>> >> I thought about that, but you never know in which out-of-tree BSP it
>> >> ended up being used, too. So better safe than sorry.
>> >
>> > Out-of-tree should be banned :-)
>> >
>> > More seriously, I suppose you wouldn't be thrilled by the idea of a
>> > "renesas,scif-rcar-gen2" ?
>>
>> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
>
> Yes, but it would at least cover the whole Gen2 family that behaves the same
> way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat
> strings only.

In light of all the recent "add fallback compatibility strings" patch series
from Simon, perhaps I should reconsider, and just match against three (new)
family-specific compatible values:

    "renesas,scif-rcar-gen1"
    "renesas,scif-rcar-gen2"
    "renesas,scif-rcar-gen3"

instead of the 8 (and more coming) SoC-specific compatible values?

Following that scheme means we will have to add many compatible values
to the existing dtsis. I.e. every SCIx device node (there are more than 100)
will have 3, like

        scif0: serial@e6e60000 {
                compatible = "renesas,scif-r8a7791", "renesas,scif-rcar-gen2",
                              "renesas,scif";

Not having the SoC-specific ones in the driver won't cause an issue when using
an old DTS with a new kernel: you can't use the new BRG features without
adding the extra clocks to the DTS anyway, so you can add the family-specific
compatible value when doing that update.

Simon, what do you think?

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
>> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
>> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
>> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
>> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> >>>> The "renesas,scif" compatible value is currently used for the SCIF
>> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> >>>> which is also present in sh7734.
>> >>>
>> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>> >>>
>> >>> As the only DT-enabled platform to have a different SCIF type is
>> >>> r7s72100 we could also consider just switching the regtype to
>> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
>> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
>> >>> issue if we want to enable DT on arch/sh though, but even if that
>> >>> happens due to the J-Core processors I'd be surprised to see the old
>> >>> Renesas SH platforms being moved to DT.
>> >>
>> >> I thought about that, but you never know in which out-of-tree BSP it
>> >> ended up being used, too. So better safe than sorry.
>> >
>> > Out-of-tree should be banned :-)
>> >
>> > More seriously, I suppose you wouldn't be thrilled by the idea of a
>> > "renesas,scif-rcar-gen2" ?
>>
>> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
>
> Yes, but it would at least cover the whole Gen2 family that behaves the same
> way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat
> strings only.

In light of all the recent "add fallback compatibility strings" patch series
from Simon, perhaps I should reconsider, and just match against three (new)
family-specific compatible values:

    "renesas,scif-rcar-gen1"
    "renesas,scif-rcar-gen2"
    "renesas,scif-rcar-gen3"

instead of the 8 (and more coming) SoC-specific compatible values?

Following that scheme means we will have to add many compatible values
to the existing dtsis. I.e. every SCIx device node (there are more than 100)
will have 3, like

        scif0: serial@e6e60000 {
                compatible = "renesas,scif-r8a7791", "renesas,scif-rcar-gen2",
                              "renesas,scif";

Not having the SoC-specific ones in the driver won't cause an issue when using
an old DTS with a new kernel: you can't use the new BRG features without
adding the extra clocks to the DTS anyway, so you can add the family-specific
compatible value when doing that update.

Simon, what do you think?

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Simon Horman]

On Thu, Dec 10, 2015 at 10:21:27AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> >> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >> >>>> The "renesas,scif" compatible value is currently used for the SCIF
> >> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >> >>>> which is also present in sh7734.
> >> >>>
> >> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >> >>>
> >> >>> As the only DT-enabled platform to have a different SCIF type is
> >> >>> r7s72100 we could also consider just switching the regtype to
> >> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> >> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
> >> >>> issue if we want to enable DT on arch/sh though, but even if that
> >> >>> happens due to the J-Core processors I'd be surprised to see the old
> >> >>> Renesas SH platforms being moved to DT.
> >> >>
> >> >> I thought about that, but you never know in which out-of-tree BSP it
> >> >> ended up being used, too. So better safe than sorry.
> >> >
> >> > Out-of-tree should be banned :-)
> >> >
> >> > More seriously, I suppose you wouldn't be thrilled by the idea of a
> >> > "renesas,scif-rcar-gen2" ?
> >>
> >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
> >
> > Yes, but it would at least cover the whole Gen2 family that behaves the same
> > way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat
> > strings only.
> 
> In light of all the recent "add fallback compatibility strings" patch series
> from Simon, perhaps I should reconsider, and just match against three (new)
> family-specific compatible values:
> 
>     "renesas,scif-rcar-gen1"
>     "renesas,scif-rcar-gen2"
>     "renesas,scif-rcar-gen3"
> 
> instead of the 8 (and more coming) SoC-specific compatible values?
> 
> Following that scheme means we will have to add many compatible values
> to the existing dtsis. I.e. every SCIx device node (there are more than 100)
> will have 3, like
> 
>         scif0: serial@e6e60000 {
>                 compatible = "renesas,scif-r8a7791", "renesas,scif-rcar-gen2",
>                               "renesas,scif";
> 
> Not having the SoC-specific ones in the driver won't cause an issue when using
> an old DTS with a new kernel: you can't use the new BRG features without
> adding the extra clocks to the DTS anyway, so you can add the family-specific
> compatible value when doing that update.
> 
> Simon, what do you think?

This sounds good to me.
In fact it sounds like the kind of upgrade path that I would like
to see in action.

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Simon Horman]

On Thu, Dec 10, 2015 at 10:21:27AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> >> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >> >>>> The "renesas,scif" compatible value is currently used for the SCIF
> >> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >> >>>> which is also present in sh7734.
> >> >>>
> >> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >> >>>
> >> >>> As the only DT-enabled platform to have a different SCIF type is
> >> >>> r7s72100 we could also consider just switching the regtype to
> >> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> >> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
> >> >>> issue if we want to enable DT on arch/sh though, but even if that
> >> >>> happens due to the J-Core processors I'd be surprised to see the old
> >> >>> Renesas SH platforms being moved to DT.
> >> >>
> >> >> I thought about that, but you never know in which out-of-tree BSP it
> >> >> ended up being used, too. So better safe than sorry.
> >> >
> >> > Out-of-tree should be banned :-)
> >> >
> >> > More seriously, I suppose you wouldn't be thrilled by the idea of a
> >> > "renesas,scif-rcar-gen2" ?
> >>
> >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
> >
> > Yes, but it would at least cover the whole Gen2 family that behaves the same
> > way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat
> > strings only.
> 
> In light of all the recent "add fallback compatibility strings" patch series
> from Simon, perhaps I should reconsider, and just match against three (new)
> family-specific compatible values:
> 
>     "renesas,scif-rcar-gen1"
>     "renesas,scif-rcar-gen2"
>     "renesas,scif-rcar-gen3"
> 
> instead of the 8 (and more coming) SoC-specific compatible values?
> 
> Following that scheme means we will have to add many compatible values
> to the existing dtsis. I.e. every SCIx device node (there are more than 100)
> will have 3, like
> 
>         scif0: serial@e6e60000 {
>                 compatible = "renesas,scif-r8a7791", "renesas,scif-rcar-gen2",
>                               "renesas,scif";
> 
> Not having the SoC-specific ones in the driver won't cause an issue when using
> an old DTS with a new kernel: you can't use the new BRG features without
> adding the extra clocks to the DTS anyway, so you can add the family-specific
> compatible value when doing that update.
> 
> Simon, what do you think?

This sounds good to me.
In fact it sounds like the kind of upgrade path that I would like
to see in action.

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

Hi Geert,

On Thursday 10 December 2015 10:21:27 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> >>> On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >>>> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >>>>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >>>>>> The "renesas,scif" compatible value is currently used for the SCIF
> >>>>>> variant in all Renesas SoCs of the R-Car family.  However, the
> >>>>>> variant used in the R-Car family is not the common "SH-4(A)"
> >>>>>> variant, but a derivative with added "Baud Rate Generator for
> >>>>>> External Clock" (BRG), which is also present in sh7734.
> >>>>> 
> >>>>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >>>>> 
> >>>>> As the only DT-enabled platform to have a different SCIF type is
> >>>>> r7s72100 we could also consider just switching the regtype to
> >>>>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as
> >>>>> it's listed after the "renesas,scif- r7s72100" entry. That might
> >>>>> cause an issue if we want to enable DT on arch/sh though, but even if
> >>>>> that happens due to the J-Core processors I'd be surprised to see the
> >>>>> old Renesas SH platforms being moved to DT.
> >>>> 
> >>>> I thought about that, but you never know in which out-of-tree BSP it
> >>>> ended up being used, too. So better safe than sorry.
> >>> 
> >>> Out-of-tree should be banned :-)
> >>> 
> >>> More seriously, I suppose you wouldn't be thrilled by the idea of a
> >>> "renesas,scif-rcar-gen2" ?
> >> 
> >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
> > 
> > Yes, but it would at least cover the whole Gen2 family that behaves the
> > same way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's
> > two compat strings only.
> 
> In light of all the recent "add fallback compatibility strings" patch series
> from Simon, perhaps I should reconsider, and just match against three (new)
> family-specific compatible values:
> 
>     "renesas,scif-rcar-gen1"
>     "renesas,scif-rcar-gen2"
>     "renesas,scif-rcar-gen3"
> 
> instead of the 8 (and more coming) SoC-specific compatible values?
> 
> Following that scheme means we will have to add many compatible values
> to the existing dtsis. I.e. every SCIx device node (there are more than 100)
> will have 3, like
> 
>         scif0: serial@e6e60000 {
>                 compatible = "renesas,scif-r8a7791",
> "renesas,scif-rcar-gen2", "renesas,scif";
> 
> Not having the SoC-specific ones in the driver won't cause an issue when
> using an old DTS with a new kernel: you can't use the new BRG features
> without adding the extra clocks to the DTS anyway, so you can add the
> family-specific compatible value when doing that update.
> 
> Simon, what do you think?

Needless to say I agree :-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

Hi Geert,

On Thursday 10 December 2015 10:21:27 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> >>> On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >>>> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >>>>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >>>>>> The "renesas,scif" compatible value is currently used for the SCIF
> >>>>>> variant in all Renesas SoCs of the R-Car family.  However, the
> >>>>>> variant used in the R-Car family is not the common "SH-4(A)"
> >>>>>> variant, but a derivative with added "Baud Rate Generator for
> >>>>>> External Clock" (BRG), which is also present in sh7734.
> >>>>> 
> >>>>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >>>>> 
> >>>>> As the only DT-enabled platform to have a different SCIF type is
> >>>>> r7s72100 we could also consider just switching the regtype to
> >>>>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as
> >>>>> it's listed after the "renesas,scif- r7s72100" entry. That might
> >>>>> cause an issue if we want to enable DT on arch/sh though, but even if
> >>>>> that happens due to the J-Core processors I'd be surprised to see the
> >>>>> old Renesas SH platforms being moved to DT.
> >>>> 
> >>>> I thought about that, but you never know in which out-of-tree BSP it
> >>>> ended up being used, too. So better safe than sorry.
> >>> 
> >>> Out-of-tree should be banned :-)
> >>> 
> >>> More seriously, I suppose you wouldn't be thrilled by the idea of a
> >>> "renesas,scif-rcar-gen2" ?
> >> 
> >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
> > 
> > Yes, but it would at least cover the whole Gen2 family that behaves the
> > same way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's
> > two compat strings only.
> 
> In light of all the recent "add fallback compatibility strings" patch series
> from Simon, perhaps I should reconsider, and just match against three (new)
> family-specific compatible values:
> 
>     "renesas,scif-rcar-gen1"
>     "renesas,scif-rcar-gen2"
>     "renesas,scif-rcar-gen3"
> 
> instead of the 8 (and more coming) SoC-specific compatible values?
> 
> Following that scheme means we will have to add many compatible values
> to the existing dtsis. I.e. every SCIx device node (there are more than 100)
> will have 3, like
> 
>         scif0: serial@e6e60000 {
>                 compatible = "renesas,scif-r8a7791",
> "renesas,scif-rcar-gen2", "renesas,scif";
> 
> Not having the SoC-specific ones in the driver won't cause an issue when
> using an old DTS with a new kernel: you can't use the new BRG features
> without adding the extra clocks to the DTS anyway, so you can add the
> family-specific compatible value when doing that update.
> 
> Simon, what do you think?

Needless to say I agree :-)

-- 
Regards,

Laurent Pinchart

[PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Geert Uytterhoeven]

Refactor the clock and baud rate parameter code to ease adding support
for multiple clocks and baud rate generators later.
sci_scbrr_calc() now returns the bit rate error, so it can be compared
to the bit rate error for other baud rate generators.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 176 ++++++++++++++++++++++++++++++--------------
 1 file changed, 120 insertions(+), 56 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 726c96d5a511c222..12800e52f41953dc 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2,6 +2,7 @@
  * SuperH on-chip serial module support.  (SCI with no FIFO / with FIFO)
  *
  *  Copyright (C) 2002 - 2011  Paul Mundt
+ *  Copyright (C) 2015 Glider bvba
  *  Modified to support SH7720 SCIF. Markus Brunner, Mark Jonas (Jul 2007).
  *
  * based off of the old drivers/char/sh-sci.c by:
@@ -76,6 +77,11 @@ enum {
 	((port)->irqs[SCIx_ERI_IRQ] &&	\
 	 ((port)->irqs[SCIx_RXI_IRQ] < 0))
 
+enum SCI_CLKS {
+	SCI_FCK,		/* Functional Clock */
+	SCI_NUM_CLKS
+};
+
 struct sci_port {
 	struct uart_port	port;
 
@@ -92,8 +98,9 @@ struct sci_port {
 	struct timer_list	break_timer;
 	int			break_flag;
 
-	/* Function clock */
-	struct clk		*fclk;
+	/* Clocks */
+	struct clk		*clks[SCI_NUM_CLKS];
+	unsigned long		clk_rates[SCI_NUM_CLKS];
 
 	int			irqs[SCIx_NR_IRQS];
 	char			*irqstr[SCIx_NR_IRQS];
@@ -496,17 +503,24 @@ static int sci_probe_regmap(struct plat_sci_port *cfg)
 
 static void sci_port_enable(struct sci_port *sci_port)
 {
+	unsigned int i;
+
 	if (!sci_port->port.dev)
 		return;
 
 	pm_runtime_get_sync(sci_port->port.dev);
 
-	clk_prepare_enable(sci_port->fclk);
-	sci_port->port.uartclk = clk_get_rate(sci_port->fclk);
+	for (i = 0; i < SCI_NUM_CLKS; i++) {
+		clk_prepare_enable(sci_port->clks[i]);
+		sci_port->clk_rates[i] = clk_get_rate(sci_port->clks[i]);
+	}
+	sci_port->port.uartclk = sci_port->clk_rates[SCI_FCK];
 }
 
 static void sci_port_disable(struct sci_port *sci_port)
 {
+	unsigned int i;
+
 	if (!sci_port->port.dev)
 		return;
 
@@ -518,7 +532,8 @@ static void sci_port_disable(struct sci_port *sci_port)
 	del_timer_sync(&sci_port->break_timer);
 	sci_port->break_flag = 0;
 
-	clk_disable_unprepare(sci_port->fclk);
+	for (i = SCI_NUM_CLKS; i-- > 0; )
+		clk_disable_unprepare(sci_port->clks[i]);
 
 	pm_runtime_put_sync(sci_port->port.dev);
 }
@@ -1657,6 +1672,7 @@ static int sci_notifier(struct notifier_block *self,
 {
 	struct sci_port *sci_port;
 	unsigned long flags;
+	unsigned int i;
 
 	sci_port = container_of(self, struct sci_port, freq_transition);
 
@@ -1664,7 +1680,9 @@ static int sci_notifier(struct notifier_block *self,
 		struct uart_port *port = &sci_port->port;
 
 		spin_lock_irqsave(&port->lock, flags);
-		port->uartclk = clk_get_rate(sci_port->fclk);
+		for (i = 0; i < SCI_NUM_CLKS; i++)
+			sci_port->clk_rates[i] +				clk_get_rate(sci_port->clks[i]);
 		spin_unlock_irqrestore(&port->lock, flags);
 	}
 
@@ -1907,11 +1925,12 @@ static void sci_shutdown(struct uart_port *port)
 }
 
 /* calculate sample rate, BRR, and clock select */
-static void sci_scbrr_calc(struct sci_port *s, unsigned int bps,
-			   unsigned long freq, int *brr, unsigned int *srr,
-			   unsigned int *cks)
+static int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
+			  unsigned int *brr, unsigned int *srr,
+			  unsigned int *cks)
 {
 	unsigned int min_sr, max_sr, shift, sr, br, a, b, c;
+	unsigned long freq = s->clk_rates[SCI_FCK];
 	int err, min_err = INT_MAX;
 
 	if (s->sampling_rate) {
@@ -1963,6 +1982,7 @@ static void sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 
 	dev_dbg(s->port.dev, "BRR: %u%+d bps using N %u SR %u cks %u\n", bps,
 		min_err, *brr, *srr + 1, *cks);
+	return min_err;
 }
 
 static void sci_reset(struct uart_port *port)
@@ -1984,11 +2004,14 @@ static void sci_reset(struct uart_port *port)
 static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 			    struct ktermios *old)
 {
+	unsigned int baud, smr_val = 0, scr_val = 0, i;
+	unsigned int brr = 255, cks = 0, srr = 15;
+	unsigned int brr1 = 255, cks1 = 0, srr1 = 15;
 	struct sci_port *s = to_sci_port(port);
 	const struct plat_sci_reg *reg;
-	unsigned int baud, smr_val = 0, max_baud, cks = 0;
-	int t = -1;
-	unsigned int srr = 15;
+	int min_err = INT_MAX, err;
+	unsigned long max_freq = 0;
+	int best_clk = -1;
 
 	if ((termios->c_cflag & CSIZE) = CS7)
 		smr_val |= SCSMR_CHR;
@@ -2007,35 +2030,59 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	 * that the previous boot loader has enabled required clocks and
 	 * setup the baud rate generator hardware for us already.
 	 */
-	if (port->uartclk)
-		max_baud = port->uartclk / max(s->sampling_rate, 8U);
-	else
-		max_baud = 115200;
+	if (!port->uartclk) {
+		baud = uart_get_baud_rate(port, termios, old, 0, 115200);
+		goto done;
+	}
 
-	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
-	if (likely(baud && port->uartclk))
-		sci_scbrr_calc(s, baud, port->uartclk, &t, &srr, &cks);
+	for (i = 0; i < SCI_NUM_CLKS; i++)
+		max_freq = max(max_freq, s->clk_rates[i]);
+
+	baud = uart_get_baud_rate(port, termios, old, 0,
+				  max_freq / max(s->sampling_rate, 8U));
+	if (!baud)
+		goto done;
+
+	/* Functional Clock and standard Bit Rate Register */
+	err = sci_scbrr_calc(s, baud, &brr1, &srr1, &cks1);
+	if (abs(err) < abs(min_err)) {
+		best_clk = SCI_FCK;
+		min_err = err;
+		brr = brr1;
+		srr = srr1;
+		cks = cks1;
+	}
+
+done:
+	if (best_clk >= 0)
+		dev_dbg(port->dev, "Using clk %pC for %u%+d bps\n",
+			s->clks[best_clk], baud, min_err);
 
 	sci_port_enable(s);
 
 	sci_reset(port);
 
-	smr_val |= serial_port_in(port, SCSMR) & SCSMR_CKS;
-
 	uart_update_timeout(port, termios->c_cflag, baud);
 
-	dev_dbg(port->dev, "%s: SMR %x, cks %x, t %x, SCSCR %x\n",
-		__func__, smr_val, cks, t, s->cfg->scscr);
-
-	if (t >= 0) {
-		serial_port_out(port, SCSMR, (smr_val & ~SCSMR_CKS) | cks);
-		serial_port_out(port, SCBRR, t);
-		reg = sci_getreg(port, HSSRR);
-		if (reg->size)
+	if (best_clk >= 0) {
+		smr_val |= cks;
+		dev_dbg(port->dev, "SMR 0x%x BRR %u SRR %u\n", smr_val, brr,
+			srr);
+		serial_port_out(port, SCSMR, smr_val);
+		serial_port_out(port, SCBRR, brr);
+		if (sci_getreg(port, HSSRR)->size)
 			serial_port_out(port, HSSRR, srr | HSCIF_SRE);
-		udelay((1000000+(baud-1)) / baud); /* Wait one bit interval */
-	} else
+
+		/* Wait one bit interval */
+		udelay((1000000 + (baud - 1)) / baud);
+	} else {
+		/* Don't touch the bit rate configuration */
+		scr_val = s->cfg->scscr & (SCSCR_CKE1 | SCSCR_CKE0);
+		smr_val |= serial_port_in(port, SCSMR) & SCSMR_CKS;
+		dev_dbg(port->dev, "SCR 0x%x SMR 0x%x\n", scr_val, smr_val);
+		serial_port_out(port, SCSCR, scr_val);
 		serial_port_out(port, SCSMR, smr_val);
+	}
 
 	sci_init_pins(port, termios->c_cflag);
 
@@ -2060,7 +2107,9 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 		serial_port_out(port, SCFCR, ctrl);
 	}
 
-	serial_port_out(port, SCSCR, s->cfg->scscr);
+	scr_val |= s->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0);
+	dev_dbg(port->dev, "SCSCR 0x%x\n", scr_val);
+	serial_port_out(port, SCSCR, scr_val);
 
 #ifdef CONFIG_SERIAL_SH_SCI_DMA
 	/*
@@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
 
 static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 {
-	/* Get the SCI functional clock. It's called "fck" on ARM. */
-	sci_port->fclk = devm_clk_get(dev, "fck");
-	if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
-		return -EPROBE_DEFER;
-	if (!IS_ERR(sci_port->fclk))
-		return 0;
+	const char *clk_names[] = {
+		[SCI_FCK] = "fck",
+	};
+	struct clk *clk;
+	unsigned int i;
 
-	/*
-	 * But it used to be called "sci_ick", and we need to maintain DT
-	 * backward compatibility.
-	 */
-	sci_port->fclk = devm_clk_get(dev, "sci_ick");
-	if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
-		return -EPROBE_DEFER;
-	if (!IS_ERR(sci_port->fclk))
-		return 0;
+	for (i = 0; i < SCI_NUM_CLKS; i++) {
+		clk = devm_clk_get(dev, clk_names[i]);
+		if (PTR_ERR(clk) = -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 
-	/*
-	 * Not all SH platforms declare a clock lookup entry for SCI devices,
-	 * in which case we need to get the global "peripheral_clk" clock.
-	 */
-	sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
-	if (!IS_ERR(sci_port->fclk))
-		return 0;
+		if (IS_ERR(clk) && i = SCI_FCK) {
+			/*
+			 * "fck" used to be called "sci_ick", and we need to
+			 * maintain DT backward compatibility.
+			 */
+			clk = devm_clk_get(dev, "sci_ick");
+			if (PTR_ERR(clk) = -EPROBE_DEFER)
+				return -EPROBE_DEFER;
+
+			if (!IS_ERR(clk))
+				goto found;
+
+			/*
+			 * Not all SH platforms declare a clock lookup entry
+			 * for SCI devices, in which case we need to get the
+			 * global "peripheral_clk" clock.
+			 */
+			clk = devm_clk_get(dev, "peripheral_clk");
+			if (!IS_ERR(clk))
+				goto found;
+
+			dev_err(dev, "failed to get functional clock\n");
+			return PTR_ERR(clk);
+		}
 
-	dev_err(dev, "failed to get functional clock\n");
-	return PTR_ERR(sci_port->fclk);
+found:
+		if (!IS_ERR(clk))
+			dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk, clk);
+		sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
+	}
+	return 0;
 }
 
 static int sci_init_single(struct platform_device *dev,
-- 
1.9.1

[PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Geert Uytterhoeven]

Refactor the clock and baud rate parameter code to ease adding support
for multiple clocks and baud rate generators later.
sci_scbrr_calc() now returns the bit rate error, so it can be compared
to the bit rate error for other baud rate generators.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 176 ++++++++++++++++++++++++++++++--------------
 1 file changed, 120 insertions(+), 56 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 726c96d5a511c222..12800e52f41953dc 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2,6 +2,7 @@
  * SuperH on-chip serial module support.  (SCI with no FIFO / with FIFO)
  *
  *  Copyright (C) 2002 - 2011  Paul Mundt
+ *  Copyright (C) 2015 Glider bvba
  *  Modified to support SH7720 SCIF. Markus Brunner, Mark Jonas (Jul 2007).
  *
  * based off of the old drivers/char/sh-sci.c by:
@@ -76,6 +77,11 @@ enum {
 	((port)->irqs[SCIx_ERI_IRQ] &&	\
 	 ((port)->irqs[SCIx_RXI_IRQ] < 0))
 
+enum SCI_CLKS {
+	SCI_FCK,		/* Functional Clock */
+	SCI_NUM_CLKS
+};
+
 struct sci_port {
 	struct uart_port	port;
 
@@ -92,8 +98,9 @@ struct sci_port {
 	struct timer_list	break_timer;
 	int			break_flag;
 
-	/* Function clock */
-	struct clk		*fclk;
+	/* Clocks */
+	struct clk		*clks[SCI_NUM_CLKS];
+	unsigned long		clk_rates[SCI_NUM_CLKS];
 
 	int			irqs[SCIx_NR_IRQS];
 	char			*irqstr[SCIx_NR_IRQS];
@@ -496,17 +503,24 @@ static int sci_probe_regmap(struct plat_sci_port *cfg)
 
 static void sci_port_enable(struct sci_port *sci_port)
 {
+	unsigned int i;
+
 	if (!sci_port->port.dev)
 		return;
 
 	pm_runtime_get_sync(sci_port->port.dev);
 
-	clk_prepare_enable(sci_port->fclk);
-	sci_port->port.uartclk = clk_get_rate(sci_port->fclk);
+	for (i = 0; i < SCI_NUM_CLKS; i++) {
+		clk_prepare_enable(sci_port->clks[i]);
+		sci_port->clk_rates[i] = clk_get_rate(sci_port->clks[i]);
+	}
+	sci_port->port.uartclk = sci_port->clk_rates[SCI_FCK];
 }
 
 static void sci_port_disable(struct sci_port *sci_port)
 {
+	unsigned int i;
+
 	if (!sci_port->port.dev)
 		return;
 
@@ -518,7 +532,8 @@ static void sci_port_disable(struct sci_port *sci_port)
 	del_timer_sync(&sci_port->break_timer);
 	sci_port->break_flag = 0;
 
-	clk_disable_unprepare(sci_port->fclk);
+	for (i = SCI_NUM_CLKS; i-- > 0; )
+		clk_disable_unprepare(sci_port->clks[i]);
 
 	pm_runtime_put_sync(sci_port->port.dev);
 }
@@ -1657,6 +1672,7 @@ static int sci_notifier(struct notifier_block *self,
 {
 	struct sci_port *sci_port;
 	unsigned long flags;
+	unsigned int i;
 
 	sci_port = container_of(self, struct sci_port, freq_transition);
 
@@ -1664,7 +1680,9 @@ static int sci_notifier(struct notifier_block *self,
 		struct uart_port *port = &sci_port->port;
 
 		spin_lock_irqsave(&port->lock, flags);
-		port->uartclk = clk_get_rate(sci_port->fclk);
+		for (i = 0; i < SCI_NUM_CLKS; i++)
+			sci_port->clk_rates[i] =
+				clk_get_rate(sci_port->clks[i]);
 		spin_unlock_irqrestore(&port->lock, flags);
 	}
 
@@ -1907,11 +1925,12 @@ static void sci_shutdown(struct uart_port *port)
 }
 
 /* calculate sample rate, BRR, and clock select */
-static void sci_scbrr_calc(struct sci_port *s, unsigned int bps,
-			   unsigned long freq, int *brr, unsigned int *srr,
-			   unsigned int *cks)
+static int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
+			  unsigned int *brr, unsigned int *srr,
+			  unsigned int *cks)
 {
 	unsigned int min_sr, max_sr, shift, sr, br, a, b, c;
+	unsigned long freq = s->clk_rates[SCI_FCK];
 	int err, min_err = INT_MAX;
 
 	if (s->sampling_rate) {
@@ -1963,6 +1982,7 @@ static void sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 
 	dev_dbg(s->port.dev, "BRR: %u%+d bps using N %u SR %u cks %u\n", bps,
 		min_err, *brr, *srr + 1, *cks);
+	return min_err;
 }
 
 static void sci_reset(struct uart_port *port)
@@ -1984,11 +2004,14 @@ static void sci_reset(struct uart_port *port)
 static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 			    struct ktermios *old)
 {
+	unsigned int baud, smr_val = 0, scr_val = 0, i;
+	unsigned int brr = 255, cks = 0, srr = 15;
+	unsigned int brr1 = 255, cks1 = 0, srr1 = 15;
 	struct sci_port *s = to_sci_port(port);
 	const struct plat_sci_reg *reg;
-	unsigned int baud, smr_val = 0, max_baud, cks = 0;
-	int t = -1;
-	unsigned int srr = 15;
+	int min_err = INT_MAX, err;
+	unsigned long max_freq = 0;
+	int best_clk = -1;
 
 	if ((termios->c_cflag & CSIZE) == CS7)
 		smr_val |= SCSMR_CHR;
@@ -2007,35 +2030,59 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	 * that the previous boot loader has enabled required clocks and
 	 * setup the baud rate generator hardware for us already.
 	 */
-	if (port->uartclk)
-		max_baud = port->uartclk / max(s->sampling_rate, 8U);
-	else
-		max_baud = 115200;
+	if (!port->uartclk) {
+		baud = uart_get_baud_rate(port, termios, old, 0, 115200);
+		goto done;
+	}
 
-	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
-	if (likely(baud && port->uartclk))
-		sci_scbrr_calc(s, baud, port->uartclk, &t, &srr, &cks);
+	for (i = 0; i < SCI_NUM_CLKS; i++)
+		max_freq = max(max_freq, s->clk_rates[i]);
+
+	baud = uart_get_baud_rate(port, termios, old, 0,
+				  max_freq / max(s->sampling_rate, 8U));
+	if (!baud)
+		goto done;
+
+	/* Functional Clock and standard Bit Rate Register */
+	err = sci_scbrr_calc(s, baud, &brr1, &srr1, &cks1);
+	if (abs(err) < abs(min_err)) {
+		best_clk = SCI_FCK;
+		min_err = err;
+		brr = brr1;
+		srr = srr1;
+		cks = cks1;
+	}
+
+done:
+	if (best_clk >= 0)
+		dev_dbg(port->dev, "Using clk %pC for %u%+d bps\n",
+			s->clks[best_clk], baud, min_err);
 
 	sci_port_enable(s);
 
 	sci_reset(port);
 
-	smr_val |= serial_port_in(port, SCSMR) & SCSMR_CKS;
-
 	uart_update_timeout(port, termios->c_cflag, baud);
 
-	dev_dbg(port->dev, "%s: SMR %x, cks %x, t %x, SCSCR %x\n",
-		__func__, smr_val, cks, t, s->cfg->scscr);
-
-	if (t >= 0) {
-		serial_port_out(port, SCSMR, (smr_val & ~SCSMR_CKS) | cks);
-		serial_port_out(port, SCBRR, t);
-		reg = sci_getreg(port, HSSRR);
-		if (reg->size)
+	if (best_clk >= 0) {
+		smr_val |= cks;
+		dev_dbg(port->dev, "SMR 0x%x BRR %u SRR %u\n", smr_val, brr,
+			srr);
+		serial_port_out(port, SCSMR, smr_val);
+		serial_port_out(port, SCBRR, brr);
+		if (sci_getreg(port, HSSRR)->size)
 			serial_port_out(port, HSSRR, srr | HSCIF_SRE);
-		udelay((1000000+(baud-1)) / baud); /* Wait one bit interval */
-	} else
+
+		/* Wait one bit interval */
+		udelay((1000000 + (baud - 1)) / baud);
+	} else {
+		/* Don't touch the bit rate configuration */
+		scr_val = s->cfg->scscr & (SCSCR_CKE1 | SCSCR_CKE0);
+		smr_val |= serial_port_in(port, SCSMR) & SCSMR_CKS;
+		dev_dbg(port->dev, "SCR 0x%x SMR 0x%x\n", scr_val, smr_val);
+		serial_port_out(port, SCSCR, scr_val);
 		serial_port_out(port, SCSMR, smr_val);
+	}
 
 	sci_init_pins(port, termios->c_cflag);
 
@@ -2060,7 +2107,9 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 		serial_port_out(port, SCFCR, ctrl);
 	}
 
-	serial_port_out(port, SCSCR, s->cfg->scscr);
+	scr_val |= s->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0);
+	dev_dbg(port->dev, "SCSCR 0x%x\n", scr_val);
+	serial_port_out(port, SCSCR, scr_val);
 
 #ifdef CONFIG_SERIAL_SH_SCI_DMA
 	/*
@@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
 
 static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 {
-	/* Get the SCI functional clock. It's called "fck" on ARM. */
-	sci_port->fclk = devm_clk_get(dev, "fck");
-	if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
-		return -EPROBE_DEFER;
-	if (!IS_ERR(sci_port->fclk))
-		return 0;
+	const char *clk_names[] = {
+		[SCI_FCK] = "fck",
+	};
+	struct clk *clk;
+	unsigned int i;
 
-	/*
-	 * But it used to be called "sci_ick", and we need to maintain DT
-	 * backward compatibility.
-	 */
-	sci_port->fclk = devm_clk_get(dev, "sci_ick");
-	if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
-		return -EPROBE_DEFER;
-	if (!IS_ERR(sci_port->fclk))
-		return 0;
+	for (i = 0; i < SCI_NUM_CLKS; i++) {
+		clk = devm_clk_get(dev, clk_names[i]);
+		if (PTR_ERR(clk) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 
-	/*
-	 * Not all SH platforms declare a clock lookup entry for SCI devices,
-	 * in which case we need to get the global "peripheral_clk" clock.
-	 */
-	sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
-	if (!IS_ERR(sci_port->fclk))
-		return 0;
+		if (IS_ERR(clk) && i == SCI_FCK) {
+			/*
+			 * "fck" used to be called "sci_ick", and we need to
+			 * maintain DT backward compatibility.
+			 */
+			clk = devm_clk_get(dev, "sci_ick");
+			if (PTR_ERR(clk) == -EPROBE_DEFER)
+				return -EPROBE_DEFER;
+
+			if (!IS_ERR(clk))
+				goto found;
+
+			/*
+			 * Not all SH platforms declare a clock lookup entry
+			 * for SCI devices, in which case we need to get the
+			 * global "peripheral_clk" clock.
+			 */
+			clk = devm_clk_get(dev, "peripheral_clk");
+			if (!IS_ERR(clk))
+				goto found;
+
+			dev_err(dev, "failed to get functional clock\n");
+			return PTR_ERR(clk);
+		}
 
-	dev_err(dev, "failed to get functional clock\n");
-	return PTR_ERR(sci_port->fclk);
+found:
+		if (!IS_ERR(clk))
+			dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk, clk);
+		sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
+	}
+	return 0;
 }
 
 static int sci_init_single(struct platform_device *dev,
-- 
1.9.1

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
> Refactor the clock and baud rate parameter code to ease adding support
> for multiple clocks and baud rate generators later.
> sci_scbrr_calc() now returns the bit rate error, so it can be compared
> to the bit rate error for other baud rate generators.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 176 +++++++++++++++++++++++++++--------------
>  1 file changed, 120 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 726c96d5a511c222..12800e52f41953dc 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2,6 +2,7 @@
>   * SuperH on-chip serial module support.  (SCI with no FIFO / with FIFO)
>   *
>   *  Copyright (C) 2002 - 2011  Paul Mundt
> + *  Copyright (C) 2015 Glider bvba
>   *  Modified to support SH7720 SCIF. Markus Brunner, Mark Jonas (Jul 2007).
> *
>   * based off of the old drivers/char/sh-sci.c by:
> @@ -76,6 +77,11 @@ enum {
>  	((port)->irqs[SCIx_ERI_IRQ] &&	\
>  	 ((port)->irqs[SCIx_RXI_IRQ] < 0))
> 
> +enum SCI_CLKS {
> +	SCI_FCK,		/* Functional Clock */
> +	SCI_NUM_CLKS
> +};
> +
>  struct sci_port {
>  	struct uart_port	port;
> 
> @@ -92,8 +98,9 @@ struct sci_port {
>  	struct timer_list	break_timer;
>  	int			break_flag;
> 
> -	/* Function clock */
> -	struct clk		*fclk;
> +	/* Clocks */
> +	struct clk		*clks[SCI_NUM_CLKS];
> +	unsigned long		clk_rates[SCI_NUM_CLKS];
> 
>  	int			irqs[SCIx_NR_IRQS];
>  	char			*irqstr[SCIx_NR_IRQS];
> @@ -496,17 +503,24 @@ static int sci_probe_regmap(struct plat_sci_port *cfg)
> 
>  static void sci_port_enable(struct sci_port *sci_port)
>  {
> +	unsigned int i;
> +
>  	if (!sci_port->port.dev)
>  		return;
> 
>  	pm_runtime_get_sync(sci_port->port.dev);
> 
> -	clk_prepare_enable(sci_port->fclk);
> -	sci_port->port.uartclk = clk_get_rate(sci_port->fclk);
> +	for (i = 0; i < SCI_NUM_CLKS; i++) {
> +		clk_prepare_enable(sci_port->clks[i]);
> +		sci_port->clk_rates[i] = clk_get_rate(sci_port->clks[i]);
> +	}
> +	sci_port->port.uartclk = sci_port->clk_rates[SCI_FCK];
>  }
> 
>  static void sci_port_disable(struct sci_port *sci_port)
>  {
> +	unsigned int i;
> +
>  	if (!sci_port->port.dev)
>  		return;
> 
> @@ -518,7 +532,8 @@ static void sci_port_disable(struct sci_port *sci_port)
>  	del_timer_sync(&sci_port->break_timer);
>  	sci_port->break_flag = 0;
> 
> -	clk_disable_unprepare(sci_port->fclk);
> +	for (i = SCI_NUM_CLKS; i-- > 0; )
> +		clk_disable_unprepare(sci_port->clks[i]);
> 
>  	pm_runtime_put_sync(sci_port->port.dev);
>  }
> @@ -1657,6 +1672,7 @@ static int sci_notifier(struct notifier_block *self,
>  {
>  	struct sci_port *sci_port;
>  	unsigned long flags;
> +	unsigned int i;
> 
>  	sci_port = container_of(self, struct sci_port, freq_transition);
> 
> @@ -1664,7 +1680,9 @@ static int sci_notifier(struct notifier_block *self,
>  		struct uart_port *port = &sci_port->port;
> 
>  		spin_lock_irqsave(&port->lock, flags);
> -		port->uartclk = clk_get_rate(sci_port->fclk);
> +		for (i = 0; i < SCI_NUM_CLKS; i++)
> +			sci_port->clk_rates[i] > +				clk_get_rate(sci_port->clks[i]);
>  		spin_unlock_irqrestore(&port->lock, flags);
>  	}
> 
> @@ -1907,11 +1925,12 @@ static void sci_shutdown(struct uart_port *port)
>  }
> 
>  /* calculate sample rate, BRR, and clock select */
> -static void sci_scbrr_calc(struct sci_port *s, unsigned int bps,
> -			   unsigned long freq, int *brr, unsigned int *srr,
> -			   unsigned int *cks)
> +static int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
> +			  unsigned int *brr, unsigned int *srr,
> +			  unsigned int *cks)
>  {
>  	unsigned int min_sr, max_sr, shift, sr, br, a, b, c;
> +	unsigned long freq = s->clk_rates[SCI_FCK];
>  	int err, min_err = INT_MAX;
> 
>  	if (s->sampling_rate) {
> @@ -1963,6 +1982,7 @@ static void sci_scbrr_calc(struct sci_port *s,
> unsigned int bps,
> 
>  	dev_dbg(s->port.dev, "BRR: %u%+d bps using N %u SR %u cks %u\n", bps,
>  		min_err, *brr, *srr + 1, *cks);
> +	return min_err;
>  }
> 
>  static void sci_reset(struct uart_port *port)
> @@ -1984,11 +2004,14 @@ static void sci_reset(struct uart_port *port)
>  static void sci_set_termios(struct uart_port *port, struct ktermios
> *termios, struct ktermios *old)
>  {
> +	unsigned int baud, smr_val = 0, scr_val = 0, i;
> +	unsigned int brr = 255, cks = 0, srr = 15;
> +	unsigned int brr1 = 255, cks1 = 0, srr1 = 15;
>  	struct sci_port *s = to_sci_port(port);
>  	const struct plat_sci_reg *reg;
> -	unsigned int baud, smr_val = 0, max_baud, cks = 0;
> -	int t = -1;
> -	unsigned int srr = 15;
> +	int min_err = INT_MAX, err;
> +	unsigned long max_freq = 0;
> +	int best_clk = -1;
> 
>  	if ((termios->c_cflag & CSIZE) = CS7)
>  		smr_val |= SCSMR_CHR;
> @@ -2007,35 +2030,59 @@ static void sci_set_termios(struct uart_port *port,
> struct ktermios *termios, * that the previous boot loader has enabled
> required clocks and * setup the baud rate generator hardware for us
> already.
>  	 */
> -	if (port->uartclk)
> -		max_baud = port->uartclk / max(s->sampling_rate, 8U);
> -	else
> -		max_baud = 115200;
> +	if (!port->uartclk) {
> +		baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> +		goto done;
> +	}
> 
> -	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
> -	if (likely(baud && port->uartclk))
> -		sci_scbrr_calc(s, baud, port->uartclk, &t, &srr, &cks);
> +	for (i = 0; i < SCI_NUM_CLKS; i++)
> +		max_freq = max(max_freq, s->clk_rates[i]);
> +
> +	baud = uart_get_baud_rate(port, termios, old, 0,
> +				  max_freq / max(s->sampling_rate, 8U));
> +	if (!baud)
> +		goto done;
> +
> +	/* Functional Clock and standard Bit Rate Register */
> +	err = sci_scbrr_calc(s, baud, &brr1, &srr1, &cks1);
> +	if (abs(err) < abs(min_err)) {
> +		best_clk = SCI_FCK;
> +		min_err = err;
> +		brr = brr1;
> +		srr = srr1;
> +		cks = cks1;
> +	}
> +
> +done:
> +	if (best_clk >= 0)
> +		dev_dbg(port->dev, "Using clk %pC for %u%+d bps\n",
> +			s->clks[best_clk], baud, min_err);
> 
>  	sci_port_enable(s);
> 
>  	sci_reset(port);
> 
> -	smr_val |= serial_port_in(port, SCSMR) & SCSMR_CKS;
> -
>  	uart_update_timeout(port, termios->c_cflag, baud);
> 
> -	dev_dbg(port->dev, "%s: SMR %x, cks %x, t %x, SCSCR %x\n",
> -		__func__, smr_val, cks, t, s->cfg->scscr);
> -
> -	if (t >= 0) {
> -		serial_port_out(port, SCSMR, (smr_val & ~SCSMR_CKS) | cks);
> -		serial_port_out(port, SCBRR, t);
> -		reg = sci_getreg(port, HSSRR);
> -		if (reg->size)
> +	if (best_clk >= 0) {
> +		smr_val |= cks;
> +		dev_dbg(port->dev, "SMR 0x%x BRR %u SRR %u\n", smr_val, brr,
> +			srr);
> +		serial_port_out(port, SCSMR, smr_val);
> +		serial_port_out(port, SCBRR, brr);
> +		if (sci_getreg(port, HSSRR)->size)
>  			serial_port_out(port, HSSRR, srr | HSCIF_SRE);
> -		udelay((1000000+(baud-1)) / baud); /* Wait one bit interval */
> -	} else
> +
> +		/* Wait one bit interval */
> +		udelay((1000000 + (baud - 1)) / baud);
> +	} else {
> +		/* Don't touch the bit rate configuration */
> +		scr_val = s->cfg->scscr & (SCSCR_CKE1 | SCSCR_CKE0);
> +		smr_val |= serial_port_in(port, SCSMR) & SCSMR_CKS;
> +		dev_dbg(port->dev, "SCR 0x%x SMR 0x%x\n", scr_val, smr_val);
> +		serial_port_out(port, SCSCR, scr_val);
>  		serial_port_out(port, SCSMR, smr_val);
> +	}
> 
>  	sci_init_pins(port, termios->c_cflag);
> 
> @@ -2060,7 +2107,9 @@ static void sci_set_termios(struct uart_port *port,
> struct ktermios *termios, serial_port_out(port, SCFCR, ctrl);
>  	}
> 
> -	serial_port_out(port, SCSCR, s->cfg->scscr);
> +	scr_val |= s->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0);
> +	dev_dbg(port->dev, "SCSCR 0x%x\n", scr_val);
> +	serial_port_out(port, SCSCR, scr_val);
> 
>  #ifdef CONFIG_SERIAL_SH_SCI_DMA
>  	/*
> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
> 
>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>  {
> -	/* Get the SCI functional clock. It's called "fck" on ARM. */
> -	sci_port->fclk = devm_clk_get(dev, "fck");
> -	if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
> -		return -EPROBE_DEFER;
> -	if (!IS_ERR(sci_port->fclk))
> -		return 0;
> +	const char *clk_names[] = {
> +		[SCI_FCK] = "fck",
> +	};
> +	struct clk *clk;
> +	unsigned int i;
> 
> -	/*
> -	 * But it used to be called "sci_ick", and we need to maintain DT
> -	 * backward compatibility.
> -	 */
> -	sci_port->fclk = devm_clk_get(dev, "sci_ick");
> -	if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
> -		return -EPROBE_DEFER;
> -	if (!IS_ERR(sci_port->fclk))
> -		return 0;
> +	for (i = 0; i < SCI_NUM_CLKS; i++) {
> +		clk = devm_clk_get(dev, clk_names[i]);
> +		if (PTR_ERR(clk) = -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> 
> -	/*
> -	 * Not all SH platforms declare a clock lookup entry for SCI devices,
> -	 * in which case we need to get the global "peripheral_clk" clock.
> -	 */
> -	sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
> -	if (!IS_ERR(sci_port->fclk))
> -		return 0;
> +		if (IS_ERR(clk) && i = SCI_FCK) {
> +			/*
> +			 * "fck" used to be called "sci_ick", and we need to
> +			 * maintain DT backward compatibility.
> +			 */
> +			clk = devm_clk_get(dev, "sci_ick");
> +			if (PTR_ERR(clk) = -EPROBE_DEFER)
> +				return -EPROBE_DEFER;
> +
> +			if (!IS_ERR(clk))
> +				goto found;
> +
> +			/*
> +			 * Not all SH platforms declare a clock lookup entry
> +			 * for SCI devices, in which case we need to get the
> +			 * global "peripheral_clk" clock.
> +			 */
> +			clk = devm_clk_get(dev, "peripheral_clk");
> +			if (!IS_ERR(clk))
> +				goto found;
> +
> +			dev_err(dev, "failed to get functional clock\n");
> +			return PTR_ERR(clk);
> +		}
> 
> -	dev_err(dev, "failed to get functional clock\n");
> -	return PTR_ERR(sci_port->fclk);
> +found:
> +		if (!IS_ERR(clk))
> +			dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk, clk);
> +		sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;

Isn't it an issue that we can't tell apart the case where there is no clock 
specified in DT and the case where we can't get the clock due to another error 
?

> +	}
> +	return 0;
>  }
> 
>  static int sci_init_single(struct platform_device *dev,

-- 
Regards,

Laurent Pinchart

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
> Refactor the clock and baud rate parameter code to ease adding support
> for multiple clocks and baud rate generators later.
> sci_scbrr_calc() now returns the bit rate error, so it can be compared
> to the bit rate error for other baud rate generators.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 176 +++++++++++++++++++++++++++--------------
>  1 file changed, 120 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 726c96d5a511c222..12800e52f41953dc 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2,6 +2,7 @@
>   * SuperH on-chip serial module support.  (SCI with no FIFO / with FIFO)
>   *
>   *  Copyright (C) 2002 - 2011  Paul Mundt
> + *  Copyright (C) 2015 Glider bvba
>   *  Modified to support SH7720 SCIF. Markus Brunner, Mark Jonas (Jul 2007).
> *
>   * based off of the old drivers/char/sh-sci.c by:
> @@ -76,6 +77,11 @@ enum {
>  	((port)->irqs[SCIx_ERI_IRQ] &&	\
>  	 ((port)->irqs[SCIx_RXI_IRQ] < 0))
> 
> +enum SCI_CLKS {
> +	SCI_FCK,		/* Functional Clock */
> +	SCI_NUM_CLKS
> +};
> +
>  struct sci_port {
>  	struct uart_port	port;
> 
> @@ -92,8 +98,9 @@ struct sci_port {
>  	struct timer_list	break_timer;
>  	int			break_flag;
> 
> -	/* Function clock */
> -	struct clk		*fclk;
> +	/* Clocks */
> +	struct clk		*clks[SCI_NUM_CLKS];
> +	unsigned long		clk_rates[SCI_NUM_CLKS];
> 
>  	int			irqs[SCIx_NR_IRQS];
>  	char			*irqstr[SCIx_NR_IRQS];
> @@ -496,17 +503,24 @@ static int sci_probe_regmap(struct plat_sci_port *cfg)
> 
>  static void sci_port_enable(struct sci_port *sci_port)
>  {
> +	unsigned int i;
> +
>  	if (!sci_port->port.dev)
>  		return;
> 
>  	pm_runtime_get_sync(sci_port->port.dev);
> 
> -	clk_prepare_enable(sci_port->fclk);
> -	sci_port->port.uartclk = clk_get_rate(sci_port->fclk);
> +	for (i = 0; i < SCI_NUM_CLKS; i++) {
> +		clk_prepare_enable(sci_port->clks[i]);
> +		sci_port->clk_rates[i] = clk_get_rate(sci_port->clks[i]);
> +	}
> +	sci_port->port.uartclk = sci_port->clk_rates[SCI_FCK];
>  }
> 
>  static void sci_port_disable(struct sci_port *sci_port)
>  {
> +	unsigned int i;
> +
>  	if (!sci_port->port.dev)
>  		return;
> 
> @@ -518,7 +532,8 @@ static void sci_port_disable(struct sci_port *sci_port)
>  	del_timer_sync(&sci_port->break_timer);
>  	sci_port->break_flag = 0;
> 
> -	clk_disable_unprepare(sci_port->fclk);
> +	for (i = SCI_NUM_CLKS; i-- > 0; )
> +		clk_disable_unprepare(sci_port->clks[i]);
> 
>  	pm_runtime_put_sync(sci_port->port.dev);
>  }
> @@ -1657,6 +1672,7 @@ static int sci_notifier(struct notifier_block *self,
>  {
>  	struct sci_port *sci_port;
>  	unsigned long flags;
> +	unsigned int i;
> 
>  	sci_port = container_of(self, struct sci_port, freq_transition);
> 
> @@ -1664,7 +1680,9 @@ static int sci_notifier(struct notifier_block *self,
>  		struct uart_port *port = &sci_port->port;
> 
>  		spin_lock_irqsave(&port->lock, flags);
> -		port->uartclk = clk_get_rate(sci_port->fclk);
> +		for (i = 0; i < SCI_NUM_CLKS; i++)
> +			sci_port->clk_rates[i] =
> +				clk_get_rate(sci_port->clks[i]);
>  		spin_unlock_irqrestore(&port->lock, flags);
>  	}
> 
> @@ -1907,11 +1925,12 @@ static void sci_shutdown(struct uart_port *port)
>  }
> 
>  /* calculate sample rate, BRR, and clock select */
> -static void sci_scbrr_calc(struct sci_port *s, unsigned int bps,
> -			   unsigned long freq, int *brr, unsigned int *srr,
> -			   unsigned int *cks)
> +static int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
> +			  unsigned int *brr, unsigned int *srr,
> +			  unsigned int *cks)
>  {
>  	unsigned int min_sr, max_sr, shift, sr, br, a, b, c;
> +	unsigned long freq = s->clk_rates[SCI_FCK];
>  	int err, min_err = INT_MAX;
> 
>  	if (s->sampling_rate) {
> @@ -1963,6 +1982,7 @@ static void sci_scbrr_calc(struct sci_port *s,
> unsigned int bps,
> 
>  	dev_dbg(s->port.dev, "BRR: %u%+d bps using N %u SR %u cks %u\n", bps,
>  		min_err, *brr, *srr + 1, *cks);
> +	return min_err;
>  }
> 
>  static void sci_reset(struct uart_port *port)
> @@ -1984,11 +2004,14 @@ static void sci_reset(struct uart_port *port)
>  static void sci_set_termios(struct uart_port *port, struct ktermios
> *termios, struct ktermios *old)
>  {
> +	unsigned int baud, smr_val = 0, scr_val = 0, i;
> +	unsigned int brr = 255, cks = 0, srr = 15;
> +	unsigned int brr1 = 255, cks1 = 0, srr1 = 15;
>  	struct sci_port *s = to_sci_port(port);
>  	const struct plat_sci_reg *reg;
> -	unsigned int baud, smr_val = 0, max_baud, cks = 0;
> -	int t = -1;
> -	unsigned int srr = 15;
> +	int min_err = INT_MAX, err;
> +	unsigned long max_freq = 0;
> +	int best_clk = -1;
> 
>  	if ((termios->c_cflag & CSIZE) == CS7)
>  		smr_val |= SCSMR_CHR;
> @@ -2007,35 +2030,59 @@ static void sci_set_termios(struct uart_port *port,
> struct ktermios *termios, * that the previous boot loader has enabled
> required clocks and * setup the baud rate generator hardware for us
> already.
>  	 */
> -	if (port->uartclk)
> -		max_baud = port->uartclk / max(s->sampling_rate, 8U);
> -	else
> -		max_baud = 115200;
> +	if (!port->uartclk) {
> +		baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> +		goto done;
> +	}
> 
> -	baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
> -	if (likely(baud && port->uartclk))
> -		sci_scbrr_calc(s, baud, port->uartclk, &t, &srr, &cks);
> +	for (i = 0; i < SCI_NUM_CLKS; i++)
> +		max_freq = max(max_freq, s->clk_rates[i]);
> +
> +	baud = uart_get_baud_rate(port, termios, old, 0,
> +				  max_freq / max(s->sampling_rate, 8U));
> +	if (!baud)
> +		goto done;
> +
> +	/* Functional Clock and standard Bit Rate Register */
> +	err = sci_scbrr_calc(s, baud, &brr1, &srr1, &cks1);
> +	if (abs(err) < abs(min_err)) {
> +		best_clk = SCI_FCK;
> +		min_err = err;
> +		brr = brr1;
> +		srr = srr1;
> +		cks = cks1;
> +	}
> +
> +done:
> +	if (best_clk >= 0)
> +		dev_dbg(port->dev, "Using clk %pC for %u%+d bps\n",
> +			s->clks[best_clk], baud, min_err);
> 
>  	sci_port_enable(s);
> 
>  	sci_reset(port);
> 
> -	smr_val |= serial_port_in(port, SCSMR) & SCSMR_CKS;
> -
>  	uart_update_timeout(port, termios->c_cflag, baud);
> 
> -	dev_dbg(port->dev, "%s: SMR %x, cks %x, t %x, SCSCR %x\n",
> -		__func__, smr_val, cks, t, s->cfg->scscr);
> -
> -	if (t >= 0) {
> -		serial_port_out(port, SCSMR, (smr_val & ~SCSMR_CKS) | cks);
> -		serial_port_out(port, SCBRR, t);
> -		reg = sci_getreg(port, HSSRR);
> -		if (reg->size)
> +	if (best_clk >= 0) {
> +		smr_val |= cks;
> +		dev_dbg(port->dev, "SMR 0x%x BRR %u SRR %u\n", smr_val, brr,
> +			srr);
> +		serial_port_out(port, SCSMR, smr_val);
> +		serial_port_out(port, SCBRR, brr);
> +		if (sci_getreg(port, HSSRR)->size)
>  			serial_port_out(port, HSSRR, srr | HSCIF_SRE);
> -		udelay((1000000+(baud-1)) / baud); /* Wait one bit interval */
> -	} else
> +
> +		/* Wait one bit interval */
> +		udelay((1000000 + (baud - 1)) / baud);
> +	} else {
> +		/* Don't touch the bit rate configuration */
> +		scr_val = s->cfg->scscr & (SCSCR_CKE1 | SCSCR_CKE0);
> +		smr_val |= serial_port_in(port, SCSMR) & SCSMR_CKS;
> +		dev_dbg(port->dev, "SCR 0x%x SMR 0x%x\n", scr_val, smr_val);
> +		serial_port_out(port, SCSCR, scr_val);
>  		serial_port_out(port, SCSMR, smr_val);
> +	}
> 
>  	sci_init_pins(port, termios->c_cflag);
> 
> @@ -2060,7 +2107,9 @@ static void sci_set_termios(struct uart_port *port,
> struct ktermios *termios, serial_port_out(port, SCFCR, ctrl);
>  	}
> 
> -	serial_port_out(port, SCSCR, s->cfg->scscr);
> +	scr_val |= s->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0);
> +	dev_dbg(port->dev, "SCSCR 0x%x\n", scr_val);
> +	serial_port_out(port, SCSCR, scr_val);
> 
>  #ifdef CONFIG_SERIAL_SH_SCI_DMA
>  	/*
> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
> 
>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>  {
> -	/* Get the SCI functional clock. It's called "fck" on ARM. */
> -	sci_port->fclk = devm_clk_get(dev, "fck");
> -	if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
> -		return -EPROBE_DEFER;
> -	if (!IS_ERR(sci_port->fclk))
> -		return 0;
> +	const char *clk_names[] = {
> +		[SCI_FCK] = "fck",
> +	};
> +	struct clk *clk;
> +	unsigned int i;
> 
> -	/*
> -	 * But it used to be called "sci_ick", and we need to maintain DT
> -	 * backward compatibility.
> -	 */
> -	sci_port->fclk = devm_clk_get(dev, "sci_ick");
> -	if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
> -		return -EPROBE_DEFER;
> -	if (!IS_ERR(sci_port->fclk))
> -		return 0;
> +	for (i = 0; i < SCI_NUM_CLKS; i++) {
> +		clk = devm_clk_get(dev, clk_names[i]);
> +		if (PTR_ERR(clk) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> 
> -	/*
> -	 * Not all SH platforms declare a clock lookup entry for SCI devices,
> -	 * in which case we need to get the global "peripheral_clk" clock.
> -	 */
> -	sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
> -	if (!IS_ERR(sci_port->fclk))
> -		return 0;
> +		if (IS_ERR(clk) && i == SCI_FCK) {
> +			/*
> +			 * "fck" used to be called "sci_ick", and we need to
> +			 * maintain DT backward compatibility.
> +			 */
> +			clk = devm_clk_get(dev, "sci_ick");
> +			if (PTR_ERR(clk) == -EPROBE_DEFER)
> +				return -EPROBE_DEFER;
> +
> +			if (!IS_ERR(clk))
> +				goto found;
> +
> +			/*
> +			 * Not all SH platforms declare a clock lookup entry
> +			 * for SCI devices, in which case we need to get the
> +			 * global "peripheral_clk" clock.
> +			 */
> +			clk = devm_clk_get(dev, "peripheral_clk");
> +			if (!IS_ERR(clk))
> +				goto found;
> +
> +			dev_err(dev, "failed to get functional clock\n");
> +			return PTR_ERR(clk);
> +		}
> 
> -	dev_err(dev, "failed to get functional clock\n");
> -	return PTR_ERR(sci_port->fclk);
> +found:
> +		if (!IS_ERR(clk))
> +			dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk, clk);
> +		sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;

Isn't it an issue that we can't tell apart the case where there is no clock 
specified in DT and the case where we can't get the clock due to another error 
?

> +	}
> +	return 0;
>  }
> 
>  static int sci_init_single(struct platform_device *dev,

-- 
Regards,

Laurent Pinchart

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
>> Refactor the clock and baud rate parameter code to ease adding support
>> for multiple clocks and baud rate generators later.
>> sci_scbrr_calc() now returns the bit rate error, so it can be compared
>> to the bit rate error for other baud rate generators.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>>  drivers/tty/serial/sh-sci.c | 176 +++++++++++++++++++++++++++--------------
>>  1 file changed, 120 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> index 726c96d5a511c222..12800e52f41953dc 100644
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c

>> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
>>
>>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>>  {
>> -     /* Get the SCI functional clock. It's called "fck" on ARM. */
>> -     sci_port->fclk = devm_clk_get(dev, "fck");
>> -     if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
>> -             return -EPROBE_DEFER;
>> -     if (!IS_ERR(sci_port->fclk))
>> -             return 0;
>> +     const char *clk_names[] = {
>> +             [SCI_FCK] = "fck",
>> +     };
>> +     struct clk *clk;
>> +     unsigned int i;
>>
>> -     /*
>> -      * But it used to be called "sci_ick", and we need to maintain DT
>> -      * backward compatibility.
>> -      */
>> -     sci_port->fclk = devm_clk_get(dev, "sci_ick");
>> -     if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
>> -             return -EPROBE_DEFER;
>> -     if (!IS_ERR(sci_port->fclk))
>> -             return 0;
>> +     for (i = 0; i < SCI_NUM_CLKS; i++) {
>> +             clk = devm_clk_get(dev, clk_names[i]);
>> +             if (PTR_ERR(clk) = -EPROBE_DEFER)
>> +                     return -EPROBE_DEFER;
>>
>> -     /*
>> -      * Not all SH platforms declare a clock lookup entry for SCI devices,
>> -      * in which case we need to get the global "peripheral_clk" clock.
>> -      */
>> -     sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
>> -     if (!IS_ERR(sci_port->fclk))
>> -             return 0;
>> +             if (IS_ERR(clk) && i = SCI_FCK) {
>> +                     /*
>> +                      * "fck" used to be called "sci_ick", and we need to
>> +                      * maintain DT backward compatibility.
>> +                      */
>> +                     clk = devm_clk_get(dev, "sci_ick");
>> +                     if (PTR_ERR(clk) = -EPROBE_DEFER)
>> +                             return -EPROBE_DEFER;
>> +
>> +                     if (!IS_ERR(clk))
>> +                             goto found;
>> +
>> +                     /*
>> +                      * Not all SH platforms declare a clock lookup entry
>> +                      * for SCI devices, in which case we need to get the
>> +                      * global "peripheral_clk" clock.
>> +                      */
>> +                     clk = devm_clk_get(dev, "peripheral_clk");
>> +                     if (!IS_ERR(clk))
>> +                             goto found;
>> +
>> +                     dev_err(dev, "failed to get functional clock\n");
>> +                     return PTR_ERR(clk);
>> +             }
>>
>> -     dev_err(dev, "failed to get functional clock\n");
>> -     return PTR_ERR(sci_port->fclk);
>> +found:
>> +             if (!IS_ERR(clk))
>> +                     dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk, clk);
>> +             sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
>
> Isn't it an issue that we can't tell apart the case where there is no clock
> specified in DT and the case where we can't get the clock due to another error
> ?

All failures here are for optional clocks.
If the real failure is that the clock wasn't specified (or misspelled) in DT,
it should have been detected during the integration phase.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
>> Refactor the clock and baud rate parameter code to ease adding support
>> for multiple clocks and baud rate generators later.
>> sci_scbrr_calc() now returns the bit rate error, so it can be compared
>> to the bit rate error for other baud rate generators.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>>  drivers/tty/serial/sh-sci.c | 176 +++++++++++++++++++++++++++--------------
>>  1 file changed, 120 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> index 726c96d5a511c222..12800e52f41953dc 100644
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c

>> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
>>
>>  static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
>>  {
>> -     /* Get the SCI functional clock. It's called "fck" on ARM. */
>> -     sci_port->fclk = devm_clk_get(dev, "fck");
>> -     if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
>> -             return -EPROBE_DEFER;
>> -     if (!IS_ERR(sci_port->fclk))
>> -             return 0;
>> +     const char *clk_names[] = {
>> +             [SCI_FCK] = "fck",
>> +     };
>> +     struct clk *clk;
>> +     unsigned int i;
>>
>> -     /*
>> -      * But it used to be called "sci_ick", and we need to maintain DT
>> -      * backward compatibility.
>> -      */
>> -     sci_port->fclk = devm_clk_get(dev, "sci_ick");
>> -     if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
>> -             return -EPROBE_DEFER;
>> -     if (!IS_ERR(sci_port->fclk))
>> -             return 0;
>> +     for (i = 0; i < SCI_NUM_CLKS; i++) {
>> +             clk = devm_clk_get(dev, clk_names[i]);
>> +             if (PTR_ERR(clk) == -EPROBE_DEFER)
>> +                     return -EPROBE_DEFER;
>>
>> -     /*
>> -      * Not all SH platforms declare a clock lookup entry for SCI devices,
>> -      * in which case we need to get the global "peripheral_clk" clock.
>> -      */
>> -     sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
>> -     if (!IS_ERR(sci_port->fclk))
>> -             return 0;
>> +             if (IS_ERR(clk) && i == SCI_FCK) {
>> +                     /*
>> +                      * "fck" used to be called "sci_ick", and we need to
>> +                      * maintain DT backward compatibility.
>> +                      */
>> +                     clk = devm_clk_get(dev, "sci_ick");
>> +                     if (PTR_ERR(clk) == -EPROBE_DEFER)
>> +                             return -EPROBE_DEFER;
>> +
>> +                     if (!IS_ERR(clk))
>> +                             goto found;
>> +
>> +                     /*
>> +                      * Not all SH platforms declare a clock lookup entry
>> +                      * for SCI devices, in which case we need to get the
>> +                      * global "peripheral_clk" clock.
>> +                      */
>> +                     clk = devm_clk_get(dev, "peripheral_clk");
>> +                     if (!IS_ERR(clk))
>> +                             goto found;
>> +
>> +                     dev_err(dev, "failed to get functional clock\n");
>> +                     return PTR_ERR(clk);
>> +             }
>>
>> -     dev_err(dev, "failed to get functional clock\n");
>> -     return PTR_ERR(sci_port->fclk);
>> +found:
>> +             if (!IS_ERR(clk))
>> +                     dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk, clk);
>> +             sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
>
> Isn't it an issue that we can't tell apart the case where there is no clock
> specified in DT and the case where we can't get the clock due to another error
> ?

All failures here are for optional clocks.
If the real failure is that the clock wasn't specified (or misspelled) in DT,
it should have been detected during the integration phase.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 08:52:19 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
> >> Refactor the clock and baud rate parameter code to ease adding support
> >> for multiple clocks and baud rate generators later.
> >> sci_scbrr_calc() now returns the bit rate error, so it can be compared
> >> to the bit rate error for other baud rate generators.
> >> 
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> ---
> >> 
> >>  drivers/tty/serial/sh-sci.c | 176 +++++++++++++++++++++++++-------------
> >>  1 file changed, 120 insertions(+), 56 deletions(-)
> >> 
> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> index 726c96d5a511c222..12800e52f41953dc 100644
> >> --- a/drivers/tty/serial/sh-sci.c
> >> +++ b/drivers/tty/serial/sh-sci.c
> >> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
> >>  *dev)
> >>  {
> >> -     /* Get the SCI functional clock. It's called "fck" on ARM. */
> >> -     sci_port->fclk = devm_clk_get(dev, "fck");
> >> -     if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
> >> -             return -EPROBE_DEFER;
> >> -     if (!IS_ERR(sci_port->fclk))
> >> -             return 0;
> >> +     const char *clk_names[] = {
> >> +             [SCI_FCK] = "fck",
> >> +     };
> >> +     struct clk *clk;
> >> +     unsigned int i;
> >> 
> >> -     /*
> >> -      * But it used to be called "sci_ick", and we need to maintain DT
> >> -      * backward compatibility.
> >> -      */
> >> -     sci_port->fclk = devm_clk_get(dev, "sci_ick");
> >> -     if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
> >> -             return -EPROBE_DEFER;
> >> -     if (!IS_ERR(sci_port->fclk))
> >> -             return 0;
> >> +     for (i = 0; i < SCI_NUM_CLKS; i++) {
> >> +             clk = devm_clk_get(dev, clk_names[i]);
> >> +             if (PTR_ERR(clk) = -EPROBE_DEFER)
> >> +                     return -EPROBE_DEFER;
> >> 
> >> -     /*
> >> -      * Not all SH platforms declare a clock lookup entry for SCI
> >> devices,
> >> -      * in which case we need to get the global "peripheral_clk" clock.
> >> -      */
> >> -     sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
> >> -     if (!IS_ERR(sci_port->fclk))
> >> -             return 0;
> >> +             if (IS_ERR(clk) && i = SCI_FCK) {
> >> +                     /*
> >> +                      * "fck" used to be called "sci_ick", and we need
> >> to
> >> +                      * maintain DT backward compatibility.
> >> +                      */
> >> +                     clk = devm_clk_get(dev, "sci_ick");
> >> +                     if (PTR_ERR(clk) = -EPROBE_DEFER)
> >> +                             return -EPROBE_DEFER;
> >> +
> >> +                     if (!IS_ERR(clk))
> >> +                             goto found;
> >> +
> >> +                     /*
> >> +                      * Not all SH platforms declare a clock lookup
> >> entry
> >> +                      * for SCI devices, in which case we need to get
> >> the
> >> +                      * global "peripheral_clk" clock.
> >> +                      */
> >> +                     clk = devm_clk_get(dev, "peripheral_clk");
> >> +                     if (!IS_ERR(clk))
> >> +                             goto found;
> >> +
> >> +                     dev_err(dev, "failed to get functional clock\n");
> >> +                     return PTR_ERR(clk);
> >> +             }
> >> 
> >> -     dev_err(dev, "failed to get functional clock\n");
> >> -     return PTR_ERR(sci_port->fclk);
> >> +found:
> >> +             if (!IS_ERR(clk))
> >> +                     dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk,
> >> clk);
> >> +             sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
> > 
> > Isn't it an issue that we can't tell apart the case where there is no
> > clock specified in DT and the case where we can't get the clock due to
> > another error ?
> 
> All failures here are for optional clocks.
> If the real failure is that the clock wasn't specified (or misspelled) in
> DT, it should have been detected during the integration phase.

There could be cases where the clock is correctly specified in DT but can't be 
retrieved due to a runtime error. I suppose that's mostly theoretical in our 
case though. Maybe a dev_dbg for the error case could be useful too ? Can we 
tell the case where the clock is not specified in DT apart from other errors 
(-EPROBE_DEFER aside as that case is already handled) ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 08:52:19 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
> >> Refactor the clock and baud rate parameter code to ease adding support
> >> for multiple clocks and baud rate generators later.
> >> sci_scbrr_calc() now returns the bit rate error, so it can be compared
> >> to the bit rate error for other baud rate generators.
> >> 
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> ---
> >> 
> >>  drivers/tty/serial/sh-sci.c | 176 +++++++++++++++++++++++++-------------
> >>  1 file changed, 120 insertions(+), 56 deletions(-)
> >> 
> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> index 726c96d5a511c222..12800e52f41953dc 100644
> >> --- a/drivers/tty/serial/sh-sci.c
> >> +++ b/drivers/tty/serial/sh-sci.c
> >> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
> >>  *dev)
> >>  {
> >> -     /* Get the SCI functional clock. It's called "fck" on ARM. */
> >> -     sci_port->fclk = devm_clk_get(dev, "fck");
> >> -     if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
> >> -             return -EPROBE_DEFER;
> >> -     if (!IS_ERR(sci_port->fclk))
> >> -             return 0;
> >> +     const char *clk_names[] = {
> >> +             [SCI_FCK] = "fck",
> >> +     };
> >> +     struct clk *clk;
> >> +     unsigned int i;
> >> 
> >> -     /*
> >> -      * But it used to be called "sci_ick", and we need to maintain DT
> >> -      * backward compatibility.
> >> -      */
> >> -     sci_port->fclk = devm_clk_get(dev, "sci_ick");
> >> -     if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
> >> -             return -EPROBE_DEFER;
> >> -     if (!IS_ERR(sci_port->fclk))
> >> -             return 0;
> >> +     for (i = 0; i < SCI_NUM_CLKS; i++) {
> >> +             clk = devm_clk_get(dev, clk_names[i]);
> >> +             if (PTR_ERR(clk) == -EPROBE_DEFER)
> >> +                     return -EPROBE_DEFER;
> >> 
> >> -     /*
> >> -      * Not all SH platforms declare a clock lookup entry for SCI
> >> devices,
> >> -      * in which case we need to get the global "peripheral_clk" clock.
> >> -      */
> >> -     sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
> >> -     if (!IS_ERR(sci_port->fclk))
> >> -             return 0;
> >> +             if (IS_ERR(clk) && i == SCI_FCK) {
> >> +                     /*
> >> +                      * "fck" used to be called "sci_ick", and we need
> >> to
> >> +                      * maintain DT backward compatibility.
> >> +                      */
> >> +                     clk = devm_clk_get(dev, "sci_ick");
> >> +                     if (PTR_ERR(clk) == -EPROBE_DEFER)
> >> +                             return -EPROBE_DEFER;
> >> +
> >> +                     if (!IS_ERR(clk))
> >> +                             goto found;
> >> +
> >> +                     /*
> >> +                      * Not all SH platforms declare a clock lookup
> >> entry
> >> +                      * for SCI devices, in which case we need to get
> >> the
> >> +                      * global "peripheral_clk" clock.
> >> +                      */
> >> +                     clk = devm_clk_get(dev, "peripheral_clk");
> >> +                     if (!IS_ERR(clk))
> >> +                             goto found;
> >> +
> >> +                     dev_err(dev, "failed to get functional clock\n");
> >> +                     return PTR_ERR(clk);
> >> +             }
> >> 
> >> -     dev_err(dev, "failed to get functional clock\n");
> >> -     return PTR_ERR(sci_port->fclk);
> >> +found:
> >> +             if (!IS_ERR(clk))
> >> +                     dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk,
> >> clk);
> >> +             sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
> > 
> > Isn't it an issue that we can't tell apart the case where there is no
> > clock specified in DT and the case where we can't get the clock due to
> > another error ?
> 
> All failures here are for optional clocks.
> If the real failure is that the clock wasn't specified (or misspelled) in
> DT, it should have been detected during the integration phase.

There could be cases where the clock is correctly specified in DT but can't be 
retrieved due to a runtime error. I suppose that's mostly theoretical in our 
case though. Maybe a dev_dbg for the error case could be useful too ? Can we 
tell the case where the clock is not specified in DT apart from other errors 
(-EPROBE_DEFER aside as that case is already handled) ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Nov 20, 2015 at 3:47 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 08:52:19 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
>> >> Refactor the clock and baud rate parameter code to ease adding support
>> >> for multiple clocks and baud rate generators later.
>> >> sci_scbrr_calc() now returns the bit rate error, so it can be compared
>> >> to the bit rate error for other baud rate generators.
>> >>
>> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> ---
>> >>
>> >>  drivers/tty/serial/sh-sci.c | 176 +++++++++++++++++++++++++-------------
>> >>  1 file changed, 120 insertions(+), 56 deletions(-)
>> >>
>> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> >> index 726c96d5a511c222..12800e52f41953dc 100644
>> >> --- a/drivers/tty/serial/sh-sci.c
>> >> +++ b/drivers/tty/serial/sh-sci.c
>> >> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
>> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
>> >>  *dev)
>> >>  {
>> >> -     /* Get the SCI functional clock. It's called "fck" on ARM. */
>> >> -     sci_port->fclk = devm_clk_get(dev, "fck");
>> >> -     if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
>> >> -             return -EPROBE_DEFER;
>> >> -     if (!IS_ERR(sci_port->fclk))
>> >> -             return 0;
>> >> +     const char *clk_names[] = {
>> >> +             [SCI_FCK] = "fck",
>> >> +     };
>> >> +     struct clk *clk;
>> >> +     unsigned int i;
>> >>
>> >> -     /*
>> >> -      * But it used to be called "sci_ick", and we need to maintain DT
>> >> -      * backward compatibility.
>> >> -      */
>> >> -     sci_port->fclk = devm_clk_get(dev, "sci_ick");
>> >> -     if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
>> >> -             return -EPROBE_DEFER;
>> >> -     if (!IS_ERR(sci_port->fclk))
>> >> -             return 0;
>> >> +     for (i = 0; i < SCI_NUM_CLKS; i++) {
>> >> +             clk = devm_clk_get(dev, clk_names[i]);
>> >> +             if (PTR_ERR(clk) = -EPROBE_DEFER)
>> >> +                     return -EPROBE_DEFER;
>> >>
>> >> -     /*
>> >> -      * Not all SH platforms declare a clock lookup entry for SCI
>> >> devices,
>> >> -      * in which case we need to get the global "peripheral_clk" clock.
>> >> -      */
>> >> -     sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
>> >> -     if (!IS_ERR(sci_port->fclk))
>> >> -             return 0;
>> >> +             if (IS_ERR(clk) && i = SCI_FCK) {
>> >> +                     /*
>> >> +                      * "fck" used to be called "sci_ick", and we need
>> >> to
>> >> +                      * maintain DT backward compatibility.
>> >> +                      */
>> >> +                     clk = devm_clk_get(dev, "sci_ick");
>> >> +                     if (PTR_ERR(clk) = -EPROBE_DEFER)
>> >> +                             return -EPROBE_DEFER;
>> >> +
>> >> +                     if (!IS_ERR(clk))
>> >> +                             goto found;
>> >> +
>> >> +                     /*
>> >> +                      * Not all SH platforms declare a clock lookup
>> >> entry
>> >> +                      * for SCI devices, in which case we need to get
>> >> the
>> >> +                      * global "peripheral_clk" clock.
>> >> +                      */
>> >> +                     clk = devm_clk_get(dev, "peripheral_clk");
>> >> +                     if (!IS_ERR(clk))
>> >> +                             goto found;
>> >> +
>> >> +                     dev_err(dev, "failed to get functional clock\n");
>> >> +                     return PTR_ERR(clk);
>> >> +             }
>> >>
>> >> -     dev_err(dev, "failed to get functional clock\n");
>> >> -     return PTR_ERR(sci_port->fclk);
>> >> +found:
>> >> +             if (!IS_ERR(clk))
>> >> +                     dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk,
>> >> clk);
>> >> +             sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
>> >
>> > Isn't it an issue that we can't tell apart the case where there is no
>> > clock specified in DT and the case where we can't get the clock due to
>> > another error ?
>>
>> All failures here are for optional clocks.
>> If the real failure is that the clock wasn't specified (or misspelled) in
>> DT, it should have been detected during the integration phase.
>
> There could be cases where the clock is correctly specified in DT but can't be
> retrieved due to a runtime error. I suppose that's mostly theoretical in our
> case though. Maybe a dev_dbg for the error case could be useful too ? Can we
> tell the case where the clock is not specified in DT apart from other errors
> (-EPROBE_DEFER aside as that case is already handled) ?

If the clock is not in clock/clock-names in DT, the error is definitely -ENOENT.

If the clock is specified in DT, it has a phandle to a clock node. If that
clock hasn't been instantiated yet, the error is EPROBE_DEFER.
Which means there are no other possible error values, right?

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Nov 20, 2015 at 3:47 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 08:52:19 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
>> >> Refactor the clock and baud rate parameter code to ease adding support
>> >> for multiple clocks and baud rate generators later.
>> >> sci_scbrr_calc() now returns the bit rate error, so it can be compared
>> >> to the bit rate error for other baud rate generators.
>> >>
>> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> ---
>> >>
>> >>  drivers/tty/serial/sh-sci.c | 176 +++++++++++++++++++++++++-------------
>> >>  1 file changed, 120 insertions(+), 56 deletions(-)
>> >>
>> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> >> index 726c96d5a511c222..12800e52f41953dc 100644
>> >> --- a/drivers/tty/serial/sh-sci.c
>> >> +++ b/drivers/tty/serial/sh-sci.c
>> >> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
>> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
>> >>  *dev)
>> >>  {
>> >> -     /* Get the SCI functional clock. It's called "fck" on ARM. */
>> >> -     sci_port->fclk = devm_clk_get(dev, "fck");
>> >> -     if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
>> >> -             return -EPROBE_DEFER;
>> >> -     if (!IS_ERR(sci_port->fclk))
>> >> -             return 0;
>> >> +     const char *clk_names[] = {
>> >> +             [SCI_FCK] = "fck",
>> >> +     };
>> >> +     struct clk *clk;
>> >> +     unsigned int i;
>> >>
>> >> -     /*
>> >> -      * But it used to be called "sci_ick", and we need to maintain DT
>> >> -      * backward compatibility.
>> >> -      */
>> >> -     sci_port->fclk = devm_clk_get(dev, "sci_ick");
>> >> -     if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
>> >> -             return -EPROBE_DEFER;
>> >> -     if (!IS_ERR(sci_port->fclk))
>> >> -             return 0;
>> >> +     for (i = 0; i < SCI_NUM_CLKS; i++) {
>> >> +             clk = devm_clk_get(dev, clk_names[i]);
>> >> +             if (PTR_ERR(clk) == -EPROBE_DEFER)
>> >> +                     return -EPROBE_DEFER;
>> >>
>> >> -     /*
>> >> -      * Not all SH platforms declare a clock lookup entry for SCI
>> >> devices,
>> >> -      * in which case we need to get the global "peripheral_clk" clock.
>> >> -      */
>> >> -     sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
>> >> -     if (!IS_ERR(sci_port->fclk))
>> >> -             return 0;
>> >> +             if (IS_ERR(clk) && i == SCI_FCK) {
>> >> +                     /*
>> >> +                      * "fck" used to be called "sci_ick", and we need
>> >> to
>> >> +                      * maintain DT backward compatibility.
>> >> +                      */
>> >> +                     clk = devm_clk_get(dev, "sci_ick");
>> >> +                     if (PTR_ERR(clk) == -EPROBE_DEFER)
>> >> +                             return -EPROBE_DEFER;
>> >> +
>> >> +                     if (!IS_ERR(clk))
>> >> +                             goto found;
>> >> +
>> >> +                     /*
>> >> +                      * Not all SH platforms declare a clock lookup
>> >> entry
>> >> +                      * for SCI devices, in which case we need to get
>> >> the
>> >> +                      * global "peripheral_clk" clock.
>> >> +                      */
>> >> +                     clk = devm_clk_get(dev, "peripheral_clk");
>> >> +                     if (!IS_ERR(clk))
>> >> +                             goto found;
>> >> +
>> >> +                     dev_err(dev, "failed to get functional clock\n");
>> >> +                     return PTR_ERR(clk);
>> >> +             }
>> >>
>> >> -     dev_err(dev, "failed to get functional clock\n");
>> >> -     return PTR_ERR(sci_port->fclk);
>> >> +found:
>> >> +             if (!IS_ERR(clk))
>> >> +                     dev_dbg(dev, "clk %u is %pC rate %pCr\n", i, clk,
>> >> clk);
>> >> +             sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
>> >
>> > Isn't it an issue that we can't tell apart the case where there is no
>> > clock specified in DT and the case where we can't get the clock due to
>> > another error ?
>>
>> All failures here are for optional clocks.
>> If the real failure is that the clock wasn't specified (or misspelled) in
>> DT, it should have been detected during the integration phase.
>
> There could be cases where the clock is correctly specified in DT but can't be
> retrieved due to a runtime error. I suppose that's mostly theoretical in our
> case though. Maybe a dev_dbg for the error case could be useful too ? Can we
> tell the case where the clock is not specified in DT apart from other errors
> (-EPROBE_DEFER aside as that case is already handled) ?

If the clock is not in clock/clock-names in DT, the error is definitely -ENOENT.

If the clock is specified in DT, it has a phandle to a clock node. If that
clock hasn't been instantiated yet, the error is EPROBE_DEFER.
Which means there are no other possible error values, right?

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Laurent Pinchart]

On Friday 20 November 2015 16:17:13 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 3:47 PM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 08:52:19 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart wrote:
> >> > On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
> >> >> Refactor the clock and baud rate parameter code to ease adding support
> >> >> for multiple clocks and baud rate generators later.
> >> >> sci_scbrr_calc() now returns the bit rate error, so it can be compared
> >> >> to the bit rate error for other baud rate generators.
> >> >> 
> >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> >> ---
> >> >> 
> >> >>  drivers/tty/serial/sh-sci.c | 176
> >> >>  +++++++++++++++++++++++++-------------
> >> >>  1 file changed, 120 insertions(+), 56 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> >> index 726c96d5a511c222..12800e52f41953dc 100644
> >> >> --- a/drivers/tty/serial/sh-sci.c
> >> >> +++ b/drivers/tty/serial/sh-sci.c
> >> >> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
> >> >> 
> >> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
> >> >>  *dev)
> >> >>  {
> >> >> 
> >> >> -     /* Get the SCI functional clock. It's called "fck" on ARM. */
> >> >> -     sci_port->fclk = devm_clk_get(dev, "fck");
> >> >> -     if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
> >> >> -             return -EPROBE_DEFER;
> >> >> -     if (!IS_ERR(sci_port->fclk))
> >> >> -             return 0;
> >> >> +     const char *clk_names[] = {
> >> >> +             [SCI_FCK] = "fck",
> >> >> +     };
> >> >> +     struct clk *clk;
> >> >> +     unsigned int i;
> >> >> 
> >> >> -     /*
> >> >> -      * But it used to be called "sci_ick", and we need to maintain
> >> >> DT
> >> >> -      * backward compatibility.
> >> >> -      */
> >> >> -     sci_port->fclk = devm_clk_get(dev, "sci_ick");
> >> >> -     if (PTR_ERR(sci_port->fclk) = -EPROBE_DEFER)
> >> >> -             return -EPROBE_DEFER;
> >> >> -     if (!IS_ERR(sci_port->fclk))
> >> >> -             return 0;
> >> >> +     for (i = 0; i < SCI_NUM_CLKS; i++) {
> >> >> +             clk = devm_clk_get(dev, clk_names[i]);
> >> >> +             if (PTR_ERR(clk) = -EPROBE_DEFER)
> >> >> +                     return -EPROBE_DEFER;
> >> >> 
> >> >> -     /*
> >> >> -      * Not all SH platforms declare a clock lookup entry for SCI
> >> >> devices,
> >> >> -      * in which case we need to get the global "peripheral_clk"
> >> >> clock.
> >> >> -      */
> >> >> -     sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
> >> >> -     if (!IS_ERR(sci_port->fclk))
> >> >> -             return 0;
> >> >> +             if (IS_ERR(clk) && i = SCI_FCK) {
> >> >> +                     /*
> >> >> +                      * "fck" used to be called "sci_ick", and we
> >> >> need
> >> >> to
> >> >> +                      * maintain DT backward compatibility.
> >> >> +                      */
> >> >> +                     clk = devm_clk_get(dev, "sci_ick");
> >> >> +                     if (PTR_ERR(clk) = -EPROBE_DEFER)
> >> >> +                             return -EPROBE_DEFER;
> >> >> +
> >> >> +                     if (!IS_ERR(clk))
> >> >> +                             goto found;
> >> >> +
> >> >> +                     /*
> >> >> +                      * Not all SH platforms declare a clock lookup
> >> >> entry
> >> >> +                      * for SCI devices, in which case we need to get
> >> >> the
> >> >> +                      * global "peripheral_clk" clock.
> >> >> +                      */
> >> >> +                     clk = devm_clk_get(dev, "peripheral_clk");
> >> >> +                     if (!IS_ERR(clk))
> >> >> +                             goto found;
> >> >> +
> >> >> +                     dev_err(dev, "failed to get functional
> >> >> clock\n");
> >> >> +                     return PTR_ERR(clk);
> >> >> +             }
> >> >> 
> >> >> -     dev_err(dev, "failed to get functional clock\n");
> >> >> -     return PTR_ERR(sci_port->fclk);
> >> >> +found:
> >> >> +             if (!IS_ERR(clk))
> >> >> +                     dev_dbg(dev, "clk %u is %pC rate %pCr\n", i,
> >> >> clk,
> >> >> clk);
> >> >> +             sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
> >> > 
> >> > Isn't it an issue that we can't tell apart the case where there is no
> >> > clock specified in DT and the case where we can't get the clock due to
> >> > another error ?
> >> 
> >> All failures here are for optional clocks.
> >> If the real failure is that the clock wasn't specified (or misspelled) in
> >> DT, it should have been detected during the integration phase.
> > 
> > There could be cases where the clock is correctly specified in DT but
> > can't be retrieved due to a runtime error. I suppose that's mostly
> > theoretical in our case though. Maybe a dev_dbg for the error case could
> > be useful too ? Can we tell the case where the clock is not specified in
> > DT apart from other errors (-EPROBE_DEFER aside as that case is already
> > handled) ?
> 
> If the clock is not in clock/clock-names in DT, the error is definitely
> -ENOENT.
> 
> If the clock is specified in DT, it has a phandle to a clock node. If that
> clock hasn't been instantiated yet, the error is EPROBE_DEFER.
> Which means there are no other possible error values, right?

There could be other errors returned from __of_clk_get_from_provider if the 
clock provider get method returns an error or if __clk_create_clk() fails. The 
latter only returns -ENOMEM so we'd have worse issues anyway. I agree that a 
clock provider get failure shouldn't be a common case.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 18/25] serial: sh-sci: Prepare for multiple clocks and baud rate generators

[Laurent Pinchart]

On Friday 20 November 2015 16:17:13 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 3:47 PM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 08:52:19 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 10:04 PM, Laurent Pinchart wrote:
> >> > On Thursday 19 November 2015 19:38:57 Geert Uytterhoeven wrote:
> >> >> Refactor the clock and baud rate parameter code to ease adding support
> >> >> for multiple clocks and baud rate generators later.
> >> >> sci_scbrr_calc() now returns the bit rate error, so it can be compared
> >> >> to the bit rate error for other baud rate generators.
> >> >> 
> >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> >> ---
> >> >> 
> >> >>  drivers/tty/serial/sh-sci.c | 176
> >> >>  +++++++++++++++++++++++++-------------
> >> >>  1 file changed, 120 insertions(+), 56 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> >> index 726c96d5a511c222..12800e52f41953dc 100644
> >> >> --- a/drivers/tty/serial/sh-sci.c
> >> >> +++ b/drivers/tty/serial/sh-sci.c
> >> >> @@ -2252,33 +2301,48 @@ static struct uart_ops sci_uart_ops = {
> >> >> 
> >> >>  static int sci_init_clocks(struct sci_port *sci_port, struct device
> >> >>  *dev)
> >> >>  {
> >> >> 
> >> >> -     /* Get the SCI functional clock. It's called "fck" on ARM. */
> >> >> -     sci_port->fclk = devm_clk_get(dev, "fck");
> >> >> -     if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
> >> >> -             return -EPROBE_DEFER;
> >> >> -     if (!IS_ERR(sci_port->fclk))
> >> >> -             return 0;
> >> >> +     const char *clk_names[] = {
> >> >> +             [SCI_FCK] = "fck",
> >> >> +     };
> >> >> +     struct clk *clk;
> >> >> +     unsigned int i;
> >> >> 
> >> >> -     /*
> >> >> -      * But it used to be called "sci_ick", and we need to maintain
> >> >> DT
> >> >> -      * backward compatibility.
> >> >> -      */
> >> >> -     sci_port->fclk = devm_clk_get(dev, "sci_ick");
> >> >> -     if (PTR_ERR(sci_port->fclk) == -EPROBE_DEFER)
> >> >> -             return -EPROBE_DEFER;
> >> >> -     if (!IS_ERR(sci_port->fclk))
> >> >> -             return 0;
> >> >> +     for (i = 0; i < SCI_NUM_CLKS; i++) {
> >> >> +             clk = devm_clk_get(dev, clk_names[i]);
> >> >> +             if (PTR_ERR(clk) == -EPROBE_DEFER)
> >> >> +                     return -EPROBE_DEFER;
> >> >> 
> >> >> -     /*
> >> >> -      * Not all SH platforms declare a clock lookup entry for SCI
> >> >> devices,
> >> >> -      * in which case we need to get the global "peripheral_clk"
> >> >> clock.
> >> >> -      */
> >> >> -     sci_port->fclk = devm_clk_get(dev, "peripheral_clk");
> >> >> -     if (!IS_ERR(sci_port->fclk))
> >> >> -             return 0;
> >> >> +             if (IS_ERR(clk) && i == SCI_FCK) {
> >> >> +                     /*
> >> >> +                      * "fck" used to be called "sci_ick", and we
> >> >> need
> >> >> to
> >> >> +                      * maintain DT backward compatibility.
> >> >> +                      */
> >> >> +                     clk = devm_clk_get(dev, "sci_ick");
> >> >> +                     if (PTR_ERR(clk) == -EPROBE_DEFER)
> >> >> +                             return -EPROBE_DEFER;
> >> >> +
> >> >> +                     if (!IS_ERR(clk))
> >> >> +                             goto found;
> >> >> +
> >> >> +                     /*
> >> >> +                      * Not all SH platforms declare a clock lookup
> >> >> entry
> >> >> +                      * for SCI devices, in which case we need to get
> >> >> the
> >> >> +                      * global "peripheral_clk" clock.
> >> >> +                      */
> >> >> +                     clk = devm_clk_get(dev, "peripheral_clk");
> >> >> +                     if (!IS_ERR(clk))
> >> >> +                             goto found;
> >> >> +
> >> >> +                     dev_err(dev, "failed to get functional
> >> >> clock\n");
> >> >> +                     return PTR_ERR(clk);
> >> >> +             }
> >> >> 
> >> >> -     dev_err(dev, "failed to get functional clock\n");
> >> >> -     return PTR_ERR(sci_port->fclk);
> >> >> +found:
> >> >> +             if (!IS_ERR(clk))
> >> >> +                     dev_dbg(dev, "clk %u is %pC rate %pCr\n", i,
> >> >> clk,
> >> >> clk);
> >> >> +             sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
> >> > 
> >> > Isn't it an issue that we can't tell apart the case where there is no
> >> > clock specified in DT and the case where we can't get the clock due to
> >> > another error ?
> >> 
> >> All failures here are for optional clocks.
> >> If the real failure is that the clock wasn't specified (or misspelled) in
> >> DT, it should have been detected during the integration phase.
> > 
> > There could be cases where the clock is correctly specified in DT but
> > can't be retrieved due to a runtime error. I suppose that's mostly
> > theoretical in our case though. Maybe a dev_dbg for the error case could
> > be useful too ? Can we tell the case where the clock is not specified in
> > DT apart from other errors (-EPROBE_DEFER aside as that case is already
> > handled) ?
> 
> If the clock is not in clock/clock-names in DT, the error is definitely
> -ENOENT.
> 
> If the clock is specified in DT, it has a phandle to a clock node. If that
> clock hasn't been instantiated yet, the error is EPROBE_DEFER.
> Which means there are no other possible error values, right?

There could be other errors returned from __of_clk_get_from_provider if the 
clock provider get method returns an error or if __clk_create_clk() fails. The 
latter only returns -ENOMEM so we'd have worse issues anyway. I agree that a 
clock provider get failure shouldn't be a common case.

-- 
Regards,

Laurent Pinchart

[PATCH 19/25] serial: sh-sci: Add support for optional external (H)SCK input

[Geert Uytterhoeven]

Add support for using the SCIx clock pin "(H)SCK" as an external clock
input on (H)SCI(F).

Note that this feature is not yet supported on the select SCIFA variants
that also have it (e.g. sh7723, sh7724, and r8a7740).

On (H)SCIF variants with an External Baud Rate Generator (BRG), the
BRG Clock Select Register must be configured for the external clock.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 63 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 60 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 12800e52f41953dc..f88aac684ed1e3b6 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -79,6 +79,7 @@ enum {
 
 enum SCI_CLKS {
 	SCI_FCK,		/* Functional Clock */
+	SCI_SCK,		/* Optional External Clock */
 	SCI_NUM_CLKS
 };
 
@@ -1924,6 +1925,36 @@ static void sci_shutdown(struct uart_port *port)
 	sci_free_irq(s);
 }
 
+static int sci_sck_calc(struct sci_port *s, unsigned int bps,
+			unsigned int *srr)
+{
+	unsigned long freq = s->clk_rates[SCI_SCK];
+	unsigned int min_sr, max_sr, sr;
+	int err, min_err = INT_MAX;
+
+	if (s->sampling_rate) {
+		/* SCI(F) has a fixed sampling rate */
+		min_sr = max_sr = s->sampling_rate / 2;
+	} else {
+		/* HSCIF has a variable 1/(8..32) sampling rate */
+		min_sr = 8;
+		max_sr = 32;
+	}
+
+	for (sr = max_sr; sr >= min_sr; sr--) {
+		err = DIV_ROUND_CLOSEST(freq, sr) - bps;
+		if (abs(err) >= abs(min_err))
+			continue;
+
+		min_err = err;
+		*srr = sr - 1;
+	}
+
+	dev_dbg(s->port.dev, "SCK: %u%+d bps using SR %u\n", bps, min_err,
+		*srr + 1);
+	return min_err;
+}
+
 /* calculate sample rate, BRR, and clock select */
 static int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 			  unsigned int *brr, unsigned int *srr,
@@ -2005,7 +2036,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 			    struct ktermios *old)
 {
 	unsigned int baud, smr_val = 0, scr_val = 0, i;
-	unsigned int brr = 255, cks = 0, srr = 15;
+	unsigned int brr = 255, cks = 0, srr = 15, sccks = 0;
 	unsigned int brr1 = 255, cks1 = 0, srr1 = 15;
 	struct sci_port *s = to_sci_port(port);
 	const struct plat_sci_reg *reg;
@@ -2043,10 +2074,26 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (!baud)
 		goto done;
 
+	/* Optional External Clock */
+	if (s->clk_rates[SCI_SCK] && port->type != PORT_SCIFA &&
+	    port->type != PORT_SCIFB) {
+		err = sci_sck_calc(s, baud, &srr1);
+		if (abs(err) < abs(min_err)) {
+			best_clk = SCI_SCK;
+			scr_val = SCSCR_CKE1;
+			sccks = SCCKS_CKS;
+			min_err = err;
+			srr = srr1;
+			if (!err)
+				goto done;
+		}
+	}
+
 	/* Functional Clock and standard Bit Rate Register */
 	err = sci_scbrr_calc(s, baud, &brr1, &srr1, &cks1);
 	if (abs(err) < abs(min_err)) {
 		best_clk = SCI_FCK;
+		scr_val = 0;
 		min_err = err;
 		brr = brr1;
 		srr = srr1;
@@ -2060,14 +2107,20 @@ done:
 
 	sci_port_enable(s);
 
+	/* Program the optional External Baud Rate Generator (BRG) first */
+	if (best_clk >= 0 && sci_getreg(port, SCCKS)->size)
+		serial_port_out(port, SCCKS, sccks);
+
 	sci_reset(port);
 
 	uart_update_timeout(port, termios->c_cflag, baud);
 
 	if (best_clk >= 0) {
 		smr_val |= cks;
-		dev_dbg(port->dev, "SMR 0x%x BRR %u SRR %u\n", smr_val, brr,
-			srr);
+		dev_dbg(port->dev,
+			 "SCR 0x%x SMR 0x%x BRR %u CKS 0x%x SRR %u\n",
+			 scr_val, smr_val, brr, sccks, srr);
+		serial_port_out(port, SCSCR, scr_val);
 		serial_port_out(port, SCSMR, smr_val);
 		serial_port_out(port, SCBRR, brr);
 		if (sci_getreg(port, HSSRR)->size)
@@ -2303,10 +2356,14 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 {
 	const char *clk_names[] = {
 		[SCI_FCK] = "fck",
+		[SCI_SCK] = "sck",
 	};
 	struct clk *clk;
 	unsigned int i;
 
+	if (sci_port->cfg->type = PORT_HSCIF)
+		clk_names[SCI_SCK] = "hsck";
+
 	for (i = 0; i < SCI_NUM_CLKS; i++) {
 		clk = devm_clk_get(dev, clk_names[i]);
 		if (PTR_ERR(clk) = -EPROBE_DEFER)
-- 
1.9.1

[PATCH 19/25] serial: sh-sci: Add support for optional external (H)SCK input

[Geert Uytterhoeven]

Add support for using the SCIx clock pin "(H)SCK" as an external clock
input on (H)SCI(F).

Note that this feature is not yet supported on the select SCIFA variants
that also have it (e.g. sh7723, sh7724, and r8a7740).

On (H)SCIF variants with an External Baud Rate Generator (BRG), the
BRG Clock Select Register must be configured for the external clock.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 63 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 60 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 12800e52f41953dc..f88aac684ed1e3b6 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -79,6 +79,7 @@ enum {
 
 enum SCI_CLKS {
 	SCI_FCK,		/* Functional Clock */
+	SCI_SCK,		/* Optional External Clock */
 	SCI_NUM_CLKS
 };
 
@@ -1924,6 +1925,36 @@ static void sci_shutdown(struct uart_port *port)
 	sci_free_irq(s);
 }
 
+static int sci_sck_calc(struct sci_port *s, unsigned int bps,
+			unsigned int *srr)
+{
+	unsigned long freq = s->clk_rates[SCI_SCK];
+	unsigned int min_sr, max_sr, sr;
+	int err, min_err = INT_MAX;
+
+	if (s->sampling_rate) {
+		/* SCI(F) has a fixed sampling rate */
+		min_sr = max_sr = s->sampling_rate / 2;
+	} else {
+		/* HSCIF has a variable 1/(8..32) sampling rate */
+		min_sr = 8;
+		max_sr = 32;
+	}
+
+	for (sr = max_sr; sr >= min_sr; sr--) {
+		err = DIV_ROUND_CLOSEST(freq, sr) - bps;
+		if (abs(err) >= abs(min_err))
+			continue;
+
+		min_err = err;
+		*srr = sr - 1;
+	}
+
+	dev_dbg(s->port.dev, "SCK: %u%+d bps using SR %u\n", bps, min_err,
+		*srr + 1);
+	return min_err;
+}
+
 /* calculate sample rate, BRR, and clock select */
 static int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 			  unsigned int *brr, unsigned int *srr,
@@ -2005,7 +2036,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 			    struct ktermios *old)
 {
 	unsigned int baud, smr_val = 0, scr_val = 0, i;
-	unsigned int brr = 255, cks = 0, srr = 15;
+	unsigned int brr = 255, cks = 0, srr = 15, sccks = 0;
 	unsigned int brr1 = 255, cks1 = 0, srr1 = 15;
 	struct sci_port *s = to_sci_port(port);
 	const struct plat_sci_reg *reg;
@@ -2043,10 +2074,26 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (!baud)
 		goto done;
 
+	/* Optional External Clock */
+	if (s->clk_rates[SCI_SCK] && port->type != PORT_SCIFA &&
+	    port->type != PORT_SCIFB) {
+		err = sci_sck_calc(s, baud, &srr1);
+		if (abs(err) < abs(min_err)) {
+			best_clk = SCI_SCK;
+			scr_val = SCSCR_CKE1;
+			sccks = SCCKS_CKS;
+			min_err = err;
+			srr = srr1;
+			if (!err)
+				goto done;
+		}
+	}
+
 	/* Functional Clock and standard Bit Rate Register */
 	err = sci_scbrr_calc(s, baud, &brr1, &srr1, &cks1);
 	if (abs(err) < abs(min_err)) {
 		best_clk = SCI_FCK;
+		scr_val = 0;
 		min_err = err;
 		brr = brr1;
 		srr = srr1;
@@ -2060,14 +2107,20 @@ done:
 
 	sci_port_enable(s);
 
+	/* Program the optional External Baud Rate Generator (BRG) first */
+	if (best_clk >= 0 && sci_getreg(port, SCCKS)->size)
+		serial_port_out(port, SCCKS, sccks);
+
 	sci_reset(port);
 
 	uart_update_timeout(port, termios->c_cflag, baud);
 
 	if (best_clk >= 0) {
 		smr_val |= cks;
-		dev_dbg(port->dev, "SMR 0x%x BRR %u SRR %u\n", smr_val, brr,
-			srr);
+		dev_dbg(port->dev,
+			 "SCR 0x%x SMR 0x%x BRR %u CKS 0x%x SRR %u\n",
+			 scr_val, smr_val, brr, sccks, srr);
+		serial_port_out(port, SCSCR, scr_val);
 		serial_port_out(port, SCSMR, smr_val);
 		serial_port_out(port, SCBRR, brr);
 		if (sci_getreg(port, HSSRR)->size)
@@ -2303,10 +2356,14 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 {
 	const char *clk_names[] = {
 		[SCI_FCK] = "fck",
+		[SCI_SCK] = "sck",
 	};
 	struct clk *clk;
 	unsigned int i;
 
+	if (sci_port->cfg->type == PORT_HSCIF)
+		clk_names[SCI_SCK] = "hsck";
+
 	for (i = 0; i < SCI_NUM_CLKS; i++) {
 		clk = devm_clk_get(dev, clk_names[i]);
 		if (PTR_ERR(clk) == -EPROBE_DEFER)
-- 
1.9.1

[PATCH 20/25] serial: sh-sci: Add support for optional BRG on (H)SCIF

[Geert Uytterhoeven]

Add support for the Baud Rate Generator for External Clock (BRG), as
found on some SCIF and HSCIF variants, which can improve baud rate range
and accuracy.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 82 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 77 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index f88aac684ed1e3b6..6b8f1675b9f6fadb 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -80,6 +80,8 @@ enum {
 enum SCI_CLKS {
 	SCI_FCK,		/* Functional Clock */
 	SCI_SCK,		/* Optional External Clock */
+	SCI_INT_CLK,		/* Optional BRG Internal Clock Source */
+	SCI_SCIF_CLK,		/* Optional BRG External Clock Source */
 	SCI_NUM_CLKS
 };
 
@@ -1955,6 +1957,40 @@ static int sci_sck_calc(struct sci_port *s, unsigned int bps,
 	return min_err;
 }
 
+static int sci_brg_calc(struct sci_port *s, unsigned int bps,
+			unsigned long freq, unsigned int *dlr,
+			unsigned int *srr)
+{
+	unsigned int min_sr, max_sr, sr, dl;
+	int err, min_err = INT_MAX;
+
+	if (s->sampling_rate) {
+		/* SCIF has a fixed sampling rate */
+		min_sr = max_sr = s->sampling_rate / 2;
+	} else {
+		/* HSCIF has a variable 1/(8..32) sampling rate */
+		min_sr = 8;
+		max_sr = 32;
+	}
+
+	for (sr = max_sr; sr >= min_sr; sr--) {
+		dl = DIV_ROUND_CLOSEST(freq, sr * bps);
+		dl = clamp(dl, 1U, 65535U);
+
+		err = DIV_ROUND_CLOSEST(freq, sr * dl) - bps;
+		if (abs(err) >= abs(min_err))
+			continue;
+
+		min_err = err;
+		*dlr = dl;
+		*srr = sr - 1;
+	}
+
+	dev_dbg(s->port.dev, "BRG: %u%+d bps using DL %u SR %u\n", bps,
+		min_err, *dlr, *srr + 1);
+	return min_err;
+}
+
 /* calculate sample rate, BRR, and clock select */
 static int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 			  unsigned int *brr, unsigned int *srr,
@@ -2036,8 +2072,8 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 			    struct ktermios *old)
 {
 	unsigned int baud, smr_val = 0, scr_val = 0, i;
-	unsigned int brr = 255, cks = 0, srr = 15, sccks = 0;
-	unsigned int brr1 = 255, cks1 = 0, srr1 = 15;
+	unsigned int brr = 255, cks = 0, srr = 15, dl = 0, sccks = 0;
+	unsigned int brr1 = 255, cks1 = 0, srr1 = 15, dl1 = 0;
 	struct sci_port *s = to_sci_port(port);
 	const struct plat_sci_reg *reg;
 	int min_err = INT_MAX, err;
@@ -2089,6 +2125,38 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 		}
 	}
 
+	/* Optional BRG External Clock Source */
+	if (s->clk_rates[SCI_SCIF_CLK] && sci_getreg(port, SCDL)->size) {
+		err = sci_brg_calc(s, baud, s->clk_rates[SCI_SCIF_CLK], &dl1,
+				   &srr1);
+		if (abs(err) < abs(min_err)) {
+			best_clk = SCI_SCIF_CLK;
+			scr_val = SCSCR_CKE1;
+			sccks = 0;
+			min_err = err;
+			dl = dl1;
+			srr = srr1;
+			if (!err)
+				goto done;
+		}
+	}
+
+	/* Optional BRG Internal Clock Source */
+	if (s->clk_rates[SCI_INT_CLK] && sci_getreg(port, SCDL)->size) {
+		err = sci_brg_calc(s, baud, s->clk_rates[SCI_INT_CLK], &dl1,
+				   &srr1);
+		if (abs(err) < abs(min_err)) {
+			best_clk = SCI_INT_CLK;
+			scr_val = SCSCR_CKE1;
+			sccks = SCCKS_XIN;
+			min_err = err;
+			dl = dl1;
+			srr = srr1;
+			if (!min_err)
+				goto done;
+		}
+	}
+
 	/* Functional Clock and standard Bit Rate Register */
 	err = sci_scbrr_calc(s, baud, &brr1, &srr1, &cks1);
 	if (abs(err) < abs(min_err)) {
@@ -2108,8 +2176,10 @@ done:
 	sci_port_enable(s);
 
 	/* Program the optional External Baud Rate Generator (BRG) first */
-	if (best_clk >= 0 && sci_getreg(port, SCCKS)->size)
+	if (best_clk >= 0 && sci_getreg(port, SCCKS)->size) {
+		serial_port_out(port, SCDL, dl);
 		serial_port_out(port, SCCKS, sccks);
+	}
 
 	sci_reset(port);
 
@@ -2118,8 +2188,8 @@ done:
 	if (best_clk >= 0) {
 		smr_val |= cks;
 		dev_dbg(port->dev,
-			 "SCR 0x%x SMR 0x%x BRR %u CKS 0x%x SRR %u\n",
-			 scr_val, smr_val, brr, sccks, srr);
+			 "SCR 0x%x SMR 0x%x BRR %u CKS 0x%x DL %u SRR %u\n",
+			 scr_val, smr_val, brr, sccks, dl, srr);
 		serial_port_out(port, SCSCR, scr_val);
 		serial_port_out(port, SCSMR, smr_val);
 		serial_port_out(port, SCBRR, brr);
@@ -2357,6 +2427,8 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 	const char *clk_names[] = {
 		[SCI_FCK] = "fck",
 		[SCI_SCK] = "sck",
+		[SCI_INT_CLK] = "int_clk",
+		[SCI_SCIF_CLK] = "scif_clk",
 	};
 	struct clk *clk;
 	unsigned int i;
-- 
1.9.1

[PATCH 20/25] serial: sh-sci: Add support for optional BRG on (H)SCIF

[Geert Uytterhoeven]

Add support for the Baud Rate Generator for External Clock (BRG), as
found on some SCIF and HSCIF variants, which can improve baud rate range
and accuracy.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 82 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 77 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index f88aac684ed1e3b6..6b8f1675b9f6fadb 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -80,6 +80,8 @@ enum {
 enum SCI_CLKS {
 	SCI_FCK,		/* Functional Clock */
 	SCI_SCK,		/* Optional External Clock */
+	SCI_INT_CLK,		/* Optional BRG Internal Clock Source */
+	SCI_SCIF_CLK,		/* Optional BRG External Clock Source */
 	SCI_NUM_CLKS
 };
 
@@ -1955,6 +1957,40 @@ static int sci_sck_calc(struct sci_port *s, unsigned int bps,
 	return min_err;
 }
 
+static int sci_brg_calc(struct sci_port *s, unsigned int bps,
+			unsigned long freq, unsigned int *dlr,
+			unsigned int *srr)
+{
+	unsigned int min_sr, max_sr, sr, dl;
+	int err, min_err = INT_MAX;
+
+	if (s->sampling_rate) {
+		/* SCIF has a fixed sampling rate */
+		min_sr = max_sr = s->sampling_rate / 2;
+	} else {
+		/* HSCIF has a variable 1/(8..32) sampling rate */
+		min_sr = 8;
+		max_sr = 32;
+	}
+
+	for (sr = max_sr; sr >= min_sr; sr--) {
+		dl = DIV_ROUND_CLOSEST(freq, sr * bps);
+		dl = clamp(dl, 1U, 65535U);
+
+		err = DIV_ROUND_CLOSEST(freq, sr * dl) - bps;
+		if (abs(err) >= abs(min_err))
+			continue;
+
+		min_err = err;
+		*dlr = dl;
+		*srr = sr - 1;
+	}
+
+	dev_dbg(s->port.dev, "BRG: %u%+d bps using DL %u SR %u\n", bps,
+		min_err, *dlr, *srr + 1);
+	return min_err;
+}
+
 /* calculate sample rate, BRR, and clock select */
 static int sci_scbrr_calc(struct sci_port *s, unsigned int bps,
 			  unsigned int *brr, unsigned int *srr,
@@ -2036,8 +2072,8 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 			    struct ktermios *old)
 {
 	unsigned int baud, smr_val = 0, scr_val = 0, i;
-	unsigned int brr = 255, cks = 0, srr = 15, sccks = 0;
-	unsigned int brr1 = 255, cks1 = 0, srr1 = 15;
+	unsigned int brr = 255, cks = 0, srr = 15, dl = 0, sccks = 0;
+	unsigned int brr1 = 255, cks1 = 0, srr1 = 15, dl1 = 0;
 	struct sci_port *s = to_sci_port(port);
 	const struct plat_sci_reg *reg;
 	int min_err = INT_MAX, err;
@@ -2089,6 +2125,38 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
 		}
 	}
 
+	/* Optional BRG External Clock Source */
+	if (s->clk_rates[SCI_SCIF_CLK] && sci_getreg(port, SCDL)->size) {
+		err = sci_brg_calc(s, baud, s->clk_rates[SCI_SCIF_CLK], &dl1,
+				   &srr1);
+		if (abs(err) < abs(min_err)) {
+			best_clk = SCI_SCIF_CLK;
+			scr_val = SCSCR_CKE1;
+			sccks = 0;
+			min_err = err;
+			dl = dl1;
+			srr = srr1;
+			if (!err)
+				goto done;
+		}
+	}
+
+	/* Optional BRG Internal Clock Source */
+	if (s->clk_rates[SCI_INT_CLK] && sci_getreg(port, SCDL)->size) {
+		err = sci_brg_calc(s, baud, s->clk_rates[SCI_INT_CLK], &dl1,
+				   &srr1);
+		if (abs(err) < abs(min_err)) {
+			best_clk = SCI_INT_CLK;
+			scr_val = SCSCR_CKE1;
+			sccks = SCCKS_XIN;
+			min_err = err;
+			dl = dl1;
+			srr = srr1;
+			if (!min_err)
+				goto done;
+		}
+	}
+
 	/* Functional Clock and standard Bit Rate Register */
 	err = sci_scbrr_calc(s, baud, &brr1, &srr1, &cks1);
 	if (abs(err) < abs(min_err)) {
@@ -2108,8 +2176,10 @@ done:
 	sci_port_enable(s);
 
 	/* Program the optional External Baud Rate Generator (BRG) first */
-	if (best_clk >= 0 && sci_getreg(port, SCCKS)->size)
+	if (best_clk >= 0 && sci_getreg(port, SCCKS)->size) {
+		serial_port_out(port, SCDL, dl);
 		serial_port_out(port, SCCKS, sccks);
+	}
 
 	sci_reset(port);
 
@@ -2118,8 +2188,8 @@ done:
 	if (best_clk >= 0) {
 		smr_val |= cks;
 		dev_dbg(port->dev,
-			 "SCR 0x%x SMR 0x%x BRR %u CKS 0x%x SRR %u\n",
-			 scr_val, smr_val, brr, sccks, srr);
+			 "SCR 0x%x SMR 0x%x BRR %u CKS 0x%x DL %u SRR %u\n",
+			 scr_val, smr_val, brr, sccks, dl, srr);
 		serial_port_out(port, SCSCR, scr_val);
 		serial_port_out(port, SCSMR, smr_val);
 		serial_port_out(port, SCBRR, brr);
@@ -2357,6 +2427,8 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
 	const char *clk_names[] = {
 		[SCI_FCK] = "fck",
 		[SCI_SCK] = "sck",
+		[SCI_INT_CLK] = "int_clk",
+		[SCI_SCIF_CLK] = "scif_clk",
 	};
 	struct clk *clk;
 	unsigned int i;
-- 
1.9.1

[PATCH 21/25] ARM: shmobile: r8a7791 dtsi: Add BRG support for (H)SCIF

[Geert Uytterhoeven]

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm/boot/dts/r8a7791.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 684120a0a479a8d0..20f0cacd3a79095b 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -670,8 +670,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -682,8 +683,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -694,8 +696,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -706,8 +709,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -718,8 +722,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -730,8 +735,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -742,8 +748,9 @@
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -754,8 +761,9 @@
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -766,8 +774,9 @@
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -1014,6 +1023,15 @@
 			status = "disabled";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* External USB clock - can be overridden by the board */
 		usb_extal_clk: usb_extal_clk {
 			compatible = "fixed-clock";
-- 
1.9.1

[PATCH 21/25] ARM: shmobile: r8a7791 dtsi: Add BRG support for (H)SCIF

[Geert Uytterhoeven]

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm/boot/dts/r8a7791.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 684120a0a479a8d0..20f0cacd3a79095b 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -670,8 +670,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -682,8 +683,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -694,8 +696,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -706,8 +709,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -718,8 +722,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -730,8 +735,9 @@
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -742,8 +748,9 @@
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -754,8 +761,9 @@
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -766,8 +774,9 @@
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "int_clk", "scif_clk";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -1014,6 +1023,15 @@
 			status = "disabled";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* External USB clock - can be overridden by the board */
 		usb_extal_clk: usb_extal_clk {
 			compatible = "fixed-clock";
-- 
1.9.1

[PATCH 22/25] ARM: shmobile: koelsch dts: Enable SCIF_CLK frequency and pins

[Geert Uytterhoeven]

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates:
  - SCIF:
      - Supports now 50, 75, 110, 1152000, 1500000, 2000000, and
        4000000 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
      - More accurate 576000 bps.
  - HSCIF:
      - Supports now 50, 75, 110, 134, 150, and 200 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
      - More accurate 576000, 1152000, 3000000, 3500000, and 4000000
	bps.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index da263dbb126db78c..9c3bc94791fc932a 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -320,6 +320,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2";
 		renesas,function = "i2c2";
@@ -340,6 +343,11 @@
 		renesas,function = "scif1";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -440,6 +448,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &sdhi0 {
 	pinctrl-0 = <&sdhi0_pins>;
 	pinctrl-names = "default";
-- 
1.9.1

[PATCH 22/25] ARM: shmobile: koelsch dts: Enable SCIF_CLK frequency and pins

[Geert Uytterhoeven]

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates:
  - SCIF:
      - Supports now 50, 75, 110, 1152000, 1500000, 2000000, and
        4000000 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
      - More accurate 576000 bps.
  - HSCIF:
      - Supports now 50, 75, 110, 134, 150, and 200 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
      - More accurate 576000, 1152000, 3000000, 3500000, and 4000000
	bps.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index da263dbb126db78c..9c3bc94791fc932a 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -320,6 +320,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2";
 		renesas,function = "i2c2";
@@ -340,6 +343,11 @@
 		renesas,function = "scif1";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -440,6 +448,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &sdhi0 {
 	pinctrl-0 = <&sdhi0_pins>;
 	pinctrl-names = "default";
-- 
1.9.1

[PATCH 23/25] arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF

[Geert Uytterhoeven]

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depend on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 74 ++++++++++++++++++++++----------
 1 file changed, 52 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 53a2a8fb42b7480c..25900761cfde201e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -84,6 +84,14 @@
 		status = "disabled";
 	};
 
+	/* External SCIF clock - to be overridden by boards that provide it */
+	scif_clk: scif {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <0>;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		interrupt-parent = <&gic>;
@@ -362,8 +370,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe6540000 0 96>;
 			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 520>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 520>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x31>, <&dmac1 0x30>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -374,8 +384,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe6550000 0 96>;
 			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 519>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 519>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x33>, <&dmac1 0x32>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -386,8 +398,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe6560000 0 96>;
 			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 518>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 518>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x35>, <&dmac1 0x34>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -398,8 +412,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe66a0000 0 96>;
 			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 517>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 517>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac0 0x37>, <&dmac0 0x36>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -410,8 +426,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe66b0000 0 96>;
 			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 516>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 516>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac0 0x39>, <&dmac0 0x38>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -422,8 +440,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6e60000 0 64>;
 			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 207>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 207>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x51>, <&dmac1 0x50>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -434,8 +454,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6e68000 0 64>;
 			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 206>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 206>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x53>, <&dmac1 0x52>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -446,8 +468,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6e88000 0 64>;
 			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 310>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 310>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x13>, <&dmac1 0x12>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -458,8 +482,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6c50000 0 64>;
 			interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 204>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 204>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac0 0x57>, <&dmac0 0x56>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -470,8 +496,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6c40000 0 64>;
 			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 203>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 203>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac0 0x59>, <&dmac0 0x58>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -482,8 +510,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6f30000 0 64>;
 			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 202>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 202>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x5b>, <&dmac1 0x5a>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
-- 
1.9.1

[PATCH 23/25] arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF

[Geert Uytterhoeven]

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depend on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 74 ++++++++++++++++++++++----------
 1 file changed, 52 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 53a2a8fb42b7480c..25900761cfde201e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -84,6 +84,14 @@
 		status = "disabled";
 	};
 
+	/* External SCIF clock - to be overridden by boards that provide it */
+	scif_clk: scif {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <0>;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		interrupt-parent = <&gic>;
@@ -362,8 +370,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe6540000 0 96>;
 			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 520>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 520>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x31>, <&dmac1 0x30>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -374,8 +384,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe6550000 0 96>;
 			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 519>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 519>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x33>, <&dmac1 0x32>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -386,8 +398,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe6560000 0 96>;
 			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 518>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 518>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x35>, <&dmac1 0x34>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -398,8 +412,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe66a0000 0 96>;
 			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 517>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 517>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac0 0x37>, <&dmac0 0x36>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -410,8 +426,10 @@
 			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
 			reg = <0 0xe66b0000 0 96>;
 			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 516>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 516>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac0 0x39>, <&dmac0 0x38>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -422,8 +440,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6e60000 0 64>;
 			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 207>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 207>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x51>, <&dmac1 0x50>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -434,8 +454,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6e68000 0 64>;
 			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 206>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 206>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x53>, <&dmac1 0x52>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -446,8 +468,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6e88000 0 64>;
 			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 310>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 310>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x13>, <&dmac1 0x12>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -458,8 +482,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6c50000 0 64>;
 			interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 204>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 204>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac0 0x57>, <&dmac0 0x56>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -470,8 +496,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6c40000 0 64>;
 			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 203>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 203>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac0 0x59>, <&dmac0 0x58>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -482,8 +510,10 @@
 			compatible = "renesas,scif-r8a7795", "renesas,scif";
 			reg = <0 0xe6f30000 0 64>;
 			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 202>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 202>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "int_clk", "scif_clk";
 			dmas = <&dmac1 0x5b>, <&dmac1 0x5a>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
-- 
1.9.1

Re: [PATCH 23/25] arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:39:02 Geert Uytterhoeven wrote:
> Add the device node for the external SCIF_CLK.
> The presence of the SCIF_CLK crystal and its clock frequency depend on
> the actual board.
> 
> Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
> resp. external clock) for the Baud Rate Generator for External Clock
> (BRG) to all SCIF and HSCIF device nodes.
> 
> This increases the range and accuracy of supported baud rates on
> (H)SCIF.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 74 +++++++++++++++++++----------
>  1 file changed, 52 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index
> 53a2a8fb42b7480c..25900761cfde201e 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -84,6 +84,14 @@
>  		status = "disabled";
>  	};
> 
> +	/* External SCIF clock - to be overridden by boards that provide it */
> +	scif_clk: scif {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <0>;
> +		status = "disabled";
> +	};

I have mixed feelings about this. Defining an external clock that isn't 
present on the board isn't very clean, even more so when the clock has such a 
generic name. Wouldn't it be better to let board files define the clock when 
they need it ? I know it would require board files to override the clocks and 
clock-names property too. Maybe we need to extend the DTS syntax to allow 
extending list properties instead of overriding them completely ?

>  	soc {
>  		compatible = "simple-bus";
>  		interrupt-parent = <&gic>;
> @@ -362,8 +370,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe6540000 0 96>;
>  			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 520>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 520>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x31>, <&dmac1 0x30>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -374,8 +384,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe6550000 0 96>;
>  			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 519>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 519>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x33>, <&dmac1 0x32>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -386,8 +398,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe6560000 0 96>;
>  			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 518>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 518>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x35>, <&dmac1 0x34>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -398,8 +412,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe66a0000 0 96>;
>  			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 517>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 517>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac0 0x37>, <&dmac0 0x36>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -410,8 +426,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe66b0000 0 96>;
>  			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 516>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 516>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac0 0x39>, <&dmac0 0x38>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -422,8 +440,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6e60000 0 64>;
>  			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 207>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 207>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x51>, <&dmac1 0x50>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -434,8 +454,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6e68000 0 64>;
>  			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 206>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 206>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x53>, <&dmac1 0x52>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -446,8 +468,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6e88000 0 64>;
>  			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 310>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 310>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x13>, <&dmac1 0x12>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -458,8 +482,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6c50000 0 64>;
>  			interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 204>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 204>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac0 0x57>, <&dmac0 0x56>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -470,8 +496,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6c40000 0 64>;
>  			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 203>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 203>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac0 0x59>, <&dmac0 0x58>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -482,8 +510,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6f30000 0 64>;
>  			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 202>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 202>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x5b>, <&dmac1 0x5a>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH 23/25] arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:39:02 Geert Uytterhoeven wrote:
> Add the device node for the external SCIF_CLK.
> The presence of the SCIF_CLK crystal and its clock frequency depend on
> the actual board.
> 
> Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
> resp. external clock) for the Baud Rate Generator for External Clock
> (BRG) to all SCIF and HSCIF device nodes.
> 
> This increases the range and accuracy of supported baud rates on
> (H)SCIF.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 74 +++++++++++++++++++----------
>  1 file changed, 52 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index
> 53a2a8fb42b7480c..25900761cfde201e 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -84,6 +84,14 @@
>  		status = "disabled";
>  	};
> 
> +	/* External SCIF clock - to be overridden by boards that provide it */
> +	scif_clk: scif {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <0>;
> +		status = "disabled";
> +	};

I have mixed feelings about this. Defining an external clock that isn't 
present on the board isn't very clean, even more so when the clock has such a 
generic name. Wouldn't it be better to let board files define the clock when 
they need it ? I know it would require board files to override the clocks and 
clock-names property too. Maybe we need to extend the DTS syntax to allow 
extending list properties instead of overriding them completely ?

>  	soc {
>  		compatible = "simple-bus";
>  		interrupt-parent = <&gic>;
> @@ -362,8 +370,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe6540000 0 96>;
>  			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 520>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 520>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x31>, <&dmac1 0x30>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -374,8 +384,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe6550000 0 96>;
>  			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 519>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 519>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x33>, <&dmac1 0x32>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -386,8 +398,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe6560000 0 96>;
>  			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 518>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 518>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x35>, <&dmac1 0x34>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -398,8 +412,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe66a0000 0 96>;
>  			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 517>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 517>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac0 0x37>, <&dmac0 0x36>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -410,8 +426,10 @@
>  			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
>  			reg = <0 0xe66b0000 0 96>;
>  			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 516>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 516>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac0 0x39>, <&dmac0 0x38>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -422,8 +440,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6e60000 0 64>;
>  			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 207>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 207>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x51>, <&dmac1 0x50>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -434,8 +454,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6e68000 0 64>;
>  			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 206>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 206>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x53>, <&dmac1 0x52>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -446,8 +468,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6e88000 0 64>;
>  			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 310>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 310>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x13>, <&dmac1 0x12>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -458,8 +482,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6c50000 0 64>;
>  			interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 204>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 204>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac0 0x57>, <&dmac0 0x56>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -470,8 +496,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6c40000 0 64>;
>  			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 203>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 203>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac0 0x59>, <&dmac0 0x58>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;
> @@ -482,8 +510,10 @@
>  			compatible = "renesas,scif-r8a7795", "renesas,scif";
>  			reg = <0 0xe6f30000 0 64>;
>  			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 202>;
> -			clock-names = "fck";
> +			clocks = <&cpg CPG_MOD 202>,
> +				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
> +				 <&scif_clk>;
> +			clock-names = "fck", "int_clk", "scif_clk";
>  			dmas = <&dmac1 0x5b>, <&dmac1 0x5a>;
>  			dma-names = "tx", "rx";
>  			power-domains = <&cpg>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH 23/25] arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:07 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:39:02 Geert Uytterhoeven wrote:
>> Add the device node for the external SCIF_CLK.
>> The presence of the SCIF_CLK crystal and its clock frequency depend on
>> the actual board.
>>
>> Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
>> resp. external clock) for the Baud Rate Generator for External Clock
>> (BRG) to all SCIF and HSCIF device nodes.
>>
>> This increases the range and accuracy of supported baud rates on
>> (H)SCIF.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 74 +++++++++++++++++++----------
>>  1 file changed, 52 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index
>> 53a2a8fb42b7480c..25900761cfde201e 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -84,6 +84,14 @@
>>               status = "disabled";
>>       };
>>
>> +     /* External SCIF clock - to be overridden by boards that provide it */
>> +     scif_clk: scif {
>> +             compatible = "fixed-clock";
>> +             #clock-cells = <0>;
>> +             clock-frequency = <0>;
>> +             status = "disabled";
>> +     };
>
> I have mixed feelings about this. Defining an external clock that isn't
> present on the board isn't very clean, even more so when the clock has such a

We have precedence of optional external clocks (can_clk, audio_clk_*).
The SoC datasheet clearly calls it "scif_clk", so that makes it an ABI, IMHO.

> generic name. Wouldn't it be better to let board files define the clock when
> they need it ? I know it would require board files to override the clocks and
> clock-names property too. Maybe we need to extend the DTS syntax to allow
> extending list properties instead of overriding them completely ?

As scif_clk is shared between all (H)SCIF instances, that would mean overriding
the clock and clock-names for all of them, which is quite a tedious task.
Most boards seem to provide a SCIF_CLK, to allow having "perfect" standard
baud rates.

Combined all of the above, I think it's sufficiently generic to keep
it that way.

Note that it's different for (H)SCK: these are per-(H)SCIF inputs, and depend
even more on board layout. Adding individual zero-frequency clock nodes for
them would preclude e.g. connecting all (H)SCK inputs to the same crystal.
Hence I didn't add them, and you do have to override all clocks and
clock-names of a node if you want to add an (H)SCK clock input (been there,
done that for testing; long live DT overlays).

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 23/25] arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:07 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:39:02 Geert Uytterhoeven wrote:
>> Add the device node for the external SCIF_CLK.
>> The presence of the SCIF_CLK crystal and its clock frequency depend on
>> the actual board.
>>
>> Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
>> resp. external clock) for the Baud Rate Generator for External Clock
>> (BRG) to all SCIF and HSCIF device nodes.
>>
>> This increases the range and accuracy of supported baud rates on
>> (H)SCIF.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 74 +++++++++++++++++++----------
>>  1 file changed, 52 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index
>> 53a2a8fb42b7480c..25900761cfde201e 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -84,6 +84,14 @@
>>               status = "disabled";
>>       };
>>
>> +     /* External SCIF clock - to be overridden by boards that provide it */
>> +     scif_clk: scif {
>> +             compatible = "fixed-clock";
>> +             #clock-cells = <0>;
>> +             clock-frequency = <0>;
>> +             status = "disabled";
>> +     };
>
> I have mixed feelings about this. Defining an external clock that isn't
> present on the board isn't very clean, even more so when the clock has such a

We have precedence of optional external clocks (can_clk, audio_clk_*).
The SoC datasheet clearly calls it "scif_clk", so that makes it an ABI, IMHO.

> generic name. Wouldn't it be better to let board files define the clock when
> they need it ? I know it would require board files to override the clocks and
> clock-names property too. Maybe we need to extend the DTS syntax to allow
> extending list properties instead of overriding them completely ?

As scif_clk is shared between all (H)SCIF instances, that would mean overriding
the clock and clock-names for all of them, which is quite a tedious task.
Most boards seem to provide a SCIF_CLK, to allow having "perfect" standard
baud rates.

Combined all of the above, I think it's sufficiently generic to keep
it that way.

Note that it's different for (H)SCK: these are per-(H)SCIF inputs, and depend
even more on board layout. Adding individual zero-frequency clock nodes for
them would preclude e.g. connecting all (H)SCK inputs to the same crystal.
Hence I didn't add them, and you do have to override all clocks and
clock-names of a node if you want to add an (H)SCK clock input (been there,
done that for testing; long live DT overlays).

Gr{oetje,eeting}s,

                        Geert

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

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

[PATCH 24/25] arm64: renesas: salvator-x dts: Enable SCIF_CLK frequency and pins

[Geert Uytterhoeven]

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates:
  - SCIF:
      - Supports now 50, 230400, 460800, 500000, and 921600 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
  - HSCIF:
      - Supports now 50, 75, and 110 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index afbd5256806e7014..0b38fecb1c5d75e9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -127,6 +127,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif1_pins: scif1 {
 		renesas,groups = "scif1_data_a", "scif1_ctrl";
 		renesas,function = "scif1";
@@ -135,6 +138,10 @@
 		renesas,groups = "scif2_data_a";
 		renesas,function = "scif2";
 	};
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk_a";
+		renesas,function = "scif_clk";
+	};
 
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2_a";
@@ -172,6 +179,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &rcar_sound {
 	pinctrl-0 = <&sound_pins &sound_clk_pins>;
 	pinctrl-names = "default";
-- 
1.9.1

[PATCH 24/25] arm64: renesas: salvator-x dts: Enable SCIF_CLK frequency and pins

[Geert Uytterhoeven]

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates:
  - SCIF:
      - Supports now 50, 230400, 460800, 500000, and 921600 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
  - HSCIF:
      - Supports now 50, 75, and 110 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index afbd5256806e7014..0b38fecb1c5d75e9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -127,6 +127,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif1_pins: scif1 {
 		renesas,groups = "scif1_data_a", "scif1_ctrl";
 		renesas,function = "scif1";
@@ -135,6 +138,10 @@
 		renesas,groups = "scif2_data_a";
 		renesas,function = "scif2";
 	};
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk_a";
+		renesas,function = "scif_clk";
+	};
 
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2_a";
@@ -172,6 +179,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &rcar_sound {
 	pinctrl-0 = <&sound_pins &sound_clk_pins>;
 	pinctrl-names = "default";
-- 
1.9.1

[PATCH 25/25] sh: sh7734: Correct SCIF type for BRG

[Geert Uytterhoeven]

The SCIF variant in the sh7734 SoC is not the common "SH-4(A)" variant,
but a derivative with added "Baud Rate Generator for External Clock"
(BRG). Correct the regtype value in platform data to fix this.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Untested due to lack of hardware and platform clock support.
---
 arch/sh/kernel/cpu/sh4a/setup-sh7734.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7734.c b/arch/sh/kernel/cpu/sh4a/setup-sh7734.c
index f617bcb734dfeb76..69b8a50310d9a23f 100644
--- a/arch/sh/kernel/cpu/sh4a/setup-sh7734.c
+++ b/arch/sh/kernel/cpu/sh4a/setup-sh7734.c
@@ -28,7 +28,7 @@ static struct plat_sci_port scif0_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif0_resources[] = {
@@ -50,7 +50,7 @@ static struct plat_sci_port scif1_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif1_resources[] = {
@@ -72,7 +72,7 @@ static struct plat_sci_port scif2_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif2_resources[] = {
@@ -94,7 +94,7 @@ static struct plat_sci_port scif3_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE | SCSCR_TOIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif3_resources[] = {
@@ -116,7 +116,7 @@ static struct plat_sci_port scif4_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif4_resources[] = {
@@ -138,7 +138,7 @@ static struct plat_sci_port scif5_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype		= SCIx_SH4_SCIF_REGTYPE,
+	.regtype	= SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif5_resources[] = {
-- 
1.9.1

[PATCH 25/25] sh: sh7734: Correct SCIF type for BRG

[Geert Uytterhoeven]

The SCIF variant in the sh7734 SoC is not the common "SH-4(A)" variant,
but a derivative with added "Baud Rate Generator for External Clock"
(BRG). Correct the regtype value in platform data to fix this.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Untested due to lack of hardware and platform clock support.
---
 arch/sh/kernel/cpu/sh4a/setup-sh7734.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7734.c b/arch/sh/kernel/cpu/sh4a/setup-sh7734.c
index f617bcb734dfeb76..69b8a50310d9a23f 100644
--- a/arch/sh/kernel/cpu/sh4a/setup-sh7734.c
+++ b/arch/sh/kernel/cpu/sh4a/setup-sh7734.c
@@ -28,7 +28,7 @@ static struct plat_sci_port scif0_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif0_resources[] = {
@@ -50,7 +50,7 @@ static struct plat_sci_port scif1_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif1_resources[] = {
@@ -72,7 +72,7 @@ static struct plat_sci_port scif2_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif2_resources[] = {
@@ -94,7 +94,7 @@ static struct plat_sci_port scif3_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE | SCSCR_TOIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif3_resources[] = {
@@ -116,7 +116,7 @@ static struct plat_sci_port scif4_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype        = SCIx_SH4_SCIF_REGTYPE,
+	.regtype        = SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif4_resources[] = {
@@ -138,7 +138,7 @@ static struct plat_sci_port scif5_platform_data = {
 	.flags          = UPF_BOOT_AUTOCONF,
 	.scscr          = SCSCR_RE | SCSCR_TE | SCSCR_REIE,
 	.type           = PORT_SCIF,
-	.regtype		= SCIx_SH4_SCIF_REGTYPE,
+	.regtype	= SCIx_SH4_SCIF_BRG_REGTYPE,
 };
 
 static struct resource scif5_resources[] = {
-- 
1.9.1

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Laurent Pinchart]

Hi Geert,

Thank you for the patches.

For patches 3-6, 13, 15-16 and 22 and 24,

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

I'm not sure I'd bother with patch 25/25, but I'm not against merging it 
either. I'd be surprised if the serial driver still worked at all on SH :-)

On Thursday 19 November 2015 19:38:39 Geert Uytterhoeven wrote:
> 	Hi,
> 
> This patch series adds support to the Renesas SCI serial driver for
>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>     pin can serve as a clock input,
>   - the optional clock sources for the Baud Rate Generator for External
>     Clock (BRG), as found on some SCIF variants and on HSCIF.

Could you briefly explain (and even better in a source code comment) how you 
handle baud rate calculation with the chained BRGs ?

> Using external clocks increases the range and accuracy of supported baud
> rates. Please see the descriptions of the DTS patches for more detailed
> information regarding the impact on the supported platforms.
> 
> For now this supports r8a7791/koelsch and r8a7795/salvator-x only, which
> have an external SCIF_CLK running at 14.7456 MHz.
> Support for other R-Car platforms will be added later.
> 
> Testing:
>   - The Baud Rate Generator for External Clock (BRG) was tested with
>     SCIF and HSCIF on r8a7791/koelsch and r8a7795/salvator-x,
>   - The external clock input on (H)SCK was tested on r8a7795/salvator-x
>     by feeding an external clock signal to (H)SCIF1,
>   - Various bit rates were monitored using a SmartScope,
>   - Regression testing was done on Renesas ARM platforms that use SCIFA
>     as the console (r8a73a4/ape6evm, r8a7740/armadillo, and
>     sh73a0/kzm9g).
> 
> Dependencies:
>   - This series depends on the series "[PATCH v2 00/16] serial: sh-sci:
>     Clock Cleanups",
>   - The SH patch 25 depends on the "serial: sh-sci" patches in this
>     series,
>   - The DTS patches 21-24 can be applied independently, once the DT
>     binding patches 1-2 are accepted,
>   - r8a7791/r8a7795 has a runtime dependency on series "[PATCH 0/2]
>     pinctrl: sh-pfc: r8a7791/r8a7795: Add SCIF_CLK support",
>   - r8a7795 also depends on
>        - platform support in e.g. renesas-drivers-2015-11-17-v4.4-rc1,
>        - "[PATCH] pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups, and
> 	 functions",
>        - "[PATCH] arm64: renesas: r8a7795 dtsi: Add all HSCIF nodes".
>   - Legacy SH has a runtime dependency on:
>       - series "[PATCH 0/2] drivers: sh: clk: Cleanup clock API",
> 
> Thanks for your comments!
> 
> Geert Uytterhoeven (25):
>   serial: sh-sci: Update DT binding documentation for external clock
>     input
>   serial: sh-sci: Update DT binding documentation for BRG support
>   serial: sh-sci: Drop useless check for zero sampling_rate
>   serial: sh-sci: Grammar s/Get ... for/Get ... from/
>   serial: sh-sci: Drop unused frame_len parameter for
>     sci_baud_calc_hscif()
>   serial: sh-sci: Don't overwrite clock selection in
>     serial_console_write()
>   serial: sh-sci: Convert from clk_get() to devm_clk_get()
>   serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned
>   serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()
>   serial: sh-sci: Improve bit rate error calculation for HSCIF
>   serial: sh-sci: Avoid calculating the receive margin for HSCIF
>   serial: sh-sci: Merge sci_scbrr_calc() and sci_baud_calc_hscif()
>   serial: sh-sci: Take into account sampling rate for max baud rate
>   serial: sh-sci: Add BRG register definitions
>   serial: sh-sci: Replace struct sci_port_info by type/regtype encoding
>   serial: sh-sci: Correct SCIF type on RZ/A1H
>   serial: sh-sci: Correct SCIF type on R-Car for BRG
>   serial: sh-sci: Prepare for multiple clocks and baud rate generators
>   serial: sh-sci: Add support for optional external (H)SCK input
>   serial: sh-sci: Add support for optional BRG on (H)SCIF
>   ARM: shmobile: r8a7791 dtsi: Add BRG support for (H)SCIF
>   ARM: shmobile: koelsch dts: Enable SCIF_CLK frequency and pins
>   arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF
>   arm64: renesas: salvator-x dts: Enable SCIF_CLK frequency and pins
>   sh: sh7734: Correct SCIF type for BRG
> 
>  .../bindings/serial/renesas,sci-serial.txt         |   9 +
>  arch/arm/boot/dts/r8a7791-koelsch.dts              |  13 +
>  arch/arm/boot/dts/r8a7791.dtsi                     |  54 ++-
>  arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  12 +
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi           |  74 ++-
>  arch/sh/kernel/cpu/sh4a/setup-sh7734.c             |  12 +-
>  drivers/tty/serial/sh-sci.c                        | 530 ++++++++++++------
>  drivers/tty/serial/sh-sci.h                        |   5 +
>  include/linux/serial_sci.h                         |   1 +
>  9 files changed, 508 insertions(+), 202 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Laurent Pinchart]

Hi Geert,

Thank you for the patches.

For patches 3-6, 13, 15-16 and 22 and 24,

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

I'm not sure I'd bother with patch 25/25, but I'm not against merging it 
either. I'd be surprised if the serial driver still worked at all on SH :-)

On Thursday 19 November 2015 19:38:39 Geert Uytterhoeven wrote:
> 	Hi,
> 
> This patch series adds support to the Renesas SCI serial driver for
>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>     pin can serve as a clock input,
>   - the optional clock sources for the Baud Rate Generator for External
>     Clock (BRG), as found on some SCIF variants and on HSCIF.

Could you briefly explain (and even better in a source code comment) how you 
handle baud rate calculation with the chained BRGs ?

> Using external clocks increases the range and accuracy of supported baud
> rates. Please see the descriptions of the DTS patches for more detailed
> information regarding the impact on the supported platforms.
> 
> For now this supports r8a7791/koelsch and r8a7795/salvator-x only, which
> have an external SCIF_CLK running at 14.7456 MHz.
> Support for other R-Car platforms will be added later.
> 
> Testing:
>   - The Baud Rate Generator for External Clock (BRG) was tested with
>     SCIF and HSCIF on r8a7791/koelsch and r8a7795/salvator-x,
>   - The external clock input on (H)SCK was tested on r8a7795/salvator-x
>     by feeding an external clock signal to (H)SCIF1,
>   - Various bit rates were monitored using a SmartScope,
>   - Regression testing was done on Renesas ARM platforms that use SCIFA
>     as the console (r8a73a4/ape6evm, r8a7740/armadillo, and
>     sh73a0/kzm9g).
> 
> Dependencies:
>   - This series depends on the series "[PATCH v2 00/16] serial: sh-sci:
>     Clock Cleanups",
>   - The SH patch 25 depends on the "serial: sh-sci" patches in this
>     series,
>   - The DTS patches 21-24 can be applied independently, once the DT
>     binding patches 1-2 are accepted,
>   - r8a7791/r8a7795 has a runtime dependency on series "[PATCH 0/2]
>     pinctrl: sh-pfc: r8a7791/r8a7795: Add SCIF_CLK support",
>   - r8a7795 also depends on
>        - platform support in e.g. renesas-drivers-2015-11-17-v4.4-rc1,
>        - "[PATCH] pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups, and
> 	 functions",
>        - "[PATCH] arm64: renesas: r8a7795 dtsi: Add all HSCIF nodes".
>   - Legacy SH has a runtime dependency on:
>       - series "[PATCH 0/2] drivers: sh: clk: Cleanup clock API",
> 
> Thanks for your comments!
> 
> Geert Uytterhoeven (25):
>   serial: sh-sci: Update DT binding documentation for external clock
>     input
>   serial: sh-sci: Update DT binding documentation for BRG support
>   serial: sh-sci: Drop useless check for zero sampling_rate
>   serial: sh-sci: Grammar s/Get ... for/Get ... from/
>   serial: sh-sci: Drop unused frame_len parameter for
>     sci_baud_calc_hscif()
>   serial: sh-sci: Don't overwrite clock selection in
>     serial_console_write()
>   serial: sh-sci: Convert from clk_get() to devm_clk_get()
>   serial: sh-sci: Make unsigned values in sci_baud_calc_hscif() unsigned
>   serial: sh-sci: Avoid overflow in sci_baud_calc_hscif()
>   serial: sh-sci: Improve bit rate error calculation for HSCIF
>   serial: sh-sci: Avoid calculating the receive margin for HSCIF
>   serial: sh-sci: Merge sci_scbrr_calc() and sci_baud_calc_hscif()
>   serial: sh-sci: Take into account sampling rate for max baud rate
>   serial: sh-sci: Add BRG register definitions
>   serial: sh-sci: Replace struct sci_port_info by type/regtype encoding
>   serial: sh-sci: Correct SCIF type on RZ/A1H
>   serial: sh-sci: Correct SCIF type on R-Car for BRG
>   serial: sh-sci: Prepare for multiple clocks and baud rate generators
>   serial: sh-sci: Add support for optional external (H)SCK input
>   serial: sh-sci: Add support for optional BRG on (H)SCIF
>   ARM: shmobile: r8a7791 dtsi: Add BRG support for (H)SCIF
>   ARM: shmobile: koelsch dts: Enable SCIF_CLK frequency and pins
>   arm64: renesas: r8a7795 dtsi: Add BRG support for (H)SCIF
>   arm64: renesas: salvator-x dts: Enable SCIF_CLK frequency and pins
>   sh: sh7734: Correct SCIF type for BRG
> 
>  .../bindings/serial/renesas,sci-serial.txt         |   9 +
>  arch/arm/boot/dts/r8a7791-koelsch.dts              |  13 +
>  arch/arm/boot/dts/r8a7791.dtsi                     |  54 ++-
>  arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  12 +
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi           |  74 ++-
>  arch/sh/kernel/cpu/sh4a/setup-sh7734.c             |  12 +-
>  drivers/tty/serial/sh-sci.c                        | 530 ++++++++++++------
>  drivers/tty/serial/sh-sci.h                        |   5 +
>  include/linux/serial_sci.h                         |   1 +
>  9 files changed, 508 insertions(+), 202 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> For patches 3-6, 13, 15-16 and 22 and 24,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Many thanks for your review comments!

> I'm not sure I'd bother with patch 25/25, but I'm not against merging it
> either. I'd be surprised if the serial driver still worked at all on SH :-)

It should not cause problems, as long as sh7734 doesn't add the optional
clocks ;-)

> On Thursday 19 November 2015 19:38:39 Geert Uytterhoeven wrote:
>> This patch series adds support to the Renesas SCI serial driver for
>>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>>     pin can serve as a clock input,
>>   - the optional clock sources for the Baud Rate Generator for External
>>     Clock (BRG), as found on some SCIF variants and on HSCIF.
>
> Could you briefly explain (and even better in a source code comment) how you
> handle baud rate calculation with the chained BRGs ?

I'll do that. Note that there's no chaining of BRGs, only muxing (so yes, it
needs more clarification ;-).

There can be 4 possible sources for the sampling clock:
  1. Internal BRG (BRR register),
  2. (H)SCK,
  3. BRG for external clock
      a. Using SCIF_CLK,
      b. Using the bus clock.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> For patches 3-6, 13, 15-16 and 22 and 24,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Many thanks for your review comments!

> I'm not sure I'd bother with patch 25/25, but I'm not against merging it
> either. I'd be surprised if the serial driver still worked at all on SH :-)

It should not cause problems, as long as sh7734 doesn't add the optional
clocks ;-)

> On Thursday 19 November 2015 19:38:39 Geert Uytterhoeven wrote:
>> This patch series adds support to the Renesas SCI serial driver for
>>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>>     pin can serve as a clock input,
>>   - the optional clock sources for the Baud Rate Generator for External
>>     Clock (BRG), as found on some SCIF variants and on HSCIF.
>
> Could you briefly explain (and even better in a source code comment) how you
> handle baud rate calculation with the chained BRGs ?

I'll do that. Note that there's no chaining of BRGs, only muxing (so yes, it
needs more clarification ;-).

There can be 4 possible sources for the sampling clock:
  1. Internal BRG (BRR register),
  2. (H)SCK,
  3. BRG for external clock
      a. Using SCIF_CLK,
      b. Using the bus clock.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 09:22:16 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart wrote:
> > For patches 3-6, 13, 15-16 and 22 and 24,
> > 
> > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 
> Many thanks for your review comments!

You're welcome.

> > I'm not sure I'd bother with patch 25/25, but I'm not against merging it
> > either. I'd be surprised if the serial driver still worked at all on SH
> > :-)
> 
> It should not cause problems, as long as sh7734 doesn't add the optional
> clocks ;-)

To be clear I don't expect this patch set to break it, I expect it to be 
broken already :-)

> > On Thursday 19 November 2015 19:38:39 Geert Uytterhoeven wrote:
> >> This patch series adds support to the Renesas SCI serial driver for
> >> 
> >>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
> >>   
> >>     pin can serve as a clock input,
> >>   
> >>   - the optional clock sources for the Baud Rate Generator for External
> >>   
> >>     Clock (BRG), as found on some SCIF variants and on HSCIF.
> > 
> > Could you briefly explain (and even better in a source code comment) how
> > you handle baud rate calculation with the chained BRGs ?
> 
> I'll do that. Note that there's no chaining of BRGs, only muxing (so yes, it
> needs more clarification ;-).

Really ? I thought the BRG-EC was one possible input for the internal BRG ? 
Does it bypass the internal BRG ? Or do you configure the internal BRG to not 
divide the clock when using the BRG-EC ?

> There can be 4 possible sources for the sampling clock:
>   1. Internal BRG (BRR register),
>   2. (H)SCK,
>   3. BRG for external clock
>       a. Using SCIF_CLK,
>       b. Using the bus clock.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 09:22:16 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart wrote:
> > For patches 3-6, 13, 15-16 and 22 and 24,
> > 
> > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 
> Many thanks for your review comments!

You're welcome.

> > I'm not sure I'd bother with patch 25/25, but I'm not against merging it
> > either. I'd be surprised if the serial driver still worked at all on SH
> > :-)
> 
> It should not cause problems, as long as sh7734 doesn't add the optional
> clocks ;-)

To be clear I don't expect this patch set to break it, I expect it to be 
broken already :-)

> > On Thursday 19 November 2015 19:38:39 Geert Uytterhoeven wrote:
> >> This patch series adds support to the Renesas SCI serial driver for
> >> 
> >>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
> >>   
> >>     pin can serve as a clock input,
> >>   
> >>   - the optional clock sources for the Baud Rate Generator for External
> >>   
> >>     Clock (BRG), as found on some SCIF variants and on HSCIF.
> > 
> > Could you briefly explain (and even better in a source code comment) how
> > you handle baud rate calculation with the chained BRGs ?
> 
> I'll do that. Note that there's no chaining of BRGs, only muxing (so yes, it
> needs more clarification ;-).

Really ? I thought the BRG-EC was one possible input for the internal BRG ? 
Does it bypass the internal BRG ? Or do you configure the internal BRG to not 
divide the clock when using the BRG-EC ?

> There can be 4 possible sources for the sampling clock:
>   1. Internal BRG (BRR register),
>   2. (H)SCK,
>   3. BRG for external clock
>       a. Using SCIF_CLK,
>       b. Using the bus clock.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Nov 20, 2015 at 9:58 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 09:22:16 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart wrote:
>> > Could you briefly explain (and even better in a source code comment) how
>> > you handle baud rate calculation with the chained BRGs ?
>>
>> I'll do that. Note that there's no chaining of BRGs, only muxing (so yes, it
>> needs more clarification ;-).
>
> Really ? I thought the BRG-EC was one possible input for the internal BRG ?
> Does it bypass the internal BRG ? Or do you configure the internal BRG to not
> divide the clock when using the BRG-EC ?

Yes, it's bypassed.

Cfr. SCSCR.CKE[1:0].
'00' means internal BRG (although the docs state P divided by 1/4/16/64),
'10' means SCK or SC_CLK (SCIF_CLK/INT_CLK).

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Nov 20, 2015 at 9:58 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 09:22:16 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart wrote:
>> > Could you briefly explain (and even better in a source code comment) how
>> > you handle baud rate calculation with the chained BRGs ?
>>
>> I'll do that. Note that there's no chaining of BRGs, only muxing (so yes, it
>> needs more clarification ;-).
>
> Really ? I thought the BRG-EC was one possible input for the internal BRG ?
> Does it bypass the internal BRG ? Or do you configure the internal BRG to not
> divide the clock when using the BRG-EC ?

Yes, it's bypassed.

Cfr. SCSCR.CKE[1:0].
'00' means internal BRG (although the docs state P divided by 1/4/16/64),
'10' means SCK or SC_CLK (SCIF_CLK/INT_CLK).

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 10:07:31 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 9:58 AM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 09:22:16 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart wrote:
> >>> Could you briefly explain (and even better in a source code comment)
> >>> how you handle baud rate calculation with the chained BRGs ?
> >> 
> >> I'll do that. Note that there's no chaining of BRGs, only muxing (so yes,
> >> it needs more clarification ;-).
> > 
> > Really ? I thought the BRG-EC was one possible input for the internal BRG
> > ? Does it bypass the internal BRG ? Or do you configure the internal BRG
> > to not divide the clock when using the BRG-EC ?
> 
> Yes, it's bypassed.
> 
> Cfr. SCSCR.CKE[1:0].
> '00' means internal BRG (although the docs state P divided by 1/4/16/64),
> '10' means SCK or SC_CLK (SCIF_CLK/INT_CLK).

That's indeed simpler. Could you capture the behaviour in a source code 
comment ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Laurent Pinchart]

Hi Geert,

On Friday 20 November 2015 10:07:31 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 9:58 AM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 09:22:16 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart wrote:
> >>> Could you briefly explain (and even better in a source code comment)
> >>> how you handle baud rate calculation with the chained BRGs ?
> >> 
> >> I'll do that. Note that there's no chaining of BRGs, only muxing (so yes,
> >> it needs more clarification ;-).
> > 
> > Really ? I thought the BRG-EC was one possible input for the internal BRG
> > ? Does it bypass the internal BRG ? Or do you configure the internal BRG
> > to not divide the clock when using the BRG-EC ?
> 
> Yes, it's bypassed.
> 
> Cfr. SCSCR.CKE[1:0].
> '00' means internal BRG (although the docs state P divided by 1/4/16/64),
> '10' means SCK or SC_CLK (SCIF_CLK/INT_CLK).

That's indeed simpler. Could you capture the behaviour in a source code 
comment ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

On Fri, Nov 20, 2015 at 3:50 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 10:07:31 Geert Uytterhoeven wrote:
>> On Fri, Nov 20, 2015 at 9:58 AM, Laurent Pinchart wrote:
>> > On Friday 20 November 2015 09:22:16 Geert Uytterhoeven wrote:
>> >> On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart wrote:
>> >>> Could you briefly explain (and even better in a source code comment)
>> >>> how you handle baud rate calculation with the chained BRGs ?
>> >>
>> >> I'll do that. Note that there's no chaining of BRGs, only muxing (so yes,
>> >> it needs more clarification ;-).
>> >
>> > Really ? I thought the BRG-EC was one possible input for the internal BRG
>> > ? Does it bypass the internal BRG ? Or do you configure the internal BRG
>> > to not divide the clock when using the BRG-EC ?
>>
>> Yes, it's bypassed.
>>
>> Cfr. SCSCR.CKE[1:0].
>> '00' means internal BRG (although the docs state P divided by 1/4/16/64),
>> '10' means SCK or SC_CLK (SCIF_CLK/INT_CLK).
>
> That's indeed simpler. Could you capture the behaviour in a source code
> comment ?

Sure.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

On Fri, Nov 20, 2015 at 3:50 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 10:07:31 Geert Uytterhoeven wrote:
>> On Fri, Nov 20, 2015 at 9:58 AM, Laurent Pinchart wrote:
>> > On Friday 20 November 2015 09:22:16 Geert Uytterhoeven wrote:
>> >> On Thu, Nov 19, 2015 at 10:08 PM, Laurent Pinchart wrote:
>> >>> Could you briefly explain (and even better in a source code comment)
>> >>> how you handle baud rate calculation with the chained BRGs ?
>> >>
>> >> I'll do that. Note that there's no chaining of BRGs, only muxing (so yes,
>> >> it needs more clarification ;-).
>> >
>> > Really ? I thought the BRG-EC was one possible input for the internal BRG
>> > ? Does it bypass the internal BRG ? Or do you configure the internal BRG
>> > to not divide the clock when using the BRG-EC ?
>>
>> Yes, it's bypassed.
>>
>> Cfr. SCSCR.CKE[1:0].
>> '00' means internal BRG (although the docs state P divided by 1/4/16/64),
>> '10' means SCK or SC_CLK (SCIF_CLK/INT_CLK).
>
> That's indeed simpler. Could you capture the behaviour in a source code
> comment ?

Sure.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 7:38 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> This patch series adds support to the Renesas SCI serial driver for
>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>     pin can serve as a clock input,
>   - the optional clock sources for the Baud Rate Generator for External
>     Clock (BRG), as found on some SCIF variants and on HSCIF.
> Using external clocks increases the range and accuracy of supported baud
> rates. Please see the descriptions of the DTS patches for more detailed
> information regarding the impact on the supported platforms.

For the consumers: I've pushed this (incl. the dependencies and a few
WIP patches) to the scif-brg branch of my renesas-drivers repo.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

On Thu, Nov 19, 2015 at 7:38 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> This patch series adds support to the Renesas SCI serial driver for
>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>     pin can serve as a clock input,
>   - the optional clock sources for the Baud Rate Generator for External
>     Clock (BRG), as found on some SCIF variants and on HSCIF.
> Using external clocks increases the range and accuracy of supported baud
> rates. Please see the descriptions of the DTS patches for more detailed
> information regarding the impact on the supported platforms.

For the consumers: I've pushed this (incl. the dependencies and a few
WIP patches) to the scif-brg branch of my renesas-drivers repo.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Greg Kroah-Hartman]

On Fri, Nov 20, 2015 at 10:09:24AM +0100, Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 7:38 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > This patch series adds support to the Renesas SCI serial driver for
> >   - the optional external clock on (H)SCI(F) and some SCIFA, where this
> >     pin can serve as a clock input,
> >   - the optional clock sources for the Baud Rate Generator for External
> >     Clock (BRG), as found on some SCIF variants and on HSCIF.
> > Using external clocks increases the range and accuracy of supported baud
> > rates. Please see the descriptions of the DTS patches for more detailed
> > information regarding the impact on the supported platforms.
> 
> For the consumers: I've pushed this (incl. the dependencies and a few
> WIP patches) to the scif-brg branch of my renesas-drivers repo.

I don't know what I can do with this series given the dependancies, but
if it helps, you can add:
	Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
to the serial patches and take them through what ever tree you want to.

thanks,

greg k-h

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Greg Kroah-Hartman]

On Fri, Nov 20, 2015 at 10:09:24AM +0100, Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 7:38 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > This patch series adds support to the Renesas SCI serial driver for
> >   - the optional external clock on (H)SCI(F) and some SCIFA, where this
> >     pin can serve as a clock input,
> >   - the optional clock sources for the Baud Rate Generator for External
> >     Clock (BRG), as found on some SCIF variants and on HSCIF.
> > Using external clocks increases the range and accuracy of supported baud
> > rates. Please see the descriptions of the DTS patches for more detailed
> > information regarding the impact on the supported platforms.
> 
> For the consumers: I've pushed this (incl. the dependencies and a few
> WIP patches) to the scif-brg branch of my renesas-drivers repo.

I don't know what I can do with this series given the dependancies, but
if it helps, you can add:
	Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
to the serial patches and take them through what ever tree you want to.

thanks,

greg k-h

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

Hi Greg,

On Sun, Dec 13, 2015 at 7:43 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Nov 20, 2015 at 10:09:24AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 7:38 PM, Geert Uytterhoeven
>> <geert+renesas@glider.be> wrote:
>> > This patch series adds support to the Renesas SCI serial driver for
>> >   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>> >     pin can serve as a clock input,
>> >   - the optional clock sources for the Baud Rate Generator for External
>> >     Clock (BRG), as found on some SCIF variants and on HSCIF.
>> > Using external clocks increases the range and accuracy of supported baud
>> > rates. Please see the descriptions of the DTS patches for more detailed
>> > information regarding the impact on the supported platforms.
>>
>> For the consumers: I've pushed this (incl. the dependencies and a few
>> WIP patches) to the scif-brg branch of my renesas-drivers repo.
>
> I don't know what I can do with this series given the dependancies, but
> if it helps, you can add:
>         Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> to the serial patches and take them through what ever tree you want to.

Thanks for your ackes, they make (my) life a bit simpler!

I was going to post an updated version tomorrow. I will include a list of
merge options.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Geert Uytterhoeven]

Hi Greg,

On Sun, Dec 13, 2015 at 7:43 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Nov 20, 2015 at 10:09:24AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 7:38 PM, Geert Uytterhoeven
>> <geert+renesas@glider.be> wrote:
>> > This patch series adds support to the Renesas SCI serial driver for
>> >   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>> >     pin can serve as a clock input,
>> >   - the optional clock sources for the Baud Rate Generator for External
>> >     Clock (BRG), as found on some SCIF variants and on HSCIF.
>> > Using external clocks increases the range and accuracy of supported baud
>> > rates. Please see the descriptions of the DTS patches for more detailed
>> > information regarding the impact on the supported platforms.
>>
>> For the consumers: I've pushed this (incl. the dependencies and a few
>> WIP patches) to the scif-brg branch of my renesas-drivers repo.
>
> I don't know what I can do with this series given the dependancies, but
> if it helps, you can add:
>         Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> to the serial patches and take them through what ever tree you want to.

Thanks for your ackes, they make (my) life a bit simpler!

I was going to post an updated version tomorrow. I will include a list of
merge options.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Simon Horman]

On Thu, Nov 19, 2015 at 07:38:39PM +0100, Geert Uytterhoeven wrote:
> 	Hi,
> 
> This patch series adds support to the Renesas SCI serial driver for
>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>     pin can serve as a clock input,
>   - the optional clock sources for the Baud Rate Generator for External
>     Clock (BRG), as found on some SCIF variants and on HSCIF.
> Using external clocks increases the range and accuracy of supported baud
> rates. Please see the descriptions of the DTS patches for more detailed
> information regarding the impact on the supported platforms.
> 
> For now this supports r8a7791/koelsch and r8a7795/salvator-x only, which
> have an external SCIF_CLK running at 14.7456 MHz.
> Support for other R-Car platforms will be added later.
> 
> Testing:
>   - The Baud Rate Generator for External Clock (BRG) was tested with
>     SCIF and HSCIF on r8a7791/koelsch and r8a7795/salvator-x,
>   - The external clock input on (H)SCK was tested on r8a7795/salvator-x
>     by feeding an external clock signal to (H)SCIF1,
>   - Various bit rates were monitored using a SmartScope,
>   - Regression testing was done on Renesas ARM platforms that use SCIFA
>     as the console (r8a73a4/ape6evm, r8a7740/armadillo, and
>     sh73a0/kzm9g).
> 	      
> Dependencies:
>   - This series depends on the series "[PATCH v2 00/16] serial: sh-sci:
>     Clock Cleanups",
>   - The SH patch 25 depends on the "serial: sh-sci" patches in this
>     series,
>   - The DTS patches 21-24 can be applied independently, once the DT
>     binding patches 1-2 are accepted,

I have marked those patches as deferred pending the bindings being
accepted.

>   - r8a7791/r8a7795 has a runtime dependency on series "[PATCH 0/2]
>     pinctrl: sh-pfc: r8a7791/r8a7795: Add SCIF_CLK support",
>   - r8a7795 also depends on
>        - platform support in e.g. renesas-drivers-2015-11-17-v4.4-rc1,
>        - "[PATCH] pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups, and
> 	 functions",
>        - "[PATCH] arm64: renesas: r8a7795 dtsi: Add all HSCIF nodes".
>   - Legacy SH has a runtime dependency on:
>       - series "[PATCH 0/2] drivers: sh: clk: Cleanup clock API",

Re: [PATCH 00/25] serial: sh-sci: Add external clock and BRG Support

[Simon Horman]

On Thu, Nov 19, 2015 at 07:38:39PM +0100, Geert Uytterhoeven wrote:
> 	Hi,
> 
> This patch series adds support to the Renesas SCI serial driver for
>   - the optional external clock on (H)SCI(F) and some SCIFA, where this
>     pin can serve as a clock input,
>   - the optional clock sources for the Baud Rate Generator for External
>     Clock (BRG), as found on some SCIF variants and on HSCIF.
> Using external clocks increases the range and accuracy of supported baud
> rates. Please see the descriptions of the DTS patches for more detailed
> information regarding the impact on the supported platforms.
> 
> For now this supports r8a7791/koelsch and r8a7795/salvator-x only, which
> have an external SCIF_CLK running at 14.7456 MHz.
> Support for other R-Car platforms will be added later.
> 
> Testing:
>   - The Baud Rate Generator for External Clock (BRG) was tested with
>     SCIF and HSCIF on r8a7791/koelsch and r8a7795/salvator-x,
>   - The external clock input on (H)SCK was tested on r8a7795/salvator-x
>     by feeding an external clock signal to (H)SCIF1,
>   - Various bit rates were monitored using a SmartScope,
>   - Regression testing was done on Renesas ARM platforms that use SCIFA
>     as the console (r8a73a4/ape6evm, r8a7740/armadillo, and
>     sh73a0/kzm9g).
> 	      
> Dependencies:
>   - This series depends on the series "[PATCH v2 00/16] serial: sh-sci:
>     Clock Cleanups",
>   - The SH patch 25 depends on the "serial: sh-sci" patches in this
>     series,
>   - The DTS patches 21-24 can be applied independently, once the DT
>     binding patches 1-2 are accepted,

I have marked those patches as deferred pending the bindings being
accepted.

>   - r8a7791/r8a7795 has a runtime dependency on series "[PATCH 0/2]
>     pinctrl: sh-pfc: r8a7791/r8a7795: Add SCIF_CLK support",
>   - r8a7795 also depends on
>        - platform support in e.g. renesas-drivers-2015-11-17-v4.4-rc1,
>        - "[PATCH] pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups, and
> 	 functions",
>        - "[PATCH] arm64: renesas: r8a7795 dtsi: Add all HSCIF nodes".
>   - Legacy SH has a runtime dependency on:
>       - series "[PATCH 0/2] drivers: sh: clk: Cleanup clock API",