From e2580413a83680f679904ad2f2c1aa6969876469 Mon Sep 17 00:00:00 2001 From: Danilo Krummrich Date: Mon, 1 Sep 2025 17:01:53 +0200 Subject: gpu: nova-core: take advantage of pci::Device::unbind() Now that we have pci::Device::unbind() we can unregister the sysmem flush page with a direct access the I/O resource, i.e. without RCU read side critical section. Signed-off-by: Danilo Krummrich Reviewed-by: Alexandre Courbot Link: https://lore.kernel.org/r/20250901150207.63094-1-dakr@kernel.org Signed-off-by: Alexandre Courbot --- drivers/gpu/nova-core/driver.rs | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'drivers/gpu/nova-core/driver.rs') diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs index 274989ea1fb4..02b3edd7bbdc 100644 --- a/drivers/gpu/nova-core/driver.rs +++ b/drivers/gpu/nova-core/driver.rs @@ -54,4 +54,8 @@ impl pci::Driver for NovaCore { Ok(this) } + + fn unbind(pdev: &pci::Device, this: Pin<&Self>) { + this.gpu.unbind(pdev.as_ref()); + } } -- cgit v1.2.3 From e7c96980ea4d93e79b43b07c5489d700207b0055 Mon Sep 17 00:00:00 2001 From: Alexandre Courbot Date: Sat, 13 Sep 2025 23:12:15 +0900 Subject: gpu: nova-core: move GSP boot code to its own module Right now the GSP boot code is very incomplete and limited to running FRTS, so having it in `Gpu::new` is not a big constraint. However, this will change as we add more steps of the GSP boot process, and not all GPU families follow the same procedure, so having these steps in a dedicated method is the logical construct. There is also the fact the GSP will require its own runtime data, and while it won't immediately need to be pinned, we want to be ready for the time where it will - most likely when it starts using mutexes. Thus, add an empty `Gsp` type that is pinned inside `Gpu` and initialized using a pin initializer. This sets the constraint we need to observe from the start, and could spare us some costly refactoring down the road. Then, move the code related to GSP boot to the `gsp::boot` module, as part of the `Gsp` implementation. Doing so allows us to make `Gpu::new` return a fallible `impl PinInit` instead of a `Result.` This is more idiomatic when working with pinned objects, and sets up the pinned initialization pattern we want to preserve as the code grows more complex. Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-2-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot --- drivers/gpu/nova-core/driver.rs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'drivers/gpu/nova-core/driver.rs') diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs index 02b3edd7bbdc..1380b47617f7 100644 --- a/drivers/gpu/nova-core/driver.rs +++ b/drivers/gpu/nova-core/driver.rs @@ -34,14 +34,19 @@ impl pci::Driver for NovaCore { pdev.enable_device_mem()?; pdev.set_master(); - let bar = Arc::pin_init( + let devres_bar = Arc::pin_init( pdev.iomap_region_sized::(0, c_str!("nova-core/bar0")), GFP_KERNEL, )?; + // Used to provided a `&Bar0` to `Gpu::new` without tying it to the lifetime of + // `devres_bar`. + let bar_clone = Arc::clone(&devres_bar); + let bar = bar_clone.access(pdev.as_ref())?; + let this = KBox::pin_init( try_pin_init!(Self { - gpu <- Gpu::new(pdev, bar)?, + gpu <- Gpu::new(pdev, devres_bar, bar), _reg: auxiliary::Registration::new( pdev.as_ref(), c_str!("nova-drm"), -- cgit v1.2.3