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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>
>>>> Reviewed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
>>>> Acked-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
>>>> ---
>>>> 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@xxxxxxxxxxxx/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.
>
