Re: [PATCH v3 3/4] clk: sunxi-ng: Convert early providers to platform drivers

[Måns Rullgård]

Maxime Ripard <mripard@xxxxxxxxxx> writes:

> On Mon, Jun 26, 2023 at 01:21:33PM +0100, Måns Rullgård wrote:
>> Samuel Holland <samuel@xxxxxxxxxxxx> writes:
>> 
>> > 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@xxxxxxxxxxxx>
>> > ---
>> >
>> > (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