Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i0ad843c9:Fastmail
Message-ID: <0515dc20-2e82-bd16-301a-6ffff010af13@sholland.org>
Date:   Mon, 5 Dec 2022 02:17:40 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux ppc64le; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Content-Language: en-US
To:     Conor Dooley <conor@kernel.org>,
        Anup Patel <apatel@ventanamicro.com>,
        Rob Herring <robh@kernel.org>,
        "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Daniel Lezcano <daniel.lezcano@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andrew Jones <ajones@ventanamicro.com>,
        Atish Patra <atishp@atishpatra.org>,
        Conor Dooley <conor.dooley@microchip.com>,
        Anup Patel <anup@brainfault.org>, devicetree@vger.kernel.org,
        linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
        Palmer Dabbelt <palmer@rivosinc.com>
References: <20221201123954.1111603-1-apatel@ventanamicro.com>
 <20221201123954.1111603-4-apatel@ventanamicro.com>
 <20221202000603.GA1720201-robh@kernel.org>
 <CAK9=C2VbM+CP0Y9Xx-SM9O4TFrQmOKvVWy-u5mxdPxrhacK4JQ@mail.gmail.com>
 <Y40ueQiTZK6hi7RS@spud>
From:   Samuel Holland <samuel@sholland.org>
Subject: Re: [PATCH v5 3/3] clocksource: timer-riscv: Set
 CLOCK_EVT_FEAT_C3STOP based on DT
In-Reply-To: <Y40ueQiTZK6hi7RS@spud>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.
>