Hi everyone,
This RFC is based on top of Danilo's initial driver stub series
v4 [1] and adds very basic support for the Timer and Falcon devices, in
order to see and "feel" the proposed register access abstractions and
discuss them before moving forward with GSP initialization.
It is kept simple
It is common to build a u64 from its high and low parts obtained from
two 32-bit registers. Conversely, it is also common to split a u64 into
two u32s to write them into registers. Add an extension trait for u64
that implement these methods in a new `num` module.
It is expected that this trait wil
Register data manipulation is one of the error-prone areas of a kernel
driver. It is particularly easy to mix addresses of registers, masks and
shifts of fields, and to proceed with invalid values.
This patch introduces the nv_reg!() macro, which creates a safe type
definition for a given register
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 w
This is still very preliminary work, and is mostly designed to show how
register fields can be turned into safe types that force us to handle
invalid values.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/nova-core/driver.rs| 2 +-
drivers/gpu/nova-core/falcon.rs| 124 +++
Hi Danilo,
On Thu Feb 27, 2025 at 2:55 AM JST, Danilo Krummrich wrote:
> Add the initial nova-core driver stub.
>
> nova-core is intended to serve as a common base for nova-drm (the
> corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
> hard- and firmware abstraction layer fo
On Tue, Mar 04, 2025 at 11:19:49PM +0900, Alexandre Courbot wrote:
> On Thu Feb 27, 2025 at 2:55 AM JST, Danilo Krummrich wrote:
>
> > +// TODO replace with something like derive(FromPrimitive)
> > +impl TryFrom for Chipset {
> > +type Error = kernel::error::Error;
> > +
> > +fn try_from(v
What support does Nouveau have for the RTX A2000? I don't see it specifically
listed on the "CodeNames.html" page. I'm assuming it would fall either in the
Turing or Ampere families, but its not clear.
Jeff VanDorp
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole u
On Fri, Feb 28, 2025 at 02:40:13PM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
>
> > - Nuke the driver binding manually through sysfs with the unbind files.
> > - Nuke all userspace that might beholding files and other resources open.
> > - At thi
On Tue, Mar 04, 2025 at 06:34:48PM +0100, Danilo Krummrich wrote:
> The `LocalModule` type is the type of the module created by `module!`,
> `module_pci_driver!`, `module_platform_driver!`, etc.
>
> Since the exact type of the module is sometimes generated on the fly by
> the listed macros, provid
On Tue, Mar 04, 2025 at 06:34:49PM +0100, Danilo Krummrich wrote:
> The `firmware` field of the `module!` only accepts literal strings,
> which is due to the fact that it is implemented as a proc macro.
>
> Some drivers require a lot of firmware files (such as nova-core) and
> hence benefit from m
Signed-off-by: Alexandre Courbot
---
rust/kernel/error.rs | 1 +
1 file changed, 1 insertion(+)
diff --git a/rust/kernel/error.rs b/rust/kernel/error.rs
index
1e510181432cceae46219f7ed3597a88b85ebe0a..475d14a4830774aa7717d3b5e70c7ff9de203dc2
100644
--- a/rust/kernel/error.rs
+++ b/rust/kernel/
This is the initial series for the nova-core stub driver.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova project, including nova-cor
On Tue, Mar 04, 2025 at 05:10:45PM +0100, Simona Vetter wrote:
> On Fri, Feb 28, 2025 at 02:40:13PM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
> >
> > > - Nuke the driver binding manually through sysfs with the unbind files.
> > > - Nuke all us
Add the initial documentation of the Nova project.
The initial project documentation consists out of a brief introduction
of the project, as well as project guidelines both general and nova-core
specific and a task list for nova-core specifically.
The task list is divided into tasks for general R
Add the initial nova-core driver stub.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova project, including nova-core and nova-drm, in
The `firmware` field of the `module!` only accepts literal strings,
which is due to the fact that it is implemented as a proc macro.
Some drivers require a lot of firmware files (such as nova-core) and
hence benefit from more flexibility composing firmware path strings.
The `firmware::ModInfoBuil
The `LocalModule` type is the type of the module created by `module!`,
`module_pci_driver!`, `module_platform_driver!`, etc.
Since the exact type of the module is sometimes generated on the fly by
the listed macros, provide an alias.
This is first used by the `module_firmware!` macro introduced i
Analogous to the `module!` macro `module_firmware!` adds additional
firmware path strings to the .modinfo section.
In contrast to `module!`, where path strings need to be string literals,
path strings can be composed with the `firmware::ModInfoBuilder`.
Some drivers require a lot of firmware file
On Tue, Mar 04, 2025 at 06:34:50PM +0100, Danilo Krummrich wrote:
> Analogous to the `module!` macro `module_firmware!` adds additional
> firmware path strings to the .modinfo section.
>
> In contrast to `module!`, where path strings need to be string literals,
> path strings can be composed with
On Tue, Mar 04, 2025 at 12:42:01PM -0400, Jason Gunthorpe wrote:
> On Tue, Mar 04, 2025 at 05:10:45PM +0100, Simona Vetter wrote:
> > On Fri, Feb 28, 2025 at 02:40:13PM -0400, Jason Gunthorpe wrote:
> > > On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
> > >
> > > > - Nuke the drive
On Mon, Mar 03, 2025 at 05:50:02PM -0400, Jason Gunthorpe wrote:
> On Mon, Mar 03, 2025 at 08:36:34PM +0100, Danilo Krummrich wrote:
> > > > And yes, for *device resources* it is unsound if we do not ensure that
> > > > the
> > > > device resource is actually dropped at device unbind.
> > >
> > >
if (drm->dev->switch_power_state == DRM_SWITCH_POWER_OFF ||
+ drm->dev->switch_power_state == DRM_SWITCH_POWER_DYNAMIC_OFF)
+ return 0;
+
return nouveau_do_resume(drm, false);
}
---
base-commit: 7eb172143d5508b4da468ed59ee857c6e5e01da6
change-id:
23 matches
Mail list logo
