Hi Marc,
On Tue, May 3, 2022 at 3:12 PM Marc Zyngier <maz@xxxxxxxxxx> wrote:
> On 2022-05-03 12:55, Phil Edworthy wrote:
> > Some SoCs use a gated clock for the timer and the means to reset the
> > timer.
> > Hence add these as optional.
>
> The architecture is crystal clear on the subject: the counter
> is in an always-on domain. Why should this be visible to SW?
> Also, reseting the counter breaks the guaranteed monotonicity
> we rely on.
The DT bindings do state:
always-on:
type: boolean
description: If present, the timer is powered through an always-on power
domain, therefore it never loses context.
and (surprisingly?) the absence of this property seems to be the
norm...
And:
arm,no-tick-in-suspend:
type: boolean
description: The main counter does not tick when the system is in
low-power system suspend on some SoCs. This behavior does not match the
Architecture Reference Manual's specification that the system
counter "must
be implemented in an always-on power domain."
So there's already precedent for clocks that can be disabled.
> Worse case, this belongs to the boot firmware, not the kernel,
> and I don't think this should be described in the DT.
"DT describes hardware, not software policy"?
> > --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > @@ -64,6 +64,13 @@ properties:
> > CNTFRQ on all CPUs to a uniform correct value. Use of this
> > property is
> > strongly discouraged; fix your firmware unless absolutely
> > impossible.
> >
> > + clocks:
> > + description: Optional clock for the timer.
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > always-on:
> > type: boolean
> > description: If present, the timer is powered through an always-on
> > power
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
