From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 51A00C5516D for ; Fri, 31 Jul 2026 12:59:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9B7C410E1F7; Fri, 31 Jul 2026 12:59:48 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="VUbIQ/Rk"; dkim-atps=neutral Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8DB9F10E1F7 for ; Fri, 31 Jul 2026 12:59:47 +0000 (UTC) Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-47f8580ed9eso1136034f8f.0 for ; Fri, 31 Jul 2026 05:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785502786; x=1786107586; darn=lists.freedesktop.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=P9eJPXgMx/k8Zzskbe/ENfQg92M9fVEFYQJ0hF5Ni8Q=; b=VUbIQ/RkT2QQts3G1Xj6rYwPCubhdZ+xfHO0DLfVFmCb8a5xaz0f+8A8WHNCrBiHRE MN0riLcp6RVvJaSzNBpIR/7KU2aj0zNWnj29H79kTpfI2oC01nKalI08/H3DtYInrmCb fUAeBcBK0XejtftU1cxcDzZ/Fiue62ycQPws8q/gproj8LmaeVqVQBfOiAk7V3kXIDgk xWIjyCs8RLC+pEp0pg6WlNTmUGw6vP7xWwU5XnzVbtqju8FAW33toEyNzKH1S9DOiPpI f5YOQ2+hqaGPJCofe+S2m1HufRnXL5BkY6jh+lEmXJHn37RIN+zQL0dfD/6MUilWOkde aUBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785502786; x=1786107586; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=P9eJPXgMx/k8Zzskbe/ENfQg92M9fVEFYQJ0hF5Ni8Q=; b=sBhoYNLSs/1ryTKisz8lzRXtWsehfcTPSKWfHcrUpcQ+gZElnC7R7n9Nww43yasWOD aDZ8qAmK9zvKqUSRCOwMZ4P7hMYkYonApKEpby3Y/u51Fqz5r4TSSDTQ2OVSHmoukvLc nVBPB1kMlm36fUGK0IpeVsknzkwyM+e7T9GXbMbne0/YzKQXFR3wpLS0cxgg+gV2TjSk oLv2szbiOUIJA4GM+E4R7rTQes3f+pBap2DJ6xNjzngyGkGX2y0bGnlTEILjB5Y8IFs+ //LnTigfBTRk4n2VupBrigKWc1vHUIdTqJCyLoC/ORRTqI/1Nmc5jwLaobrfS2JW3MYi AmXA== X-Forwarded-Encrypted: i=1; AHgh+Roo2QZXDf8huK2UlPV9A9I81JGpQqcVUQI7w/yYirMtORZTjEeqD7k4EJwDVE4by5uLV5DGhm/ECSU=@lists.freedesktop.org X-Gm-Message-State: AOJu0Yx7BLkgEU/kvNVnKoCF0ryxnY9PNigZ9Hu+bAfhF09JVgXrDWWs hGViM74lIRc3gX0xjYVWlbuAfExz1IanExZU8KxBRwv7sEXmPUZdgs8AtQZTbeRWxtj0Vu3bBA4 aBaqVxWxjn8YgcTLzmg== X-Received: from wmbdr14.prod.google.com ([2002:a05:600c:608e:b0:493:af1f:8829]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:40cd:b0:47f:6d9a:d7a6 with SMTP id ffacd0b85a97d-47fd2aed4ebmr4411247f8f.25.1785502783123; Fri, 31 Jul 2026 05:59:43 -0700 (PDT) Date: Fri, 31 Jul 2026 12:59:42 +0000 In-Reply-To: <20260731-tyr-debugfs-v2-v2-8-aea19eccb996@linux.dev> Mime-Version: 1.0 References: <20260731-tyr-debugfs-v2-v2-0-aea19eccb996@linux.dev> <20260731-tyr-debugfs-v2-v2-8-aea19eccb996@linux.dev> Message-ID: Subject: Re: [PATCH v2 8/9] drm/tyr: add gpuvas debugfs file From: Alice Ryhl To: Alvin Sun Cc: Miguel Ojeda , Boqun Feng , Gary Guo , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Daniel Almeida , Tamir Duberstein , Alexandre Courbot , "Onur =?utf-8?B?w5Z6a2Fu?=" , Greg Kroah-Hartman , "Rafael J. Wysocki" , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Alexander Viro , Christian Brauner , Jan Kara , Matthew Brost , "Thomas =?utf-8?Q?Hellstr=C3=B6m?=" , "=?utf-8?B?TWHDrXJh?= Canal" , Melissa Wen , Wambui Karuga , Eric Anholt , Ben Gamari , rust-for-linux@vger.kernel.org, driver-core@lists.linux.dev, dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="utf-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Jul 31, 2026 at 01:05:46AM +0800, Alvin Sun wrote: > Add a gpuvas debugfs file listing all GPU VAs for the Tyr DRM driver. > Collects VMs into a shared list during firmware init and renders them > via dump_gpuva_info on read. > > Signed-off-by: Alvin Sun > --- > drivers/gpu/drm/tyr/debugfs.rs | 65 ++++++++++++++++++++++++++++++++++++++++++ > drivers/gpu/drm/tyr/driver.rs | 16 +++++++++++ > drivers/gpu/drm/tyr/fw.rs | 8 ++++++ > drivers/gpu/drm/tyr/tyr.rs | 1 + > drivers/gpu/drm/tyr/vm.rs | 5 ++++ > 5 files changed, 95 insertions(+) > > diff --git a/drivers/gpu/drm/tyr/debugfs.rs b/drivers/gpu/drm/tyr/debugfs.rs > new file mode 100644 > index 0000000000000..d381b1901bd08 > --- /dev/null > +++ b/drivers/gpu/drm/tyr/debugfs.rs > @@ -0,0 +1,65 @@ > +// SPDX-License-Identifier: GPL-2.0 or MIT > + > +//! Debugfs support for the Tyr DRM driver. > + > +use kernel::{ > + alloc::KVec, > + drm, > + new_mutex, > + prelude::*, > + seq_file, > + sync::{ > + Arc, > + Mutex, // > + }, // > +}; > + > +use crate::{ > + driver::TyrDrmDriver, > + vm::Vm, // > +}; > + > +/// Registry of VMs for debugfs access. > +#[pin_data] > +pub(crate) struct VmRegistry<'drm> { > + #[pin] > + vms: Mutex>>>, > +} > + > +impl<'drm> VmRegistry<'drm> { > + pub(crate) fn new() -> impl PinInit { > + pin_init!(Self { vms <- new_mutex!(KVec::new()) }) > + } > + > + pub(crate) fn register(&self, vm: Arc>) -> Result { > + Ok(self.vms.lock().push(vm, GFP_KERNEL)?) > + } > + > + fn for_each(&self, mut f: impl FnMut(&Vm<'drm>) -> Result) -> Result { > + for vm in self.vms.lock().iter() { > + f(vm)?; > + } > + Ok(()) > + } > +} This code maintains a separate list of all of the vms for access from debugfs, but I would have expected that this is not necessary. If we already store the vms inside the driver's private data, then can't we just access them from the normal storage location? By having multiple copies of the same information, you risk that they get out of sync. In this case, you never remove vms from the list even if the vm stops being used, which seems wrong. Alice