Hi Alexandre,
On Thu, Feb 06, 2025 at 11:05:37PM +0900, Alexandre Courbot wrote:
> > +
> > +/// Enum representation of the GPU chipset.
> > +#[derive(fmt::Debug)]
>
> I suspect you will eventually want to also derive Copy and Clone, as
> well as PartialEq and Eq (so the assigned values can be use
On Wed, Feb 05, 2025 at 04:56:32PM +0200, Zhi Wang wrote:
> On Wed, 5 Feb 2025 15:13:12 +0100
> Miguel Ojeda wrote:
>
> > On Wed, Feb 5, 2025 at 2:57 PM Zhi Wang wrote:
> > >
> > > It would be also helpful to make the process explicit. E.g. sharing your
> > > command lines used to checking the p
On Wed, Feb 05, 2025 at 03:56:46PM +0200, Zhi Wang wrote:
> On Tue, 4 Feb 2025 20:03:12 +0100
> Danilo Krummrich wrote:
>
> > +
> > +Generic register abstraction
> > +
> > +
> > +Work out how register constants and structu
Rust infrastructure
required by the project, tasks regarding GSP enablement and firmware
abstraction, general GPU driver tasks as well as tasks related to
external API design and test infrastructure.
Signed-off-by: Danilo Krummrich
---
- Add task "Generic register abstraction".
https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopeiae/T/#u [1]
Link: https://lwn.net/Articles/990736/ [2]
Link: https://youtu.be/3Igmx28B3BQ?si=sBdSEer4tAPKGpOs [3]
Signed-off-by: Danilo Krummrich
---
Changes in v2:
- Fix module name in Kconfig description. (John)
- Expand Kconfig description a bit.
On Tue, Feb 04, 2025 at 06:42:46PM +, Timur Tabi wrote:
> On Fri, 2025-01-31 at 23:04 +0100, Danilo Krummrich wrote:
> > +/// Structure encapsulating the firmware blobs required for the GPU to
> > operate.
> > +#[allow(dead_code)]
> > +pub(crate) struct Firm
On Tue, Feb 04, 2025 at 06:40:41PM +, Timur Tabi wrote:
> On Fri, 2025-01-31 at 23:04 +0100, Danilo Krummrich wrote:
> > +Rust abstraction for debugfs APIs.
> > +
> > +| Reference: Export GSP log buffers
> > +| Complexity: Beginner
>
> Seriously?
Well, that seems indeed a bit optimistic. :-)
On Mon, Feb 03, 2025 at 03:24:10PM -0500, Joel Fernandes wrote:
> Hi Danilo,
>
> On Fri, Jan 31, 2025 at 11:04:24PM +0100, Danilo Krummrich wrote:
> > +#[pin_data]
> > +pub(crate) struct NovaCore {
> > +#[pin]
> > +pub(crate) gpu: Gpu,
> > +}
>
&
Hi Lina,
On Sun, Feb 02, 2025 at 10:34:49PM +0900, Asahi Lina wrote:
> Some hardware requires dummy page mappings to efficiently implement
> Vulkan sparse features. These mappings consist of the same physical
> memory page, repeated for a large range of address space (e.g. 16GiB).
>
> Add support
On Fri, Jan 31, 2025 at 08:01:00PM -0800, John Hubbard wrote:
> On 1/31/25 2:04 PM, 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 m
On Sat, Feb 01, 2025 at 09:33:28AM +0100, Greg KH wrote:
> On Fri, Jan 31, 2025 at 11:04:24PM +0100, Danilo Krummrich wrote:
> > +impl Gpu {
> > +pub(crate) fn new(pdev: &pci::Device, bar: Devres) ->
> > Result> {
> > +let spec = GpuSpec::new(&
On Sat, Feb 01, 2025 at 09:14:48AM +0100, Karol Herbst wrote:
> On Fri, Jan 31, 2025 at 11:04 PM Danilo Krummrich wrote:
> > +impl pci::Driver for NovaCore {
> > +type IdInfo = ();
> > +const ID_TABLE: pci::IdTable = &PCI_TABLE;
> > +
> > +fn probe
https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopeiae/T/#u [1]
Link: https://lwn.net/Articles/990736/ [2]
Link: https://youtu.be/3Igmx28B3BQ?si=sBdSEer4tAPKGpOs [3]
Signed-off-by: Danilo Krummrich
---
MAINTAINERS| 10 ++
drivers/gpu/Makefile | 1 +
drivers/gpu
Rust infrastructure
required by the project, tasks regarding GSP enablement and firmware
abstraction, general GPU driver tasks as well as tasks related to
external API design and test infrastructure.
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/drivers.rst | 1
On Wed, Jan 29, 2025 at 04:18:30PM +0100, Philipp Stanner wrote:
> On Tue, 2025-01-28 at 15:56 +0100, Danilo Krummrich wrote:
> > On Tue, Jan 28, 2025 at 03:29:27PM +0100, Philipp Stanner wrote:
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c
> > >
On Tue, Jan 28, 2025 at 03:29:27PM +0100, Philipp Stanner wrote:
> drm_sched_init() has a great many parameters and upcoming new
> functionality for the scheduler might add even more. Generally, the
> great number of parameters reduces readability and has already caused
> one missnaming in:
>
> co
Hi Zhi,
On Fri, Jan 24, 2025 at 10:29:43AM -0800, Zhi Wang wrote:
> Hi folks:
>
> Here is another re-spin of handling the large GSP message return.
>
> Besides the support of the large GSP message, kernel doc and many cleanups
> are introduced according to the comments in the previous spin [1].
On Thu, Jan 23, 2025 at 10:35:43AM +0100, Philipp Stanner wrote:
> On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
> > On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> > > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > > >
On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > On Wed, 22 Jan 2025 15:08:20 +0100
> > Philipp Stanner wrote:
> >
> > > int drm_sched_init(struct drm_gpu_scheduler *sched,
> > > - const struct drm_sched_backend_o
On Wed, Jan 22, 2025 at 03:08:20PM +0100, Philipp Stanner wrote:
> drm_sched_init() has a great many parameters and upcoming new
> functionality for the scheduler might add even more. Generally, the
> great number of parameters reduces readability and has already caused
> one missnaming in:
>
> co
On Fri, Nov 22, 2024 at 04:57:12AM -0800, Zhi Wang wrote:
> Introduce a kernel doc to explain the scrubber on Ada.
>
> Cc: Milos Tijanic
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ad102.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/dr
On Fri, Nov 22, 2024 at 04:57:11AM -0800, Zhi Wang wrote:
> Set the max supported vGPU count according to the number of VFs when
> SRIOV is supported on Ada.
>
> Suggested-by: Jason Gunthorpe
> Cc: Surath Mitra
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
On Fri, Nov 22, 2024 at 04:57:10AM -0800, Zhi Wang wrote:
> To support the maximum vGPUs on the device that support SRIOV, a larger
> WPR2 heap size is required. On Ada with SRIOV supported, the size should
> be set to at least 549MB. By setting the WPR2 heap size up to 549MB, the
> scrubber ucode
On Fri, Nov 22, 2024 at 04:57:09AM -0800, Zhi Wang wrote:
> To support the maximum vGPUs on the device that support SRIOV, a larger
> WPR2 heap size is required.
>
> Support WPR2 heap size override when initializing the WPR2 heap memory
> layout. If zero, use the default WRP2 heap size.
>
> No fu
On Fri, Nov 22, 2024 at 04:57:05AM -0800, Zhi Wang wrote:
> To support the per-SKU GSP WPR2 heap initialization, first, factor out the
> common routine for all the SKUs.
>
> Factor out nvkm_gsp_init_fw_heap(). Adjust some indent to make
> checkpatch.pl happy.
>
> No functional change is intended.
On Fri, Nov 22, 2024 at 04:57:07AM -0800, Zhi Wang wrote:
> When WPR2 heap size > 256MB, the FB memory needs to be scrubbed before
> use.
>
> If not, the GSP firmware hangs when booting.
>
> Introduce ad102_gsp_init_fw_heap(). Load scrubber ucode image when
> WRP2 heap size > 256MB after the FB m
On Fri, Nov 22, 2024 at 04:57:08AM -0800, Zhi Wang wrote:
> When WPR2 heap size > 256MB, the FB memory needs to be scrubbed
> before use.
>
> If not, the GSP firmware hangs when booting.
>
> If the scrubber firmware presents, execute it to scrub the FB memory
> before executing any other ucode im
On 1/9/25 11:58 PM, Timur Tabi wrote:
On Fri, 2024-11-22 at 04:57 -0800, Zhi Wang wrote:
+static int
+ad102_execute_scrubber(struct nvkm_gsp *gsp)
+{
+ struct nvkm_falcon_fw fw = {0};
+ struct nvkm_subdev *subdev = &gsp->subdev;
+ struct nvkm_device *device = subdev->device;
+
On 09.01.2025 17:58, Danilo Krummrich wrote:
> On Thu, Jan 09, 2025 at 10:55:53AM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This is the 3rd iteration of this after talking to Ben and
>> Danilo, I think this makes sense now.
>>
>> The fence
On 1/9/25 12:43 AM, Timur Tabi wrote:
Fix some malformed kernel-doc comments that were added in a recent commit.
Also, kernel-doc does not support global variables, so change those
kernel-doc comments into regular comments.
Fixes: 214c9539cf2f ("drm/nouveau: expose GSP-RM logging buffers via de
On Thu, Jan 09, 2025 at 10:55:53AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This is the 3rd iteration of this after talking to Ben and
> Danilo, I think this makes sense now.
>
> The fence sync logic doesn't handle a fence sync across devices
> as it tries to write to a channel offset f
On Wed, Jan 08, 2025 at 11:04:21AM +1000, Dave Airlie wrote:
> On Wed, 8 Jan 2025 at 02:02, Danilo Krummrich wrote:
> >
> > On Tue, Jan 07, 2025 at 03:58:46PM +1000, Dave Airlie wrote:
> > > From: Dave Airlie
> > >
> > > If we have two nouveau con
On Tue, Jan 07, 2025 at 03:58:46PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> If we have two nouveau controlled devices and one passes a dma-fence
> to the other, when we hit the sync path it can cause the second device
> to try and put a sync wait in it's pushbuf for the seqno of the cont
On Thu, Jan 02, 2025 at 12:49:36PM +0100, Takashi Iwai wrote:
> Macbook 5,1 with MCP79 lost its backlight control since the recent
> change for supporting GFP-RM; it rewrote the whole nv50 backlight
> control code and each display engine is supposed to have an entry for
> IOR bl callback, but it di
On Mon, Jan 06, 2025 at 01:00:12AM +0200, Dmitry Baryshkov wrote:
> The nouveau driver is the only user of the drm_encoder_slave interface.
> Demote it from KMS helpers module to the nouveau driver itself, moving
> corresponding I2C encoders to be handled by nouveau driver too.
>
> Ideally those t
un Li
Why is there also Duanjun's SOB? If there is a co-author, this should be
indicated with a "Co-developed-by" tag. Adding the SOB only is not sufficient,
please see [1].
> Signed-off-by: Danilo Krummrich
Please don't add my SOB to your commits -- I'll ad
On Sun, Dec 15, 2024 at 12:19:24PM +0200, Dmitry Baryshkov wrote:
> Nouveau driver is the only user of the drm_encoder_slave API. Rework
> necessary bits of drm_encoder_slave into the nouveau_i2c_encoder API and
> drop drm_encoder_slave.c from the DRM KMS helper.
Please fix the CHECK warnings prod
On Sun, Dec 15, 2024 at 12:19:23PM +0200, Dmitry Baryshkov wrote:
> Chrontel CH7006 and Silicon Image sil164 drivers use drm_encoder_slave
> interface which is being used only by the nouveau driver. It doesn't
> make sense to keep this interface inside the DRM subsystem. In
> preparation to moving
On Mon, Dec 16, 2024 at 02:58:59PM +0200, Dmitry Baryshkov wrote:
> On Mon, Dec 16, 2024 at 01:41:56PM +0100, Danilo Krummrich wrote:
> > On Mon, Dec 16, 2024 at 02:16:51PM +0200, Laurent Pinchart wrote:
> > > On Mon, Dec 16, 2024 at 02:11:41PM +0200, Dmitry Baryshkov wrote:
>
On Mon, Dec 16, 2024 at 02:16:51PM +0200, Laurent Pinchart wrote:
> On Mon, Dec 16, 2024 at 02:11:41PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Dec 16, 2024 at 12:45:15PM +0100, Danilo Krummrich wrote:
> > > On Sun, Dec 15, 2024 at 12:19:22PM +0200, Dmitry Baryshkov wrote:
&
On Sun, Dec 15, 2024 at 12:19:22PM +0200, Dmitry Baryshkov wrote:
> The nouveau driver is the only user of the drm_encoder_slave interface.
> Demote it from KMS helpers module to the nouveau driver itself, moving
> corresponding I2C encoders to be handled by nouveau driver too.
I understand nouvea
Thanks for the patch, some notes below.
On Mon, Dec 16, 2024 at 09:52:46AM +0800, Zhanxin Qi wrote:
> The nvbios_iccsense_parse function allocates memory for sensor data
> but fails to free it when the function exits, leading to a memory
> leak. Add proper cleanup to free the allocated memory.
>
On Thu, Oct 31, 2024 at 01:52:47AM -0700, Zhi Wang wrote:
> To receive a GSP message queue element from the GSP status queue, the
> driver needs to make sure there are available elements in the queue.
>
> The previous r535_gsp_msgq_wait() consists of three functions, which is
> a little too compli
On Thu, Oct 31, 2024 at 01:52:37AM -0700, Zhi Wang wrote:
> The name "repc" has different meanings in different contexts.
>
> To improve the readability, it's better to refine it to a name that
> reflects what it actually represents.
>
> Rename "repc" to "gsp_rpc_len" in the GSP message recv path
Hi Zhi,
On Thu, Oct 31, 2024 at 01:52:36AM -0700, Zhi Wang wrote:
> In order to explain the name clean-ups in GSP RPC routines, a kernel
> doc to explain the memory layout and terms is required.
>
> Add a kernel doc to introduce the GSP RPC.
Thanks for adding this -- very much appreciated!
>
>
On 10/30/24 9:29 PM, Timur Tabi wrote:
Store the struct device pointer used to allocate the DMA buffer in
the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release
the buffer without needing the nvkm_gsp. This is needed so that
we can retain DMA buffers even after the nvkm_gsp object
On 11/25/24 6:00 PM, Danilo Krummrich wrote:
On 11/25/24 5:55 PM, Timur Tabi wrote:
On Mon, 2024-11-25 at 15:25 +0100, Danilo Krummrich wrote:
Typically DRM drivers use the DRM debugfs root entry. However, since
Nouveau is heading towards a split into a core and a DRM driver, create
a module
On 11/14/24 1:46 AM, Dave Airlie wrote:
From: Dave Airlie
When this code moved to non-coherent allocator the sync was put too
early for some firmwares which called the setup function, move the
sync down after the setup function.
Reported-by: Diogo Ivo
Do you have a link of where this issue
On 11/25/24 5:55 PM, Timur Tabi wrote:
On Mon, 2024-11-25 at 15:25 +0100, Danilo Krummrich wrote:
Typically DRM drivers use the DRM debugfs root entry. However, since
Nouveau is heading towards a split into a core and a DRM driver, create
a module specific debugfs root directory.
Subsequent
On 10/17/24 9:19 AM, Zhi Wang wrote:
Hi folks:
Here are some fixes of weird bugs I encountered when I was enabling vGPU [1] on
core-driver aka NVKM. They are exposed because of the new RPCs required by
vGPU.
For testing, I tried to run Uniengine Heaven[2] on my RTX 4060 for 8 hours and
the GL C
device driver binding).
Signed-off-by: Danilo Krummrich
---
Unless there are any concerns, I'll pick this patch and rebase Timur's patches
on top of it.
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 16
drivers/gpu/drm/nouveau/nouveau_debugfs.h | 16
d
Hi Zhi,
On 10/31/24 9:52 AM, Zhi Wang wrote:
Hi folks:
Here is the leftover of the previous spin of NVKM GSP RPC fixes, which
is handling the return of large GSP message. PATCH 1 and 2 in the previous
spin were merged [1], and this spin is based on top of PATCH 1 and PATCH 2
in the previous spi
On Tue, Oct 29, 2024 at 07:50:06PM +, Timur Tabi wrote:
> On Thu, 2024-10-03 at 23:48 +0200, Danilo Krummrich wrote:
> > > +#ifdef CONFIG_DEBUG_FS
> > > + /*
> > > + * Logging buffers in debugfs. The wrapper objects need to remain
> > > +
On Thu, Oct 17, 2024 at 07:50:24PM +, Zhi Wang wrote:
> On 17/10/2024 14.29, Danilo Krummrich wrote:
> > External email: Use caution opening links or attachments
> >
> >
>
> Hi Danilo:
>
> Thanks for the reply. See my comments below. If there is no more
On Thu, Oct 17, 2024 at 12:19:19AM -0700, Zhi Wang wrote:
> Hi folks:
>
> Here are some fixes of weird bugs I encountered when I was enabling vGPU [1]
> on
> core-driver aka NVKM. They are exposed because of the new RPCs required by
> vGPU.
>
> For testing, I tried to run Uniengine Heaven[2] on
On Thu, Oct 17, 2024 at 12:19:22AM -0700, Zhi Wang wrote:
> The max RPC size is 16 pages (including the RPC header). To send an RPC
> larger than 16 pages, nvkm should split it into multiple RPCs and send
> it accordingly. The first of the split RPCs has the expected function
> number, while the re
On Sat, Oct 05, 2024 at 09:04:11AM -0700, Kees Cook wrote:
>
>
>
> >On 03/10/24 12:36, Danilo Krummrich wrote:
> >> On 9/13/24 12:23 PM, Danilo Krummrich wrote:
>
> I am reminded that I should check all my MUAs to render the date as
> -MM-DD so my brain
On Sun, Sep 22, 2024 at 06:07:09AM -0700, Zhi Wang wrote:
> The max RPC size is 16 pages (including the RPC header). To send an RPC
> larger than 16 pages, nvkm should split it into multiple RPCs and send
> it accordingly. The first of the split RPCs has the expected function
> number, while the re
On Sun, Oct 13, 2024 at 06:27:32PM +, Zhi Wang wrote:
> On 04/10/2024 20.16, Danilo Krummrich wrote:
> > External email: Use caution opening links or attachments
> >
> >
>
> Hey Danilo. I am just back from my vacation. Sorry for the delay. See my
> comments be
On Tue, Oct 08, 2024 at 02:59:41PM +0300, Yonatan Maman wrote:
> From: Yonatan Maman
>
> This patch series addresses two critical issues in the Nouveau driver
> related to device channels, error handling, and sensitive data leaks.
>
> - Vulnerability in migrate_to_ram: The migrate_to_ram functio
On Tue, Oct 08, 2024 at 10:31:02AM +0300, Yonatan Maman wrote:
> From: Yonatan Maman
>
> When `nouveau_dmem_copy_one` is called, the following error occurs:
>
> [272146.675156] nouveau :06:00.0: fifo: PBDMA9: 0004 [HCE_PRIV]
> ch 1 0300 3386
>
> This indicates that a copy push c
On Mon, Oct 07, 2024 at 04:26:59PM +0300, Yonatan Maman wrote:
> From: Yonatan Maman
>
> When `nouveau_dmem_copy_one` is called, the following error occurs:
>
> [272146.675156] nouveau :06:00.0: fifo: PBDMA9: 0004 [HCE_PRIV]
> ch 1 0300 3386
>
> This indicates that a copy push c
On Mon, Oct 07, 2024 at 03:28:22PM +0300, Yonatan Maman wrote:
>
>
> On 30/09/2024 14:20, Danilo Krummrich wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, Sep 23, 2024 at 01:54:58PM +, Yonatan Maman wrote:
>
ing back based on
> the result from the waiting.
It looks like you hit this one while working on the VFIO stuff too. So, same
question here, can we hit this case with "vanilla nouveau"?
>
> Fixes: 176fdcbddfd28 ("drm/nouveau/gsp/r535: add support for booting GSP-RM"
the end, the read pointer is wrongly advanced by 3 when handling a
> two-page GSP message in the rollback case.
>
> Fix the problems by taking the total size of the message into account
> when advancing the read pointer and calculate the read pointer in the end
> of the all copies for
On 9/17/24 2:08 PM, Colin Ian King wrote:
The mutex field has two following semicolons, replace this with just
one semicolon.
Signed-off-by: Colin Ian King
Applied to drm-misc-fixes, thanks!
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 2 +-
1 file changed, 1 insertion(+), 1 d
On Tue, Sep 10, 2024 at 04:56:16PM -0500, Timur Tabi wrote:
> The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers
> that have printf-like logs from GSP-RM and PMU encoded in them.
>
> LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA
> addresses are passed to GSP-
On 10/3/24 8:44 PM, Gustavo A. R. Silva wrote:
On 03/10/24 12:36, Danilo Krummrich wrote:
On 9/13/24 12:23 PM, Danilo Krummrich wrote:
Hi,
On 9/13/24 10:09 AM, Gustavo A. R. Silva wrote:
Hi all,
Friendly ping: who can take this, please? 🙂
Usually, that's me. But I thought you
On 9/13/24 12:23 PM, Danilo Krummrich wrote:
Hi,
On 9/13/24 10:09 AM, Gustavo A. R. Silva wrote:
Hi all,
Friendly ping: who can take this, please? 🙂
Usually, that's me. But I thought you might want to send a v2 based on Kees'
comments?
Do you plan to follow up on this? I'
On 6/3/24 11:15 AM, egyszer...@freemail.hu wrote:
From: Benjamin Szőke
The goal is to clean-up Linux repository from AUX file names, because
the use of such file names is prohibited on other operating systems
such as Windows, so the Linux repository cannot be cloned and
edited on them.
Signed-
On Fri, Sep 27, 2024 at 12:27:24PM -0300, Jason Gunthorpe wrote:
> On Fri, Sep 27, 2024 at 04:22:32PM +0200, Danilo Krummrich wrote:
> > > When you say things like this it comes across as though you are
> > > implying there are two tiers to the community. Ie those that set t
On Mon, Sep 23, 2024 at 01:54:58PM +, Yonatan Maman wrote:
> A copy push command might fail, causing `migrate_to_ram` to return a
> dirty HIGH_USER page to the user.
>
> This exposes a security vulnerability in the nouveau driver. To prevent
> memory leaks in `migrate_to_ram` upon a copy error
Hi Yonatan,
On Mon, Sep 23, 2024 at 01:54:56PM +, Yonatan Maman wrote:
> When `nouveau_dmem_copy_one` is called, the following error occurs:
>
> [272146.675156] nouveau :06:00.0: fifo: PBDMA9: 0004 [HCE_PRIV]
> ch 1 0300 3386
>
> This indicates that a copy push command trigge
On Fri, Sep 27, 2024 at 09:51:15AM -0300, Jason Gunthorpe wrote:
> On Fri, Sep 27, 2024 at 12:42:56AM +0200, Danilo Krummrich wrote:
> > On Thu, Sep 26, 2024 at 11:40:57AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote:
> > >
On Thu, Sep 26, 2024 at 11:40:57AM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote:
> >
> > No, I do object to "we are ignoring the driver being proposed by the
> > developers involved for this hardware by adding to the old one instead"
> > which it seems li
On Thu, Sep 26, 2024 at 11:07:56AM -0700, Andy Ritger wrote:
>
> I hope and expect the nova and vgpu_mgr efforts to ultimately converge.
>
> First, for the fw ABI debacle: yes, it is unfortunate that we still don't
> have a stable ABI from GSP. We /are/ working on it, though there isn't
> anythi
on, Sep 23, 2024 at 10:49:07AM +0200, Danilo Krummrich wrote:
> > > > > > 2. Proposal for upstream
> > > > > >
> > > > >
> > > > > What is the strategy in the mid / long term with this?
> >
On Tue, Sep 24, 2024 at 09:53:19PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 24, 2024 at 09:56:58PM +0200, Danilo Krummrich wrote:
>
> > Currently - and please correct me if I'm wrong - you make it sound to me as
> > if
> > you're not willing to respect the
On Tue, Sep 24, 2024 at 01:41:51PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 24, 2024 at 12:50:55AM +0200, Danilo Krummrich wrote:
>
> > > From the VFIO side I would like to see something like this merged in
> > > nearish future as it would bring a previously out of t
On Mon, Sep 23, 2024 at 12:01:40PM -0300, Jason Gunthorpe wrote:
> On Mon, Sep 23, 2024 at 10:49:07AM +0200, Danilo Krummrich wrote:
> > > 2. Proposal for upstream
> > >
> >
> > What is the strategy in the mid / long term with this?
>
Hi Zhi,
Thanks for the very detailed cover letter.
On Sun, Sep 22, 2024 at 05:49:22AM -0700, Zhi Wang wrote:
> 1. Background
> =
>
> NVIDIA vGPU[1] software enables powerful GPU performance for workloads
> ranging from graphics-rich virtual workstations to data science and AI,
> enab
On Sun, Sep 22, 2024 at 04:11:21PM +0300, Zhi Wang wrote:
> On Sun, 22 Sep 2024 05:49:22 -0700
> Zhi Wang wrote:
>
> +Ben.
>
> Forget to add you. My bad.
Please also add the driver maintainers!
I had to fetch the patchset from the KVM list, since they did not hit the
nouveau list (I'm trying
Hi,
On 9/13/24 10:09 AM, Gustavo A. R. Silva wrote:
Hi all,
Friendly ping: who can take this, please? 🙂
Usually, that's me. But I thought you might want to send a v2 based on Kees'
comments?
- Danilo
Thanks
-Gustavo
On 21/08/24 22:16, Gustavo A. R. Silva wrote:
Use the `DEFINE_RAW_FLEX(
On 9/5/24 1:24 AM, Ben Skeggs wrote:
init() was removed from ramgp102 when reworking the memory detection, as
it was thought that the code was only necessary when the driver performs
mclk changes, which nouveau doesn't support on pascal.
However, it turns out that we still need to execute this o
Hi Ben,
On 9/4/24 1:16 AM, Ben Skeggs wrote:
init() was removed from ramgp102 when reworking the memory detection, as
it was thought that the code was only necessary when the driver performs
mclk changes, which nouveau doesn't support on pascal.
However, it turns out that we still need to execu
On Mon, Sep 02, 2024 at 06:15:42PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2024 at 01:31:37AM +0200, Danilo Krummrich wrote:
> > From: Asahi Lina
> >
> > DRM drivers need to be able to declare which driver-specific ioctls they
> > support. Add an abstraction impl
On Mon, Sep 02, 2024 at 06:29:06PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2024 at 01:31:39AM +0200, Danilo Krummrich wrote:
> > Implement the DRM driver abstractions.
> >
> > The `Driver` trait provides the interface to the actual driver to fill
> > in the driver
On Fri, Aug 30, 2024 at 03:36:54PM +0800, Jinjie Ruan wrote:
> Avoids the need for manual cleanup of_node_put() in early exits
> from the loop.
>
> Signed-off-by: Jinjie Ruan
Applied to drm-misc-next, thanks!
lable video memory, with a default of 32. Adapt this for
the new client interface.
Signed-off-by: Thomas Zimmermann
Acked-by: Danilo Krummrich
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +--
1 file changed, 5 insertions(
On Fri, Aug 16, 2024 at 06:19:23AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a
> BUG() on startup, when the iommu is enabled:
>
> kernel BUG at include/linux/scatterlist.h:187!
> invalid opcode: [#1] PREEMPT SMP NO
On 8/12/24 2:34 PM, Thomas Zimmermann wrote:
Hi
Am 12.08.24 um 14:17 schrieb Danilo Krummrich:
On 8/12/24 10:28 AM, Thomas Zimmermann wrote:
Replace the call to drm_fb_helper_output_poll_changed() with a call
to drm_client_dev_hotplug(). It is equivalent in functionality, but
uses the DRM
: Daniel Vetter
Acked-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index ee637f1fe03d..ab4e11dc0b8a 100644
--- a/drivers/gpu
Vetter
Acked-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 -
drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index e4c8ce6dd40a
Signed-off-by: Thomas Zimmermann
Acked-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
drivers/gpu/drm/nouveau/nouveau_vga.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_vga.h | 1 -
3 files changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b
On Sat, Aug 03, 2024 at 03:23:48AM +, Timur Tabi wrote:
> On Sat, 2024-08-03 at 02:00 +0200, Danilo Krummrich wrote:
> > > + /* Each GPU has a subdir based on its device name, so find it */
> > > + struct drm_device *drm_dev = dev_get_drvdata(dev);
>
On Fri, Aug 02, 2024 at 02:05:17PM -0500, Timur Tabi wrote:
I was about to apply this patch, but noticed a bug while smoke testing things.
> +/**
> + * r535_gsp_libos_debugfs_init - create logging debugfs entries
> + * @gsp: gsp pointer
> + *
> + * Create the debugfs entries. This exposes the log
On Wed, Jul 31, 2024 at 04:22:10PM +, Timur Tabi wrote:
> On Wed, 2024-07-31 at 16:54 +0200, Danilo Krummrich wrote:
> > >
> > > gsp_logs.shutdown(&gsp_logs) -- are you sure you want this? This is some
> > > weird C++ wanna-be code, IMHO. I don&#x
On Tue, Jul 30, 2024 at 09:49:15PM +, Timur Tabi wrote:
> > "Driver exit" is a bit of an undefined term, the closest thing is probably
> > "driver detach" (from a device). In this case I think you actually mean
> > "module
> > exit" though.
>
> Yes, I use driver and module interchangeably, but
Hi Timur,
On Mon, Jul 29, 2024 at 06:07:20PM -0500, Timur Tabi wrote:
The patch looks great, just a few more nits below.
> The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers
> that have printf-like logs from GSP-RM and PMU encoded in them.
>
> LOGINIT, LOGINTR, and LOGRM are a
On 7/30/24 1:09 AM, Timur Tabi wrote:
On Mon, 2024-07-29 at 18:07 -0500, Timur Tabi wrote:
Store the struct device pointer used to allocate the DMA buffer in
the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release
the buffer without needing the nvkm_gsp. This is needed so that
we c
1 - 100 of 713 matches
Mail list logo
