[PATCH v3 4/8] drivers: arm_architected_timer: refactor for pbl compatibility
Sascha Hauer
s.hauer at pengutronix.de
Thu Aug 20 01:00:55 PDT 2026
On 2026-08-20 09:32, Stefan Kerkmann wrote:
> >> diff --git a/drivers/clocksource/arm_architected_timer.c b/drivers/clocksource/arm_architected_timer.c
> >> index daced94c0e..ea5f5b8e05 100644
> >> --- a/drivers/clocksource/arm_architected_timer.c
> >> +++ b/drivers/clocksource/arm_architected_timer.c
> >> @@ -9,6 +9,7 @@
> >> #include <linux/clk.h>
> >> #include <io.h>
> >> #include <asm/system.h>
> >> +#include <asm/hardware/arm_architected_timer.h>
> >>
> >> static uint64_t arm_arch_clocksource_read(void)
> >> {
> >> @@ -22,22 +23,29 @@ static struct clocksource cs = {
> >> .priority = 70,
> >> };
> >>
> >> -static int arm_arch_timer_probe(struct device *dev)
> >> +int arm_arch_timer_init(uint64_t cntfrq)
> >> {
> >> - u32 cntfrq;
> >> - int ret;
> >> -
> >> - /* Some platforms don't set CNTFRQ_EL0 before barebox */
> >> - ret = of_property_read_u32(dev->of_node, "clock-frequency", &cntfrq);
> >> -
> >> - if (ret)
> >> + if (!cntfrq)
> >> cntfrq = get_cntfrq();
> >
> > I wonder if we should just drop the cntfrq argument. All users call
> > set_cntfrq() before calling this, so get_cntfrq() should return the
> > correct value and we can rely on it.
> >
>
> Maybe keep the argument and use set_cntfrq in arm_arch_timer_init if the
> argument is !=0? Then arm_arch_timer_init is the function to use if a C
> environment is available? This would prevent any inconsistency.
I am not sure, but set_cntfrq() might only be usable in EL3, so you
would have to be careful about the exception level when calling
arm_arch_timer_init() with a non zero argument.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the barebox
mailing list