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

Conor Dooley conor at kernel.org
Fri Nov 25 15:44:01 PST 2022


On Fri, Nov 25, 2022 at 01:13:04PM +0000, Conor Dooley wrote:
> On Fri, Nov 25, 2022 at 04:51:05PM +0530, Anup Patel wrote:
> > We should set CLOCK_EVT_FEAT_C3STOP for a clock_event_device only
> > when riscv,timer-cant-wake-up 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.
> 
> I need to go do some testing on what setting the C3STOP flag does on
> platforms other than PolarFire SoC. I'm not sure that we should be
> enabling this flag *at all* until we know that it does not break on
> other platforms too.

I tried my fu540 & fu740 - both of those seem to exhibit broken timer
behaviour with C3STOP set. Ethernet doesn't work upstream on the
VisionFive, so I didn't go through the hassle of testing that - but I
would imagine it is the same as the fu740. Whenever I get a VisionFive 2
I'll give that a try too.

I did try the D1 (thanks for fielding my dumb questions Samuel) but I
was not able to get the thing to boot if I disabled the sunxi timer :/
Ethernet would not come up in U-Boot, clearly I did something not
right..

Obviously we need to fix things & get it backported etc, so taking a
pragmatic approach: I think that it is better to merge this stuff even
though it there's a pretty good chance I think that it'll break the
SBI timer on a D1, since it is not intended that it will be used.

It does make me worried about some of the other platforms though, like
that Bouffalolabs SoC that Jisheng sent in a DT for. It's also using
thead stuff so I wonder if it needs C3STOP too. I've added Jisheng to
CC :)

> > Signed-off-by: Anup Patel <apatel at ventanamicro.com>
> > ---
> >  drivers/clocksource/timer-riscv.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c
> > index a0d66fabf073..0c8bdd168a45 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_cant_wake_cpu;
> >  
> >  static int riscv_clock_next_event(unsigned long delta,
> >  		struct clock_event_device *ce)
> > @@ -85,6 +86,8 @@ static int riscv_timer_starting_cpu(unsigned int cpu)
> >  
> >  	ce->cpumask = cpumask_of(cpu);
> >  	ce->irq = riscv_clock_event_irq;
> > +	if (riscv_timer_cant_wake_cpu)
> > +		ce->features |= CLOCK_EVT_FEAT_C3STOP;
> >  	clockevents_config_and_register(ce, riscv_timebase, 100, 0x7fffffff);
> >  
> >  	enable_percpu_irq(riscv_clock_event_irq,
> > @@ -139,6 +142,13 @@ static int __init riscv_timer_init_dt(struct device_node *n)
> >  	if (cpuid != smp_processor_id())
> >  		return 0;
> >  
> > +	child = of_find_compatible_node(NULL, NULL, "riscv,timer");
> > +	if (child) {
> > +		riscv_timer_cant_wake_cpu = of_property_read_bool(child,
> > +						"riscv,timer-cant-wake-cpu");
> > +		of_node_put(child);
> > +	}
> > +
> >  	domain = NULL;
> >  	child = of_get_compatible_child(n, "riscv,cpu-intc");
> >  	if (!child) {

Anyway, the mechanics of the change here look good to me. The re-use of
child is understandable but a little odd though, since riscv,timer /is
not/ actually a child. That's relatively minor thing to change though.

I'm still not happy about turning on C3STOP when we have not figured out
why it's breaking timer behaviour, but I think that's the lessor of two
evils. Somewhat reluctantly:
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

I'll try to spend some time looking into why it's broken.

Thanks,
Conor.




More information about the linux-riscv mailing list