From: Palmer Dabbelt <[email protected]>
As of d9f15a9de44a ("Revert "clocksource/drivers/riscv: Events are
stopped during CPU suspend"") this driver no longer functions correctly
for the T-Head firmware. That shouldn't impact any users, as we've got
a functioning driver that's higher priority, but let's just be safe and
ban it from probing at all.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
This feel super ugly to me, but I'm not sure how to do this more
cleanly. I'm not even sure if it's necessary, but I just ran back into
the driver reviewing some other patches so I figured I'd say something.
---
drivers/clocksource/timer-riscv.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c
index a0d66fabf073..d2d0236d1ae6 100644
--- a/drivers/clocksource/timer-riscv.c
+++ b/drivers/clocksource/timer-riscv.c
@@ -139,6 +139,22 @@ static int __init riscv_timer_init_dt(struct device_node *n)
if (cpuid != smp_processor_id())
return 0;
+ /*
+ * The T-Head firmware does not route timer interrups to the core
+ * during non-retentive suspend. This is allowed by the specifications
+ * (no interrupts are required to wake up the core during non-retentive
+ * suspend), but most systems don't behave that way and Linux just
+ * assumes that interrupts work.
+ *
+ * There's another timer for the T-Head sytems that behave this way
+ * that is already probed by default, but just to be sure skip
+ * initializing the SBI driver as it'll just break things later.
+ */
+ if (sbi_get_mvendorid() == THEAD_VENDOR_ID) {
+ pr_debug_once("Skipping SBI timer on T-Head due to missed wakeups");
+ return 0;
+ }
+
domain = NULL;
child = of_get_compatible_child(n, "riscv,cpu-intc");
if (!child) {
--
2.39.1
Hi Palmer,
On 2/9/23 17:23, Palmer Dabbelt wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As of d9f15a9de44a ("Revert "clocksource/drivers/riscv: Events are
> stopped during CPU suspend"") this driver no longer functions correctly
> for the T-Head firmware. That shouldn't impact any users, as we've got
The current situation is that the C9xx CLINT binding was just accepted,
so the CLINT is not yet described in any devicetree. So at least with
upstream OpenSBI, which needs the CLINT DT node, the SBI timer extension
never worked at all.
> a functioning driver that's higher priority, but let's just be safe and
> ban it from probing at all.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> This feel super ugly to me, but I'm not sure how to do this more
> cleanly. I'm not even sure if it's necessary, but I just ran back into
> the driver reviewing some other patches so I figured I'd say something.
This is not necessary as long as we add the riscv,timer node with the
riscv,timer-cannot-wake-cpu property before we add the CLINT node. So it
should not be a problem for any C9xx platform going forward.
Regards,
Samuel
> ---
> drivers/clocksource/timer-riscv.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c
> index a0d66fabf073..d2d0236d1ae6 100644
> --- a/drivers/clocksource/timer-riscv.c
> +++ b/drivers/clocksource/timer-riscv.c
> @@ -139,6 +139,22 @@ static int __init riscv_timer_init_dt(struct device_node *n)
> if (cpuid != smp_processor_id())
> return 0;
>
> + /*
> + * The T-Head firmware does not route timer interrups to the core
> + * during non-retentive suspend. This is allowed by the specifications
> + * (no interrupts are required to wake up the core during non-retentive
> + * suspend), but most systems don't behave that way and Linux just
> + * assumes that interrupts work.
> + *
> + * There's another timer for the T-Head sytems that behave this way
> + * that is already probed by default, but just to be sure skip
> + * initializing the SBI driver as it'll just break things later.
> + */
> + if (sbi_get_mvendorid() == THEAD_VENDOR_ID) {
> + pr_debug_once("Skipping SBI timer on T-Head due to missed wakeups");
> + return 0;
> + }
> +
> domain = NULL;
> child = of_get_compatible_child(n, "riscv,cpu-intc");
> if (!child) {
On Thu, 09 Feb 2023 15:35:53 PST (-0800), [email protected] wrote:
> Hi Palmer,
>
> On 2/9/23 17:23, Palmer Dabbelt wrote:
>> From: Palmer Dabbelt <[email protected]>
>>
>> As of d9f15a9de44a ("Revert "clocksource/drivers/riscv: Events are
>> stopped during CPU suspend"") this driver no longer functions correctly
>> for the T-Head firmware. That shouldn't impact any users, as we've got
>
> The current situation is that the C9xx CLINT binding was just accepted,
> so the CLINT is not yet described in any devicetree. So at least with
> upstream OpenSBI, which needs the CLINT DT node, the SBI timer extension
> never worked at all.
>
>> a functioning driver that's higher priority, but let's just be safe and
>> ban it from probing at all.
>>
>> Signed-off-by: Palmer Dabbelt <[email protected]>
>> ---
>> This feel super ugly to me, but I'm not sure how to do this more
>> cleanly. I'm not even sure if it's necessary, but I just ran back into
>> the driver reviewing some other patches so I figured I'd say something.
>
> This is not necessary as long as we add the riscv,timer node with the
> riscv,timer-cannot-wake-cpu property before we add the CLINT node. So it
> should not be a problem for any C9xx platform going forward.
Awesome, that sounds way better.
>
> Regards,
> Samuel
>
>> ---
>> drivers/clocksource/timer-riscv.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c
>> index a0d66fabf073..d2d0236d1ae6 100644
>> --- a/drivers/clocksource/timer-riscv.c
>> +++ b/drivers/clocksource/timer-riscv.c
>> @@ -139,6 +139,22 @@ static int __init riscv_timer_init_dt(struct device_node *n)
>> if (cpuid != smp_processor_id())
>> return 0;
>>
>> + /*
>> + * The T-Head firmware does not route timer interrups to the core
>> + * during non-retentive suspend. This is allowed by the specifications
>> + * (no interrupts are required to wake up the core during non-retentive
>> + * suspend), but most systems don't behave that way and Linux just
>> + * assumes that interrupts work.
>> + *
>> + * There's another timer for the T-Head sytems that behave this way
>> + * that is already probed by default, but just to be sure skip
>> + * initializing the SBI driver as it'll just break things later.
>> + */
>> + if (sbi_get_mvendorid() == THEAD_VENDOR_ID) {
>> + pr_debug_once("Skipping SBI timer on T-Head due to missed wakeups");
>> + return 0;
>> + }
>> +
>> domain = NULL;
>> child = of_get_compatible_child(n, "riscv,cpu-intc");
>> if (!child) {
Hey Palmer,
On Thu, Feb 09, 2023 at 03:23:02PM -0800, Palmer Dabbelt wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As of d9f15a9de44a ("Revert "clocksource/drivers/riscv: Events are
> stopped during CPU suspend"") this driver no longer functions correctly
> for the T-Head firmware. That shouldn't impact any users, as we've got
> a functioning driver that's higher priority, but let's just be safe and
> ban it from probing at all.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> This feel super ugly to me, but I'm not sure how to do this more
> cleanly. I'm not even sure if it's necessary, but I just ran back into
> the driver reviewing some other patches so I figured I'd say something.
I'm not super sure what you're trying to fix here. That revert went
through to restore behaviour for the SiFive stuff that do deliver events
in suspend.
Subsequently, we added a DT property (probably the wrong one tbh, but
that's all said and done now) that communicates that a timer is
incapable of waking the cpus. See commit 98ce3981716c ("dt-bindings:
timer: Add bindings for the RISC-V timer device") & the full patchset is
at:
https://lore.kernel.org/linux-riscv/[email protected]/
AFAIU, the binding for the T-HEAD clint was only accepted in the last
week & there's nothing actually using this timer. IIRC, when I wanted to
test the timer, Samuel cooked me up a WIP openSBI etc to enable it.
So ye, I don't think this is needed fortunately!
Cheers,
Conor.
On Thu, 09 Feb 2023 15:40:45 PST (-0800), Conor Dooley wrote:
> Hey Palmer,
>
> On Thu, Feb 09, 2023 at 03:23:02PM -0800, Palmer Dabbelt wrote:
>> From: Palmer Dabbelt <[email protected]>
>>
>> As of d9f15a9de44a ("Revert "clocksource/drivers/riscv: Events are
>> stopped during CPU suspend"") this driver no longer functions correctly
>> for the T-Head firmware. That shouldn't impact any users, as we've got
>> a functioning driver that's higher priority, but let's just be safe and
>> ban it from probing at all.
>>
>> Signed-off-by: Palmer Dabbelt <[email protected]>
>> ---
>> This feel super ugly to me, but I'm not sure how to do this more
>> cleanly. I'm not even sure if it's necessary, but I just ran back into
>> the driver reviewing some other patches so I figured I'd say something.
>
> I'm not super sure what you're trying to fix here. That revert went
> through to restore behaviour for the SiFive stuff that do deliver events
> in suspend.
My worry was that we'd end up probing the SBI driver on T-Head systems,
where it doesn't work (as the combination of SBI timer and SBI suspend
depends on unspecified behavior). So we'd be better off just failing
early and obviously in the case, rather than letting users think they
could get away with only the SBI drivers.
> Subsequently, we added a DT property (probably the wrong one tbh, but
> that's all said and done now) that communicates that a timer is
> incapable of waking the cpus. See commit 98ce3981716c ("dt-bindings:
> timer: Add bindings for the RISC-V timer device") & the full patchset is
> at:
> https://lore.kernel.org/linux-riscv/[email protected]/
>
> AFAIU, the binding for the T-HEAD clint was only accepted in the last
> week & there's nothing actually using this timer. IIRC, when I wanted to
> test the timer, Samuel cooked me up a WIP openSBI etc to enable it.
That makes sense. I'd assumed these DTs just had the SBI timer in there
(as a bunch of other stuff requires it), but from Samuel's reply it
sounds like I was just wrong here. I guess we're sort of in a grey area
for DTs that aren't in the kernel source tree, but this code is ugly
enough I'm OK just ignoring those.
> So ye, I don't think this is needed fortunately!
Ya, I think so too.
>
> Cheers,
> Conor.