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.

Patches on top of 6.16.

Marc Zyngier (4):
  ACPI: GTDT: Generate platform devices for MMIO timers
  clocksource/drivers/arm_arch_timer: Add standalone MMIO driver
  clocksource/drivers/arm_arch_timer_mmio: Switch over to standalone
    driver
  clocksource/drivers/arm_arch_timer_mmio: Add MMIO clocksource

 MAINTAINERS                               |   1 +
 drivers/acpi/arm64/gtdt.c                 |  29 +-
 drivers/clocksource/Makefile              |   1 +
 drivers/clocksource/arm_arch_timer.c      | 686 ++--------------------
 drivers/clocksource/arm_arch_timer_mmio.c | 439 ++++++++++++++
 include/clocksource/arm_arch_timer.h      |   5 -
 6 files changed, 531 insertions(+), 630 deletions(-)
 create mode 100644 drivers/clocksource/arm_arch_timer_mmio.c

-- 
2.39.2

+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@arm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>

Alexandru found it useful(avoids some unexpected hang IIUC) in his setup
based on bootwrapper which doesn't initialise MMIO timers.

-- 
Regards,
Sudeep

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@arm.com>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> 
> 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@2a810000': -22
..
[    0.528000] kvm [1]: kvm_arch_timer: uninitialized timecounter
..
# 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
..
# ls /dev/kvm
/dev/kvm

Thanks,
Alex

On Wed, Aug 13, 2025 at 12:35:31PM +0100, Alexandru Elisei 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@arm.com>
> > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> > 
> > 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@2a810000': -22
> ..
> [    0.528000] kvm [1]: kvm_arch_timer: uninitialized timecounter
> ..
> # 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
> ..
> # ls /dev/kvm
> /dev/kvm
> 

Thanks for the details. I misunderstood as some VM boot hang and was wondering
why I couldn't reproduce it(was failing gracefully though no KVM and hence
VM fails to launch).

-- 
Regards,
Sudeep

On Wed, 13 Aug 2025 12:35:31 +0100,
Alexandru Elisei <alexandru.elisei@arm.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@arm.com>
> > Reviewed-by: Sudeep Holla <sudeep.holla@arm.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@2a810000': -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.

On 13/08/2025 13:49, Marc Zyngier wrote:
> On Wed, 13 Aug 2025 12:35:31 +0100,
> Alexandru Elisei <alexandru.elisei@arm.com> wrote:

[ ... ]

>> 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!

Applied (including patch 1/4)

Thanks

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog