From: Boqun Feng <boqun.feng@gmail.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"David Airlie" <airlied@gmail.com>,
"John Hubbard" <jhubbard@nvidia.com>,
"Ben Skeggs" <bskeggs@nvidia.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Simona Vetter" <simona@ffwll.ch>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH RFC v3 6/7] gpu: nova-core: add basic timer device
Date: Thu, 20 Mar 2025 11:17:58 -0700 [thread overview]
Message-ID: <Z9xb1r1x5tOzAIZT@boqun-archlinux> (raw)
In-Reply-To: <20250320-nova_timer-v3-6-79aa2ad25a79@nvidia.com>
Hi Alexandre,
On Thu, Mar 20, 2025 at 10:39:14PM +0900, Alexandre Courbot wrote:
> Add a basic timer device and exercise it during device probing. This
> first draft is probably very questionable.
>
> One point in particular which should IMHO receive attention: the generic
> wait_on() method aims at providing similar functionality to Nouveau's
> nvkm_[num]sec() macros. Since this method will be heavily used with
> different conditions to test, I'd like to avoid monomorphizing it
> entirely with each instance ; that's something that is achieved in
> nvkm_xsec() using functions that the macros invoke.
>
> I have tried achieving the same result in Rust using closures (kept
> as-is in the current code), but they seem to be monomorphized as well.
> Calling extra functions could work better, but looks also less elegant
> to me, so I am really open to suggestions here.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpu/nova-core/driver.rs | 4 +-
> drivers/gpu/nova-core/gpu.rs | 55 +++++++++++++++-
> drivers/gpu/nova-core/nova_core.rs | 1 +
> drivers/gpu/nova-core/regs.rs | 11 ++++
> drivers/gpu/nova-core/timer.rs | 132 +++++++++++++++++++++++++++++++++++++
> 5 files changed, 201 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
> index 63c19f140fbdd65d8fccf81669ac590807cc120f..0cd23aa306e4082405f480afc0530a41131485e7 100644
> --- a/drivers/gpu/nova-core/driver.rs
> +++ b/drivers/gpu/nova-core/driver.rs
> @@ -10,7 +10,7 @@ pub(crate) struct NovaCore {
> pub(crate) gpu: Gpu,
> }
>
> -const BAR0_SIZE: usize = 8;
> +const BAR0_SIZE: usize = 0x9500;
> pub(crate) type Bar0 = pci::Bar<BAR0_SIZE>;
>
> kernel::pci_device_table!(
> @@ -42,6 +42,8 @@ fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>
> GFP_KERNEL,
> )?;
>
> + let _ = this.gpu.test_timer();
> +
> Ok(this)
> }
> }
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index d96901e5c8eace1e7c57c77da7def209e8149cd3..f010d3152530b1cec032ca620e59de51a2fc1a13 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -6,8 +6,10 @@
>
> use crate::driver::Bar0;
> use crate::regs;
> +use crate::timer::Timer;
> use crate::util;
> use core::fmt;
> +use core::time::Duration;
>
Since there is already a Delta type proposed to represent the timestamp
difference in kernel:
https://lore.kernel.org/rust-for-linux/20250220070611.214262-4-fujita.tomonori@gmail.com/
, could you please make your work based on that and avoid using
core::time::Duration. Thanks!
> macro_rules! define_chipset {
> ({ $($variant:ident = $value:expr),* $(,)* }) =>
> @@ -179,6 +181,7 @@ pub(crate) struct Gpu {
> /// MMIO mapping of PCI BAR 0
> bar: Devres<Bar0>,
> fw: Firmware,
> + timer: Timer,
> }
>
[...]
> +
> +/// A timestamp with nanosecond granularity obtained from the GPU timer.
> +///
> +/// A timestamp can also be substracted to another in order to obtain a [`Duration`].
> +///
> +/// TODO: add Kunit tests!
> +#[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
> +pub(crate) struct Timestamp(u64);
> +
Also an Instant type has been proposed and reviewed for a while:
https://lore.kernel.org/rust-for-linux/20250220070611.214262-5-fujita.tomonori@gmail.com/
we should use that type instead of re-inventing the wheel here. Of
course, it's currently not quite working because Instant is only for
CLOCK_MONOTONIC. But there was a proposal to make `Instant` generic over
clock:
https://lore.kernel.org/rust-for-linux/20230714-rust-time-v2-1-f5aed84218c4@asahilina.net/
if you follow that design, you can implement a `Instant<NovaGpu>`, where
ipml Now for NovaGpu {
fn now() -> Instant<Self> {
// your Timer::read() implementation.
}
}
Thanks!
Regards,
Boqun
> +impl Display for Timestamp {
> + fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
> + write!(f, "{}", self.0)
> + }
> +}
> +
> +impl Add<Duration> for Timestamp {
> + type Output = Self;
> +
> + fn add(mut self, rhs: Duration) -> Self::Output {
> + let mut nanos = rhs.as_nanos();
> + while nanos > u64::MAX as u128 {
> + self.0 = self.0.wrapping_add(nanos as u64);
> + nanos -= u64::MAX as u128;
> + }
> +
> + Timestamp(self.0.wrapping_add(nanos as u64))
> + }
> +}
> +
> +impl Sub for Timestamp {
> + type Output = Duration;
> +
> + fn sub(self, rhs: Self) -> Self::Output {
> + Duration::from_nanos(self.0.wrapping_sub(rhs.0))
> + }
> +}
> +
> +pub(crate) struct Timer {}
> +
> +impl Timer {
> + pub(crate) fn new() -> Self {
> + Self {}
> + }
> +
> + /// Read the current timer timestamp.
> + pub(crate) fn read(&self, bar: &Bar0) -> Timestamp {
> + loop {
> + let hi = regs::PtimerTime1::read(bar);
> + let lo = regs::PtimerTime0::read(bar);
> +
> + if hi.hi() == regs::PtimerTime1::read(bar).hi() {
> + return Timestamp(u64::from_u32s(hi.hi(), lo.lo()));
> + }
> + }
> + }
> +
[...]
next prev parent reply other threads:[~2025-03-20 18:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 13:39 [RFC PATCH v3 0/7] gpu: nova-core: register definitions and basic timer and falcon devices Alexandre Courbot
2025-03-20 13:39 ` [PATCH RFC v3 1/7] rust: add useful ops for u64 Alexandre Courbot
2025-03-20 13:39 ` [PATCH RFC v3 2/7] rust: make ETIMEDOUT error available Alexandre Courbot
2025-03-20 13:39 ` [PATCH RFC v3 3/7] gpu: nova-core: derive useful traits for Chipset Alexandre Courbot
2025-03-20 13:39 ` [PATCH RFC v3 4/7] gpu: nova-core: add missing GA100 definition Alexandre Courbot
2025-03-20 13:39 ` [PATCH RFC v3 5/7] gpu: nova-core: use register!() to define register layout Alexandre Courbot
2025-03-20 13:39 ` [PATCH RFC v3 6/7] gpu: nova-core: add basic timer device Alexandre Courbot
2025-03-20 15:54 ` Daniel Brooks
2025-03-21 3:09 ` Alexandre Courbot
2025-03-20 18:17 ` Boqun Feng [this message]
2025-03-21 5:41 ` Alexandre Courbot
2025-03-21 16:20 ` Daniel Brooks
2025-03-24 1:03 ` Alexandre Courbot
2025-03-20 13:39 ` [PATCH RFC v3 7/7] gpu: nova-core: add falcon register definitions and probe code Alexandre Courbot
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=Z9xb1r1x5tOzAIZT@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=bskeggs@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
/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;
as well as URLs for NNTP newsgroup(s).