* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
@ 2022-12-04 23:34 ` Conor Dooley
0 siblings, 0 replies; 26+ messages in thread
From: Conor Dooley @ 2022-12-04 23:34 UTC (permalink / raw)
To: Anup Patel, Rob Herring, Lad, Prabhakar
Cc: Rob Herring, Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
Daniel Lezcano, Thomas Gleixner, Andrew Jones, Atish Patra,
Samuel Holland, Conor Dooley, Anup Patel, devicetree, linux-riscv,
linux-kernel, Palmer Dabbelt
[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]
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@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@ventanamicro.com>
> > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > Acked-by: Palmer Dabbelt <palmer@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.
I would like to get DT maintainer approval of an approach here soon-ish
so that we can something sorted for the jh7110 stuff and for the
bouffalolabs SoC - the latter of which may very well be in the "no
events in suspend" camp as it also uses thead stuff.
Sorry for kinda rowing back on my previous acceptance of the approach,
but I am really between two minds on this.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
2022-12-04 23:34 ` Conor Dooley
@ 2022-12-05 8:17 ` Samuel Holland
-1 siblings, 0 replies; 26+ messages in thread
From: Samuel Holland @ 2022-12-05 8:17 UTC (permalink / raw)
To: Conor Dooley, Anup Patel, Rob Herring, Lad, Prabhakar
Cc: Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
Daniel Lezcano, Thomas Gleixner, Andrew Jones, Atish Patra,
Conor Dooley, Anup Patel, devicetree, linux-riscv, linux-kernel,
Palmer Dabbelt
On 12/4/22 17:34, Conor Dooley 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@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@ventanamicro.com>
>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>>>> Acked-by: Palmer Dabbelt <palmer@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).
For clarity: that doesn't mean the platform will _never_ use the SBI
timer facility, just that Linux happens to not use it right now.
> *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.
Specifically, only sleep states with a "local-timer-stop" property would
be inhibited by the C3STOP flag, so there is only possibility of a
regression if some DT declaring such a sleep state exists anywhere.
Regards,
Samuel
> 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.
>
> I would like to get DT maintainer approval of an approach here soon-ish
> so that we can something sorted for the jh7110 stuff and for the
> bouffalolabs SoC - the latter of which may very well be in the "no
> events in suspend" camp as it also uses thead stuff.
>
> Sorry for kinda rowing back on my previous acceptance of the approach,
> but I am really between two minds on this.
>
> Thanks,
> Conor.
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
@ 2022-12-05 8:17 ` Samuel Holland
0 siblings, 0 replies; 26+ messages in thread
From: Samuel Holland @ 2022-12-05 8:17 UTC (permalink / raw)
To: Conor Dooley, Anup Patel, Rob Herring, Lad, Prabhakar
Cc: Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
Daniel Lezcano, Thomas Gleixner, Andrew Jones, Atish Patra,
Conor Dooley, Anup Patel, devicetree, linux-riscv, linux-kernel,
Palmer Dabbelt
On 12/4/22 17:34, Conor Dooley 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@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@ventanamicro.com>
>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>>>> Acked-by: Palmer Dabbelt <palmer@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).
For clarity: that doesn't mean the platform will _never_ use the SBI
timer facility, just that Linux happens to not use it right now.
> *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.
Specifically, only sleep states with a "local-timer-stop" property would
be inhibited by the C3STOP flag, so there is only possibility of a
regression if some DT declaring such a sleep state exists anywhere.
Regards,
Samuel
> 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.
>
> I would like to get DT maintainer approval of an approach here soon-ish
> so that we can something sorted for the jh7110 stuff and for the
> bouffalolabs SoC - the latter of which may very well be in the "no
> events in suspend" camp as it also uses thead stuff.
>
> Sorry for kinda rowing back on my previous acceptance of the approach,
> but I am really between two minds on this.
>
> Thanks,
> Conor.
>
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
2022-12-05 8:17 ` Samuel Holland
@ 2022-12-05 8:33 ` Conor Dooley
-1 siblings, 0 replies; 26+ messages in thread
From: Conor Dooley @ 2022-12-05 8:33 UTC (permalink / raw)
To: Samuel Holland
Cc: Conor Dooley, Anup Patel, Rob Herring, Lad, Prabhakar,
Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
Daniel Lezcano, Thomas Gleixner, Andrew Jones, Atish Patra,
Anup Patel, devicetree, linux-riscv, linux-kernel, Palmer Dabbelt
On Mon, Dec 05, 2022 at 02:17:40AM -0600, Samuel Holland wrote:
> On 12/4/22 17:34, Conor Dooley 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@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@ventanamicro.com>
> >>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> >>>> Acked-by: Palmer Dabbelt <palmer@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).
>
> For clarity: that doesn't mean the platform will _never_ use the SBI
> timer facility, just that Linux happens to not use it right now.
Yeah sorry - should have been a bit clearer there. There's a few other
SoCs about that are using the thead cores, so I'd be "worried" that they
share the timer behaviour but do not have an alternative like you do on
the D1. That's part of what's kinda given me cold feet on the current
approach.
> > *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.
>
> Specifically, only sleep states with a "local-timer-stop" property would
> be inhibited by the C3STOP flag, so there is only possibility of a
> regression if some DT declaring such a sleep state exists anywhere.
>
> Regards,
> Samuel
>
> > 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.
> >
> > I would like to get DT maintainer approval of an approach here soon-ish
> > so that we can something sorted for the jh7110 stuff and for the
> > bouffalolabs SoC - the latter of which may very well be in the "no
> > events in suspend" camp as it also uses thead stuff.
> >
> > Sorry for kinda rowing back on my previous acceptance of the approach,
> > but I am really between two minds on this.
> >
> > Thanks,
> > Conor.
> >
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
@ 2022-12-05 8:33 ` Conor Dooley
0 siblings, 0 replies; 26+ messages in thread
From: Conor Dooley @ 2022-12-05 8:33 UTC (permalink / raw)
To: Samuel Holland
Cc: Conor Dooley, Anup Patel, Rob Herring, Lad, Prabhakar,
Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
Daniel Lezcano, Thomas Gleixner, Andrew Jones, Atish Patra,
Anup Patel, devicetree, linux-riscv, linux-kernel, Palmer Dabbelt
On Mon, Dec 05, 2022 at 02:17:40AM -0600, Samuel Holland wrote:
> On 12/4/22 17:34, Conor Dooley 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@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@ventanamicro.com>
> >>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> >>>> Acked-by: Palmer Dabbelt <palmer@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).
>
> For clarity: that doesn't mean the platform will _never_ use the SBI
> timer facility, just that Linux happens to not use it right now.
Yeah sorry - should have been a bit clearer there. There's a few other
SoCs about that are using the thead cores, so I'd be "worried" that they
share the timer behaviour but do not have an alternative like you do on
the D1. That's part of what's kinda given me cold feet on the current
approach.
> > *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.
>
> Specifically, only sleep states with a "local-timer-stop" property would
> be inhibited by the C3STOP flag, so there is only possibility of a
> regression if some DT declaring such a sleep state exists anywhere.
>
> Regards,
> Samuel
>
> > 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.
> >
> > I would like to get DT maintainer approval of an approach here soon-ish
> > so that we can something sorted for the jh7110 stuff and for the
> > bouffalolabs SoC - the latter of which may very well be in the "no
> > events in suspend" camp as it also uses thead stuff.
> >
> > Sorry for kinda rowing back on my previous acceptance of the approach,
> > but I am really between two minds on this.
> >
> > Thanks,
> > Conor.
> >
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
2022-12-05 8:33 ` Conor Dooley
@ 2022-12-28 11:59 ` Conor Dooley
-1 siblings, 0 replies; 26+ messages in thread
From: Conor Dooley @ 2022-12-28 11:59 UTC (permalink / raw)
To: Conor Dooley, Anup Patel
Cc: Samuel Holland, Anup Patel, Rob Herring, Lad, Prabhakar,
Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
Daniel Lezcano, Thomas Gleixner, Andrew Jones, Atish Patra,
Anup Patel, devicetree, linux-riscv, linux-kernel, Palmer Dabbelt
[-- Attachment #1.1: Type: text/plain, Size: 5917 bytes --]
Hey Anup (& Daniel++),
On Mon, Dec 05, 2022 at 08:33:53AM +0000, Conor Dooley wrote:
> On Mon, Dec 05, 2022 at 02:17:40AM -0600, Samuel Holland wrote:
> > On 12/4/22 17:34, Conor Dooley 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@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@ventanamicro.com>
> > >>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > >>>> Acked-by: Palmer Dabbelt <palmer@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).
> >
> > For clarity: that doesn't mean the platform will _never_ use the SBI
> > timer facility, just that Linux happens to not use it right now.
>
> Yeah sorry - should have been a bit clearer there. There's a few other
> SoCs about that are using the thead cores, so I'd be "worried" that they
> share the timer behaviour but do not have an alternative like you do on
> the D1. That's part of what's kinda given me cold feet on the current
> approach.
>
> > > *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.
> >
> > Specifically, only sleep states with a "local-timer-stop" property would
> > be inhibited by the C3STOP flag, so there is only possibility of a
> > regression if some DT declaring such a sleep state exists anywhere.
What is the plan for this series? IIRC, a rebase was required on top of
the revert?
I'm not overly pushed either way at this point, I'd like to get this
C3STOP issue sorted out before more thead powered SoCs start showing up
with the same implementation issues.
I know it is the Christmas period so not expecting anything to actually
happen right away.
Thanks,
Conor.
> > > 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.
> > >
> > > I would like to get DT maintainer approval of an approach here soon-ish
> > > so that we can something sorted for the jh7110 stuff and for the
> > > bouffalolabs SoC - the latter of which may very well be in the "no
> > > events in suspend" camp as it also uses thead stuff.
> > >
> > > Sorry for kinda rowing back on my previous acceptance of the approach,
> > > but I am really between two minds on this.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
@ 2022-12-28 11:59 ` Conor Dooley
0 siblings, 0 replies; 26+ messages in thread
From: Conor Dooley @ 2022-12-28 11:59 UTC (permalink / raw)
To: Conor Dooley, Anup Patel
Cc: Samuel Holland, Anup Patel, Rob Herring, Lad, Prabhakar,
Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
Daniel Lezcano, Thomas Gleixner, Andrew Jones, Atish Patra,
Anup Patel, devicetree, linux-riscv, linux-kernel, Palmer Dabbelt
[-- Attachment #1: Type: text/plain, Size: 5917 bytes --]
Hey Anup (& Daniel++),
On Mon, Dec 05, 2022 at 08:33:53AM +0000, Conor Dooley wrote:
> On Mon, Dec 05, 2022 at 02:17:40AM -0600, Samuel Holland wrote:
> > On 12/4/22 17:34, Conor Dooley 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@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@ventanamicro.com>
> > >>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > >>>> Acked-by: Palmer Dabbelt <palmer@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).
> >
> > For clarity: that doesn't mean the platform will _never_ use the SBI
> > timer facility, just that Linux happens to not use it right now.
>
> Yeah sorry - should have been a bit clearer there. There's a few other
> SoCs about that are using the thead cores, so I'd be "worried" that they
> share the timer behaviour but do not have an alternative like you do on
> the D1. That's part of what's kinda given me cold feet on the current
> approach.
>
> > > *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.
> >
> > Specifically, only sleep states with a "local-timer-stop" property would
> > be inhibited by the C3STOP flag, so there is only possibility of a
> > regression if some DT declaring such a sleep state exists anywhere.
What is the plan for this series? IIRC, a rebase was required on top of
the revert?
I'm not overly pushed either way at this point, I'd like to get this
C3STOP issue sorted out before more thead powered SoCs start showing up
with the same implementation issues.
I know it is the Christmas period so not expecting anything to actually
happen right away.
Thanks,
Conor.
> > > 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.
> > >
> > > I would like to get DT maintainer approval of an approach here soon-ish
> > > so that we can something sorted for the jh7110 stuff and for the
> > > bouffalolabs SoC - the latter of which may very well be in the "no
> > > events in suspend" camp as it also uses thead stuff.
> > >
> > > Sorry for kinda rowing back on my previous acceptance of the approach,
> > > but I am really between two minds on this.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
2022-12-04 23:34 ` Conor Dooley
@ 2022-12-06 22:02 ` Lad, Prabhakar
-1 siblings, 0 replies; 26+ messages in thread
From: Lad, Prabhakar @ 2022-12-06 22:02 UTC (permalink / raw)
To: Conor Dooley
Cc: Anup Patel, Rob Herring, Krzysztof Kozlowski, Palmer Dabbelt,
Paul Walmsley, Daniel Lezcano, Thomas Gleixner, Andrew Jones,
Atish Patra, Samuel Holland, Conor Dooley, Anup Patel, devicetree,
linux-riscv, linux-kernel, Palmer Dabbelt
Hi Conor,
On Sun, Dec 4, 2022 at 11:34 PM Conor Dooley <conor@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@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@ventanamicro.com>
> > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > > Acked-by: Palmer Dabbelt <palmer@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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v5 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
@ 2022-12-06 22:02 ` Lad, Prabhakar
0 siblings, 0 replies; 26+ messages in thread
From: Lad, Prabhakar @ 2022-12-06 22:02 UTC (permalink / raw)
To: Conor Dooley
Cc: Anup Patel, Rob Herring, Krzysztof Kozlowski, Palmer Dabbelt,
Paul Walmsley, Daniel Lezcano, Thomas Gleixner, Andrew Jones,
Atish Patra, Samuel Holland, Conor Dooley, Anup Patel, devicetree,
linux-riscv, linux-kernel, Palmer Dabbelt
Hi Conor,
On Sun, Dec 4, 2022 at 11:34 PM Conor Dooley <conor@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@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@ventanamicro.com>
> > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > > Acked-by: Palmer Dabbelt <palmer@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
^ permalink raw reply [flat|nested] 26+ messages in thread