[PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT

[Lad, Prabhakar]

Hi Conor,

On Sun, Dec 4, 2022 at 11:34 PM Conor Dooley <conor at kernel.org> wrote:
>
> Hey Rob, Anup, Prabhakar,
>
> On Fri, Dec 02, 2022 at 12:03:05PM +0530, Anup Patel wrote:
> > On Fri, Dec 2, 2022 at 5:36 AM Rob Herring <robh at kernel.org> wrote:
> > >
> > > On Thu, Dec 01, 2022 at 06:09:54PM +0530, Anup Patel wrote:
> > > > We should set CLOCK_EVT_FEAT_C3STOP for a clock_event_device only
> > > > when riscv,timer-cannot-wake-cpu DT property is present in the RISC-V
> > > > timer DT node.
> > > >
> > > > This way CLOCK_EVT_FEAT_C3STOP feature is set for clock_event_device
> > > > based on RISC-V platform capabilities rather than having it set for
> > > > all RISC-V platforms.
> > > >
> > > > Signed-off-by: Anup Patel <apatel at ventanamicro.com>
> > > > Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
> > > > Acked-by: Palmer Dabbelt <palmer at rivosinc.com>
> > > > ---
> > > >  drivers/clocksource/timer-riscv.c | 12 +++++++++++-
> > > >  1 file changed, 11 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c
> > > > index 969a552da8d2..1b4b36df5484 100644
> > > > --- a/drivers/clocksource/timer-riscv.c
> > > > +++ b/drivers/clocksource/timer-riscv.c
> > > > @@ -28,6 +28,7 @@
> > > >  #include <asm/timex.h>
> > > >
> > > >  static DEFINE_STATIC_KEY_FALSE(riscv_sstc_available);
> > > > +static bool riscv_timer_cannot_wake_cpu;
> > > >
> > > >  static int riscv_clock_next_event(unsigned long delta,
> > > >               struct clock_event_device *ce)
> > > > @@ -51,7 +52,7 @@ static int riscv_clock_next_event(unsigned long delta,
> > > >  static unsigned int riscv_clock_event_irq;
> > > >  static DEFINE_PER_CPU(struct clock_event_device, riscv_clock_event) = {
> > > >       .name                   = "riscv_timer_clockevent",
> > > > -     .features               = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP,
> > > > +     .features               = CLOCK_EVT_FEAT_ONESHOT,
> > >
> > > A platform that depended on CLOCK_EVT_FEAT_C3STOP being set will break
> > > with this change because its existing DT will not have the new property.
> > >
> > > It needs to be the other way around which would effectively be the
> > > existing 'always-on' property.
> >
> > There are no RISC-V platforms using C3STOP. The patch which
> > added C3STOP has been reverted.
> > (Refer, https://lore.kernel.org/lkml/a218ebf8-0fba-168d-6598-c970bbff5faf@sholland.org/T/)
> >
> > I just need to rebase this patch upon the C3STOP revert patch.
>
> I guess you could say that the C3STOP addition was done spec-ulatively*,
> as the platform that actually exhibits that behaviour does not use the
> riscv-timer & its maintainer acked the revert (allwinner d1 family).
>
> *The spec does not make any guarantees about whether events arrive
> during suspend, only the behaviour *if* they arrive.
>
> Switching the property to "always-on" would require retrofitting that
> property to every other existing platform (and therefore regressing some
> behaviour there, no?).
>
> Most of the existing platforms are "toys" or demo platforms though, so
> it would not, I guess, be the end of the world to do so. Doubly so since
> none of them actually implement any sleep states that making it an
> "always-on" property.
>
> I've said since the start that defaulting to C3STOP is the "safer" thing
> to do, and although we disagreed on this last time Anup, I think the
> better outcome of someone missing a DT property is inaccessible sleep
> states rather than going into sleep states they cannot get out of.
>
> For PolarFire SoC, which I guess is one of the few "commerical"
> platforms, I'd be willing to accept retrofitting, since we have not yet
> implemented such sleep states yet.
>
> Maybe Prabhakar knows whether the RZ/Five has either a) implemented
> sleep states and b) which side of the "timer events arrive in suspend"
> divide their platform lies on.
> I'm particular interested here since that is not a SiFive core complex.
>
On RZ/Five we haven't implemented the sleep states yet.

Cheers,
Prabhakar