[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

        Hi Philipp, Mike, Stephen, Simon, Magnus,
	(see questions *** below!)

Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
state of the mode pins either by a call from the platform code, or
directly by using a hardcoded register access. This is a bit messy, and
creates a dependency between driver and platform code.

This patch series converts the various Renesas R-Car clock drivers
and support code from reading the mode pin states using a hardcoded
register access to using a new minimalistic R-Car RST driver.

All R-Car clock drivers will rely on the presence in DT of a device node
for the RST module.  Backwards compatibility with old DTBs is retained
only for R-Car Gen2, which has fallback code using its own private copy
of rcar_gen2_read_mode_pins().

After this, there is still one remaining user of
rcar_gen2_read_mode_pins() left in platform code. A patch series to
remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").

This series consists of 5 parts:
  A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
     driver,
  B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
     files,
  C. Patches 12-17 convert the clock drivers to call into the new R-Car
     RST driver,
  D. Patches 18-20 remove passing mode pin state to the clock drivers
     from the platform code,
  E. Patches 21-23 remove dead code from the clock drivers.

As is usually the case with moving functionality from platform code to
DT, there are lots of hard dependencies:
  - The DT updates in Part B can be merged as soon as the DT bindings in
    Part A have been approved,
  - The clock driver updates in Part C depend functionally on the driver
    code in Part A, and on the DT updates in Part B,
  - The board code cleanups in Part D depend on the clock driver updates
    in Part C,
  - The block driver cleanups in part E depend on the board code
    cleanups in part D.

Hence to maintain the required lockstep between SoC driver, clock
drivers, shmobile platform code, and shmobile DT, I propose to queue up
all patches in a single branch against v4.9-rc1, and send pull requests
to both Mike/Stephen (clock) and Simon (rest).

***

  - Philip: While this is a driver for a reset-controller, currently it
    doesn't provide any reset-controller functionality. Hence I added it
    to drivers/soc/renesas/. Is that OK for you?

  - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
    approach above?

This series has evolved over time, cfr.:
  - "[PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for
    obtaining mode pin state"
    (http://www.spinics.net/lists/linux-renesas-soc/msg04289.html),
  - "[PATCH/RFC 00/11] ARM: shmobile: Let CPG use syscon for MD pin
    values" (http://www.spinics.net/lists/linux-clk/msg01478.html),
  - "[PATCH 00/10] arm64: renesas: Obtain MD pin values using
    syscon/regmap".
    (http://www.spinics.net/lists/linux-sh/msg44757.html)

Changes compared to v3:
  - Add Acked-by, Reviewed-by,
  - Add support for R-Car V2H,
  - Add support for RZ/G1M and RZ/G1E,
  - Remove the initcall and the rcar_rst_base check in rcar_rst_init(),
    as rcar_rst_init() is only used as a support function for
    rcar_rst_read_mode_pins(),
  - Refer to rcar_rst_gen2 for R-Car Gen3 instead of providing an
    identical copy,
  - Use our own private copy of rcar_gen2_read_mode_pins() instead of
    the one in the R-Car Gen2 platform code, as the latter is planned to
    be removed,
  - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
    from DT",

Changes compared to v2:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value and "renesas,modemr" property, use a
    real driver instead,
  - Add support for R-Car M1A, H1, and M3-W.

Changes compared to v1:
  - Add support for R-Car H3.

This patch series is against v4.9-rc1. When applying it to
renesas-devel-20161021-v4.9-rc1, there's a small conflict in
drivers/soc/renesas/Makefile (both sides added lines).

For your convenience, this series is also available in the
topic/rcar-rst-v4 branch of my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
This has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
r8a7795/salvator-x, and r8a7796/salvator-x.

Thanks!

Geert Uytterhoeven (23):
  reset: Add renesas,rst DT bindings
  soc: renesas: Add R-Car RST driver
  ARM: dts: r8a7778: Add device node for RESET/WDT module
  ARM: dts: r8a7779: Add device node for RESET/WDT module
  ARM: dts: r8a7790: Add device node for RST module
  ARM: dts: r8a7791: Add device node for RST module
  ARM: dts: r8a7792: Add device node for RST module
  ARM: dts: r8a7793: Add device node for RST module
  ARM: dts: r8a7794: Add device node for RST module
  arm64: renesas: r8a7795 dtsi: Add device node for RST module
  arm64: renesas: r8a7796 dtsi: Add device node for RST module
  clk: renesas: r8a7778: Obtain mode pin values using R-Car RST driver
  clk: renesas: r8a7779: Obtain mode pin values from R-Car RST driver
  clk: renesas: rcar-gen2: Obtain mode pin values using RST driver
  clk: renesas: r8a7795: Obtain mode pin values from R-Car RST driver
  clk: renesas: r8a7796: Obtain mode pin values from R-Car RST driver
  clk: renesas: rcar-gen3-cpg: Remove obsolete
    rcar_gen3_read_mode_pins()
  ARM: shmobile: r8a7778: Stop passing mode pins state to clock driver
  ARM: shmobile: r8a7779: Stop passing mode pins state to clock driver
  ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver
  clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()
  clk: renesas: r8a7779: Remove obsolete r8a7779_clocks_init()
  clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init()

 .../devicetree/bindings/reset/renesas,rst.txt      | 37 +++++++++
 arch/arm/boot/dts/r8a7778.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7779.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7790.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7791.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7792.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7793.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7794.dtsi                     |  5 ++
 arch/arm/mach-shmobile/setup-r8a7778.c             | 15 ----
 arch/arm/mach-shmobile/setup-r8a7779.c             | 27 -------
 arch/arm/mach-shmobile/setup-rcar-gen2.c           |  5 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           |  5 ++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi           |  5 ++
 drivers/clk/renesas/clk-r8a7778.c                  | 26 +++---
 drivers/clk/renesas/clk-r8a7779.c                  | 18 ++---
 drivers/clk/renesas/clk-rcar-gen2.c                | 32 ++++++--
 drivers/clk/renesas/r8a7795-cpg-mssr.c             |  8 +-
 drivers/clk/renesas/r8a7796-cpg-mssr.c             |  8 +-
 drivers/clk/renesas/rcar-gen3-cpg.c                | 17 ----
 drivers/clk/renesas/rcar-gen3-cpg.h                |  1 -
 drivers/soc/renesas/Makefile                       |  5 ++
 drivers/soc/renesas/rcar-rst.c                     | 92 ++++++++++++++++++++++
 include/linux/clk/renesas.h                        |  4 -
 include/linux/soc/renesas/rcar-rst.h               |  6 ++
 24 files changed, 246 insertions(+), 100 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
 create mode 100644 drivers/soc/renesas/rcar-rst.c
 create mode 100644 include/linux/soc/renesas/rcar-rst.h

-- 
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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

        Hi Philipp, Mike, Stephen, Simon, Magnus,
	(see questions *** below!)

Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
state of the mode pins either by a call from the platform code, or
directly by using a hardcoded register access. This is a bit messy, and
creates a dependency between driver and platform code.

This patch series converts the various Renesas R-Car clock drivers
and support code from reading the mode pin states using a hardcoded
register access to using a new minimalistic R-Car RST driver.

All R-Car clock drivers will rely on the presence in DT of a device node
for the RST module.  Backwards compatibility with old DTBs is retained
only for R-Car Gen2, which has fallback code using its own private copy
of rcar_gen2_read_mode_pins().

After this, there is still one remaining user of
rcar_gen2_read_mode_pins() left in platform code. A patch series to
remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").

This series consists of 5 parts:
  A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
     driver,
  B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
     files,
  C. Patches 12-17 convert the clock drivers to call into the new R-Car
     RST driver,
  D. Patches 18-20 remove passing mode pin state to the clock drivers
     from the platform code,
  E. Patches 21-23 remove dead code from the clock drivers.

As is usually the case with moving functionality from platform code to
DT, there are lots of hard dependencies:
  - The DT updates in Part B can be merged as soon as the DT bindings in
    Part A have been approved,
  - The clock driver updates in Part C depend functionally on the driver
    code in Part A, and on the DT updates in Part B,
  - The board code cleanups in Part D depend on the clock driver updates
    in Part C,
  - The block driver cleanups in part E depend on the board code
    cleanups in part D.

Hence to maintain the required lockstep between SoC driver, clock
drivers, shmobile platform code, and shmobile DT, I propose to queue up
all patches in a single branch against v4.9-rc1, and send pull requests
to both Mike/Stephen (clock) and Simon (rest).

***

  - Philip: While this is a driver for a reset-controller, currently it
    doesn't provide any reset-controller functionality. Hence I added it
    to drivers/soc/renesas/. Is that OK for you?

  - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
    approach above?

This series has evolved over time, cfr.:
  - "[PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for
    obtaining mode pin state"
    (http://www.spinics.net/lists/linux-renesas-soc/msg04289.html),
  - "[PATCH/RFC 00/11] ARM: shmobile: Let CPG use syscon for MD pin
    values" (http://www.spinics.net/lists/linux-clk/msg01478.html),
  - "[PATCH 00/10] arm64: renesas: Obtain MD pin values using
    syscon/regmap".
    (http://www.spinics.net/lists/linux-sh/msg44757.html)

Changes compared to v3:
  - Add Acked-by, Reviewed-by,
  - Add support for R-Car V2H,
  - Add support for RZ/G1M and RZ/G1E,
  - Remove the initcall and the rcar_rst_base check in rcar_rst_init(),
    as rcar_rst_init() is only used as a support function for
    rcar_rst_read_mode_pins(),
  - Refer to rcar_rst_gen2 for R-Car Gen3 instead of providing an
    identical copy,
  - Use our own private copy of rcar_gen2_read_mode_pins() instead of
    the one in the R-Car Gen2 platform code, as the latter is planned to
    be removed,
  - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
    from DT",

Changes compared to v2:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value and "renesas,modemr" property, use a
    real driver instead,
  - Add support for R-Car M1A, H1, and M3-W.

Changes compared to v1:
  - Add support for R-Car H3.

This patch series is against v4.9-rc1. When applying it to
renesas-devel-20161021-v4.9-rc1, there's a small conflict in
drivers/soc/renesas/Makefile (both sides added lines).

For your convenience, this series is also available in the
topic/rcar-rst-v4 branch of my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
This has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
r8a7795/salvator-x, and r8a7796/salvator-x.

Thanks!

Geert Uytterhoeven (23):
  reset: Add renesas,rst DT bindings
  soc: renesas: Add R-Car RST driver
  ARM: dts: r8a7778: Add device node for RESET/WDT module
  ARM: dts: r8a7779: Add device node for RESET/WDT module
  ARM: dts: r8a7790: Add device node for RST module
  ARM: dts: r8a7791: Add device node for RST module
  ARM: dts: r8a7792: Add device node for RST module
  ARM: dts: r8a7793: Add device node for RST module
  ARM: dts: r8a7794: Add device node for RST module
  arm64: renesas: r8a7795 dtsi: Add device node for RST module
  arm64: renesas: r8a7796 dtsi: Add device node for RST module
  clk: renesas: r8a7778: Obtain mode pin values using R-Car RST driver
  clk: renesas: r8a7779: Obtain mode pin values from R-Car RST driver
  clk: renesas: rcar-gen2: Obtain mode pin values using RST driver
  clk: renesas: r8a7795: Obtain mode pin values from R-Car RST driver
  clk: renesas: r8a7796: Obtain mode pin values from R-Car RST driver
  clk: renesas: rcar-gen3-cpg: Remove obsolete
    rcar_gen3_read_mode_pins()
  ARM: shmobile: r8a7778: Stop passing mode pins state to clock driver
  ARM: shmobile: r8a7779: Stop passing mode pins state to clock driver
  ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver
  clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()
  clk: renesas: r8a7779: Remove obsolete r8a7779_clocks_init()
  clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init()

 .../devicetree/bindings/reset/renesas,rst.txt      | 37 +++++++++
 arch/arm/boot/dts/r8a7778.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7779.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7790.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7791.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7792.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7793.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7794.dtsi                     |  5 ++
 arch/arm/mach-shmobile/setup-r8a7778.c             | 15 ----
 arch/arm/mach-shmobile/setup-r8a7779.c             | 27 -------
 arch/arm/mach-shmobile/setup-rcar-gen2.c           |  5 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           |  5 ++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi           |  5 ++
 drivers/clk/renesas/clk-r8a7778.c                  | 26 +++---
 drivers/clk/renesas/clk-r8a7779.c                  | 18 ++---
 drivers/clk/renesas/clk-rcar-gen2.c                | 32 ++++++--
 drivers/clk/renesas/r8a7795-cpg-mssr.c             |  8 +-
 drivers/clk/renesas/r8a7796-cpg-mssr.c             |  8 +-
 drivers/clk/renesas/rcar-gen3-cpg.c                | 17 ----
 drivers/clk/renesas/rcar-gen3-cpg.h                |  1 -
 drivers/soc/renesas/Makefile                       |  5 ++
 drivers/soc/renesas/rcar-rst.c                     | 92 ++++++++++++++++++++++
 include/linux/clk/renesas.h                        |  4 -
 include/linux/soc/renesas/rcar-rst.h               |  6 ++
 24 files changed, 246 insertions(+), 100 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
 create mode 100644 drivers/soc/renesas/rcar-rst.c
 create mode 100644 include/linux/soc/renesas/rcar-rst.h

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

        Hi Philipp, Mike, Stephen, Simon, Magnus,
	(see questions *** below!)

Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
state of the mode pins either by a call from the platform code, or
directly by using a hardcoded register access. This is a bit messy, and
creates a dependency between driver and platform code.

This patch series converts the various Renesas R-Car clock drivers
and support code from reading the mode pin states using a hardcoded
register access to using a new minimalistic R-Car RST driver.

All R-Car clock drivers will rely on the presence in DT of a device node
for the RST module.  Backwards compatibility with old DTBs is retained
only for R-Car Gen2, which has fallback code using its own private copy
of rcar_gen2_read_mode_pins().

After this, there is still one remaining user of
rcar_gen2_read_mode_pins() left in platform code. A patch series to
remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").

This series consists of 5 parts:
  A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
     driver,
  B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
     files,
  C. Patches 12-17 convert the clock drivers to call into the new R-Car
     RST driver,
  D. Patches 18-20 remove passing mode pin state to the clock drivers
     from the platform code,
  E. Patches 21-23 remove dead code from the clock drivers.

As is usually the case with moving functionality from platform code to
DT, there are lots of hard dependencies:
  - The DT updates in Part B can be merged as soon as the DT bindings in
    Part A have been approved,
  - The clock driver updates in Part C depend functionally on the driver
    code in Part A, and on the DT updates in Part B,
  - The board code cleanups in Part D depend on the clock driver updates
    in Part C,
  - The block driver cleanups in part E depend on the board code
    cleanups in part D.

Hence to maintain the required lockstep between SoC driver, clock
drivers, shmobile platform code, and shmobile DT, I propose to queue up
all patches in a single branch against v4.9-rc1, and send pull requests
to both Mike/Stephen (clock) and Simon (rest).

***

  - Philip: While this is a driver for a reset-controller, currently it
    doesn't provide any reset-controller functionality. Hence I added it
    to drivers/soc/renesas/. Is that OK for you?

  - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
    approach above?

This series has evolved over time, cfr.:
  - "[PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for
    obtaining mode pin state"
    (http://www.spinics.net/lists/linux-renesas-soc/msg04289.html),
  - "[PATCH/RFC 00/11] ARM: shmobile: Let CPG use syscon for MD pin
    values" (http://www.spinics.net/lists/linux-clk/msg01478.html),
  - "[PATCH 00/10] arm64: renesas: Obtain MD pin values using
    syscon/regmap".
    (http://www.spinics.net/lists/linux-sh/msg44757.html)

Changes compared to v3:
  - Add Acked-by, Reviewed-by,
  - Add support for R-Car V2H,
  - Add support for RZ/G1M and RZ/G1E,
  - Remove the initcall and the rcar_rst_base check in rcar_rst_init(),
    as rcar_rst_init() is only used as a support function for
    rcar_rst_read_mode_pins(),
  - Refer to rcar_rst_gen2 for R-Car Gen3 instead of providing an
    identical copy,
  - Use our own private copy of rcar_gen2_read_mode_pins() instead of
    the one in the R-Car Gen2 platform code, as the latter is planned to
    be removed,
  - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
    from DT",

Changes compared to v2:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value and "renesas,modemr" property, use a
    real driver instead,
  - Add support for R-Car M1A, H1, and M3-W.

Changes compared to v1:
  - Add support for R-Car H3.

This patch series is against v4.9-rc1. When applying it to
renesas-devel-20161021-v4.9-rc1, there's a small conflict in
drivers/soc/renesas/Makefile (both sides added lines).

For your convenience, this series is also available in the
topic/rcar-rst-v4 branch of my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
This has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
r8a7795/salvator-x, and r8a7796/salvator-x.

Thanks!

Geert Uytterhoeven (23):
  reset: Add renesas,rst DT bindings
  soc: renesas: Add R-Car RST driver
  ARM: dts: r8a7778: Add device node for RESET/WDT module
  ARM: dts: r8a7779: Add device node for RESET/WDT module
  ARM: dts: r8a7790: Add device node for RST module
  ARM: dts: r8a7791: Add device node for RST module
  ARM: dts: r8a7792: Add device node for RST module
  ARM: dts: r8a7793: Add device node for RST module
  ARM: dts: r8a7794: Add device node for RST module
  arm64: renesas: r8a7795 dtsi: Add device node for RST module
  arm64: renesas: r8a7796 dtsi: Add device node for RST module
  clk: renesas: r8a7778: Obtain mode pin values using R-Car RST driver
  clk: renesas: r8a7779: Obtain mode pin values from R-Car RST driver
  clk: renesas: rcar-gen2: Obtain mode pin values using RST driver
  clk: renesas: r8a7795: Obtain mode pin values from R-Car RST driver
  clk: renesas: r8a7796: Obtain mode pin values from R-Car RST driver
  clk: renesas: rcar-gen3-cpg: Remove obsolete
    rcar_gen3_read_mode_pins()
  ARM: shmobile: r8a7778: Stop passing mode pins state to clock driver
  ARM: shmobile: r8a7779: Stop passing mode pins state to clock driver
  ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver
  clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()
  clk: renesas: r8a7779: Remove obsolete r8a7779_clocks_init()
  clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init()

 .../devicetree/bindings/reset/renesas,rst.txt      | 37 +++++++++
 arch/arm/boot/dts/r8a7778.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7779.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7790.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7791.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7792.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7793.dtsi                     |  5 ++
 arch/arm/boot/dts/r8a7794.dtsi                     |  5 ++
 arch/arm/mach-shmobile/setup-r8a7778.c             | 15 ----
 arch/arm/mach-shmobile/setup-r8a7779.c             | 27 -------
 arch/arm/mach-shmobile/setup-rcar-gen2.c           |  5 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           |  5 ++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi           |  5 ++
 drivers/clk/renesas/clk-r8a7778.c                  | 26 +++---
 drivers/clk/renesas/clk-r8a7779.c                  | 18 ++---
 drivers/clk/renesas/clk-rcar-gen2.c                | 32 ++++++--
 drivers/clk/renesas/r8a7795-cpg-mssr.c             |  8 +-
 drivers/clk/renesas/r8a7796-cpg-mssr.c             |  8 +-
 drivers/clk/renesas/rcar-gen3-cpg.c                | 17 ----
 drivers/clk/renesas/rcar-gen3-cpg.h                |  1 -
 drivers/soc/renesas/Makefile                       |  5 ++
 drivers/soc/renesas/rcar-rst.c                     | 92 ++++++++++++++++++++++
 include/linux/clk/renesas.h                        |  4 -
 include/linux/soc/renesas/rcar-rst.h               |  6 ++
 24 files changed, 246 insertions(+), 100 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
 create mode 100644 drivers/soc/renesas/rcar-rst.c
 create mode 100644 include/linux/soc/renesas/rcar-rst.h

-- 
1.9.1

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

[PATCH v4 01/23] reset: Add renesas,rst DT bindings

[Geert Uytterhoeven]

Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).

As the features provided by the hardware module differ a lot across the
various SoC families and members, only SoC-specific compatible values
are defined.

For now we use the RST only for providing access to the state of the
mode pins, which is needed by the clock driver.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
v4:
  - Add Acked-by,
  - Fix comma and period in list,
  - Add RZ/G1M and RZ/G1E,

v3:
  - Clarify current usage,
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,
  - Add R-Car M3-W,
  - Add R-Car Gen1,

v2:
  - Add Acked-by.
---
 .../devicetree/bindings/reset/renesas,rst.txt      | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt

diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt
new file mode 100644
index 0000000000000000..fe5e0f37b3c93579
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
@@ -0,0 +1,37 @@
+DT bindings for the Renesas R-Car and RZ/G Reset Controllers
+
+The R-Car and RZ/G Reset Controllers provide reset control, and implement the
+following functions:
+  - Latching of the levels on mode pins when PRESET# is negated,
+  - Mode monitoring register,
+  - Reset control of peripheral devices (on R-Car Gen1),
+  - Watchdog timer (on R-Car Gen1),
+  - Register-based reset control and boot address registers for the various CPU
+    cores (on R-Car Gen2 and Gen3, and on RZ/G).
+
+
+Required properties:
+  - compatible: Should be
+		  - "renesas,<soctype>-reset-wdt" for R-Car Gen1,
+		  - "renesas,<soctype>-rst" for R-Car Gen2 and Gen3, and RZ/G
+		Examples with soctypes are:
+		  - "renesas,r8a7743-rst" (RZ/G1M)
+		  - "renesas,r8a7745-rst" (RZ/G1E)
+		  - "renesas,r8a7778-reset-wdt" (R-Car M1A)
+		  - "renesas,r8a7779-reset-wdt" (R-Car H1)
+		  - "renesas,r8a7790-rst" (R-Car H2)
+		  - "renesas,r8a7791-rst" (R-Car M2-W)
+		  - "renesas,r8a7792-rst" (R-Car V2H
+		  - "renesas,r8a7793-rst" (R-Car M2-N)
+		  - "renesas,r8a7794-rst" (R-Car E2)
+		  - "renesas,r8a7795-rst" (R-Car H3)
+		  - "renesas,r8a7796-rst" (R-Car M3-W)
+  - reg: Address start and address range for the device.
+
+
+Example:
+
+	rst: reset-controller@e6160000 {
+		compatible = "renesas,r8a7795-rst";
+		reg = <0 0xe6160000 0 0x0200>;
+	};
-- 
1.9.1

Re: [PATCH v4 01/23] reset: Add renesas,rst DT bindings

[Philipp Zabel]

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
> 
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
> 
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
>   - Add Acked-by,
>   - Fix comma and period in list,
>   - Add RZ/G1M and RZ/G1E,
> 
> v3:
>   - Clarify current usage,
>   - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
>   - Drop "syscon" compatible value,
>   - Add R-Car M3-W,
>   - Add R-Car Gen1,
> 
> v2:
>   - Add Acked-by.
> ---
>  .../devicetree/bindings/reset/renesas,rst.txt      | 37 ++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
> 
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> new file mode 100644
> index 0000000000000000..fe5e0f37b3c93579
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> @@ -0,0 +1,37 @@
> +DT bindings for the Renesas R-Car and RZ/G Reset Controllers
> +
> +The R-Car and RZ/G Reset Controllers provide reset control, and implement the
> +following functions:
> +  - Latching of the levels on mode pins when PRESET# is negated,
> +  - Mode monitoring register,
> +  - Reset control of peripheral devices (on R-Car Gen1),
> +  - Watchdog timer (on R-Car Gen1),
> +  - Register-based reset control and boot address registers for the various CPU
> +    cores (on R-Car Gen2 and Gen3, and on RZ/G).
> +
> +
> +Required properties:
> +  - compatible: Should be
> +		  - "renesas,<soctype>-reset-wdt" for R-Car Gen1,
> +		  - "renesas,<soctype>-rst" for R-Car Gen2 and Gen3, and RZ/G
> +		Examples with soctypes are:
> +		  - "renesas,r8a7743-rst" (RZ/G1M)
> +		  - "renesas,r8a7745-rst" (RZ/G1E)
> +		  - "renesas,r8a7778-reset-wdt" (R-Car M1A)
> +		  - "renesas,r8a7779-reset-wdt" (R-Car H1)
> +		  - "renesas,r8a7790-rst" (R-Car H2)
> +		  - "renesas,r8a7791-rst" (R-Car M2-W)
> +		  - "renesas,r8a7792-rst" (R-Car V2H
> +		  - "renesas,r8a7793-rst" (R-Car M2-N)
> +		  - "renesas,r8a7794-rst" (R-Car E2)
> +		  - "renesas,r8a7795-rst" (R-Car H3)
> +		  - "renesas,r8a7796-rst" (R-Car M3-W)
> +  - reg: Address start and address range for the device.
> +
> +
> +Example:
> +
> +	rst: reset-controller@e6160000 {
> +		compatible = "renesas,r8a7795-rst";
> +		reg = <0 0xe6160000 0 0x0200>;
> +	};


Acked-by: Philipp Zabel <p.zabel@pengutronix.de>

regards
Philipp

[PATCH v4 01/23] reset: Add renesas,rst DT bindings

[Philipp Zabel]

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
> 
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
> 
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
>   - Add Acked-by,
>   - Fix comma and period in list,
>   - Add RZ/G1M and RZ/G1E,
> 
> v3:
>   - Clarify current usage,
>   - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
>   - Drop "syscon" compatible value,
>   - Add R-Car M3-W,
>   - Add R-Car Gen1,
> 
> v2:
>   - Add Acked-by.
> ---
>  .../devicetree/bindings/reset/renesas,rst.txt      | 37 ++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
> 
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> new file mode 100644
> index 0000000000000000..fe5e0f37b3c93579
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> @@ -0,0 +1,37 @@
> +DT bindings for the Renesas R-Car and RZ/G Reset Controllers
> +
> +The R-Car and RZ/G Reset Controllers provide reset control, and implement the
> +following functions:
> +  - Latching of the levels on mode pins when PRESET# is negated,
> +  - Mode monitoring register,
> +  - Reset control of peripheral devices (on R-Car Gen1),
> +  - Watchdog timer (on R-Car Gen1),
> +  - Register-based reset control and boot address registers for the various CPU
> +    cores (on R-Car Gen2 and Gen3, and on RZ/G).
> +
> +
> +Required properties:
> +  - compatible: Should be
> +		  - "renesas,<soctype>-reset-wdt" for R-Car Gen1,
> +		  - "renesas,<soctype>-rst" for R-Car Gen2 and Gen3, and RZ/G
> +		Examples with soctypes are:
> +		  - "renesas,r8a7743-rst" (RZ/G1M)
> +		  - "renesas,r8a7745-rst" (RZ/G1E)
> +		  - "renesas,r8a7778-reset-wdt" (R-Car M1A)
> +		  - "renesas,r8a7779-reset-wdt" (R-Car H1)
> +		  - "renesas,r8a7790-rst" (R-Car H2)
> +		  - "renesas,r8a7791-rst" (R-Car M2-W)
> +		  - "renesas,r8a7792-rst" (R-Car V2H
> +		  - "renesas,r8a7793-rst" (R-Car M2-N)
> +		  - "renesas,r8a7794-rst" (R-Car E2)
> +		  - "renesas,r8a7795-rst" (R-Car H3)
> +		  - "renesas,r8a7796-rst" (R-Car M3-W)
> +  - reg: Address start and address range for the device.
> +
> +
> +Example:
> +
> +	rst: reset-controller at e6160000 {
> +		compatible = "renesas,r8a7795-rst";
> +		reg = <0 0xe6160000 0 0x0200>;
> +	};


Acked-by: Philipp Zabel <p.zabel@pengutronix.de>

regards
Philipp

Re: [PATCH v4 01/23] reset: Add renesas,rst DT bindings

[Philipp Zabel]

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
> 
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
> 
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> Acked-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
> Acked-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
> Acked-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> ---
> v4:
>   - Add Acked-by,
>   - Fix comma and period in list,
>   - Add RZ/G1M and RZ/G1E,
> 
> v3:
>   - Clarify current usage,
>   - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
>   - Drop "syscon" compatible value,
>   - Add R-Car M3-W,
>   - Add R-Car Gen1,
> 
> v2:
>   - Add Acked-by.
> ---
>  .../devicetree/bindings/reset/renesas,rst.txt      | 37 ++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
> 
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> new file mode 100644
> index 0000000000000000..fe5e0f37b3c93579
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> @@ -0,0 +1,37 @@
> +DT bindings for the Renesas R-Car and RZ/G Reset Controllers
> +
> +The R-Car and RZ/G Reset Controllers provide reset control, and implement the
> +following functions:
> +  - Latching of the levels on mode pins when PRESET# is negated,
> +  - Mode monitoring register,
> +  - Reset control of peripheral devices (on R-Car Gen1),
> +  - Watchdog timer (on R-Car Gen1),
> +  - Register-based reset control and boot address registers for the various CPU
> +    cores (on R-Car Gen2 and Gen3, and on RZ/G).
> +
> +
> +Required properties:
> +  - compatible: Should be
> +		  - "renesas,<soctype>-reset-wdt" for R-Car Gen1,
> +		  - "renesas,<soctype>-rst" for R-Car Gen2 and Gen3, and RZ/G
> +		Examples with soctypes are:
> +		  - "renesas,r8a7743-rst" (RZ/G1M)
> +		  - "renesas,r8a7745-rst" (RZ/G1E)
> +		  - "renesas,r8a7778-reset-wdt" (R-Car M1A)
> +		  - "renesas,r8a7779-reset-wdt" (R-Car H1)
> +		  - "renesas,r8a7790-rst" (R-Car H2)
> +		  - "renesas,r8a7791-rst" (R-Car M2-W)
> +		  - "renesas,r8a7792-rst" (R-Car V2H
> +		  - "renesas,r8a7793-rst" (R-Car M2-N)
> +		  - "renesas,r8a7794-rst" (R-Car E2)
> +		  - "renesas,r8a7795-rst" (R-Car H3)
> +		  - "renesas,r8a7796-rst" (R-Car M3-W)
> +  - reg: Address start and address range for the device.
> +
> +
> +Example:
> +
> +	rst: reset-controller@e6160000 {
> +		compatible = "renesas,r8a7795-rst";
> +		reg = <0 0xe6160000 0 0x0200>;
> +	};


Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

regards
Philipp

--
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 v4 01/23] reset: Add renesas,rst DT bindings

[Rob Herring]

On Fri, Oct 21, 2016 at 03:17:15PM +0200, Geert Uytterhoeven wrote:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
> 
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
> 
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
>   - Add Acked-by,
>   - Fix comma and period in list,
>   - Add RZ/G1M and RZ/G1E,
> 
> v3:
>   - Clarify current usage,
>   - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
>   - Drop "syscon" compatible value,
>   - Add R-Car M3-W,
>   - Add R-Car Gen1,
> 
> v2:
>   - Add Acked-by.
> ---
>  .../devicetree/bindings/reset/renesas,rst.txt      | 37 ++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt

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

[PATCH v4 01/23] reset: Add renesas,rst DT bindings

[Rob Herring]

On Fri, Oct 21, 2016 at 03:17:15PM +0200, Geert Uytterhoeven wrote:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
> 
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
> 
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
>   - Add Acked-by,
>   - Fix comma and period in list,
>   - Add RZ/G1M and RZ/G1E,
> 
> v3:
>   - Clarify current usage,
>   - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
>   - Drop "syscon" compatible value,
>   - Add R-Car M3-W,
>   - Add R-Car Gen1,
> 
> v2:
>   - Add Acked-by.
> ---
>  .../devicetree/bindings/reset/renesas,rst.txt      | 37 ++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt

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

Re: [PATCH v4 01/23] reset: Add renesas,rst DT bindings

[Rob Herring]

On Fri, Oct 21, 2016 at 03:17:15PM +0200, Geert Uytterhoeven wrote:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
> 
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
> 
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
>   - Add Acked-by,
>   - Fix comma and period in list,
>   - Add RZ/G1M and RZ/G1E,
> 
> v3:
>   - Clarify current usage,
>   - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
>   - Drop "syscon" compatible value,
>   - Add R-Car M3-W,
>   - Add R-Car Gen1,
> 
> v2:
>   - Add Acked-by.
> ---
>  .../devicetree/bindings/reset/renesas,rst.txt      | 37 ++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt

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

[PATCH v4 02/23] soc: renesas: Add R-Car RST driver

[Geert Uytterhoeven]

Add a driver for the Renesas R-Car Gen1 RESET/WDT and R-Car Gen2/Gen3
and RZ/G RST module.

For now this driver just provides an API to obtain the state of the mode
pins, as latched at reset time.  As this is typically called from the
probe function of a clock driver, which can run much earlier than any
initcall, calling rcar_rst_read_mode_pins() just forces an early
initialization of the driver.

Despite the current simple and almost identical handling for all
supported SoCs, the driver matches against SoC-specific compatible
values, as the features provided by the hardware module differ a lot
across the various SoC families and members.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,
  - Remove the initcall and the rcar_rst_base check in rcar_rst_init(),
    as rcar_rst_init() is only used as a support function for
    rcar_rst_read_mode_pins(),
  - Refer to rcar_rst_gen2 for R-Car Gen3 instead of providing an
    identical copy,
  - Add RZ/G1M and RZ/G1E,

v3:
  - New.
---
 drivers/soc/renesas/Makefile         |  5 ++
 drivers/soc/renesas/rcar-rst.c       | 92 ++++++++++++++++++++++++++++++++++++
 include/linux/soc/renesas/rcar-rst.h |  6 +++
 3 files changed, 103 insertions(+)
 create mode 100644 drivers/soc/renesas/rcar-rst.c
 create mode 100644 include/linux/soc/renesas/rcar-rst.h

diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 623039c3514cdc34..86cc78cd1962701a 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,8 @@
+obj-$(CONFIG_ARCH_RCAR_GEN1)	+= rcar-rst.o
+obj-$(CONFIG_ARCH_RCAR_GEN2)	+= rcar-rst.o
+obj-$(CONFIG_ARCH_R8A7795)	+= rcar-rst.o
+obj-$(CONFIG_ARCH_R8A7796)	+= rcar-rst.o
+
 obj-$(CONFIG_ARCH_R8A7779)	+= rcar-sysc.o r8a7779-sysc.o
 obj-$(CONFIG_ARCH_R8A7790)	+= rcar-sysc.o r8a7790-sysc.o
 obj-$(CONFIG_ARCH_R8A7791)	+= rcar-sysc.o r8a7791-sysc.o
diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
new file mode 100644
index 0000000000000000..a6d1c26d31675cf3
--- /dev/null
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -0,0 +1,92 @@
+/*
+ * R-Car Gen1 RESET/WDT, R-Car Gen2, Gen3, and RZ/G RST Driver
+ *
+ * Copyright (C) 2016 Glider bvba
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/soc/renesas/rcar-rst.h>
+
+struct rst_config {
+	unsigned int modemr;	/* Mode Monitoring Register Offset */
+};
+
+static const struct rst_config rcar_rst_gen1 __initconst = {
+	.modemr = 0x20,
+};
+
+static const struct rst_config rcar_rst_gen2 __initconst = {
+	.modemr = 0x60,
+};
+
+static const struct of_device_id rcar_rst_matches[] __initconst = {
+	/* RZ/G is handled like R-Car Gen2 */
+	{ .compatible = "renesas,r8a7743-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7745-rst", .data = &rcar_rst_gen2 },
+	/* R-Car Gen1 */
+	{ .compatible = "renesas,r8a7778-reset-wdt", .data = &rcar_rst_gen1 },
+	{ .compatible = "renesas,r8a7779-reset-wdt", .data = &rcar_rst_gen1 },
+	/* R-Car Gen2 */
+	{ .compatible = "renesas,r8a7790-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7791-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7792-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7793-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7794-rst", .data = &rcar_rst_gen2 },
+	/* R-Car Gen3 is handled like R-Car Gen2 */
+	{ .compatible = "renesas,r8a7795-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7796-rst", .data = &rcar_rst_gen2 },
+	{ /* sentinel */ }
+};
+
+static void __iomem *rcar_rst_base __initdata;
+static u32 saved_mode __initdata;
+
+static int __init rcar_rst_init(void)
+{
+	const struct of_device_id *match;
+	const struct rst_config *cfg;
+	struct device_node *np;
+	void __iomem *base;
+	int error = 0;
+
+	np = of_find_matching_node_and_match(NULL, rcar_rst_matches, &match);
+	if (!np)
+		return -ENODEV;
+
+	base = of_iomap(np, 0);
+	if (!base) {
+		pr_warn("%s: Cannot map regs\n", np->full_name);
+		error = -ENOMEM;
+		goto out_put;
+	}
+
+	rcar_rst_base = base;
+	cfg = match->data;
+	saved_mode = ioread32(base + cfg->modemr);
+
+	pr_debug("%s: MODE = 0x%08x\n", np->full_name, saved_mode);
+
+out_put:
+	of_node_put(np);
+	return error;
+}
+
+int __init rcar_rst_read_mode_pins(u32 *mode)
+{
+	int error;
+
+	if (!rcar_rst_base) {
+		error = rcar_rst_init();
+		if (error)
+			return error;
+	}
+
+	*mode = saved_mode;
+	return 0;
+}
diff --git a/include/linux/soc/renesas/rcar-rst.h b/include/linux/soc/renesas/rcar-rst.h
new file mode 100644
index 0000000000000000..a18e0783946b66ec
--- /dev/null
+++ b/include/linux/soc/renesas/rcar-rst.h
@@ -0,0 +1,6 @@
+#ifndef __LINUX_SOC_RENESAS_RCAR_RST_H__
+#define __LINUX_SOC_RENESAS_RCAR_RST_H__
+
+int rcar_rst_read_mode_pins(u32 *mode);
+
+#endif /* __LINUX_SOC_RENESAS_RCAR_RST_H__ */
-- 
1.9.1

[PATCH v4 02/23] soc: renesas: Add R-Car RST driver

[Geert Uytterhoeven]

Add a driver for the Renesas R-Car Gen1 RESET/WDT and R-Car Gen2/Gen3
and RZ/G RST module.

For now this driver just provides an API to obtain the state of the mode
pins, as latched at reset time.  As this is typically called from the
probe function of a clock driver, which can run much earlier than any
initcall, calling rcar_rst_read_mode_pins() just forces an early
initialization of the driver.

Despite the current simple and almost identical handling for all
supported SoCs, the driver matches against SoC-specific compatible
values, as the features provided by the hardware module differ a lot
across the various SoC families and members.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,
  - Remove the initcall and the rcar_rst_base check in rcar_rst_init(),
    as rcar_rst_init() is only used as a support function for
    rcar_rst_read_mode_pins(),
  - Refer to rcar_rst_gen2 for R-Car Gen3 instead of providing an
    identical copy,
  - Add RZ/G1M and RZ/G1E,

v3:
  - New.
---
 drivers/soc/renesas/Makefile         |  5 ++
 drivers/soc/renesas/rcar-rst.c       | 92 ++++++++++++++++++++++++++++++++++++
 include/linux/soc/renesas/rcar-rst.h |  6 +++
 3 files changed, 103 insertions(+)
 create mode 100644 drivers/soc/renesas/rcar-rst.c
 create mode 100644 include/linux/soc/renesas/rcar-rst.h

diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 623039c3514cdc34..86cc78cd1962701a 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,8 @@
+obj-$(CONFIG_ARCH_RCAR_GEN1)	+= rcar-rst.o
+obj-$(CONFIG_ARCH_RCAR_GEN2)	+= rcar-rst.o
+obj-$(CONFIG_ARCH_R8A7795)	+= rcar-rst.o
+obj-$(CONFIG_ARCH_R8A7796)	+= rcar-rst.o
+
 obj-$(CONFIG_ARCH_R8A7779)	+= rcar-sysc.o r8a7779-sysc.o
 obj-$(CONFIG_ARCH_R8A7790)	+= rcar-sysc.o r8a7790-sysc.o
 obj-$(CONFIG_ARCH_R8A7791)	+= rcar-sysc.o r8a7791-sysc.o
diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
new file mode 100644
index 0000000000000000..a6d1c26d31675cf3
--- /dev/null
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -0,0 +1,92 @@
+/*
+ * R-Car Gen1 RESET/WDT, R-Car Gen2, Gen3, and RZ/G RST Driver
+ *
+ * Copyright (C) 2016 Glider bvba
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/soc/renesas/rcar-rst.h>
+
+struct rst_config {
+	unsigned int modemr;	/* Mode Monitoring Register Offset */
+};
+
+static const struct rst_config rcar_rst_gen1 __initconst = {
+	.modemr = 0x20,
+};
+
+static const struct rst_config rcar_rst_gen2 __initconst = {
+	.modemr = 0x60,
+};
+
+static const struct of_device_id rcar_rst_matches[] __initconst = {
+	/* RZ/G is handled like R-Car Gen2 */
+	{ .compatible = "renesas,r8a7743-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7745-rst", .data = &rcar_rst_gen2 },
+	/* R-Car Gen1 */
+	{ .compatible = "renesas,r8a7778-reset-wdt", .data = &rcar_rst_gen1 },
+	{ .compatible = "renesas,r8a7779-reset-wdt", .data = &rcar_rst_gen1 },
+	/* R-Car Gen2 */
+	{ .compatible = "renesas,r8a7790-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7791-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7792-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7793-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7794-rst", .data = &rcar_rst_gen2 },
+	/* R-Car Gen3 is handled like R-Car Gen2 */
+	{ .compatible = "renesas,r8a7795-rst", .data = &rcar_rst_gen2 },
+	{ .compatible = "renesas,r8a7796-rst", .data = &rcar_rst_gen2 },
+	{ /* sentinel */ }
+};
+
+static void __iomem *rcar_rst_base __initdata;
+static u32 saved_mode __initdata;
+
+static int __init rcar_rst_init(void)
+{
+	const struct of_device_id *match;
+	const struct rst_config *cfg;
+	struct device_node *np;
+	void __iomem *base;
+	int error = 0;
+
+	np = of_find_matching_node_and_match(NULL, rcar_rst_matches, &match);
+	if (!np)
+		return -ENODEV;
+
+	base = of_iomap(np, 0);
+	if (!base) {
+		pr_warn("%s: Cannot map regs\n", np->full_name);
+		error = -ENOMEM;
+		goto out_put;
+	}
+
+	rcar_rst_base = base;
+	cfg = match->data;
+	saved_mode = ioread32(base + cfg->modemr);
+
+	pr_debug("%s: MODE = 0x%08x\n", np->full_name, saved_mode);
+
+out_put:
+	of_node_put(np);
+	return error;
+}
+
+int __init rcar_rst_read_mode_pins(u32 *mode)
+{
+	int error;
+
+	if (!rcar_rst_base) {
+		error = rcar_rst_init();
+		if (error)
+			return error;
+	}
+
+	*mode = saved_mode;
+	return 0;
+}
diff --git a/include/linux/soc/renesas/rcar-rst.h b/include/linux/soc/renesas/rcar-rst.h
new file mode 100644
index 0000000000000000..a18e0783946b66ec
--- /dev/null
+++ b/include/linux/soc/renesas/rcar-rst.h
@@ -0,0 +1,6 @@
+#ifndef __LINUX_SOC_RENESAS_RCAR_RST_H__
+#define __LINUX_SOC_RENESAS_RCAR_RST_H__
+
+int rcar_rst_read_mode_pins(u32 *mode);
+
+#endif /* __LINUX_SOC_RENESAS_RCAR_RST_H__ */
-- 
1.9.1

[PATCH v4 03/23] ARM: dts: r8a7778: Add device node for RESET/WDT module

[Geert Uytterhoeven]

Add a device node for the RESET/WDT module, which provides a.o. reset
control, mode pin monitoring, and watchdog control.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 arch/arm/boot/dts/r8a7778.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index e571d66ea0fe1721..3d0a18abd408c76d 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -626,4 +626,9 @@
 				"sru-src6", "sru-src7", "sru-src8";
 		};
 	};
+
+	rst: reset-controller@ffcc0000 {
+		compatible = "renesas,r8a7778-reset-wdt";
+		reg = <0xffcc0000 0x40>;
+	};
 };
-- 
1.9.1

[PATCH v4 04/23] ARM: dts: r8a7779: Add device node for RESET/WDT module

[Geert Uytterhoeven]

Add a device node for the RESET/WDT module, which provides a.o. reset
control, mode pin monitoring, and watchdog control.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 arch/arm/boot/dts/r8a7779.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index b9bbcce69dfbd5b9..4a30b232624e1d24 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -595,4 +595,9 @@
 		reg = <0xffd85000 0x0200>;
 		#power-domain-cells = <1>;
 	};
+
+	rst: reset-controller@ffcc0000 {
+		compatible = "renesas,r8a7779-reset-wdt";
+		reg = <0xffcc0000 0x48>;
+	};
 };
-- 
1.9.1

[PATCH v4 05/23] ARM: dts: r8a7790: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7790.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 351fcc2f87df6b28..3f10b0bf1b08fa89 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1471,6 +1471,11 @@
 		};
 	};
 
+	rst: reset-controller@e6160000 {
+		compatible = "renesas,r8a7790-rst";
+		reg = <0 0xe6160000 0 0x0100>;
+	};
+
 	sysc: system-controller@e6180000 {
 		compatible = "renesas,r8a7790-sysc";
 		reg = <0 0xe6180000 0 0x0200>;
-- 
1.9.1

[PATCH v4 05/23] ARM: dts: r8a7790: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Acked-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
---
v4:
  - Add Acked-by,

v3:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7790.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 351fcc2f87df6b28..3f10b0bf1b08fa89 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1471,6 +1471,11 @@
 		};
 	};
 
+	rst: reset-controller@e6160000 {
+		compatible = "renesas,r8a7790-rst";
+		reg = <0 0xe6160000 0 0x0100>;
+	};
+
 	sysc: system-controller@e6180000 {
 		compatible = "renesas,r8a7790-sysc";
 		reg = <0 0xe6180000 0 0x0200>;
-- 
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 v4 06/23] ARM: dts: r8a7791: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7791.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 162b55c665a3519e..c465c79bcca6e8f3 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1482,6 +1482,11 @@
 		};
 	};
 
+	rst: reset-controller@e6160000 {
+		compatible = "renesas,r8a7791-rst";
+		reg = <0 0xe6160000 0 0x0100>;
+	};
+
 	sysc: system-controller@e6180000 {
 		compatible = "renesas,r8a7791-sysc";
 		reg = <0 0xe6180000 0 0x0200>;
-- 
1.9.1

[PATCH v4 07/23] ARM: dts: r8a7792: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v4:
  - New.
---
 arch/arm/boot/dts/r8a7792.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 713141d38b3ea960..6e1f61f65d292b0b 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -118,6 +118,11 @@
 				      IRQ_TYPE_LEVEL_LOW)>;
 		};
 
+		rst: reset-controller@e6160000 {
+			compatible = "renesas,r8a7792-rst";
+			reg = <0 0xe6160000 0 0x0100>;
+		};
+
 		sysc: system-controller@e6180000 {
 			compatible = "renesas,r8a7792-sysc";
 			reg = <0 0xe6180000 0 0x0200>;
-- 
1.9.1

[PATCH v4 07/23] ARM: dts: r8a7792: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v4:
  - New.
---
 arch/arm/boot/dts/r8a7792.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 713141d38b3ea960..6e1f61f65d292b0b 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -118,6 +118,11 @@
 				      IRQ_TYPE_LEVEL_LOW)>;
 		};
 
+		rst: reset-controller at e6160000 {
+			compatible = "renesas,r8a7792-rst";
+			reg = <0 0xe6160000 0 0x0100>;
+		};
+
 		sysc: system-controller at e6180000 {
 			compatible = "renesas,r8a7792-sysc";
 			reg = <0 0xe6180000 0 0x0200>;
-- 
1.9.1

[PATCH v4 08/23] ARM: dts: r8a7793: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7793.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 8d02aacf28926271..e4b385eccf74e95e 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1279,6 +1279,11 @@
 		};
 	};
 
+	rst: reset-controller@e6160000 {
+		compatible = "renesas,r8a7793-rst";
+		reg = <0 0xe6160000 0 0x0100>;
+	};
+
 	sysc: system-controller@e6180000 {
 		compatible = "renesas,r8a7793-sysc";
 		reg = <0 0xe6180000 0 0x0200>;
-- 
1.9.1

[PATCH v4 09/23] ARM: dts: r8a7794: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7794.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 9365580a194facc7..69e4f4fad89b2323 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1375,6 +1375,11 @@
 		};
 	};
 
+	rst: reset-controller@e6160000 {
+		compatible = "renesas,r8a7794-rst";
+		reg = <0 0xe6160000 0 0x0100>;
+	};
+
 	sysc: system-controller@e6180000 {
 		compatible = "renesas,r8a7794-sysc";
 		reg = <0 0xe6180000 0 0x0200>;
-- 
1.9.1

[PATCH v4 09/23] ARM: dts: r8a7794: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Acked-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
---
v4:
  - Add Acked-by,

v3:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,

v2:
  - Correct unit address,
  - Drop RFC status and TODO,
  - Change one-line summary prefix to match current arm-soc practices.
---
 arch/arm/boot/dts/r8a7794.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 9365580a194facc7..69e4f4fad89b2323 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1375,6 +1375,11 @@
 		};
 	};
 
+	rst: reset-controller@e6160000 {
+		compatible = "renesas,r8a7794-rst";
+		reg = <0 0xe6160000 0 0x0100>;
+	};
+
 	sysc: system-controller@e6180000 {
 		compatible = "renesas,r8a7794-sysc";
 		reg = <0 0xe6180000 0 0x0200>;
-- 
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 v4 10/23] arm64: renesas: r8a7795 dtsi: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,

v2:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 8c15040f2540d63a..625dda713548da78 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -321,6 +321,11 @@
 			#power-domain-cells = <0>;
 		};
 
+		rst: reset-controller@e6160000 {
+			compatible = "renesas,r8a7795-rst";
+			reg = <0 0xe6160000 0 0x0200>;
+		};
+
 		sysc: system-controller@e6180000 {
 			compatible = "renesas,r8a7795-sysc";
 			reg = <0 0xe6180000 0 0x0400>;
-- 
1.9.1

[PATCH v4 10/23] arm64: renesas: r8a7795 dtsi: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
  - Drop "syscon" compatible value,

v2:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 8c15040f2540d63a..625dda713548da78 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -321,6 +321,11 @@
 			#power-domain-cells = <0>;
 		};
 
+		rst: reset-controller at e6160000 {
+			compatible = "renesas,r8a7795-rst";
+			reg = <0 0xe6160000 0 0x0200>;
+		};
+
 		sysc: system-controller at e6180000 {
 			compatible = "renesas,r8a7795-sysc";
 			reg = <0 0xe6180000 0 0x0400>;
-- 
1.9.1

[PATCH v4 11/23] arm64: renesas: r8a7796 dtsi: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 9217da9835256573..75c8c55a824835bf 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -233,6 +233,11 @@
 			#power-domain-cells = <0>;
 		};
 
+		rst: reset-controller@e6160000 {
+			compatible = "renesas,r8a7796-rst";
+			reg = <0 0xe6160000 0 0x0200>;
+		};
+
 		sysc: system-controller@e6180000 {
 			compatible = "renesas,r8a7796-sysc";
 			reg = <0 0xe6180000 0 0x0400>;
-- 
1.9.1

[PATCH v4 11/23] arm64: renesas: r8a7796 dtsi: Add device node for RST module

[Geert Uytterhoeven]

Add a device node for the RST module, which provides a.o. reset control
and mode pin monitoring.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 9217da9835256573..75c8c55a824835bf 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -233,6 +233,11 @@
 			#power-domain-cells = <0>;
 		};
 
+		rst: reset-controller at e6160000 {
+			compatible = "renesas,r8a7796-rst";
+			reg = <0 0xe6160000 0 0x0200>;
+		};
+
 		sysc: system-controller at e6180000 {
 			compatible = "renesas,r8a7796-sysc";
 			reg = <0 0xe6180000 0 0x0400>;
-- 
1.9.1

[PATCH v4 12/23] clk: renesas: r8a7778: Obtain mode pin values using R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RESET/WDT module.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7778.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/clk/renesas/clk-r8a7778.c b/drivers/clk/renesas/clk-r8a7778.c
index 40e3a501a50e200f..07ea411098a75ad1 100644
--- a/drivers/clk/renesas/clk-r8a7778.c
+++ b/drivers/clk/renesas/clk-r8a7778.c
@@ -12,6 +12,7 @@
 #include <linux/clk/renesas.h>
 #include <linux/of_address.h>
 #include <linux/slab.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 struct r8a7778_cpg {
 	struct clk_onecell_data data;
@@ -83,6 +84,18 @@ static void __init r8a7778_cpg_clocks_init(struct device_node *np)
 	struct clk **clks;
 	unsigned int i;
 	int num_clks;
+	u32 mode;
+
+	if (rcar_rst_read_mode_pins(&mode))
+		return;
+
+	BUG_ON(!(mode & BIT(19)));
+
+	cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
+			 (!!(mode & BIT(12)) << 1) |
+			 (!!(mode & BIT(11)));
+	cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
+			(!!(mode & BIT(1)));
 
 	num_clks = of_property_count_strings(np, "clock-output-names");
 	if (num_clks < 0) {
-- 
1.9.1

[PATCH v4 13/23] clk: renesas: r8a7779: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RESET/WDT module.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7779.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7779.c b/drivers/clk/renesas/clk-r8a7779.c
index cf2a37df03b15e60..ca7551bcb1153c3d 100644
--- a/drivers/clk/renesas/clk-r8a7779.c
+++ b/drivers/clk/renesas/clk-r8a7779.c
@@ -18,6 +18,7 @@
 #include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 #include <dt-bindings/clock/r8a7779-clock.h>
 
@@ -127,6 +128,10 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 	struct clk **clks;
 	unsigned int i, plla_mult;
 	int num_clks;
+	u32 mode;
+
+	if (rcar_rst_read_mode_pins(&mode))
+		return;
 
 	num_clks = of_property_count_strings(np, "clock-output-names");
 	if (num_clks < 0) {
@@ -148,8 +153,8 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 	cpg->data.clks = clks;
 	cpg->data.clk_num = num_clks;
 
-	config = &cpg_clk_configs[CPG_CLK_CONFIG_INDEX(cpg_mode)];
-	plla_mult = cpg_plla_mult[CPG_PLLA_MULT_INDEX(cpg_mode)];
+	config = &cpg_clk_configs[CPG_CLK_CONFIG_INDEX(mode)];
+	plla_mult = cpg_plla_mult[CPG_PLLA_MULT_INDEX(mode)];
 
 	for (i = 0; i < num_clks; ++i) {
 		const char *name;
-- 
1.9.1

[PATCH v4 13/23] clk: renesas: r8a7779: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RESET/WDT module.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7779.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7779.c b/drivers/clk/renesas/clk-r8a7779.c
index cf2a37df03b15e60..ca7551bcb1153c3d 100644
--- a/drivers/clk/renesas/clk-r8a7779.c
+++ b/drivers/clk/renesas/clk-r8a7779.c
@@ -18,6 +18,7 @@
 #include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 #include <dt-bindings/clock/r8a7779-clock.h>
 
@@ -127,6 +128,10 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 	struct clk **clks;
 	unsigned int i, plla_mult;
 	int num_clks;
+	u32 mode;
+
+	if (rcar_rst_read_mode_pins(&mode))
+		return;
 
 	num_clks = of_property_count_strings(np, "clock-output-names");
 	if (num_clks < 0) {
@@ -148,8 +153,8 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 	cpg->data.clks = clks;
 	cpg->data.clk_num = num_clks;
 
-	config = &cpg_clk_configs[CPG_CLK_CONFIG_INDEX(cpg_mode)];
-	plla_mult = cpg_plla_mult[CPG_PLLA_MULT_INDEX(cpg_mode)];
+	config = &cpg_clk_configs[CPG_CLK_CONFIG_INDEX(mode)];
+	plla_mult = cpg_plla_mult[CPG_PLLA_MULT_INDEX(mode)];
 
 	for (i = 0; i < num_clks; ++i) {
 		const char *name;
-- 
1.9.1

[PATCH v4 13/23] clk: renesas: r8a7779: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RESET/WDT module.

Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Acked-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7779.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7779.c b/drivers/clk/renesas/clk-r8a7779.c
index cf2a37df03b15e60..ca7551bcb1153c3d 100644
--- a/drivers/clk/renesas/clk-r8a7779.c
+++ b/drivers/clk/renesas/clk-r8a7779.c
@@ -18,6 +18,7 @@
 #include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 #include <dt-bindings/clock/r8a7779-clock.h>
 
@@ -127,6 +128,10 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 	struct clk **clks;
 	unsigned int i, plla_mult;
 	int num_clks;
+	u32 mode;
+
+	if (rcar_rst_read_mode_pins(&mode))
+		return;
 
 	num_clks = of_property_count_strings(np, "clock-output-names");
 	if (num_clks < 0) {
@@ -148,8 +153,8 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 	cpg->data.clks = clks;
 	cpg->data.clk_num = num_clks;
 
-	config = &cpg_clk_configs[CPG_CLK_CONFIG_INDEX(cpg_mode)];
-	plla_mult = cpg_plla_mult[CPG_PLLA_MULT_INDEX(cpg_mode)];
+	config = &cpg_clk_configs[CPG_CLK_CONFIG_INDEX(mode)];
+	plla_mult = cpg_plla_mult[CPG_PLLA_MULT_INDEX(mode)];
 
 	for (i = 0; i < num_clks; ++i) {
 		const char *name;
-- 
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 v4 14/23] clk: renesas: rcar-gen2: Obtain mode pin values using RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Fall back to our own private copy of rcar_gen2_read_mode_pins() for
backward-compatibility with old DTs.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,
  - Use our own private copy of rcar_gen2_read_mode_pins() instead of
    the one in the R-Car Gen2 platform code, as the latter is planned to
    be removed,

v3:
  -  Use the R-Car RST driver instead of syscon/regmap and the
     "renesas,modemr" property in DT,

v2:
  - drivers/clk/shmobile/ was renamed to drivers/clk/renesas/.
---
 drivers/clk/renesas/clk-rcar-gen2.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/clk/renesas/clk-rcar-gen2.c b/drivers/clk/renesas/clk-rcar-gen2.c
index 00e6aba4b9c09596..3291fd430ad4e215 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -19,6 +19,7 @@
 #include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 struct rcar_gen2_cpg {
 	struct clk_onecell_data data;
@@ -364,6 +365,23 @@ struct cpg_pll_config {
 						 4, 0, table, &cpg->lock);
 }
 
+/*
+ * Reset register definitions.
+ */
+#define MODEMR	0xe6160060
+
+static u32 __init rcar_gen2_read_mode_pins(void)
+{
+	void __iomem *modemr = ioremap_nocache(MODEMR, 4);
+	u32 mode;
+
+	BUG_ON(!modemr);
+	mode = ioread32(modemr);
+	iounmap(modemr);
+
+	return mode;
+}
+
 static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 {
 	const struct cpg_pll_config *config;
@@ -372,6 +390,13 @@ static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 	unsigned int i;
 	int num_clks;
 
+	if (rcar_rst_read_mode_pins(&cpg_mode)) {
+		/* Backward-compatibility with old DT */
+		pr_warn("%s: failed to obtain mode pins from RST\n",
+			np->full_name);
+		cpg_mode = rcar_gen2_read_mode_pins();
+	}
+
 	num_clks = of_property_count_strings(np, "clock-output-names");
 	if (num_clks < 0) {
 		pr_err("%s: failed to count clocks\n", __func__);
-- 
1.9.1

[PATCH v4 14/23] clk: renesas: rcar-gen2: Obtain mode pin values using RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Fall back to our own private copy of rcar_gen2_read_mode_pins() for
backward-compatibility with old DTs.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,
  - Use our own private copy of rcar_gen2_read_mode_pins() instead of
    the one in the R-Car Gen2 platform code, as the latter is planned to
    be removed,

v3:
  -  Use the R-Car RST driver instead of syscon/regmap and the
     "renesas,modemr" property in DT,

v2:
  - drivers/clk/shmobile/ was renamed to drivers/clk/renesas/.
---
 drivers/clk/renesas/clk-rcar-gen2.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/clk/renesas/clk-rcar-gen2.c b/drivers/clk/renesas/clk-rcar-gen2.c
index 00e6aba4b9c09596..3291fd430ad4e215 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -19,6 +19,7 @@
 #include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 struct rcar_gen2_cpg {
 	struct clk_onecell_data data;
@@ -364,6 +365,23 @@ struct cpg_pll_config {
 						 4, 0, table, &cpg->lock);
 }
 
+/*
+ * Reset register definitions.
+ */
+#define MODEMR	0xe6160060
+
+static u32 __init rcar_gen2_read_mode_pins(void)
+{
+	void __iomem *modemr = ioremap_nocache(MODEMR, 4);
+	u32 mode;
+
+	BUG_ON(!modemr);
+	mode = ioread32(modemr);
+	iounmap(modemr);
+
+	return mode;
+}
+
 static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 {
 	const struct cpg_pll_config *config;
@@ -372,6 +390,13 @@ static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 	unsigned int i;
 	int num_clks;
 
+	if (rcar_rst_read_mode_pins(&cpg_mode)) {
+		/* Backward-compatibility with old DT */
+		pr_warn("%s: failed to obtain mode pins from RST\n",
+			np->full_name);
+		cpg_mode = rcar_gen2_read_mode_pins();
+	}
+
 	num_clks = of_property_count_strings(np, "clock-output-names");
 	if (num_clks < 0) {
 		pr_err("%s: failed to count clocks\n", __func__);
-- 
1.9.1

[PATCH v4 14/23] clk: renesas: rcar-gen2: Obtain mode pin values using RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Fall back to our own private copy of rcar_gen2_read_mode_pins() for
backward-compatibility with old DTs.

Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Acked-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
---
v4:
  - Add Acked-by,
  - Use our own private copy of rcar_gen2_read_mode_pins() instead of
    the one in the R-Car Gen2 platform code, as the latter is planned to
    be removed,

v3:
  -  Use the R-Car RST driver instead of syscon/regmap and the
     "renesas,modemr" property in DT,

v2:
  - drivers/clk/shmobile/ was renamed to drivers/clk/renesas/.
---
 drivers/clk/renesas/clk-rcar-gen2.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/clk/renesas/clk-rcar-gen2.c b/drivers/clk/renesas/clk-rcar-gen2.c
index 00e6aba4b9c09596..3291fd430ad4e215 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -19,6 +19,7 @@
 #include <linux/of_address.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 struct rcar_gen2_cpg {
 	struct clk_onecell_data data;
@@ -364,6 +365,23 @@ struct cpg_pll_config {
 						 4, 0, table, &cpg->lock);
 }
 
+/*
+ * Reset register definitions.
+ */
+#define MODEMR	0xe6160060
+
+static u32 __init rcar_gen2_read_mode_pins(void)
+{
+	void __iomem *modemr = ioremap_nocache(MODEMR, 4);
+	u32 mode;
+
+	BUG_ON(!modemr);
+	mode = ioread32(modemr);
+	iounmap(modemr);
+
+	return mode;
+}
+
 static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 {
 	const struct cpg_pll_config *config;
@@ -372,6 +390,13 @@ static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 	unsigned int i;
 	int num_clks;
 
+	if (rcar_rst_read_mode_pins(&cpg_mode)) {
+		/* Backward-compatibility with old DT */
+		pr_warn("%s: failed to obtain mode pins from RST\n",
+			np->full_name);
+		cpg_mode = rcar_gen2_read_mode_pins();
+	}
+
 	num_clks = of_property_count_strings(np, "clock-output-names");
 	if (num_clks < 0) {
 		pr_err("%s: failed to count clocks\n", __func__);
-- 
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 v4 15/23] clk: renesas: r8a7795: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
v4:
  - Add Acked-by, Reviewed-by,

v3:
  - New.
---
 drivers/clk/renesas/r8a7795-cpg-mssr.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index f255e451e8cafbbf..726c3d7940b491b9 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -15,6 +15,7 @@
 #include <linux/device.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 #include <dt-bindings/clock/r8a7795-cpg-mssr.h>
 
@@ -311,7 +312,12 @@ enum clk_ids {
 static int __init r8a7795_cpg_mssr_init(struct device *dev)
 {
 	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
-	u32 cpg_mode = rcar_gen3_read_mode_pins();
+	u32 cpg_mode;
+	int error;
+
+	error = rcar_rst_read_mode_pins(&cpg_mode);
+	if (error)
+		return error;
 
 	cpg_pll_config = &cpg_pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
 	if (!cpg_pll_config->extal_div) {
-- 
1.9.1

[PATCH v4 15/23] clk: renesas: r8a7795: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
v4:
  - Add Acked-by, Reviewed-by,

v3:
  - New.
---
 drivers/clk/renesas/r8a7795-cpg-mssr.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index f255e451e8cafbbf..726c3d7940b491b9 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -15,6 +15,7 @@
 #include <linux/device.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 #include <dt-bindings/clock/r8a7795-cpg-mssr.h>
 
@@ -311,7 +312,12 @@ enum clk_ids {
 static int __init r8a7795_cpg_mssr_init(struct device *dev)
 {
 	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
-	u32 cpg_mode = rcar_gen3_read_mode_pins();
+	u32 cpg_mode;
+	int error;
+
+	error = rcar_rst_read_mode_pins(&cpg_mode);
+	if (error)
+		return error;
 
 	cpg_pll_config = &cpg_pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
 	if (!cpg_pll_config->extal_div) {
-- 
1.9.1

[PATCH v4 16/23] clk: renesas: r8a7796: Obtain mode pin values from R-Car RST driver

[Geert Uytterhoeven]

Obtain the values of the mode pins from the R-Car RST driver, which
relies on the presence in DT of a device node for the RST module.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
v4:
  - Add Acked-by, Reviewed-by,

v3:
  - New.
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index eb347ed265f2adfa..1c144b21869df39c 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -16,6 +16,7 @@
 #include <linux/device.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/soc/renesas/rcar-rst.h>
 
 #include <dt-bindings/clock/r8a7796-cpg-mssr.h>
 
@@ -190,7 +191,12 @@ enum clk_ids {
 static int __init r8a7796_cpg_mssr_init(struct device *dev)
 {
 	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
-	u32 cpg_mode = rcar_gen3_read_mode_pins();
+	u32 cpg_mode;
+	int error;
+
+	error = rcar_rst_read_mode_pins(&cpg_mode);
+	if (error)
+		return error;
 
 	cpg_pll_config = &cpg_pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
 	if (!cpg_pll_config->extal_div) {
-- 
1.9.1

[PATCH v4 17/23] clk: renesas: rcar-gen3-cpg: Remove obsolete rcar_gen3_read_mode_pins()

[Geert Uytterhoeven]

All R-Car Gen3 clock drivers now obtain the values of the mode pins from
the R-Car RST driver.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
v4:
  - Add Acked-by, Reviewed-by,

v3:
  - New.
---
 drivers/clk/renesas/rcar-gen3-cpg.c | 17 -----------------
 drivers/clk/renesas/rcar-gen3-cpg.h |  1 -
 2 files changed, 18 deletions(-)

diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c b/drivers/clk/renesas/rcar-gen3-cpg.c
index bb4f2f9a8c2f5ba8..9d76076da4948fc4 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -333,23 +333,6 @@ struct clk * __init rcar_gen3_cpg_clk_register(struct device *dev,
 					 __clk_get_name(parent), 0, mult, div);
 }
 
-/*
- * Reset register definitions.
- */
-#define MODEMR	0xe6160060
-
-u32 __init rcar_gen3_read_mode_pins(void)
-{
-	void __iomem *modemr = ioremap_nocache(MODEMR, 4);
-	u32 mode;
-
-	BUG_ON(!modemr);
-	mode = ioread32(modemr);
-	iounmap(modemr);
-
-	return mode;
-}
-
 int __init rcar_gen3_cpg_init(const struct rcar_gen3_cpg_pll_config *config,
 			      unsigned int clk_extalr)
 {
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.h b/drivers/clk/renesas/rcar-gen3-cpg.h
index f699085147d1aece..f788f481dd42cdf6 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.h
+++ b/drivers/clk/renesas/rcar-gen3-cpg.h
@@ -33,7 +33,6 @@ struct rcar_gen3_cpg_pll_config {
 
 #define CPG_RCKCR	0x240
 
-u32 rcar_gen3_read_mode_pins(void);
 struct clk *rcar_gen3_cpg_clk_register(struct device *dev,
 	const struct cpg_core_clk *core, const struct cpg_mssr_info *info,
 	struct clk **clks, void __iomem *base);
-- 
1.9.1

[PATCH v4 18/23] ARM: shmobile: r8a7778: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car M1A CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just remove the .init_time() callback, the
generic ARM code will take care of calling of_clk_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 arch/arm/mach-shmobile/setup-r8a7778.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index cf236db686a9dd47..7fa4a0b5f6549287 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -15,7 +15,6 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/clk/renesas.h>
 #include <linux/io.h>
 #include <linux/irqchip.h>
 
@@ -23,19 +22,6 @@
 
 #include "common.h"
 
-#define MODEMR 0xffcc0020
-
-static void __init r8a7778_timer_init(void)
-{
-	u32 mode;
-	void __iomem *modemr = ioremap_nocache(MODEMR, 4);
-
-	BUG_ON(!modemr);
-	mode = ioread32(modemr);
-	iounmap(modemr);
-	r8a7778_clocks_init(mode);
-}
-
 #define INT2SMSKCR0	0x82288 /* 0xfe782288 */
 #define INT2SMSKCR1	0x8228c /* 0xfe78228c */
 
@@ -70,6 +56,5 @@ static void __init r8a7778_init_irq_dt(void)
 	.init_early	= shmobile_init_delay,
 	.init_irq	= r8a7778_init_irq_dt,
 	.init_late	= shmobile_init_late,
-	.init_time	= r8a7778_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
 MACHINE_END
-- 
1.9.1

[PATCH v4 19/23] ARM: shmobile: r8a7779: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car H1 CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just remove the .init_time() callback, the
generic ARM code will take care of calling of_clk_init() and
clocksource_probe().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 arch/arm/mach-shmobile/setup-r8a7779.c | 27 ---------------------------
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index 0007ff51d180379f..0686112f243525b6 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -14,8 +14,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
-#include <linux/clk/renesas.h>
-#include <linux/clocksource.h>
 #include <linux/init.h>
 #include <linux/irq.h>
 #include <linux/irqchip.h>
@@ -76,30 +74,6 @@ static void __init r8a7779_init_irq_dt(void)
 	__raw_writel(0x003fee3f, INT2SMSKCR4);
 }
 
-#define MODEMR		0xffcc0020
-
-static u32 __init r8a7779_read_mode_pins(void)
-{
-	static u32 mode;
-	static bool mode_valid;
-
-	if (!mode_valid) {
-		void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
-		BUG_ON(!modemr);
-		mode = ioread32(modemr);
-		iounmap(modemr);
-		mode_valid = true;
-	}
-
-	return mode;
-}
-
-static void __init r8a7779_init_time(void)
-{
-	r8a7779_clocks_init(r8a7779_read_mode_pins());
-	clocksource_probe();
-}
-
 static const char *const r8a7779_compat_dt[] __initconst = {
 	"renesas,r8a7779",
 	NULL,
@@ -109,7 +83,6 @@ static void __init r8a7779_init_time(void)
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
 	.init_early	= shmobile_init_delay,
-	.init_time	= r8a7779_init_time,
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= r8a7779_compat_dt,
-- 
1.9.1

[PATCH v4 19/23] ARM: shmobile: r8a7779: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car H1 CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just remove the .init_time() callback, the
generic ARM code will take care of calling of_clk_init() and
clocksource_probe().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 arch/arm/mach-shmobile/setup-r8a7779.c | 27 ---------------------------
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index 0007ff51d180379f..0686112f243525b6 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -14,8 +14,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
-#include <linux/clk/renesas.h>
-#include <linux/clocksource.h>
 #include <linux/init.h>
 #include <linux/irq.h>
 #include <linux/irqchip.h>
@@ -76,30 +74,6 @@ static void __init r8a7779_init_irq_dt(void)
 	__raw_writel(0x003fee3f, INT2SMSKCR4);
 }
 
-#define MODEMR		0xffcc0020
-
-static u32 __init r8a7779_read_mode_pins(void)
-{
-	static u32 mode;
-	static bool mode_valid;
-
-	if (!mode_valid) {
-		void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
-		BUG_ON(!modemr);
-		mode = ioread32(modemr);
-		iounmap(modemr);
-		mode_valid = true;
-	}
-
-	return mode;
-}
-
-static void __init r8a7779_init_time(void)
-{
-	r8a7779_clocks_init(r8a7779_read_mode_pins());
-	clocksource_probe();
-}
-
 static const char *const r8a7779_compat_dt[] __initconst = {
 	"renesas,r8a7779",
 	NULL,
@@ -109,7 +83,6 @@ static void __init r8a7779_init_time(void)
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
 	.init_early	= shmobile_init_delay,
-	.init_time	= r8a7779_init_time,
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= r8a7779_compat_dt,
-- 
1.9.1

[PATCH v4 19/23] ARM: shmobile: r8a7779: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car H1 CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just remove the .init_time() callback, the
generic ARM code will take care of calling of_clk_init() and
clocksource_probe().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 arch/arm/mach-shmobile/setup-r8a7779.c | 27 ---------------------------
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index 0007ff51d180379f..0686112f243525b6 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -14,8 +14,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
-#include <linux/clk/renesas.h>
-#include <linux/clocksource.h>
 #include <linux/init.h>
 #include <linux/irq.h>
 #include <linux/irqchip.h>
@@ -76,30 +74,6 @@ static void __init r8a7779_init_irq_dt(void)
 	__raw_writel(0x003fee3f, INT2SMSKCR4);
 }
 
-#define MODEMR		0xffcc0020
-
-static u32 __init r8a7779_read_mode_pins(void)
-{
-	static u32 mode;
-	static bool mode_valid;
-
-	if (!mode_valid) {
-		void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
-		BUG_ON(!modemr);
-		mode = ioread32(modemr);
-		iounmap(modemr);
-		mode_valid = true;
-	}
-
-	return mode;
-}
-
-static void __init r8a7779_init_time(void)
-{
-	r8a7779_clocks_init(r8a7779_read_mode_pins());
-	clocksource_probe();
-}
-
 static const char *const r8a7779_compat_dt[] __initconst = {
 	"renesas,r8a7779",
 	NULL,
@@ -109,7 +83,6 @@ static void __init r8a7779_init_time(void)
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
 	.init_early	= shmobile_init_delay,
-	.init_time	= r8a7779_init_time,
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= r8a7779_compat_dt,
-- 
1.9.1

[PATCH v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car Gen2 CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just call of_clk_init() instead.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,
  - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
    from DT",
  - Remove the call to rcar_gen2_read_mode_pins(),

v3:
  - Drop "select MFD_SYSCON", as the clock driver no longer uses syscon,

v2:
  - Kill compiler warning if CONFIG_ARM_ARCH_TIMER is not enabled.
---
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index afb9fdcd3d9084e2..b527258e0a62e806 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -15,7 +15,7 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/clk/renesas.h>
+#include <linux/clk-provider.h>
 #include <linux/clocksource.h>
 #include <linux/device.h>
 #include <linux/dma-contiguous.h>
@@ -71,7 +71,6 @@ static unsigned int __init get_extal_freq(void)
 
 void __init rcar_gen2_timer_init(void)
 {
-	u32 mode = rcar_gen2_read_mode_pins();
 #ifdef CONFIG_ARM_ARCH_TIMER
 	void __iomem *base;
 	u32 freq;
@@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
 	iounmap(base);
 #endif /* CONFIG_ARM_ARCH_TIMER */
 
-	rcar_gen2_clocks_init(mode);
+	of_clk_init(NULL);
 	clocksource_probe();
 }
 
-- 
1.9.1

[PATCH v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

Now the R-Car Gen2 CPG clock driver obtains the state of the mode pins
from the R-Car RST driver, there's no longer a need to pass this state
explicitly. Hence we can just call of_clk_init() instead.

Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Acked-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
---
v4:
  - Add Acked-by,
  - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
    from DT",
  - Remove the call to rcar_gen2_read_mode_pins(),

v3:
  - Drop "select MFD_SYSCON", as the clock driver no longer uses syscon,

v2:
  - Kill compiler warning if CONFIG_ARM_ARCH_TIMER is not enabled.
---
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index afb9fdcd3d9084e2..b527258e0a62e806 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -15,7 +15,7 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/clk/renesas.h>
+#include <linux/clk-provider.h>
 #include <linux/clocksource.h>
 #include <linux/device.h>
 #include <linux/dma-contiguous.h>
@@ -71,7 +71,6 @@ static unsigned int __init get_extal_freq(void)
 
 void __init rcar_gen2_timer_init(void)
 {
-	u32 mode = rcar_gen2_read_mode_pins();
 #ifdef CONFIG_ARM_ARCH_TIMER
 	void __iomem *base;
 	u32 freq;
@@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
 	iounmap(base);
 #endif /* CONFIG_ARM_ARCH_TIMER */
 
-	rcar_gen2_clocks_init(mode);
+	of_clk_init(NULL);
 	clocksource_probe();
 }
 
-- 
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

Re: [PATCH v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver

[Sergei Shtylyov]

On 10/21/2016 04:17 PM, Geert Uytterhoeven wrote:

> Now the R-Car Gen2 CPG clock driver obtains the state of the mode pins
> from the R-Car RST driver, there's no longer a need to pass this state
> explicitly. Hence we can just call of_clk_init() instead.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> ---
> v4:
>   - Add Acked-by,
>   - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
>     from DT",
>   - Remove the call to rcar_gen2_read_mode_pins(),
>
> v3:
>   - Drop "select MFD_SYSCON", as the clock driver no longer uses syscon,
>
> v2:
>   - Kill compiler warning if CONFIG_ARM_ARCH_TIMER is not enabled.
> ---
>  arch/arm/mach-shmobile/setup-rcar-gen2.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> index afb9fdcd3d9084e2..b527258e0a62e806 100644
> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
[...]
> @@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
>  	iounmap(base);
>  #endif /* CONFIG_ARM_ARCH_TIMER */
>
> -	rcar_gen2_clocks_init(mode);
> +	of_clk_init(NULL);
>  	clocksource_probe();
>  }
>

   This hunk no longer applies to devel.

MBR, Sergei

[PATCH v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver

[Sergei Shtylyov]

On 10/21/2016 04:17 PM, Geert Uytterhoeven wrote:

> Now the R-Car Gen2 CPG clock driver obtains the state of the mode pins
> from the R-Car RST driver, there's no longer a need to pass this state
> explicitly. Hence we can just call of_clk_init() instead.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> ---
> v4:
>   - Add Acked-by,
>   - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
>     from DT",
>   - Remove the call to rcar_gen2_read_mode_pins(),
>
> v3:
>   - Drop "select MFD_SYSCON", as the clock driver no longer uses syscon,
>
> v2:
>   - Kill compiler warning if CONFIG_ARM_ARCH_TIMER is not enabled.
> ---
>  arch/arm/mach-shmobile/setup-rcar-gen2.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> index afb9fdcd3d9084e2..b527258e0a62e806 100644
> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
[...]
> @@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
>  	iounmap(base);
>  #endif /* CONFIG_ARM_ARCH_TIMER */
>
> -	rcar_gen2_clocks_init(mode);
> +	of_clk_init(NULL);
>  	clocksource_probe();
>  }
>

   This hunk no longer applies to devel.

MBR, Sergei

Re: [PATCH v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

On Tue, Nov 1, 2016 at 2:35 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
>
> [...]
>>
>> @@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
>>         iounmap(base);
>>  #endif /* CONFIG_ARM_ARCH_TIMER */
>>
>> -       rcar_gen2_clocks_init(mode);
>> +       of_clk_init(NULL);
>>         clocksource_probe();
>>  }
>>
>
>   This hunk no longer applies to devel.

Indeed, but I can't update it, as we can't have all mach-shmobile changes in
the clock tree. So Simon will have to resolve the conflict later.

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 v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

On Tue, Nov 1, 2016 at 2:35 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
>
> [...]
>>
>> @@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
>>         iounmap(base);
>>  #endif /* CONFIG_ARM_ARCH_TIMER */
>>
>> -       rcar_gen2_clocks_init(mode);
>> +       of_clk_init(NULL);
>>         clocksource_probe();
>>  }
>>
>
>   This hunk no longer applies to devel.

Indeed, but I can't update it, as we can't have all mach-shmobile changes in
the clock tree. So Simon will have to resolve the conflict later.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver

[Geert Uytterhoeven]

On Tue, Nov 1, 2016 at 2:35 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
>
> [...]
>>
>> @@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
>>         iounmap(base);
>>  #endif /* CONFIG_ARM_ARCH_TIMER */
>>
>> -       rcar_gen2_clocks_init(mode);
>> +       of_clk_init(NULL);
>>         clocksource_probe();
>>  }
>>
>
>   This hunk no longer applies to devel.

Indeed, but I can't update it, as we can't have all mach-shmobile changes in
the clock tree. So Simon will have to resolve the conflict later.

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 v4 21/23] clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()

[Geert Uytterhoeven]

The R-Car M1A board code no longer calls r8a7778_clocks_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7778.c | 13 -------------
 include/linux/clk/renesas.h       |  1 -
 2 files changed, 14 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7778.c b/drivers/clk/renesas/clk-r8a7778.c
index 07ea411098a75ad1..886a8380e91247a1 100644
--- a/drivers/clk/renesas/clk-r8a7778.c
+++ b/drivers/clk/renesas/clk-r8a7778.c
@@ -143,16 +143,3 @@ static void __init r8a7778_cpg_clocks_init(struct device_node *np)
 
 CLK_OF_DECLARE(r8a7778_cpg_clks, "renesas,r8a7778-cpg-clocks",
 	       r8a7778_cpg_clocks_init);
-
-void __init r8a7778_clocks_init(u32 mode)
-{
-	BUG_ON(!(mode & BIT(19)));
-
-	cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
-			 (!!(mode & BIT(12)) << 1) |
-			 (!!(mode & BIT(11)));
-	cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
-			(!!(mode & BIT(1)));
-
-	of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index ba6fa4148515e5c9..2b663bba1adcc7c1 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,7 +20,6 @@
 struct device_node;
 struct generic_pm_domain;
 
-void r8a7778_clocks_init(u32 mode);
 void r8a7779_clocks_init(u32 mode);
 void rcar_gen2_clocks_init(u32 mode);
 
-- 
1.9.1

[PATCH v4 21/23] clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()

[Geert Uytterhoeven]

The R-Car M1A board code no longer calls r8a7778_clocks_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7778.c | 13 -------------
 include/linux/clk/renesas.h       |  1 -
 2 files changed, 14 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7778.c b/drivers/clk/renesas/clk-r8a7778.c
index 07ea411098a75ad1..886a8380e91247a1 100644
--- a/drivers/clk/renesas/clk-r8a7778.c
+++ b/drivers/clk/renesas/clk-r8a7778.c
@@ -143,16 +143,3 @@ static void __init r8a7778_cpg_clocks_init(struct device_node *np)
 
 CLK_OF_DECLARE(r8a7778_cpg_clks, "renesas,r8a7778-cpg-clocks",
 	       r8a7778_cpg_clocks_init);
-
-void __init r8a7778_clocks_init(u32 mode)
-{
-	BUG_ON(!(mode & BIT(19)));
-
-	cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
-			 (!!(mode & BIT(12)) << 1) |
-			 (!!(mode & BIT(11)));
-	cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
-			(!!(mode & BIT(1)));
-
-	of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index ba6fa4148515e5c9..2b663bba1adcc7c1 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,7 +20,6 @@
 struct device_node;
 struct generic_pm_domain;
 
-void r8a7778_clocks_init(u32 mode);
 void r8a7779_clocks_init(u32 mode);
 void rcar_gen2_clocks_init(u32 mode);
 
-- 
1.9.1

[PATCH v4 22/23] clk: renesas: r8a7779: Remove obsolete r8a7779_clocks_init()

[Geert Uytterhoeven]

The R-Car H1 board code no longer calls r8a7779_clocks_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7779.c | 9 ---------
 include/linux/clk/renesas.h       | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7779.c b/drivers/clk/renesas/clk-r8a7779.c
index ca7551bcb1153c3d..27fbfafaf2cd0353 100644
--- a/drivers/clk/renesas/clk-r8a7779.c
+++ b/drivers/clk/renesas/clk-r8a7779.c
@@ -89,8 +89,6 @@ struct cpg_clk_config {
  * Initialization
  */
 
-static u32 cpg_mode __initdata;
-
 static struct clk * __init
 r8a7779_cpg_register_clock(struct device_node *np, struct r8a7779_cpg *cpg,
 			   const struct cpg_clk_config *config,
@@ -178,10 +176,3 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 }
 CLK_OF_DECLARE(r8a7779_cpg_clks, "renesas,r8a7779-cpg-clocks",
 	       r8a7779_cpg_clocks_init);
-
-void __init r8a7779_clocks_init(u32 mode)
-{
-	cpg_mode = mode;
-
-	of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 2b663bba1adcc7c1..9e969941f3f62878 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,7 +20,6 @@
 struct device_node;
 struct generic_pm_domain;
 
-void r8a7779_clocks_init(u32 mode);
 void rcar_gen2_clocks_init(u32 mode);
 
 void cpg_mstp_add_clk_domain(struct device_node *np);
-- 
1.9.1

[PATCH v4 22/23] clk: renesas: r8a7779: Remove obsolete r8a7779_clocks_init()

[Geert Uytterhoeven]

The R-Car H1 board code no longer calls r8a7779_clocks_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7779.c | 9 ---------
 include/linux/clk/renesas.h       | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7779.c b/drivers/clk/renesas/clk-r8a7779.c
index ca7551bcb1153c3d..27fbfafaf2cd0353 100644
--- a/drivers/clk/renesas/clk-r8a7779.c
+++ b/drivers/clk/renesas/clk-r8a7779.c
@@ -89,8 +89,6 @@ struct cpg_clk_config {
  * Initialization
  */
 
-static u32 cpg_mode __initdata;
-
 static struct clk * __init
 r8a7779_cpg_register_clock(struct device_node *np, struct r8a7779_cpg *cpg,
 			   const struct cpg_clk_config *config,
@@ -178,10 +176,3 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 }
 CLK_OF_DECLARE(r8a7779_cpg_clks, "renesas,r8a7779-cpg-clocks",
 	       r8a7779_cpg_clocks_init);
-
-void __init r8a7779_clocks_init(u32 mode)
-{
-	cpg_mode = mode;
-
-	of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 2b663bba1adcc7c1..9e969941f3f62878 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,7 +20,6 @@
 struct device_node;
 struct generic_pm_domain;
 
-void r8a7779_clocks_init(u32 mode);
 void rcar_gen2_clocks_init(u32 mode);
 
 void cpg_mstp_add_clk_domain(struct device_node *np);
-- 
1.9.1

[PATCH v4 22/23] clk: renesas: r8a7779: Remove obsolete r8a7779_clocks_init()

[Geert Uytterhoeven]

The R-Car H1 board code no longer calls r8a7779_clocks_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - New.
---
 drivers/clk/renesas/clk-r8a7779.c | 9 ---------
 include/linux/clk/renesas.h       | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/clk/renesas/clk-r8a7779.c b/drivers/clk/renesas/clk-r8a7779.c
index ca7551bcb1153c3d..27fbfafaf2cd0353 100644
--- a/drivers/clk/renesas/clk-r8a7779.c
+++ b/drivers/clk/renesas/clk-r8a7779.c
@@ -89,8 +89,6 @@ struct cpg_clk_config {
  * Initialization
  */
 
-static u32 cpg_mode __initdata;
-
 static struct clk * __init
 r8a7779_cpg_register_clock(struct device_node *np, struct r8a7779_cpg *cpg,
 			   const struct cpg_clk_config *config,
@@ -178,10 +176,3 @@ static void __init r8a7779_cpg_clocks_init(struct device_node *np)
 }
 CLK_OF_DECLARE(r8a7779_cpg_clks, "renesas,r8a7779-cpg-clocks",
 	       r8a7779_cpg_clocks_init);
-
-void __init r8a7779_clocks_init(u32 mode)
-{
-	cpg_mode = mode;
-
-	of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 2b663bba1adcc7c1..9e969941f3f62878 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,7 +20,6 @@
 struct device_node;
 struct generic_pm_domain;
 
-void r8a7779_clocks_init(u32 mode);
 void rcar_gen2_clocks_init(u32 mode);
 
 void cpg_mstp_add_clk_domain(struct device_node *np);
-- 
1.9.1

[PATCH v4 23/23] clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init()

[Geert Uytterhoeven]

The R-Car Gen2 board code no longer calls rcar_gen2_clocks_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Rebased,

v2:
  - No changes.
---
 drivers/clk/renesas/clk-rcar-gen2.c | 7 -------
 include/linux/clk/renesas.h         | 2 --
 2 files changed, 9 deletions(-)

diff --git a/drivers/clk/renesas/clk-rcar-gen2.c b/drivers/clk/renesas/clk-rcar-gen2.c
index 3291fd430ad4e215..f39519edc645ca87 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -445,10 +445,3 @@ static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 }
 CLK_OF_DECLARE(rcar_gen2_cpg_clks, "renesas,rcar-gen2-cpg-clocks",
 	       rcar_gen2_cpg_clocks_init);
-
-void __init rcar_gen2_clocks_init(u32 mode)
-{
-	cpg_mode = mode;
-
-	of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 9e969941f3f62878..9ebf1f8243bb57af 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,8 +20,6 @@
 struct device_node;
 struct generic_pm_domain;
 
-void rcar_gen2_clocks_init(u32 mode);
-
 void cpg_mstp_add_clk_domain(struct device_node *np);
 #ifdef CONFIG_CLK_RENESAS_CPG_MSTP
 int cpg_mstp_attach_dev(struct generic_pm_domain *unused, struct device *dev);
-- 
1.9.1

[PATCH v4 23/23] clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init()

[Geert Uytterhoeven]

The R-Car Gen2 board code no longer calls rcar_gen2_clocks_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Rebased,

v2:
  - No changes.
---
 drivers/clk/renesas/clk-rcar-gen2.c | 7 -------
 include/linux/clk/renesas.h         | 2 --
 2 files changed, 9 deletions(-)

diff --git a/drivers/clk/renesas/clk-rcar-gen2.c b/drivers/clk/renesas/clk-rcar-gen2.c
index 3291fd430ad4e215..f39519edc645ca87 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -445,10 +445,3 @@ static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 }
 CLK_OF_DECLARE(rcar_gen2_cpg_clks, "renesas,rcar-gen2-cpg-clocks",
 	       rcar_gen2_cpg_clocks_init);
-
-void __init rcar_gen2_clocks_init(u32 mode)
-{
-	cpg_mode = mode;
-
-	of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 9e969941f3f62878..9ebf1f8243bb57af 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,8 +20,6 @@
 struct device_node;
 struct generic_pm_domain;
 
-void rcar_gen2_clocks_init(u32 mode);
-
 void cpg_mstp_add_clk_domain(struct device_node *np);
 #ifdef CONFIG_CLK_RENESAS_CPG_MSTP
 int cpg_mstp_attach_dev(struct generic_pm_domain *unused, struct device *dev);
-- 
1.9.1

[PATCH v4 23/23] clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init()

[Geert Uytterhoeven]

The R-Car Gen2 board code no longer calls rcar_gen2_clocks_init().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
---
v4:
  - Add Acked-by,

v3:
  - Rebased,

v2:
  - No changes.
---
 drivers/clk/renesas/clk-rcar-gen2.c | 7 -------
 include/linux/clk/renesas.h         | 2 --
 2 files changed, 9 deletions(-)

diff --git a/drivers/clk/renesas/clk-rcar-gen2.c b/drivers/clk/renesas/clk-rcar-gen2.c
index 3291fd430ad4e215..f39519edc645ca87 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -445,10 +445,3 @@ static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
 }
 CLK_OF_DECLARE(rcar_gen2_cpg_clks, "renesas,rcar-gen2-cpg-clocks",
 	       rcar_gen2_cpg_clocks_init);
-
-void __init rcar_gen2_clocks_init(u32 mode)
-{
-	cpg_mode = mode;
-
-	of_clk_init(NULL);
-}
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 9e969941f3f62878..9ebf1f8243bb57af 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -20,8 +20,6 @@
 struct device_node;
 struct generic_pm_domain;
 
-void rcar_gen2_clocks_init(u32 mode);
-
 void cpg_mstp_add_clk_domain(struct device_node *np);
 #ifdef CONFIG_CLK_RENESAS_CPG_MSTP
 int cpg_mstp_attach_dev(struct generic_pm_domain *unused, struct device *dev);
-- 
1.9.1

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

     A. Hi Geert,

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
>         Hi Philipp, Mike, Stephen, Simon, Magnus,
> 	(see questions *** below!)
> 
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
> 
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
> 
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().

I think you should add a binding doc even though the DT bindings are
still trivial.

> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> 
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>      driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>      files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>      RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>      from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
> 
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
>     Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
>     code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
>     in Part C,
>   - The block driver cleanups in part E depend on the board code
>     cleanups in part D.
> 
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
> 
> ***
> 
>   - Philip: While this is a driver for a reset-controller, currently it
>     doesn't provide any reset-controller functionality. Hence I added it
>     to drivers/soc/renesas/. Is that OK for you?

Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.

regards
Philipp

[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

     A. Hi Geert,

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
>         Hi Philipp, Mike, Stephen, Simon, Magnus,
> 	(see questions *** below!)
> 
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
> 
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
> 
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().

I think you should add a binding doc even though the DT bindings are
still trivial.

> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> 
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>      driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>      files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>      RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>      from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
> 
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
>     Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
>     code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
>     in Part C,
>   - The block driver cleanups in part E depend on the board code
>     cleanups in part D.
> 
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
> 
> ***
> 
>   - Philip: While this is a driver for a reset-controller, currently it
>     doesn't provide any reset-controller functionality. Hence I added it
>     to drivers/soc/renesas/. Is that OK for you?

Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.

regards
Philipp

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

     A. Hi Geert,

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
>         Hi Philipp, Mike, Stephen, Simon, Magnus,
> 	(see questions *** below!)
> 
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
> 
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
> 
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().

I think you should add a binding doc even though the DT bindings are
still trivial.

> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> 
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>      driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>      files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>      RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>      from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
> 
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
>     Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
>     code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
>     in Part C,
>   - The block driver cleanups in part E depend on the board code
>     cleanups in part D.
> 
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
> 
> ***
> 
>   - Philip: While this is a driver for a reset-controller, currently it
>     doesn't provide any reset-controller functionality. Hence I added it
>     to drivers/soc/renesas/. Is that OK for you?

Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.

regards
Philipp

--
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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

Am Freitag, den 21.10.2016, 17:45 +0200 schrieb Philipp Zabel:
>      A. Hi Geert,
> 
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> >         Hi Philipp, Mike, Stephen, Simon, Magnus,
> > 	(see questions *** below!)
> > 
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> > 
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> > 
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> 
> I think you should add a binding doc even though the DT bindings are
> still trivial.

Disregard that, I literally sent this mail and a second later noticed
patch 1 for the first time.

regards
Philipp

[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

Am Freitag, den 21.10.2016, 17:45 +0200 schrieb Philipp Zabel:
>      A. Hi Geert,
> 
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> >         Hi Philipp, Mike, Stephen, Simon, Magnus,
> > 	(see questions *** below!)
> > 
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> > 
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> > 
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> 
> I think you should add a binding doc even though the DT bindings are
> still trivial.

Disregard that, I literally sent this mail and a second later noticed
patch 1 for the first time.

regards
Philipp

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

Am Freitag, den 21.10.2016, 17:45 +0200 schrieb Philipp Zabel:
>      A. Hi Geert,
> 
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> >         Hi Philipp, Mike, Stephen, Simon, Magnus,
> > 	(see questions *** below!)
> > 
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> > 
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> > 
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> 
> I think you should add a binding doc even though the DT bindings are
> still trivial.

Disregard that, I literally sent this mail and a second later noticed
patch 1 for the first time.

regards
Philipp
--
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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Philip,

On Fri, Oct 21, 2016 at 5:45 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
>>         Hi Philipp, Mike, Stephen, Simon, Magnus,
>>       (see questions *** below!)
>>
>> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> state of the mode pins either by a call from the platform code, or
>> directly by using a hardcoded register access. This is a bit messy, and
>> creates a dependency between driver and platform code.
>>
>> This patch series converts the various Renesas R-Car clock drivers
>> and support code from reading the mode pin states using a hardcoded
>> register access to using a new minimalistic R-Car RST driver.

[...]

>>   - Philip: While this is a driver for a reset-controller, currently it
>>     doesn't provide any reset-controller functionality. Hence I added it
>>     to drivers/soc/renesas/. Is that OK for you?
>
> Absolutely, as long as the driver isn't even a reset controller
> provider, this is the right place.

Thank you!

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Philip,

On Fri, Oct 21, 2016 at 5:45 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
>>         Hi Philipp, Mike, Stephen, Simon, Magnus,
>>       (see questions *** below!)
>>
>> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> state of the mode pins either by a call from the platform code, or
>> directly by using a hardcoded register access. This is a bit messy, and
>> creates a dependency between driver and platform code.
>>
>> This patch series converts the various Renesas R-Car clock drivers
>> and support code from reading the mode pin states using a hardcoded
>> register access to using a new minimalistic R-Car RST driver.

[...]

>>   - Philip: While this is a driver for a reset-controller, currently it
>>     doesn't provide any reset-controller functionality. Hence I added it
>>     to drivers/soc/renesas/. Is that OK for you?
>
> Absolutely, as long as the driver isn't even a reset controller
> provider, this is the right place.

Thank you!

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Philip,

On Fri, Oct 21, 2016 at 5:45 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
>>         Hi Philipp, Mike, Stephen, Simon, Magnus,
>>       (see questions *** below!)
>>
>> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> state of the mode pins either by a call from the platform code, or
>> directly by using a hardcoded register access. This is a bit messy, and
>> creates a dependency between driver and platform code.
>>
>> This patch series converts the various Renesas R-Car clock drivers
>> and support code from reading the mode pin states using a hardcoded
>> register access to using a new minimalistic R-Car RST driver.

[...]

>>   - Philip: While this is a driver for a reset-controller, currently it
>>     doesn't provide any reset-controller functionality. Hence I added it
>>     to drivers/soc/renesas/. Is that OK for you?
>
> Absolutely, as long as the driver isn't even a reset controller
> provider, this is the right place.

Thank you!

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Philip,

On Fri, Oct 21, 2016 at 5:45 PM, Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
>>         Hi Philipp, Mike, Stephen, Simon, Magnus,
>>       (see questions *** below!)
>>
>> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> state of the mode pins either by a call from the platform code, or
>> directly by using a hardcoded register access. This is a bit messy, and
>> creates a dependency between driver and platform code.
>>
>> This patch series converts the various Renesas R-Car clock drivers
>> and support code from reading the mode pin states using a hardcoded
>> register access to using a new minimalistic R-Car RST driver.

[...]

>>   - Philip: While this is a driver for a reset-controller, currently it
>>     doesn't provide any reset-controller functionality. Hence I added it
>>     to drivers/soc/renesas/. Is that OK for you?
>
> Absolutely, as long as the driver isn't even a reset controller
> provider, this is the right place.

Thank you!

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Mike, Stephen,

On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
>
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
>
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().
>
> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>      driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>      files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>      RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>      from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
>
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
>     Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
>     code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
>     in Part C,
>   - The block driver cleanups in part E depend on the board code
>     cleanups in part D.
>
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
>
> ***

>   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>     approach above?

Is this OK for you?

I'd like to move forward with this, as this is a prerequisite for adding
support for new SoCs (RZ/G) without adding more copies of
rcar_gen2_read_mode_pins(), and removing that function from platform code
for good.

Thanks!

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Mike, Stephen,

On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
>
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
>
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().
>
> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>      driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>      files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>      RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>      from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
>
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
>     Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
>     code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
>     in Part C,
>   - The block driver cleanups in part E depend on the board code
>     cleanups in part D.
>
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
>
> ***

>   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>     approach above?

Is this OK for you?

I'd like to move forward with this, as this is a prerequisite for adding
support for new SoCs (RZ/G) without adding more copies of
rcar_gen2_read_mode_pins(), and removing that function from platform code
for good.

Thanks!

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Mike, Stephen,

On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
>
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
>
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().
>
> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>      driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>      files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>      RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>      from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
>
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
>     Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
>     code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
>     in Part C,
>   - The block driver cleanups in part E depend on the board code
>     cleanups in part D.
>
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
>
> ***

>   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>     approach above?

Is this OK for you?

I'd like to move forward with this, as this is a prerequisite for adding
support for new SoCs (RZ/G) without adding more copies of
rcar_gen2_read_mode_pins(), and removing that function from platform code
for good.

Thanks!

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Simon Horman]

On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> Hi Mike, Stephen,
> 
> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> >
> > After this, there is still one remaining user of
> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >
> > This series consists of 5 parts:
> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >      driver,
> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >      files,
> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >      RST driver,
> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >      from the platform code,
> >   E. Patches 21-23 remove dead code from the clock drivers.
> >
> > As is usually the case with moving functionality from platform code to
> > DT, there are lots of hard dependencies:
> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >     Part A have been approved,
> >   - The clock driver updates in Part C depend functionally on the driver
> >     code in Part A, and on the DT updates in Part B,
> >   - The board code cleanups in Part D depend on the clock driver updates
> >     in Part C,
> >   - The block driver cleanups in part E depend on the board code
> >     cleanups in part D.
> >
> > Hence to maintain the required lockstep between SoC driver, clock
> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> > all patches in a single branch against v4.9-rc1, and send pull requests
> > to both Mike/Stephen (clock) and Simon (rest).
> >
> > ***
> 
> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >     approach above?
> 
> Is this OK for you?
> 
> I'd like to move forward with this, as this is a prerequisite for adding
> support for new SoCs (RZ/G) without adding more copies of
> rcar_gen2_read_mode_pins(), and removing that function from platform code
> for good.

This seems reasonable to me but likely the ARM SoC maintainers will want to
know about this plan before it is executed.

[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Simon Horman]

On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> Hi Mike, Stephen,
> 
> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> >
> > After this, there is still one remaining user of
> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >
> > This series consists of 5 parts:
> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >      driver,
> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >      files,
> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >      RST driver,
> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >      from the platform code,
> >   E. Patches 21-23 remove dead code from the clock drivers.
> >
> > As is usually the case with moving functionality from platform code to
> > DT, there are lots of hard dependencies:
> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >     Part A have been approved,
> >   - The clock driver updates in Part C depend functionally on the driver
> >     code in Part A, and on the DT updates in Part B,
> >   - The board code cleanups in Part D depend on the clock driver updates
> >     in Part C,
> >   - The block driver cleanups in part E depend on the board code
> >     cleanups in part D.
> >
> > Hence to maintain the required lockstep between SoC driver, clock
> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> > all patches in a single branch against v4.9-rc1, and send pull requests
> > to both Mike/Stephen (clock) and Simon (rest).
> >
> > ***
> 
> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >     approach above?
> 
> Is this OK for you?
> 
> I'd like to move forward with this, as this is a prerequisite for adding
> support for new SoCs (RZ/G) without adding more copies of
> rcar_gen2_read_mode_pins(), and removing that function from platform code
> for good.

This seems reasonable to me but likely the ARM SoC maintainers will want to
know about this plan before it is executed.

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Simon Horman]

On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> Hi Mike, Stephen,
> 
> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> >
> > After this, there is still one remaining user of
> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >
> > This series consists of 5 parts:
> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >      driver,
> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >      files,
> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >      RST driver,
> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >      from the platform code,
> >   E. Patches 21-23 remove dead code from the clock drivers.
> >
> > As is usually the case with moving functionality from platform code to
> > DT, there are lots of hard dependencies:
> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >     Part A have been approved,
> >   - The clock driver updates in Part C depend functionally on the driver
> >     code in Part A, and on the DT updates in Part B,
> >   - The board code cleanups in Part D depend on the clock driver updates
> >     in Part C,
> >   - The block driver cleanups in part E depend on the board code
> >     cleanups in part D.
> >
> > Hence to maintain the required lockstep between SoC driver, clock
> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> > all patches in a single branch against v4.9-rc1, and send pull requests
> > to both Mike/Stephen (clock) and Simon (rest).
> >
> > ***
> 
> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >     approach above?
> 
> Is this OK for you?
> 
> I'd like to move forward with this, as this is a prerequisite for adding
> support for new SoCs (RZ/G) without adding more copies of
> rcar_gen2_read_mode_pins(), and removing that function from platform code
> for good.

This seems reasonable to me but likely the ARM SoC maintainers will want to
know about this plan before it is executed.

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Simon Horman]

On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> Hi Mike, Stephen,
> 
> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> >
> > After this, there is still one remaining user of
> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >
> > This series consists of 5 parts:
> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >      driver,
> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >      files,
> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >      RST driver,
> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >      from the platform code,
> >   E. Patches 21-23 remove dead code from the clock drivers.
> >
> > As is usually the case with moving functionality from platform code to
> > DT, there are lots of hard dependencies:
> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >     Part A have been approved,
> >   - The clock driver updates in Part C depend functionally on the driver
> >     code in Part A, and on the DT updates in Part B,
> >   - The board code cleanups in Part D depend on the clock driver updates
> >     in Part C,
> >   - The block driver cleanups in part E depend on the board code
> >     cleanups in part D.
> >
> > Hence to maintain the required lockstep between SoC driver, clock
> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> > all patches in a single branch against v4.9-rc1, and send pull requests
> > to both Mike/Stephen (clock) and Simon (rest).
> >
> > ***
> 
> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >     approach above?
> 
> Is this OK for you?
> 
> I'd like to move forward with this, as this is a prerequisite for adding
> support for new SoCs (RZ/G) without adding more copies of
> rcar_gen2_read_mode_pins(), and removing that function from platform code
> for good.

This seems reasonable to me but likely the ARM SoC maintainers will want to
know about this plan before it is executed.
--
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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Mike, Stephen, Arnd, Olof, Kevin,

Is the merge strategy [see ##### below] OK for you?
Thanks a lot!

On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> <geert+renesas@glider.be> wrote:
>> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> > state of the mode pins either by a call from the platform code, or
>> > directly by using a hardcoded register access. This is a bit messy, and
>> > creates a dependency between driver and platform code.
>> >
>> > This patch series converts the various Renesas R-Car clock drivers
>> > and support code from reading the mode pin states using a hardcoded
>> > register access to using a new minimalistic R-Car RST driver.
>> >
>> > All R-Car clock drivers will rely on the presence in DT of a device node
>> > for the RST module.  Backwards compatibility with old DTBs is retained
>> > only for R-Car Gen2, which has fallback code using its own private copy
>> > of rcar_gen2_read_mode_pins().
>> >
>> > After this, there is still one remaining user of
>> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >
>> > This series consists of 5 parts:
>> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >      driver,
>> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >      files,
>> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >      RST driver,
>> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >      from the platform code,
>> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >
>> > As is usually the case with moving functionality from platform code to
>> > DT, there are lots of hard dependencies:
>> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >     Part A have been approved,
>> >   - The clock driver updates in Part C depend functionally on the driver
>> >     code in Part A, and on the DT updates in Part B,
>> >   - The board code cleanups in Part D depend on the clock driver updates
>> >     in Part C,
>> >   - The block driver cleanups in part E depend on the board code
>> >     cleanups in part D.
>> >
>> > Hence to maintain the required lockstep between SoC driver, clock
>> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> > all patches in a single branch against v4.9-rc1, and send pull requests
>> > to both Mike/Stephen (clock) and Simon (rest).
>> >
>> > ***
>>
>> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >     approach above?
>>
>> Is this OK for you?

#####

(link to the full series at
 https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

>>
>> I'd like to move forward with this, as this is a prerequisite for adding
>> support for new SoCs (RZ/G) without adding more copies of
>> rcar_gen2_read_mode_pins(), and removing that function from platform code
>> for good.
>
> This seems reasonable to me but likely the ARM SoC maintainers will want to
> know about this plan before it is executed.

OK, adding more people in the loop...

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Mike, Stephen, Arnd, Olof, Kevin,

Is the merge strategy [see ##### below] OK for you?
Thanks a lot!

On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> <geert+renesas@glider.be> wrote:
>> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> > state of the mode pins either by a call from the platform code, or
>> > directly by using a hardcoded register access. This is a bit messy, and
>> > creates a dependency between driver and platform code.
>> >
>> > This patch series converts the various Renesas R-Car clock drivers
>> > and support code from reading the mode pin states using a hardcoded
>> > register access to using a new minimalistic R-Car RST driver.
>> >
>> > All R-Car clock drivers will rely on the presence in DT of a device node
>> > for the RST module.  Backwards compatibility with old DTBs is retained
>> > only for R-Car Gen2, which has fallback code using its own private copy
>> > of rcar_gen2_read_mode_pins().
>> >
>> > After this, there is still one remaining user of
>> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >
>> > This series consists of 5 parts:
>> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >      driver,
>> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >      files,
>> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >      RST driver,
>> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >      from the platform code,
>> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >
>> > As is usually the case with moving functionality from platform code to
>> > DT, there are lots of hard dependencies:
>> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >     Part A have been approved,
>> >   - The clock driver updates in Part C depend functionally on the driver
>> >     code in Part A, and on the DT updates in Part B,
>> >   - The board code cleanups in Part D depend on the clock driver updates
>> >     in Part C,
>> >   - The block driver cleanups in part E depend on the board code
>> >     cleanups in part D.
>> >
>> > Hence to maintain the required lockstep between SoC driver, clock
>> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> > all patches in a single branch against v4.9-rc1, and send pull requests
>> > to both Mike/Stephen (clock) and Simon (rest).
>> >
>> > ***
>>
>> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >     approach above?
>>
>> Is this OK for you?

#####

(link to the full series at
 https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

>>
>> I'd like to move forward with this, as this is a prerequisite for adding
>> support for new SoCs (RZ/G) without adding more copies of
>> rcar_gen2_read_mode_pins(), and removing that function from platform code
>> for good.
>
> This seems reasonable to me but likely the ARM SoC maintainers will want to
> know about this plan before it is executed.

OK, adding more people in the loop...

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Mike, Stephen, Arnd, Olof, Kevin,

Is the merge strategy [see ##### below] OK for you?
Thanks a lot!

On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> <geert+renesas@glider.be> wrote:
>> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> > state of the mode pins either by a call from the platform code, or
>> > directly by using a hardcoded register access. This is a bit messy, and
>> > creates a dependency between driver and platform code.
>> >
>> > This patch series converts the various Renesas R-Car clock drivers
>> > and support code from reading the mode pin states using a hardcoded
>> > register access to using a new minimalistic R-Car RST driver.
>> >
>> > All R-Car clock drivers will rely on the presence in DT of a device node
>> > for the RST module.  Backwards compatibility with old DTBs is retained
>> > only for R-Car Gen2, which has fallback code using its own private copy
>> > of rcar_gen2_read_mode_pins().
>> >
>> > After this, there is still one remaining user of
>> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >
>> > This series consists of 5 parts:
>> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >      driver,
>> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >      files,
>> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >      RST driver,
>> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >      from the platform code,
>> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >
>> > As is usually the case with moving functionality from platform code to
>> > DT, there are lots of hard dependencies:
>> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >     Part A have been approved,
>> >   - The clock driver updates in Part C depend functionally on the driver
>> >     code in Part A, and on the DT updates in Part B,
>> >   - The board code cleanups in Part D depend on the clock driver updates
>> >     in Part C,
>> >   - The block driver cleanups in part E depend on the board code
>> >     cleanups in part D.
>> >
>> > Hence to maintain the required lockstep between SoC driver, clock
>> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> > all patches in a single branch against v4.9-rc1, and send pull requests
>> > to both Mike/Stephen (clock) and Simon (rest).
>> >
>> > ***
>>
>> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >     approach above?
>>
>> Is this OK for you?

#####

(link to the full series at
 https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

>>
>> I'd like to move forward with this, as this is a prerequisite for adding
>> support for new SoCs (RZ/G) without adding more copies of
>> rcar_gen2_read_mode_pins(), and removing that function from platform code
>> for good.
>
> This seems reasonable to me but likely the ARM SoC maintainers will want to
> know about this plan before it is executed.

OK, adding more people in the loop...

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Mike, Stephen, Arnd, Olof, Kevin,

Is the merge strategy [see ##### below] OK for you?
Thanks a lot!

On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
>> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> > state of the mode pins either by a call from the platform code, or
>> > directly by using a hardcoded register access. This is a bit messy, and
>> > creates a dependency between driver and platform code.
>> >
>> > This patch series converts the various Renesas R-Car clock drivers
>> > and support code from reading the mode pin states using a hardcoded
>> > register access to using a new minimalistic R-Car RST driver.
>> >
>> > All R-Car clock drivers will rely on the presence in DT of a device node
>> > for the RST module.  Backwards compatibility with old DTBs is retained
>> > only for R-Car Gen2, which has fallback code using its own private copy
>> > of rcar_gen2_read_mode_pins().
>> >
>> > After this, there is still one remaining user of
>> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >
>> > This series consists of 5 parts:
>> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >      driver,
>> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >      files,
>> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >      RST driver,
>> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >      from the platform code,
>> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >
>> > As is usually the case with moving functionality from platform code to
>> > DT, there are lots of hard dependencies:
>> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >     Part A have been approved,
>> >   - The clock driver updates in Part C depend functionally on the driver
>> >     code in Part A, and on the DT updates in Part B,
>> >   - The board code cleanups in Part D depend on the clock driver updates
>> >     in Part C,
>> >   - The block driver cleanups in part E depend on the board code
>> >     cleanups in part D.
>> >
>> > Hence to maintain the required lockstep between SoC driver, clock
>> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> > all patches in a single branch against v4.9-rc1, and send pull requests
>> > to both Mike/Stephen (clock) and Simon (rest).
>> >
>> > ***
>>
>> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >     approach above?
>>
>> Is this OK for you?

#####

(link to the full series at
 https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

>>
>> I'd like to move forward with this, as this is a prerequisite for adding
>> support for new SoCs (RZ/G) without adding more copies of
>> rcar_gen2_read_mode_pins(), and removing that function from platform code
>> for good.
>
> This seems reasonable to me but likely the ARM SoC maintainers will want to
> know about this plan before it is executed.

OK, adding more people in the loop...

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 10/31, Geert Uytterhoeven wrote:
> Hi Mike, Stephen, Arnd, Olof, Kevin,
> 
> Is the merge strategy [see ##### below] OK for you?
> Thanks a lot!
> 
> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> >> <geert+renesas@glider.be> wrote:
> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> >> > state of the mode pins either by a call from the platform code, or
> >> > directly by using a hardcoded register access. This is a bit messy, and
> >> > creates a dependency between driver and platform code.
> >> >
> >> > This patch series converts the various Renesas R-Car clock drivers
> >> > and support code from reading the mode pin states using a hardcoded
> >> > register access to using a new minimalistic R-Car RST driver.
> >> >
> >> > All R-Car clock drivers will rely on the presence in DT of a device node
> >> > for the RST module.  Backwards compatibility with old DTBs is retained
> >> > only for R-Car Gen2, which has fallback code using its own private copy
> >> > of rcar_gen2_read_mode_pins().
> >> >
> >> > After this, there is still one remaining user of
> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >> >
> >> > This series consists of 5 parts:
> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >> >      driver,
> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >> >      files,
> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >> >      RST driver,
> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >> >      from the platform code,
> >> >   E. Patches 21-23 remove dead code from the clock drivers.
> >> >
> >> > As is usually the case with moving functionality from platform code to
> >> > DT, there are lots of hard dependencies:
> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >> >     Part A have been approved,
> >> >   - The clock driver updates in Part C depend functionally on the driver
> >> >     code in Part A, and on the DT updates in Part B,
> >> >   - The board code cleanups in Part D depend on the clock driver updates
> >> >     in Part C,
> >> >   - The block driver cleanups in part E depend on the board code
> >> >     cleanups in part D.
> >> >
> >> > Hence to maintain the required lockstep between SoC driver, clock
> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> >> > all patches in a single branch against v4.9-rc1, and send pull requests
> >> > to both Mike/Stephen (clock) and Simon (rest).
> >> >
> >> > ***
> >>
> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >> >     approach above?
> >>
> >> Is this OK for you?
> 
> #####
> 
> (link to the full series at
>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

Would the pull requests for clk also have dts changes at the base
of the tree? Perhaps clk side can just ack the clk patches and
then have it all routed through arm-soc? The only worry I have is
if we need to make some sort of change in clk side that conflicts
with these changes. I don't usually like taking dts changes
through clk tree, so I'd like to avoid that if possible.

Part E could happen anytime after everything else happens, so
that doesn't seem like a concern. Part C could also be made to
only call into the new reset drivers if the reset dts nodes are
present? If that's done then we could merge clk patches anytime
and remove the dead code and the node search at some later time
when everything has settled?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 10/31, Geert Uytterhoeven wrote:
> Hi Mike, Stephen, Arnd, Olof, Kevin,
> 
> Is the merge strategy [see ##### below] OK for you?
> Thanks a lot!
> 
> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> >> <geert+renesas@glider.be> wrote:
> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> >> > state of the mode pins either by a call from the platform code, or
> >> > directly by using a hardcoded register access. This is a bit messy, and
> >> > creates a dependency between driver and platform code.
> >> >
> >> > This patch series converts the various Renesas R-Car clock drivers
> >> > and support code from reading the mode pin states using a hardcoded
> >> > register access to using a new minimalistic R-Car RST driver.
> >> >
> >> > All R-Car clock drivers will rely on the presence in DT of a device node
> >> > for the RST module.  Backwards compatibility with old DTBs is retained
> >> > only for R-Car Gen2, which has fallback code using its own private copy
> >> > of rcar_gen2_read_mode_pins().
> >> >
> >> > After this, there is still one remaining user of
> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >> >
> >> > This series consists of 5 parts:
> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >> >      driver,
> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >> >      files,
> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >> >      RST driver,
> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >> >      from the platform code,
> >> >   E. Patches 21-23 remove dead code from the clock drivers.
> >> >
> >> > As is usually the case with moving functionality from platform code to
> >> > DT, there are lots of hard dependencies:
> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >> >     Part A have been approved,
> >> >   - The clock driver updates in Part C depend functionally on the driver
> >> >     code in Part A, and on the DT updates in Part B,
> >> >   - The board code cleanups in Part D depend on the clock driver updates
> >> >     in Part C,
> >> >   - The block driver cleanups in part E depend on the board code
> >> >     cleanups in part D.
> >> >
> >> > Hence to maintain the required lockstep between SoC driver, clock
> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> >> > all patches in a single branch against v4.9-rc1, and send pull requests
> >> > to both Mike/Stephen (clock) and Simon (rest).
> >> >
> >> > ***
> >>
> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >> >     approach above?
> >>
> >> Is this OK for you?
> 
> #####
> 
> (link to the full series at
>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

Would the pull requests for clk also have dts changes at the base
of the tree? Perhaps clk side can just ack the clk patches and
then have it all routed through arm-soc? The only worry I have is
if we need to make some sort of change in clk side that conflicts
with these changes. I don't usually like taking dts changes
through clk tree, so I'd like to avoid that if possible.

Part E could happen anytime after everything else happens, so
that doesn't seem like a concern. Part C could also be made to
only call into the new reset drivers if the reset dts nodes are
present? If that's done then we could merge clk patches anytime
and remove the dead code and the node search at some later time
when everything has settled?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 10/31, Geert Uytterhoeven wrote:
> Hi Mike, Stephen, Arnd, Olof, Kevin,
> 
> Is the merge strategy [see ##### below] OK for you?
> Thanks a lot!
> 
> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> >> <geert+renesas@glider.be> wrote:
> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> >> > state of the mode pins either by a call from the platform code, or
> >> > directly by using a hardcoded register access. This is a bit messy, and
> >> > creates a dependency between driver and platform code.
> >> >
> >> > This patch series converts the various Renesas R-Car clock drivers
> >> > and support code from reading the mode pin states using a hardcoded
> >> > register access to using a new minimalistic R-Car RST driver.
> >> >
> >> > All R-Car clock drivers will rely on the presence in DT of a device node
> >> > for the RST module.  Backwards compatibility with old DTBs is retained
> >> > only for R-Car Gen2, which has fallback code using its own private copy
> >> > of rcar_gen2_read_mode_pins().
> >> >
> >> > After this, there is still one remaining user of
> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >> >
> >> > This series consists of 5 parts:
> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >> >      driver,
> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >> >      files,
> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >> >      RST driver,
> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >> >      from the platform code,
> >> >   E. Patches 21-23 remove dead code from the clock drivers.
> >> >
> >> > As is usually the case with moving functionality from platform code to
> >> > DT, there are lots of hard dependencies:
> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >> >     Part A have been approved,
> >> >   - The clock driver updates in Part C depend functionally on the driver
> >> >     code in Part A, and on the DT updates in Part B,
> >> >   - The board code cleanups in Part D depend on the clock driver updates
> >> >     in Part C,
> >> >   - The block driver cleanups in part E depend on the board code
> >> >     cleanups in part D.
> >> >
> >> > Hence to maintain the required lockstep between SoC driver, clock
> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> >> > all patches in a single branch against v4.9-rc1, and send pull requests
> >> > to both Mike/Stephen (clock) and Simon (rest).
> >> >
> >> > ***
> >>
> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >> >     approach above?
> >>
> >> Is this OK for you?
> 
> #####
> 
> (link to the full series at
>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

Would the pull requests for clk also have dts changes at the base
of the tree? Perhaps clk side can just ack the clk patches and
then have it all routed through arm-soc? The only worry I have is
if we need to make some sort of change in clk side that conflicts
with these changes. I don't usually like taking dts changes
through clk tree, so I'd like to avoid that if possible.

Part E could happen anytime after everything else happens, so
that doesn't seem like a concern. Part C could also be made to
only call into the new reset drivers if the reset dts nodes are
present? If that's done then we could merge clk patches anytime
and remove the dead code and the node search at some later time
when everything has settled?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 10/31, Geert Uytterhoeven wrote:
> Hi Mike, Stephen, Arnd, Olof, Kevin,
> 
> Is the merge strategy [see ##### below] OK for you?
> Thanks a lot!
> 
> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> >> <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> >> > state of the mode pins either by a call from the platform code, or
> >> > directly by using a hardcoded register access. This is a bit messy, and
> >> > creates a dependency between driver and platform code.
> >> >
> >> > This patch series converts the various Renesas R-Car clock drivers
> >> > and support code from reading the mode pin states using a hardcoded
> >> > register access to using a new minimalistic R-Car RST driver.
> >> >
> >> > All R-Car clock drivers will rely on the presence in DT of a device node
> >> > for the RST module.  Backwards compatibility with old DTBs is retained
> >> > only for R-Car Gen2, which has fallback code using its own private copy
> >> > of rcar_gen2_read_mode_pins().
> >> >
> >> > After this, there is still one remaining user of
> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >> >
> >> > This series consists of 5 parts:
> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >> >      driver,
> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >> >      files,
> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >> >      RST driver,
> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >> >      from the platform code,
> >> >   E. Patches 21-23 remove dead code from the clock drivers.
> >> >
> >> > As is usually the case with moving functionality from platform code to
> >> > DT, there are lots of hard dependencies:
> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >> >     Part A have been approved,
> >> >   - The clock driver updates in Part C depend functionally on the driver
> >> >     code in Part A, and on the DT updates in Part B,
> >> >   - The board code cleanups in Part D depend on the clock driver updates
> >> >     in Part C,
> >> >   - The block driver cleanups in part E depend on the board code
> >> >     cleanups in part D.
> >> >
> >> > Hence to maintain the required lockstep between SoC driver, clock
> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> >> > all patches in a single branch against v4.9-rc1, and send pull requests
> >> > to both Mike/Stephen (clock) and Simon (rest).
> >> >
> >> > ***
> >>
> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >> >     approach above?
> >>
> >> Is this OK for you?
> 
> #####
> 
> (link to the full series at
>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

Would the pull requests for clk also have dts changes at the base
of the tree? Perhaps clk side can just ack the clk patches and
then have it all routed through arm-soc? The only worry I have is
if we need to make some sort of change in clk side that conflicts
with these changes. I don't usually like taking dts changes
through clk tree, so I'd like to avoid that if possible.

Part E could happen anytime after everything else happens, so
that doesn't seem like a concern. Part C could also be made to
only call into the new reset drivers if the reset dts nodes are
present? If that's done then we could merge clk patches anytime
and remove the dead code and the node search at some later time
when everything has settled?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

Thanks for your answers!

On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/31, Geert Uytterhoeven wrote:
>> Hi Mike, Stephen, Arnd, Olof, Kevin,
>>
>> Is the merge strategy [see ##### below] OK for you?
>> Thanks a lot!
>>
>> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> >> <geert+renesas@glider.be> wrote:
>> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> >> > state of the mode pins either by a call from the platform code, or
>> >> > directly by using a hardcoded register access. This is a bit messy, and
>> >> > creates a dependency between driver and platform code.
>> >> >
>> >> > This patch series converts the various Renesas R-Car clock drivers
>> >> > and support code from reading the mode pin states using a hardcoded
>> >> > register access to using a new minimalistic R-Car RST driver.
>> >> >
>> >> > All R-Car clock drivers will rely on the presence in DT of a device node
>> >> > for the RST module.  Backwards compatibility with old DTBs is retained
>> >> > only for R-Car Gen2, which has fallback code using its own private copy
>> >> > of rcar_gen2_read_mode_pins().
>> >> >
>> >> > After this, there is still one remaining user of
>> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >> >
>> >> > This series consists of 5 parts:
>> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >> >      driver,
>> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >> >      files,
>> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >> >      RST driver,
>> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >> >      from the platform code,
>> >> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >> >
>> >> > As is usually the case with moving functionality from platform code to
>> >> > DT, there are lots of hard dependencies:
>> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >> >     Part A have been approved,
>> >> >   - The clock driver updates in Part C depend functionally on the driver
>> >> >     code in Part A, and on the DT updates in Part B,
>> >> >   - The board code cleanups in Part D depend on the clock driver updates
>> >> >     in Part C,
>> >> >   - The block driver cleanups in part E depend on the board code
>> >> >     cleanups in part D.
>> >> >
>> >> > Hence to maintain the required lockstep between SoC driver, clock
>> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> >> > all patches in a single branch against v4.9-rc1, and send pull requests
>> >> > to both Mike/Stephen (clock) and Simon (rest).
>> >> >
>> >> > ***
>> >>
>> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >> >     approach above?
>> >>
>> >> Is this OK for you?
>>
>> #####
>>
>> (link to the full series at
>>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)
>
> Would the pull requests for clk also have dts changes at the base
> of the tree? Perhaps clk side can just ack the clk patches and

Yes they would: this is moving functionality from platform code to DT.
Without the DT updates, it will break bisection (except for R-Car Gen2,
where we have fallback code to handle old DTBs).

> then have it all routed through arm-soc? The only worry I have is
> if we need to make some sort of change in clk side that conflicts
> with these changes. I don't usually like taking dts changes
> through clk tree, so I'd like to avoid that if possible.

Everything could go through arm-soc only with your Acked-by.
However, there are new clock drivers pending on this series.
Either they have to go through arm-soc, too, or this series would
be pulled into the clk tree with these new clock drivers.

> Part E could happen anytime after everything else happens, so
> that doesn't seem like a concern.

Part E can indeed by postponed.
But if parts A-D are applied together, there's no reason to postpone part E.

> Part C could also be made to
> only call into the new reset drivers if the reset dts nodes are
> present? If that's done then we could merge clk patches anytime
> and remove the dead code and the node search at some later time
> when everything has settled?

That would require adding more backwards compatibility code for
old DTBs, even for platform where we're not interested in maintaining
that. In addition, Part C depends on the header file for the reset driver
to compile the clock driver, even if you would add some DT detection,
and on the reset driver to link. So I'm afraid this is not feasible.

Thanks again!

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

Thanks for your answers!

On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/31, Geert Uytterhoeven wrote:
>> Hi Mike, Stephen, Arnd, Olof, Kevin,
>>
>> Is the merge strategy [see ##### below] OK for you?
>> Thanks a lot!
>>
>> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> >> <geert+renesas@glider.be> wrote:
>> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> >> > state of the mode pins either by a call from the platform code, or
>> >> > directly by using a hardcoded register access. This is a bit messy, and
>> >> > creates a dependency between driver and platform code.
>> >> >
>> >> > This patch series converts the various Renesas R-Car clock drivers
>> >> > and support code from reading the mode pin states using a hardcoded
>> >> > register access to using a new minimalistic R-Car RST driver.
>> >> >
>> >> > All R-Car clock drivers will rely on the presence in DT of a device node
>> >> > for the RST module.  Backwards compatibility with old DTBs is retained
>> >> > only for R-Car Gen2, which has fallback code using its own private copy
>> >> > of rcar_gen2_read_mode_pins().
>> >> >
>> >> > After this, there is still one remaining user of
>> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >> >
>> >> > This series consists of 5 parts:
>> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >> >      driver,
>> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >> >      files,
>> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >> >      RST driver,
>> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >> >      from the platform code,
>> >> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >> >
>> >> > As is usually the case with moving functionality from platform code to
>> >> > DT, there are lots of hard dependencies:
>> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >> >     Part A have been approved,
>> >> >   - The clock driver updates in Part C depend functionally on the driver
>> >> >     code in Part A, and on the DT updates in Part B,
>> >> >   - The board code cleanups in Part D depend on the clock driver updates
>> >> >     in Part C,
>> >> >   - The block driver cleanups in part E depend on the board code
>> >> >     cleanups in part D.
>> >> >
>> >> > Hence to maintain the required lockstep between SoC driver, clock
>> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> >> > all patches in a single branch against v4.9-rc1, and send pull requests
>> >> > to both Mike/Stephen (clock) and Simon (rest).
>> >> >
>> >> > ***
>> >>
>> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >> >     approach above?
>> >>
>> >> Is this OK for you?
>>
>> #####
>>
>> (link to the full series at
>>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)
>
> Would the pull requests for clk also have dts changes at the base
> of the tree? Perhaps clk side can just ack the clk patches and

Yes they would: this is moving functionality from platform code to DT.
Without the DT updates, it will break bisection (except for R-Car Gen2,
where we have fallback code to handle old DTBs).

> then have it all routed through arm-soc? The only worry I have is
> if we need to make some sort of change in clk side that conflicts
> with these changes. I don't usually like taking dts changes
> through clk tree, so I'd like to avoid that if possible.

Everything could go through arm-soc only with your Acked-by.
However, there are new clock drivers pending on this series.
Either they have to go through arm-soc, too, or this series would
be pulled into the clk tree with these new clock drivers.

> Part E could happen anytime after everything else happens, so
> that doesn't seem like a concern.

Part E can indeed by postponed.
But if parts A-D are applied together, there's no reason to postpone part E.

> Part C could also be made to
> only call into the new reset drivers if the reset dts nodes are
> present? If that's done then we could merge clk patches anytime
> and remove the dead code and the node search at some later time
> when everything has settled?

That would require adding more backwards compatibility code for
old DTBs, even for platform where we're not interested in maintaining
that. In addition, Part C depends on the header file for the reset driver
to compile the clock driver, even if you would add some DT detection,
and on the reset driver to link. So I'm afraid this is not feasible.

Thanks again!

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

Thanks for your answers!

On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/31, Geert Uytterhoeven wrote:
>> Hi Mike, Stephen, Arnd, Olof, Kevin,
>>
>> Is the merge strategy [see ##### below] OK for you?
>> Thanks a lot!
>>
>> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> >> <geert+renesas@glider.be> wrote:
>> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> >> > state of the mode pins either by a call from the platform code, or
>> >> > directly by using a hardcoded register access. This is a bit messy, and
>> >> > creates a dependency between driver and platform code.
>> >> >
>> >> > This patch series converts the various Renesas R-Car clock drivers
>> >> > and support code from reading the mode pin states using a hardcoded
>> >> > register access to using a new minimalistic R-Car RST driver.
>> >> >
>> >> > All R-Car clock drivers will rely on the presence in DT of a device node
>> >> > for the RST module.  Backwards compatibility with old DTBs is retained
>> >> > only for R-Car Gen2, which has fallback code using its own private copy
>> >> > of rcar_gen2_read_mode_pins().
>> >> >
>> >> > After this, there is still one remaining user of
>> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >> >
>> >> > This series consists of 5 parts:
>> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >> >      driver,
>> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >> >      files,
>> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >> >      RST driver,
>> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >> >      from the platform code,
>> >> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >> >
>> >> > As is usually the case with moving functionality from platform code to
>> >> > DT, there are lots of hard dependencies:
>> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >> >     Part A have been approved,
>> >> >   - The clock driver updates in Part C depend functionally on the driver
>> >> >     code in Part A, and on the DT updates in Part B,
>> >> >   - The board code cleanups in Part D depend on the clock driver updates
>> >> >     in Part C,
>> >> >   - The block driver cleanups in part E depend on the board code
>> >> >     cleanups in part D.
>> >> >
>> >> > Hence to maintain the required lockstep between SoC driver, clock
>> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> >> > all patches in a single branch against v4.9-rc1, and send pull requests
>> >> > to both Mike/Stephen (clock) and Simon (rest).
>> >> >
>> >> > ***
>> >>
>> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >> >     approach above?
>> >>
>> >> Is this OK for you?
>>
>> #####
>>
>> (link to the full series at
>>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)
>
> Would the pull requests for clk also have dts changes at the base
> of the tree? Perhaps clk side can just ack the clk patches and

Yes they would: this is moving functionality from platform code to DT.
Without the DT updates, it will break bisection (except for R-Car Gen2,
where we have fallback code to handle old DTBs).

> then have it all routed through arm-soc? The only worry I have is
> if we need to make some sort of change in clk side that conflicts
> with these changes. I don't usually like taking dts changes
> through clk tree, so I'd like to avoid that if possible.

Everything could go through arm-soc only with your Acked-by.
However, there are new clock drivers pending on this series.
Either they have to go through arm-soc, too, or this series would
be pulled into the clk tree with these new clock drivers.

> Part E could happen anytime after everything else happens, so
> that doesn't seem like a concern.

Part E can indeed by postponed.
But if parts A-D are applied together, there's no reason to postpone part E.

> Part C could also be made to
> only call into the new reset drivers if the reset dts nodes are
> present? If that's done then we could merge clk patches anytime
> and remove the dead code and the node search at some later time
> when everything has settled?

That would require adding more backwards compatibility code for
old DTBs, even for platform where we're not interested in maintaining
that. In addition, Part C depends on the header file for the reset driver
to compile the clock driver, even if you would add some DT detection,
and on the reset driver to link. So I'm afraid this is not feasible.

Thanks again!

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

Thanks for your answers!

On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> On 10/31, Geert Uytterhoeven wrote:
>> Hi Mike, Stephen, Arnd, Olof, Kevin,
>>
>> Is the merge strategy [see ##### below] OK for you?
>> Thanks a lot!
>>
>> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
>> >> <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
>> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> >> > state of the mode pins either by a call from the platform code, or
>> >> > directly by using a hardcoded register access. This is a bit messy, and
>> >> > creates a dependency between driver and platform code.
>> >> >
>> >> > This patch series converts the various Renesas R-Car clock drivers
>> >> > and support code from reading the mode pin states using a hardcoded
>> >> > register access to using a new minimalistic R-Car RST driver.
>> >> >
>> >> > All R-Car clock drivers will rely on the presence in DT of a device node
>> >> > for the RST module.  Backwards compatibility with old DTBs is retained
>> >> > only for R-Car Gen2, which has fallback code using its own private copy
>> >> > of rcar_gen2_read_mode_pins().
>> >> >
>> >> > After this, there is still one remaining user of
>> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
>> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
>> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
>> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
>> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>> >> >
>> >> > This series consists of 5 parts:
>> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>> >> >      driver,
>> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>> >> >      files,
>> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>> >> >      RST driver,
>> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
>> >> >      from the platform code,
>> >> >   E. Patches 21-23 remove dead code from the clock drivers.
>> >> >
>> >> > As is usually the case with moving functionality from platform code to
>> >> > DT, there are lots of hard dependencies:
>> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
>> >> >     Part A have been approved,
>> >> >   - The clock driver updates in Part C depend functionally on the driver
>> >> >     code in Part A, and on the DT updates in Part B,
>> >> >   - The board code cleanups in Part D depend on the clock driver updates
>> >> >     in Part C,
>> >> >   - The block driver cleanups in part E depend on the board code
>> >> >     cleanups in part D.
>> >> >
>> >> > Hence to maintain the required lockstep between SoC driver, clock
>> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
>> >> > all patches in a single branch against v4.9-rc1, and send pull requests
>> >> > to both Mike/Stephen (clock) and Simon (rest).
>> >> >
>> >> > ***
>> >>
>> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
>> >> >     approach above?
>> >>
>> >> Is this OK for you?
>>
>> #####
>>
>> (link to the full series at
>>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)
>
> Would the pull requests for clk also have dts changes at the base
> of the tree? Perhaps clk side can just ack the clk patches and

Yes they would: this is moving functionality from platform code to DT.
Without the DT updates, it will break bisection (except for R-Car Gen2,
where we have fallback code to handle old DTBs).

> then have it all routed through arm-soc? The only worry I have is
> if we need to make some sort of change in clk side that conflicts
> with these changes. I don't usually like taking dts changes
> through clk tree, so I'd like to avoid that if possible.

Everything could go through arm-soc only with your Acked-by.
However, there are new clock drivers pending on this series.
Either they have to go through arm-soc, too, or this series would
be pulled into the clk tree with these new clock drivers.

> Part E could happen anytime after everything else happens, so
> that doesn't seem like a concern.

Part E can indeed by postponed.
But if parts A-D are applied together, there's no reason to postpone part E.

> Part C could also be made to
> only call into the new reset drivers if the reset dts nodes are
> present? If that's done then we could merge clk patches anytime
> and remove the dead code and the node search at some later time
> when everything has settled?

That would require adding more backwards compatibility code for
old DTBs, even for platform where we're not interested in maintaining
that. In addition, Part C depends on the header file for the reset driver
to compile the clock driver, even if you would add some DT detection,
and on the reset driver to link. So I'm afraid this is not feasible.

Thanks again!

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
> 
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
> 
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
> 
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
> 
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
> 
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
> 
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
> 
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
> 

TL;DR: Sounds fine, I'll be on the lookout for the PR.

Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.

So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like 

	if (rcar_rst_read_mode_pins())
		return;
		
with
	
	if (rcar_rst_read_mode_pins() != -ENODEV)
		return;


Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.

In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
> 
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
> 
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
> 
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
> 
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
> 
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
> 
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
> 
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
> 

TL;DR: Sounds fine, I'll be on the lookout for the PR.

Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.

So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like 

	if (rcar_rst_read_mode_pins())
		return;
		
with
	
	if (rcar_rst_read_mode_pins() != -ENODEV)
		return;


Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.

In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
> 
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
> 
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
> 
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
> 
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
> 
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
> 
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
> 
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
> 

TL;DR: Sounds fine, I'll be on the lookout for the PR.

Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.

So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like 

	if (rcar_rst_read_mode_pins())
		return;
		
with
	
	if (rcar_rst_read_mode_pins() != -ENODEV)
		return;


Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.

In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
> 
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
> 
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
> 
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
> 
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
> 
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
> 
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
> 
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
> 

TL;DR: Sounds fine, I'll be on the lookout for the PR.

Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.

So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like 

	if (rcar_rst_read_mode_pins())
		return;
		
with
	
	if (rcar_rst_read_mode_pins() != -ENODEV)
		return;


Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.

In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

On Fri, Nov 4, 2016 at 8:49 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 11/02, Geert Uytterhoeven wrote:
>> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> >
>> > Would the pull requests for clk also have dts changes at the base
>> > of the tree? Perhaps clk side can just ack the clk patches and
>>
>> Yes they would: this is moving functionality from platform code to DT.
>> Without the DT updates, it will break bisection (except for R-Car Gen2,
>> where we have fallback code to handle old DTBs).
>>
>> > then have it all routed through arm-soc? The only worry I have is
>> > if we need to make some sort of change in clk side that conflicts
>> > with these changes. I don't usually like taking dts changes
>> > through clk tree, so I'd like to avoid that if possible.
>>
>> Everything could go through arm-soc only with your Acked-by.
>> However, there are new clock drivers pending on this series.
>> Either they have to go through arm-soc, too, or this series would
>> be pulled into the clk tree with these new clock drivers.
>>
>> > Part E could happen anytime after everything else happens, so
>> > that doesn't seem like a concern.
>>
>> Part E can indeed by postponed.
>> But if parts A-D are applied together, there's no reason to postpone part E.
>>
>> > Part C could also be made to
>> > only call into the new reset drivers if the reset dts nodes are
>> > present? If that's done then we could merge clk patches anytime
>> > and remove the dead code and the node search at some later time
>> > when everything has settled?
>>
>> That would require adding more backwards compatibility code for
>> old DTBs, even for platform where we're not interested in maintaining
>> that. In addition, Part C depends on the header file for the reset driver
>> to compile the clock driver, even if you would add some DT detection,
>> and on the reset driver to link. So I'm afraid this is not feasible.
>
> TL;DR: Sounds fine, I'll be on the lookout for the PR.

Thank you very much!

> Longer version: Let me step back a bit and actually think about
> this longer than 2 minutes. From what I see
> rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
> aren't present. Great.
>
> So clk tree could be given a pull for the clk patches, part C, on
> top of part A, the reset driver. If the rcar_rst_read_mode_pins()
> returns failure because the node is missing, we fall back to the
> old style of doing things. Some drivers already do that anyway,

For R-Car Gen2, we want to keep backwards compatibility for a while.
But not for the others, and I didn't want to add more code that was going
to be removed again soon.

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

On Fri, Nov 4, 2016 at 8:49 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 11/02, Geert Uytterhoeven wrote:
>> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> >
>> > Would the pull requests for clk also have dts changes at the base
>> > of the tree? Perhaps clk side can just ack the clk patches and
>>
>> Yes they would: this is moving functionality from platform code to DT.
>> Without the DT updates, it will break bisection (except for R-Car Gen2,
>> where we have fallback code to handle old DTBs).
>>
>> > then have it all routed through arm-soc? The only worry I have is
>> > if we need to make some sort of change in clk side that conflicts
>> > with these changes. I don't usually like taking dts changes
>> > through clk tree, so I'd like to avoid that if possible.
>>
>> Everything could go through arm-soc only with your Acked-by.
>> However, there are new clock drivers pending on this series.
>> Either they have to go through arm-soc, too, or this series would
>> be pulled into the clk tree with these new clock drivers.
>>
>> > Part E could happen anytime after everything else happens, so
>> > that doesn't seem like a concern.
>>
>> Part E can indeed by postponed.
>> But if parts A-D are applied together, there's no reason to postpone part E.
>>
>> > Part C could also be made to
>> > only call into the new reset drivers if the reset dts nodes are
>> > present? If that's done then we could merge clk patches anytime
>> > and remove the dead code and the node search at some later time
>> > when everything has settled?
>>
>> That would require adding more backwards compatibility code for
>> old DTBs, even for platform where we're not interested in maintaining
>> that. In addition, Part C depends on the header file for the reset driver
>> to compile the clock driver, even if you would add some DT detection,
>> and on the reset driver to link. So I'm afraid this is not feasible.
>
> TL;DR: Sounds fine, I'll be on the lookout for the PR.

Thank you very much!

> Longer version: Let me step back a bit and actually think about
> this longer than 2 minutes. From what I see
> rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
> aren't present. Great.
>
> So clk tree could be given a pull for the clk patches, part C, on
> top of part A, the reset driver. If the rcar_rst_read_mode_pins()
> returns failure because the node is missing, we fall back to the
> old style of doing things. Some drivers already do that anyway,

For R-Car Gen2, we want to keep backwards compatibility for a while.
But not for the others, and I didn't want to add more code that was going
to be removed again soon.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

On Fri, Nov 4, 2016 at 8:49 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 11/02, Geert Uytterhoeven wrote:
>> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> >
>> > Would the pull requests for clk also have dts changes at the base
>> > of the tree? Perhaps clk side can just ack the clk patches and
>>
>> Yes they would: this is moving functionality from platform code to DT.
>> Without the DT updates, it will break bisection (except for R-Car Gen2,
>> where we have fallback code to handle old DTBs).
>>
>> > then have it all routed through arm-soc? The only worry I have is
>> > if we need to make some sort of change in clk side that conflicts
>> > with these changes. I don't usually like taking dts changes
>> > through clk tree, so I'd like to avoid that if possible.
>>
>> Everything could go through arm-soc only with your Acked-by.
>> However, there are new clock drivers pending on this series.
>> Either they have to go through arm-soc, too, or this series would
>> be pulled into the clk tree with these new clock drivers.
>>
>> > Part E could happen anytime after everything else happens, so
>> > that doesn't seem like a concern.
>>
>> Part E can indeed by postponed.
>> But if parts A-D are applied together, there's no reason to postpone part E.
>>
>> > Part C could also be made to
>> > only call into the new reset drivers if the reset dts nodes are
>> > present? If that's done then we could merge clk patches anytime
>> > and remove the dead code and the node search at some later time
>> > when everything has settled?
>>
>> That would require adding more backwards compatibility code for
>> old DTBs, even for platform where we're not interested in maintaining
>> that. In addition, Part C depends on the header file for the reset driver
>> to compile the clock driver, even if you would add some DT detection,
>> and on the reset driver to link. So I'm afraid this is not feasible.
>
> TL;DR: Sounds fine, I'll be on the lookout for the PR.

Thank you very much!

> Longer version: Let me step back a bit and actually think about
> this longer than 2 minutes. From what I see
> rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
> aren't present. Great.
>
> So clk tree could be given a pull for the clk patches, part C, on
> top of part A, the reset driver. If the rcar_rst_read_mode_pins()
> returns failure because the node is missing, we fall back to the
> old style of doing things. Some drivers already do that anyway,

For R-Car Gen2, we want to keep backwards compatibility for a while.
But not for the others, and I didn't want to add more code that was going
to be removed again soon.

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 v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Geert Uytterhoeven]

Hi Stephen,

On Fri, Nov 4, 2016 at 8:49 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 11/02, Geert Uytterhoeven wrote:
>> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> >
>> > Would the pull requests for clk also have dts changes at the base
>> > of the tree? Perhaps clk side can just ack the clk patches and
>>
>> Yes they would: this is moving functionality from platform code to DT.
>> Without the DT updates, it will break bisection (except for R-Car Gen2,
>> where we have fallback code to handle old DTBs).
>>
>> > then have it all routed through arm-soc? The only worry I have is
>> > if we need to make some sort of change in clk side that conflicts
>> > with these changes. I don't usually like taking dts changes
>> > through clk tree, so I'd like to avoid that if possible.
>>
>> Everything could go through arm-soc only with your Acked-by.
>> However, there are new clock drivers pending on this series.
>> Either they have to go through arm-soc, too, or this series would
>> be pulled into the clk tree with these new clock drivers.
>>
>> > Part E could happen anytime after everything else happens, so
>> > that doesn't seem like a concern.
>>
>> Part E can indeed by postponed.
>> But if parts A-D are applied together, there's no reason to postpone part E.
>>
>> > Part C could also be made to
>> > only call into the new reset drivers if the reset dts nodes are
>> > present? If that's done then we could merge clk patches anytime
>> > and remove the dead code and the node search at some later time
>> > when everything has settled?
>>
>> That would require adding more backwards compatibility code for
>> old DTBs, even for platform where we're not interested in maintaining
>> that. In addition, Part C depends on the header file for the reset driver
>> to compile the clock driver, even if you would add some DT detection,
>> and on the reset driver to link. So I'm afraid this is not feasible.
>
> TL;DR: Sounds fine, I'll be on the lookout for the PR.

Thank you very much!

> Longer version: Let me step back a bit and actually think about
> this longer than 2 minutes. From what I see
> rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
> aren't present. Great.
>
> So clk tree could be given a pull for the clk patches, part C, on
> top of part A, the reset driver. If the rcar_rst_read_mode_pins()
> returns failure because the node is missing, we fall back to the
> old style of doing things. Some drivers already do that anyway,

For R-Car Gen2, we want to keep backwards compatibility for a while.
But not for the others, and I didn't want to add more code that was going
to be removed again soon.

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