From: Danilo Krummrich <dakr@kernel.org>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@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>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"John Hubbard" <jhubbard@nvidia.com>,
"Ben Skeggs" <bskeggs@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 10/16] gpu: nova-core: add basic timer device
Date: Tue, 22 Apr 2025 14:07:17 +0200 [thread overview]
Message-ID: <aAeGdRvlm5EVJOw3@cassiopeiae> (raw)
In-Reply-To: <20250420-nova-frts-v1-10-ecd1cca23963@nvidia.com>
On Sun, Apr 20, 2025 at 09:19:42PM +0900, Alexandre Courbot wrote:
> Add a timer that works with GPU time and provides the ability to wait on
> a condition with a specific timeout.
What can this timer do for us, what and HrTimer can't do for us?
>
> The `Duration` Rust type is used to keep track is differences between
> timestamps ; this will be replaced by the equivalent kernel type once it
> lands.
Fine for me -- can you please add a corresponding TODO and add it to your list
of follow-up patches?
> diff --git a/drivers/gpu/nova-core/timer.rs b/drivers/gpu/nova-core/timer.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..8987352f4192bc9b4b2fc0fb5f2e8e62ff27be68
> --- /dev/null
> +++ b/drivers/gpu/nova-core/timer.rs
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Nova Core Timer subdevice
> +
> +// To be removed when all code is used.
> +#![allow(dead_code)]
Please prefer 'expect'.
> +
> +use core::fmt::Display;
> +use core::ops::{Add, Sub};
> +use core::time::Duration;
> +
> +use kernel::devres::Devres;
> +use kernel::num::U64Ext;
> +use kernel::prelude::*;
> +
> +use crate::driver::Bar0;
> +use crate::regs;
> +
> +/// A timestamp with nanosecond granularity obtained from the GPU timer.
> +///
> +/// A timestamp can also be substracted to another in order to obtain a [`Duration`].
> +#[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
> +pub(crate) struct Timestamp(u64);
> +
> +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()));
> + }
So, if hi did not change since we've read both hi and lo, we can trust both
values. Probably worth to add a brief comment.
Additionally, we may want to add that if we get unlucky, it takes around 4s to
get unlucky again, even though that's rather obvious.
> + }
> + }
> +
> + #[allow(dead_code)]
> + pub(crate) fn time(bar: &Bar0, time: u64) {
> + regs::PtimerTime1::default()
> + .set_hi(time.upper_32_bits())
> + .write(bar);
> + regs::PtimerTime0::default()
> + .set_lo(time.lower_32_bits())
> + .write(bar);
> + }
> +
> + /// Wait until `cond` is true or `timeout` elapsed, based on GPU time.
> + ///
> + /// When `cond` evaluates to `Some`, its return value is returned.
> + ///
> + /// `Err(ETIMEDOUT)` is returned if `timeout` has been reached without `cond` evaluating to
> + /// `Some`, or if the timer device is stuck for some reason.
> + pub(crate) fn wait_on<R, F: Fn() -> Option<R>>(
> + &self,
> + bar: &Devres<Bar0>,
> + timeout: Duration,
> + cond: F,
> + ) -> Result<R> {
> + // Number of consecutive time reads after which we consider the timer frozen if it hasn't
> + // moved forward.
> + const MAX_STALLED_READS: usize = 16;
Huh! Can't we trust the timer hardware? Probably one reason more to use HrTimer?
> +
> + let (mut cur_time, mut prev_time, deadline) = {
> + let cur_time = with_bar!(bar, |b| self.read(b))?;
> + let deadline = cur_time + timeout;
> +
> + (cur_time, cur_time, deadline)
> + };
> + let mut num_reads = 0;
> +
> + loop {
> + if let Some(ret) = cond() {
> + return Ok(ret);
> + }
> +
> + (|| {
> + cur_time = with_bar!(bar, |b| self.read(b))?;
> +
> + /* Check if the timer is frozen for some reason. */
> + if cur_time == prev_time {
> + if num_reads >= MAX_STALLED_READS {
> + return Err(ETIMEDOUT);
> + }
> + num_reads += 1;
> + } else {
> + if cur_time >= deadline {
> + return Err(ETIMEDOUT);
> + }
> +
> + num_reads = 0;
> + prev_time = cur_time;
> + }
> +
> + Ok(())
> + })()?;
> + }
> + }
> +}
>
> --
> 2.49.0
>
next prev parent reply other threads:[~2025-04-22 12:07 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-20 12:19 [PATCH 00/16] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Alexandre Courbot
2025-04-20 12:19 ` [PATCH 01/16] rust: add useful ops for u64 Alexandre Courbot
2025-04-20 12:19 ` [PATCH 02/16] rust: make ETIMEDOUT error available Alexandre Courbot
2025-04-20 12:19 ` [PATCH 03/16] gpu: nova-core: derive useful traits for Chipset Alexandre Courbot
2025-04-22 16:23 ` Joel Fernandes
2025-04-24 7:50 ` Alexandre Courbot
2025-04-20 12:19 ` [PATCH 04/16] gpu: nova-core: add missing GA100 definition Alexandre Courbot
2025-04-20 12:19 ` [PATCH 05/16] gpu: nova-core: take bound device in Gpu::new Alexandre Courbot
2025-04-20 12:19 ` [PATCH 06/16] gpu: nova-core: define registers layout using helper macro Alexandre Courbot
2025-04-22 10:29 ` Danilo Krummrich
2025-04-28 14:27 ` Alexandre Courbot
2025-04-20 12:19 ` [PATCH 07/16] gpu: nova-core: move Firmware to firmware module Alexandre Courbot
2025-04-20 12:19 ` [PATCH 08/16] gpu: nova-core: wait for GFW_BOOT completion Alexandre Courbot
2025-04-21 21:45 ` Joel Fernandes
2025-04-22 11:28 ` Danilo Krummrich
2025-04-22 13:06 ` Alexandre Courbot
2025-04-22 13:46 ` Joel Fernandes
2025-04-22 11:36 ` Danilo Krummrich
2025-04-29 12:48 ` Alexandre Courbot
2025-04-30 22:45 ` Joel Fernandes
2025-04-20 12:19 ` [PATCH 09/16] gpu: nova-core: register sysmem flush page Alexandre Courbot
2025-04-22 11:45 ` Danilo Krummrich
2025-04-23 13:03 ` Alexandre Courbot
2025-04-22 18:50 ` Joel Fernandes
2025-04-20 12:19 ` [PATCH 10/16] gpu: nova-core: add basic timer device Alexandre Courbot
2025-04-22 12:07 ` Danilo Krummrich [this message]
2025-04-29 13:13 ` Alexandre Courbot
2025-04-20 12:19 ` [PATCH 11/16] gpu: nova-core: add falcon register definitions and base code Alexandre Courbot
2025-04-22 14:44 ` Danilo Krummrich
2025-04-30 6:58 ` Joel Fernandes
2025-04-30 10:32 ` Danilo Krummrich
2025-04-30 13:25 ` Alexandre Courbot
2025-04-30 14:38 ` Joel Fernandes
2025-04-30 18:16 ` Danilo Krummrich
2025-04-30 23:08 ` Joel Fernandes
2025-05-01 0:09 ` Alexandre Courbot
2025-05-01 0:22 ` Joel Fernandes
2025-05-01 14:07 ` Alexandre Courbot
2025-04-20 12:19 ` [PATCH 12/16] gpu: nova-core: firmware: add ucode descriptor used by FWSEC-FRTS Alexandre Courbot
2025-04-22 14:46 ` Danilo Krummrich
2025-04-20 12:19 ` [PATCH 13/16] gpu: nova-core: Add support for VBIOS ucode extraction for boot Alexandre Courbot
2025-04-23 14:06 ` Danilo Krummrich
2025-04-23 14:52 ` Joel Fernandes
2025-04-23 15:02 ` Danilo Krummrich
2025-04-24 19:19 ` Joel Fernandes
2025-04-24 20:01 ` Danilo Krummrich
2025-04-24 19:54 ` Joel Fernandes
2025-04-24 20:17 ` Danilo Krummrich
2025-04-25 2:32 ` [13/16] " Joel Fernandes
2025-04-25 17:10 ` Joel Fernandes
2025-04-24 18:54 ` [PATCH 13/16] " Joel Fernandes
2025-04-24 20:08 ` Danilo Krummrich
2025-04-25 2:26 ` [13/16] " Joel Fernandes
2025-04-24 20:22 ` [PATCH 13/16] " Joel Fernandes
2025-04-26 23:17 ` [13/16] " Joel Fernandes
2025-04-20 12:19 ` [PATCH 14/16] gpu: nova-core: compute layout of the FRTS region Alexandre Courbot
2025-04-20 12:19 ` [PATCH 15/16] gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTS Alexandre Courbot
2025-04-20 12:19 ` [PATCH 16/16] gpu: nova-core: load and " Alexandre Courbot
2025-04-22 8:40 ` [PATCH 00/16] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Danilo Krummrich
2025-04-22 14:12 ` 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=aAeGdRvlm5EVJOw3@cassiopeiae \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bskeggs@nvidia.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@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 \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.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.