| Message ID | 20181216094147.6468-1-gregory.clement@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add CPU clock support for Armada 7K/8K | expand |
Hi Stephen, On dim., déc. 16 2018, Gregory CLEMENT <gregory.clement@bootlin.com> wrote: > Hello, > > This is the third version of a series allowing to manage the cpu > clock for Armada 7K/8K. 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. What is the status of this series? The only comments I had was from Rob about the binding and I answered them 3 weeks ago. Do you have any other comments? Do you expect a rebase of this series on v5.0-rc1? Thanks, Gregory > > 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 | 22 ++ > arch/arm64/Kconfig.platforms | 1 + > .../boot/dts/marvell/armada-ap806-quad.dtsi | 4 + > arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 6 + > 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, 357 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 > > -- > 2.19.2 >
Quoting Gregory CLEMENT (2019-01-10 08:16:22) > Hi Stephen, > > On dim., déc. 16 2018, Gregory CLEMENT <gregory.clement@bootlin.com> wrote: > > > Hello, > > > > This is the third version of a series allowing to manage the cpu > > clock for Armada 7K/8K. 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. > > What is the status of this series? > > The only comments I had was from Rob about the binding and I answered > them 3 weeks ago. Do you have any other comments? Do you expect a rebase > of this series on v5.0-rc1? > I'm waiting for Rob. I think the binding is not proper so presumably you will figure out what Rob wants and then change the code accordingly and resend?
Hi Stephen, On jeu., janv. 10 2019, Stephen Boyd <sboyd@kernel.org> wrote: > Quoting Gregory CLEMENT (2019-01-10 08:16:22) >> Hi Stephen, >> >> On dim., déc. 16 2018, Gregory CLEMENT <gregory.clement@bootlin.com> wrote: >> >> > Hello, >> > >> > This is the third version of a series allowing to manage the cpu >> > clock for Armada 7K/8K. 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. >> >> What is the status of this series? >> >> The only comments I had was from Rob about the binding and I answered >> them 3 weeks ago. Do you have any other comments? Do you expect a rebase >> of this series on v5.0-rc1? >> > > I'm waiting for Rob. I think the binding is not proper so presumably you > will figure out what Rob wants and then change the code accordingly and > resend? Actually the binding describes properly the hardware we have and that what I answered to Rob. Gregory
Hi Stephen, On jeu., janv. 10 2019, Gregory CLEMENT <gregory.clement@bootlin.com> wrote: > Hi Stephen, > > On jeu., janv. 10 2019, Stephen Boyd <sboyd@kernel.org> wrote: > >> Quoting Gregory CLEMENT (2019-01-10 08:16:22) >>> Hi Stephen, >>> >>> On dim., déc. 16 2018, Gregory CLEMENT <gregory.clement@bootlin.com> wrote: >>> >>> > Hello, >>> > >>> > This is the third version of a series allowing to manage the cpu >>> > clock for Armada 7K/8K. 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. >>> >>> What is the status of this series? >>> >>> The only comments I had was from Rob about the binding and I answered >>> them 3 weeks ago. Do you have any other comments? Do you expect a rebase >>> of this series on v5.0-rc1? >>> >> >> I'm waiting for Rob. I think the binding is not proper so presumably you >> will figure out what Rob wants and then change the code accordingly and >> resend? > > Actually the binding describes properly the hardware we have and that > what I answered to Rob. I pinged you about this series more than one month ago, and answered Rob concerned 2 months ago! He didn't said anything about my comments so I really think that the binding is OK and described the hardware we have. So could you consider to apply this series? Thanks, Gregory > > Gregory > > -- > Gregory Clement, Bootlin > Embedded Linux and Kernel engineering > http://bootlin.com > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel