From: Jisheng Zhang <jszhang@kernel.org>
To: Samuel Holland <samuel.holland@sifive.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] riscv: nommu: use CSR_TIME* for get_cycles* implementation
Date: Thu, 28 Mar 2024 18:11:32 +0800 [thread overview]
Message-ID: <ZgVCVKu5YaBDUULB@xhacker> (raw)
In-Reply-To: <ZgL31BFWvaLwYQrN@xhacker>
On Wed, Mar 27, 2024 at 12:29:13AM +0800, Jisheng Zhang wrote:
> On Mon, Mar 25, 2024 at 09:39:26PM -0500, Samuel Holland wrote:
> > Hi Jisheng,
> >
> > On 2024-03-25 11:40 AM, Jisheng Zhang wrote:
> > > Per riscv privileged spec, "The time CSR is a read-only shadow of the
> > > memory-mapped mtime register", "On RV32I the timeh CSR is a read-only
> > > shadow of the upper 32 bits of the memory-mapped mtime register, while
> > > time shadows only the lower 32 bits of mtime." Since get_cycles() only
> > > reads the timer, it's fine to use CSR_TIME to implement get_cycles().
> >
> > Unfortunately there are various implementations (e.g. FU740/Unmatched, probably
> > K210 which this code was originally used for) which do not implement the time
> > CSR, relying on M-mode software to emulate the CSR so S-mode software doesn't
> > notice. So this code is needed to support those platforms when running Linux in
> > M-mode.
>
> OOPS, I knew this for the first time there are such implementations
> which doesn't implement the TIME CSR :(
>
> >
> > Maybe there should be an option to assume the time CSR is/is not implemented,
> > like there is for misaligned access?
>
> Yep, this seems the only solution. Then which should be the default
> choice? I.E
>
> Assume all NOMMU goes through TIME CSR, and provide an option for
> platform lacking of TIME CSR. This prefers TIME CSR.
Hi all,
v2 will prefer TIME CSR.
Thanks
>
> VS.
>
> By default, MTIME is used, and provide one Kconfig option for TIME CSR
> usage. This prefers MTIME
>
> which choice is better? Any suggestion?
>
> Thanks in advance
>
> >
> > Regards,
> > Samuel
> >
> > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> > > ---
> > > arch/riscv/include/asm/timex.h | 40 ----------------------------------
> > > 1 file changed, 40 deletions(-)
> > >
> > > diff --git a/arch/riscv/include/asm/timex.h b/arch/riscv/include/asm/timex.h
> > > index a06697846e69..a3fb85d505d4 100644
> > > --- a/arch/riscv/include/asm/timex.h
> > > +++ b/arch/riscv/include/asm/timex.h
> > > @@ -10,44 +10,6 @@
> > >
> > > typedef unsigned long cycles_t;
> > >
> > > -#ifdef CONFIG_RISCV_M_MODE
> > > -
> > > -#include <asm/clint.h>
> > > -
> > > -#ifdef CONFIG_64BIT
> > > -static inline cycles_t get_cycles(void)
> > > -{
> > > - return readq_relaxed(clint_time_val);
> > > -}
> > > -#else /* !CONFIG_64BIT */
> > > -static inline u32 get_cycles(void)
> > > -{
> > > - return readl_relaxed(((u32 *)clint_time_val));
> > > -}
> > > -#define get_cycles get_cycles
> > > -
> > > -static inline u32 get_cycles_hi(void)
> > > -{
> > > - return readl_relaxed(((u32 *)clint_time_val) + 1);
> > > -}
> > > -#define get_cycles_hi get_cycles_hi
> > > -#endif /* CONFIG_64BIT */
> > > -
> > > -/*
> > > - * Much like MIPS, we may not have a viable counter to use at an early point
> > > - * in the boot process. Unfortunately we don't have a fallback, so instead
> > > - * we just return 0.
> > > - */
> > > -static inline unsigned long random_get_entropy(void)
> > > -{
> > > - if (unlikely(clint_time_val == NULL))
> > > - return random_get_entropy_fallback();
> > > - return get_cycles();
> > > -}
> > > -#define random_get_entropy() random_get_entropy()
> > > -
> > > -#else /* CONFIG_RISCV_M_MODE */
> > > -
> > > static inline cycles_t get_cycles(void)
> > > {
> > > return csr_read(CSR_TIME);
> > > @@ -60,8 +22,6 @@ static inline u32 get_cycles_hi(void)
> > > }
> > > #define get_cycles_hi get_cycles_hi
> > >
> > > -#endif /* !CONFIG_RISCV_M_MODE */
> > > -
> > > #ifdef CONFIG_64BIT
> > > static inline u64 get_cycles64(void)
> > > {
> >
next prev parent reply other threads:[~2024-03-28 10:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 16:40 [PATCH 0/5] riscv: improve nommu and timer-clint Jisheng Zhang
2024-03-25 16:40 ` [PATCH 1/5] riscv: nommu: remove PAGE_OFFSET hardcoding Jisheng Zhang
2024-03-25 22:46 ` Bo Gan
2024-03-26 1:28 ` Jisheng Zhang
2024-03-26 2:32 ` Samuel Holland
2024-03-25 16:40 ` [PATCH 2/5] riscv: nommu: use CSR_TIME* for get_cycles* implementation Jisheng Zhang
2024-03-26 2:39 ` Samuel Holland
2024-03-26 16:29 ` Jisheng Zhang
2024-03-27 7:58 ` [External] " yunhui cui
2024-03-28 10:11 ` Jisheng Zhang [this message]
2024-03-25 16:40 ` [PATCH 3/5] clocksource/drivers/timer-clint: Remove clint_time_val Jisheng Zhang
2024-03-25 16:40 ` [PATCH 4/5] clocksource/drivers/timer-clint: Use get_cycles() Jisheng Zhang
2024-03-25 16:40 ` [PATCH 5/5] clocksource/drivers/timer-clint: Add T-Head C9xx clint support Jisheng Zhang
2024-03-25 16:50 ` Jisheng Zhang
2024-03-25 22:22 ` Bo Gan
2024-03-26 1:25 ` Jisheng Zhang
2024-03-26 1:31 ` Jisheng Zhang
2024-03-26 16:33 ` Jisheng Zhang
2024-03-27 22:53 ` kernel test robot
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=ZgVCVKu5YaBDUULB@xhacker \
--to=jszhang@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=samuel.holland@sifive.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox