Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 28 Jun 2023 13:41:30 +0200
From:   Maxime Ripard <mripard@kernel.org>
To:     =?utf-8?B?TcOlbnMgUnVsbGfDpXJk?= <mans@mansr.com>
Cc:     Samuel Holland <samuel@sholland.org>, Chen-Yu Tsai <wens@csie.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        linux-sunxi@lists.linux.dev,
        Michael Turquette <mturquette@baylibre.com>,
        linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        Stephen Boyd <sboyd@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/4] clk: sunxi-ng: Convert early providers to
 platform drivers
Message-ID: <un3xm7ybsm54qf56ojhrtr6kehlmhdoavzcaqr2jfbcyg2kr6u@rdlq7nelycs2>
References: <20211119033338.25486-1-samuel@sholland.org>
 <20211119033338.25486-4-samuel@sholland.org>
 <yw1xedly2z3m.fsf@mansr.com>
 <maqh4yir66agto4lyulvrqrim7qnixwd246jusvvhsjlhhrmmw@gjbubqc2cv4o>
 <yw1xa5wj3kvn.fsf@mansr.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="mf236bogpjscjsps"
Content-Disposition: inline
In-Reply-To: <yw1xa5wj3kvn.fsf@mansr.com>
Precedence: bulk


--mf236bogpjscjsps
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 28, 2023 at 12:07:56PM +0100, M=E5ns Rullg=E5rd wrote:
> Maxime Ripard <mripard@kernel.org> writes:
>=20
> > On Mon, Jun 26, 2023 at 01:21:33PM +0100, M=E5ns Rullg=E5rd wrote:
> >> Samuel Holland <samuel@sholland.org> writes:
> >>=20
> >> > 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 bo=
und.
> >> > 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 cl=
ock
> >> > provider, because it provides the clock for the system timer. That o=
ne
> >> > 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(-)
> >>=20
> >> 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?
>=20
> 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.
>=20
> Before this change, the kernel log used include this line:
>=20
> clocksource: hstimer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_n=
s: 6370868154 ns
>=20
> Now there is only a cryptic "Can't get timer clock" in its place.
>=20
> 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.

Maxime

--mf236bogpjscjsps
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZJwcagAKCRDj7w1vZxhR
xe08AP4ohM6byryVMfvTgitb1BFSBhJ6x+I71Oex+5G7vPvqAAEAglGVPkTLpB/P
1ZNfSD09bTdBia8t2ImilUQ19q5PoA4=
=atgh
-----END PGP SIGNATURE-----

--mf236bogpjscjsps--