[resend,v5,0/6] Add CPU clock support for Armada 7K/8K

Message

Gregory CLEMENT April 23, 2019, 9:51 a.m. UTC

Hello,

[resent because I used an old non worlking email for Stephen Boyd]

This is the fifth version of a series allowing to manage the cpu clock
for Armada 7K/8K. The third version was sent more than 3 months
without any relevant feedback since this end of december last year.

For these SoCs, the CPUs share the same clock by cluster, so actually
the clock management is done at cluster level.

As for the other Armada 7K/8K clocks it is possible to have multiple
AP so here again we need to have unique name: the purpose of the second
patch is to share a common code which will be used in 3 drivers.

The last 2 patch enable the driver at dt and platform level and will
be applied through the mvebu subsystem.

Changelog v4->v5:

 - As requested by the device tree maintainer make the reg property
   mandatory

 - Updated the device tree files accordingly with the new binding

Changelog v3->v4:
 - Rebased on v5.1-rc1
 - Mention in the binding that a reg property can be used to make the
   device tree maintainer happy in the hope that there will be finally
   a review on this patch blocking the whole series.

Changelog v2->v3:
 - Add back the first patch documenting the binding

Changelog v1->v2:
 - Header cleanup
 - Use unsigned int instead of it for cluster member of the ap_cpu_clk struct
 - Use clk_hw instead of clk
 - Use regmap_read_poll_timeout
 - Use for_each_of_cpu_node
 - Remove unnecessary WARN_ON()
 - Remove headers from armada_ap_cp_helper.h
 - Few other minor cleanup

Gregory CLEMENT (6):
  dt-bindings: ap806: add the cluster clock node in the syscon file
  clk: mvebu: add helper file for Armada AP and CP clocks
  clk: mvebu: add CPU clock driver for Armada 7K/8K
  clk: mvebu: ap806: Fix clock name for the cluster
  arm64: marvell: enable the  Armada 7K/8K CPU clk driver
  arm64: dts: marvell: Add cpu clock node on Armada 7K/8K

 .../arm/marvell/ap806-system-controller.txt   |  26 ++
 arch/arm64/Kconfig.platforms                  |   1 +
 .../boot/dts/marvell/armada-ap806-quad.dtsi   |   4 +
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi |   7 +
 drivers/clk/mvebu/Kconfig                     |   8 +
 drivers/clk/mvebu/Makefile                    |   2 +
 drivers/clk/mvebu/ap-cpu-clk.c                | 259 ++++++++++++++++++
 drivers/clk/mvebu/ap806-system-controller.c   |  24 +-
 drivers/clk/mvebu/armada_ap_cp_helper.c       |  30 ++
 drivers/clk/mvebu/armada_ap_cp_helper.h       |  11 +
 drivers/clk/mvebu/cp110-system-controller.c   |  32 +--
 11 files changed, 362 insertions(+), 42 deletions(-)
 create mode 100644 drivers/clk/mvebu/ap-cpu-clk.c
 create mode 100644 drivers/clk/mvebu/armada_ap_cp_helper.c
 create mode 100644 drivers/clk/mvebu/armada_ap_cp_helper.h

Comments

Stephen Boyd April 26, 2019, 12:46 a.m. UTC | #1

Quoting Gregory CLEMENT (2019-04-23 02:51:01)
> Hello,
> 
> [resent because I used an old non worlking email for Stephen Boyd]
> 
> This is the fifth version of a series allowing to manage the cpu clock
> for Armada 7K/8K. The third version was sent more than 3 months
> without any relevant feedback since this end of december last year.
> 
> For these SoCs, the CPUs share the same clock by cluster, so actually
> the clock management is done at cluster level.
> 
> As for the other Armada 7K/8K clocks it is possible to have multiple
> AP so here again we need to have unique name: the purpose of the second
> patch is to share a common code which will be used in 3 drivers.
> 
> The last 2 patch enable the driver at dt and platform level and will
> be applied through the mvebu subsystem.

Has anything changed since this was sent as v2? My scripts aren't
showing any change.

> 
> Changelog v4->v5:
> 
>  - As requested by the device tree maintainer make the reg property
>    mandatory
> 
>  - Updated the device tree files accordingly with the new binding
> 
> Changelog v3->v4:
>  - Rebased on v5.1-rc1
>  - Mention in the binding that a reg property can be used to make the
>    device tree maintainer happy in the hope that there will be finally
>    a review on this patch blocking the whole series.
> 

But this says things happened. I'm still waiting for Rob to ack the
binding and I seem to recall that it was incorrect? I'll have to dig
through the archives.