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

[Måns Rullgård]

Maxime Ripard <mripard@xxxxxxxxxx> writes:

> On Wed, Jun 28, 2023 at 07:33:35PM +0100, Måns Rullgård wrote:
>> Maxime Ripard <mripard@xxxxxxxxxx> writes:
>> 
>> > On Wed, Jun 28, 2023 at 12:07:56PM +0100, Måns Rullgård wrote:
>> >> 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.
>> >
>> > Yeah, definitely.
>> >
>> > IIRC, the situation is:
>> >
>> >  - A10 has just the "regular", old, timer
>> >  - A10s/A13/GR8 has the A10 timer + hstimer
>> >  - A20 has the A13 timers + arch timers
>> >
>> > We also default to the hstimer only for the A10s/A13 which aren't
>> > affected by this patch series afaics.
>> >
>> > We also enable the HS timer for the A31, but just like the A20 it
>> > doesn't use it by default, so it's probably been broken there too.
>> >
>> > I guess one way to fix it would be to switch the HS timer driver to a
>> > lower priority than the A10 timer, so we pick that up by default instead
>> > for the A10s/A13, and then convert the HS timer driver to a proper
>> > platform_device driver that will be able to get its clock.
>> >
>> > The downside is that the A13 will lose some precision over its default
>> > timer, but I don't think it's a big deal.
>> 
>> The options I see are converting the hstimer to a platform device or
>> reverting the change to the sun4i ccu driver.
>> 
>> I don't personally have much of an opinion on this since my systems
>> aren't affected.  The only reason I looked at it was that I noticed
>> a new error message in the kernel logs.
>
> Thanks for the report then. I'm not really working on that anymore, so I
> won't submit a fix for this either.

I can have a go at converting it to a platform device if you think
that's the right approach.  I don't have anything other than A20 to
test it on, though.

-- 
Måns Rullgård