Re: [PATCH v3 3/4] clk: sunxi-ng: Convert early providers to platform drivers
From: Måns Rullgård <hidden>
Date: 2023-06-28 11:08:12
Also in:
linux-clk, linux-sunxi, lkml
Maxime Ripard [off-list ref] writes:
On Mon, Jun 26, 2023 at 01:21:33PM +0100, Måns Rullgård wrote:quoted
Samuel Holland [off-list ref] writes:quoted
The PRCM CCU drivers depend on clocks provided by other CCU drivers. For example, the sun8i-r-ccu driver uses the "pll-periph" clock provided by the SoC's main CCU. However, sun8i-r-ccu is an early OF clock provider, and many of the main CCUs (e.g. sun50i-a64-ccu) use platform drivers. This means that the consumer clocks will be orphaned until the supplier driver is bound. This can be avoided by converting the remaining CCUs to use platform drivers. Then fw_devlink will ensure the drivers are bound in the optimal order. The sun5i CCU is the only one which actually needs to be an early clock provider, because it provides the clock for the system timer. That one is left alone. Signed-off-by: Samuel Holland <samuel@sholland.org> --- (no changes since v1) drivers/clk/sunxi-ng/Kconfig | 20 ++++---- drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 58 +++++++++++++-------- drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 56 ++++++++++++-------- drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 33 ++++++++---- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 40 +++++++++++---- drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 35 +++++++++---- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 40 +++++++++++---- drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 62 ++++++++++++++-------- drivers/clk/sunxi-ng/ccu-sun8i-r.c | 65 ++++++++++++++---------- drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 57 +++++++++++++-------- drivers/clk/sunxi-ng/ccu-suniv-f1c100s.c | 38 ++++++++++---- 11 files changed, 332 insertions(+), 172 deletions(-)This broke the hstimer clocksource on A20 since it requires a clock provided by the sun4i ccu driver.The A10 is probably broken by this, but the A20 should be able to use the arch timers just like all the other Cortex-A7-based SoCs. Do you have a dmesg log that could help debug why it's not working?
The A20 works as such since, as you say, it has other clocksources. However, the hstimer has become unusable. If anyone was using, for whatever reason, it won't be working for them now. Before this change, the kernel log used include this line: clocksource: hstimer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370868154 ns Now there is only a cryptic "Can't get timer clock" in its place. As it is now, the hstimer driver is nothing but a waste of space. I figure it ought to be fixed one way or another. -- Måns Rullgård _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel