From: Conor Dooley <conor@kernel.org>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Anup Patel <apatel@ventanamicro.com>,
Rob Herring <robh+dt@kernel.org>,
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>,
Samuel Holland <samuel@sholland.org>,
Anup Patel <anup@brainfault.org>,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, Jisheng Zhang <jszhang@kernel.org>
Subject: Re: [PATCH v3 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
Date: Fri, 25 Nov 2022 23:44:01 +0000 [thread overview]
Message-ID: <Y4FTQenbPLXy/9Bz@spud> (raw)
In-Reply-To: <Y4C/YOoHxX5dxwG3@wendy>
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@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@microchip.com>
I'll try to spend some time looking into why it's broken.
Thanks,
Conor.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Anup Patel <apatel@ventanamicro.com>,
Rob Herring <robh+dt@kernel.org>,
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>,
Samuel Holland <samuel@sholland.org>,
Anup Patel <anup@brainfault.org>,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, Jisheng Zhang <jszhang@kernel.org>
Subject: Re: [PATCH v3 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT
Date: Fri, 25 Nov 2022 23:44:01 +0000 [thread overview]
Message-ID: <Y4FTQenbPLXy/9Bz@spud> (raw)
In-Reply-To: <Y4C/YOoHxX5dxwG3@wendy>
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@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@microchip.com>
I'll try to spend some time looking into why it's broken.
Thanks,
Conor.
next prev parent reply other threads:[~2022-11-25 23:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-25 11:21 [PATCH v3 0/3] Improve CLOCK_EVT_FEAT_C3STOP feature setting Anup Patel
2022-11-25 11:21 ` Anup Patel
2022-11-25 11:21 ` [PATCH v3 1/3] Revert "clocksource/drivers/riscv: Events are stopped during CPU suspend" Anup Patel
2022-11-25 11:21 ` Anup Patel
2022-11-25 11:21 ` [PATCH v3 2/3] dt-bindings: timer: Add bindings for the RISC-V timer device Anup Patel
2022-11-25 11:21 ` Anup Patel
2022-11-25 13:09 ` Conor Dooley
2022-11-25 13:09 ` Conor Dooley
2022-11-25 13:48 ` Anup Patel
2022-11-25 13:48 ` Anup Patel
2022-11-25 23:57 ` Conor Dooley
2022-11-25 23:57 ` Conor Dooley
2022-11-25 11:21 ` [PATCH v3 3/3] clocksource: timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DT Anup Patel
2022-11-25 11:21 ` Anup Patel
2022-11-25 13:13 ` Conor Dooley
2022-11-25 13:13 ` Conor Dooley
2022-11-25 23:44 ` Conor Dooley [this message]
2022-11-25 23:44 ` Conor Dooley
2022-11-26 14:51 ` Conor Dooley
2022-11-26 14:51 ` Conor Dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y4FTQenbPLXy/9Bz@spud \
--to=conor@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jszhang@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.