[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86ikir8mqw.wl-maz@kernel.org>
Date: Wed, 13 Aug 2025 12:49:43 +0100
From: Marc Zyngier <maz@...nel.org>
To: Sudeep Holla <sudeep.holla@....com>, Alexandru Elisei <alexandru.elisei@....com>
Cc: linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Hanjun Guo <guohanjun@...wei.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 0/4] clocksource: Add standalone MMIO ARM arch timer driver
On Wed, 13 Aug 2025 12:35:31 +0100,
Alexandru Elisei <alexandru.elisei@....com> wrote:
>
> Hello,
>
> On Wed, Aug 13, 2025 at 11:55:48AM +0100, Sudeep Holla wrote:
> > +Alexandru
> >
> > On Thu, Aug 07, 2025 at 05:02:39PM +0100, Marc Zyngier wrote:
> > > For the past 10 years, both Mark and I have been lamenting about the
> > > sorry state of the badly named "arch_timer" driver, and about the way
> > > the MMIO part is intricately weaved into the system-register part.
> > >
> > > The time has finally come to have a stab at it.
> > >
> > > This small series simply creates a new timer driver for the MMIO arch
> > > timer, and only that. It is an actual driver, and not some kludge that
> > > has to run super early (that's what the per-CPU timers are for). This
> > > allows, in turn, a pretty large cleanup of the per-CPU driver, though
> > > there is more to come -- one thing at a time.
> > >
> > > As an added bonus, we get a clocksource, which the original code
> > > didn't provide. Just in case it might be useful. The end-result is far
> > > more readable, and about 100 lines smaller.
> > >
> >
> > (Tested it on Juno R2 and FVP in both DT and ACPI boot)
> >
> > Tested-by: Sudeep Holla <sudeep.holla@....com>
> > Reviewed-by: Sudeep Holla <sudeep.holla@....com>
Thanks!
> >
> > Alexandru found it useful(avoids some unexpected hang IIUC) in his setup
> > based on bootwrapper which doesn't initialise MMIO timers.
>
> Just FYI, this is the testing that I did.
>
> Without this series, if firmware (boot-wrapper-aarch64 in my testing) doesn't
> configure access to the memory-mapped timer:
>
> [ 0.000000] arch_timer: Unable to find a suitable frame in timer @ 0x000000002a810000
> [ 0.000000] Failed to initialize '/timer@...10000': -22
> ..
> [ 0.528000] kvm [1]: kvm_arch_timer: uninitialized timecounter
> ..
Right, that's one of the many problems with the tight coupling between
sysreg and MMIO timers -- if one fails, they both fail, and you're
pretty lucky if you manage to limp along after that.
> # ls /dev/kvm
> ls: cannot access '/dev/kvm': No such file or directory
>
> With this series, if firmware doesn't configure access to the memory-mapped
> timer:
>
> [ 0.549399] kvm [1]: Hyp nVHE mode initialized successfully
> ..
> [ 2.018050] arch-timer-mmio 2a810000.timer: Unable to find a suitable frame in timer @ 0x000000002a810000
> [ 2.018123] arch-timer-mmio 2a810000.timer: probe with driver arch-timer-mmio failed with error -22
Ah, you have managed to test the error path. Thanks for that!
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists