From: Dave Airlie
When a buffer is evicted for memory pressure or TTM evict all,
the placement is set to the eviction domain, this means the
buffer never gets revalidated on the next exec to the correct domain.
I think this should be fine to use the initial domain from the
object creation
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 NOPTI
CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test
> Currently, this can result in runtime PM issues on systems where memory
> Luckily, we don't actually need to allocate coherent memory for the page
> table thanks to being able to pass the GPU a radix3 page table for
> suspend/resume data. So, let's rewrite nvkm_gsp_radix3_sg() to use the sg
>
From: Dave Airlie
I'm pretty sure this optimisation is actually not a great idea,
and is racy with other things waiting for fences.
Just nuke it, there should be no need to do fence waits in a
busy CPU loop.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 2
On Wed, 17 Apr 2024 at 10:57, Ben Skeggs wrote:
>
> This is a series of cleanups that I intended on doing after posting
> the initial GSP-RM support several months ago, and have now had the
> opportunity to work on again.
>
> The main intention here is to replace the ioctl-like interface that
>
From: Dave Airlie
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0008
PGD 800114e6e067 P4D 800114e6e067 PUD 109046067 PMD 0
Oops: [#1] PREEMPT SMP PTI
CPU
On Tue, 9 Apr 2024 at 21:33, Danilo Krummrich wrote:
>
> On 4/9/24 10:27, Lucas Stach wrote:
> > Am Dienstag, dem 09.04.2024 um 10:34 +1000 schrieb Dave Airlie:
> >> From: Dave Airlie
> >>
> >> Running a lot of VK CTS in parallel against nouveau, once every
On Mon, 8 Apr 2024 at 23:05, Timur Tabi wrote:
>
> On Mon, 2024-04-08 at 16:42 +1000, Dave Airlie wrote:
> > This reverts:
> > nouveau/gsp: don't check devinit disable on GSP.
> > and applies a further fix.
> >
> > It turns out the open gpu driver, checks thi
From: Dave Airlie
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0008
PGD 800114e6e067 P4D 800114e6e067 PUD 109046067 PMD 0
Oops: [#1] PREEMPT SMP PTI
CPU
d of quite of a lot of GSP error spam in dmesg.
>
> Signed-off-by: Lyude Paul
For the two patches,
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouve
sable on GSP.")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c | 12
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c
b/d
From: Dave Airlie
dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8
was causing a remap operation like the below.
op_remap: prev: 003fffed 000f a5abd18a
op_remap: next:
op_remap: unmap: 003fffed 0010 0
op_map: map
From: Dave Airlie
GSP should be handling this and I can see no evidence in opengpu
driver that this register should be touched.
Fixed acceleration on 2080 Ti GPUs.
Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
Signed-off-by: Dave Airlie
---
drivers/gpu/d
From: Dave Airlie
Later attempts to refault the bo won't happen and the whole
GPU does to lunch. I think Christian's refactoring of this
code out to the driver broke this not very well tested path.
Fixes: 141b15e59175 ("drm/nouveau: move io_reserve_lru handling into the driver
v5
From: Dave Airlie
This lock is just protecting the umem list so name it as such.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/include/nvkm/core/client.h | 2 +-
drivers/gpu/drm/nouveau/nvkm/core/client.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.c | 12
From: Dave Airlie
It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address
0x6677ed422bceb80c: [#1] PREEMPT SMP
From: Dave Airlie
Turns out usage is always in bytes not shifted.
Fixes: 72fa02fdf833 ("nouveau: add an ioctl to report vram usage")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
On Sat, 24 Feb 2024 at 03:01, Danilo Krummrich wrote:
>
> On Fri, Feb 23, 2024 at 10:14:53AM +1000, Dave Airlie wrote:
> > On Fri, 23 Feb 2024 at 00:45, Danilo Krummrich wrote:
> > >
> > > Using the kernel global workqueue to signal fences can lead to
> > >
AX_ACTIVE limit is reached by waiters, this can
> prevent the work signaling the fence from running.
>
> While this seems fairly unlikely, it's potentially exploitable.
LGTM
Reviewed-by: Dave Airlie
probably should go into drm-misc-fixes?
>
> Fixes: 39126abc5e20 ("
(ignore this one, sent another just after)
On Wed, 14 Feb 2024 at 13:40, Dave Airlie wrote:
>
> From: Dave Airlie
>
> Turing and Ampere will continue to use the old paths by default,
> but we should allow distros to decide what the policy is.
>
> Signed-off-by: Dave Airlie
From: Dave Airlie
Turing and Ampere will continue to use the old paths by default,
but we should allow distros to decide what the policy is.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/Kconfig| 8
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 6 +-
2
From: Dave Airlie
Turing and Ampere will continue to use the old paths by default,
but we should allow distros to decide what the policy is.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/Kconfig| 8
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 3 +++
2
t; It makes sense to allocate struct nouveau_sched separately anyway, since
> in a subsequent commit we can also avoid to allocate a struct
> nouveau_sched in nouveau_abi16_ioctl_channel_alloc() at all, if the
> VM_BIND uAPI has been disabled due to the legacy uAPI being used.
Looks good,
for th
On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote:
>
> On 1/29/24 02:50, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This should break the deadlock between the fctx lock and the irq lock.
> >
> > This offloads the processing off the work from the irq
On Fri, 2 Feb 2024 at 07:33, Timur Tabi wrote:
>
> On Thu, 2024-02-01 at 13:55 -0600, Timur Tabi wrote:
> > +static void
> > +nvkm_gsp_mem_dtor(struct nvkm_gsp *gsp, struct nvkm_gsp_mem *mem)
> > +{
> > + if (mem->data) {
> > + dma_free_coherent(gsp->subdev.device->dev,
From: Dave Airlie
Timur pointed this out before, and it just slipped my mind,
but this might help some things work better, around pcie power
management.
Fixes: 8d55b0a940bb ("nouveau/gsp: add some basic registry entries.")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/
From: Dave Airlie
This should break the deadlock between the fctx lock and the irq lock.
This offloads the processing off the work from the irq into a workqueue.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 ++--
drivers/gpu/drm/nouveau
On Fri, 26 Jan 2024 at 04:28, Daniel Vetter wrote:
>
> On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > fences are signalled on nvidia hw using non-stall interrupts.
> >
> > non-stall interrupts are not latched from my
From: Dave Airlie
fences are signalled on nvidia hw using non-stall interrupts.
non-stall interrupts are not latched from my reading.
When nouveau emits a fence, it requests a NON_STALL signalling,
but it only calls the interface to allow the non-stall irq to happen
after it has already
From: Dave Airlie
nvif_vmm_put gets called if addr is set, but if the allocation
fails we don't need to call put, otherwise we get a warning like
[523232.435671] [ cut here ]
[523232.435674] WARNING: CPU: 8 PID: 1505697 at
drivers/gpu/drm/nouveau/nvif/vmm.c:68
From: Dave Airlie
It appears on TU106 GPUs (2070), that some of the nvdec engines
are in the runlist but have no valid nonstall interrupt, nouveau
didn't handle that too well.
This should let nouveau/gsp work on those.
Cc: sta...@vger.kernel.org # v6.7+
---
drivers/gpu/drm/nouveau/nvkm/engine
On Thu, 4 Jan 2024 at 00:47, Dan Carpenter wrote:
>
> Hi Dave,
>
> kernel test robot noticed the following build warnings:
>
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Dave-Airlie
the timeout if link training fails - and retry up to 3
times. The "3 times" bit comes from OpenRM's link training code.
[airlied: this fixes the panel on one of my laptops]
Signed-off-by: Lyude Paul
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau/nvkm/engine/disp/r535.c | 62
nouveau gsp with
i915 primary GPU.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 28 -
drivers/gpu/drm/nouveau/nouveau_fence.h | 5 -
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b
It looks like for some messages the upper layers need to get access to the
results of the message so we can interpret it.
Rework the ctrl push interface to not free things and cleanup properly
whereever it errors out.
Requested-by: Lyude
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau
This should let the upper layers retry as needed on EAGAIN.
There may be other values we will care about in the future, but
this covers our present needs.
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 26 +++
1 file changed, 21 insertions(+), 5
Fixes a memory leak seen with kmemleak.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index
This fixes a memory leak for the acpi dod object.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 365dda6c002a
in nvidia's
driver. So, let's add that - which doesn't get eDP displays to power on
quite yet, but gets rid of the argument warning at least.
Signed-off-by: Lyude Paul
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 10 --
1 file changed, 8 insertions(+), 2
This func ptr here is normally static allocation, but gsp r535
uses a dynamic pointer, so we need to handle that better.
This fixes a crash with GSP when you use config=disp=0 to avoid
disp problems.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c | 6 --
1
This was being leaked.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
index d088e636edc3..b903785056b5 100644
Add NULL callbacks for some things GSP calls that we don't handle, but know
about
so we avoid the logging.
v2: Timur suggested allowing null fn.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff
These were leftover debug, if we need to bring them back do so
for debugging later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c | 7 ---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 9 -
2 files changed, 16 deletions(-)
diff --git a/drivers
This is a collection of nouveau debug prints, memory leak, a very
annoying race condition causing system hangs with prime scenarios,
and a fix from Lyude to get the panel on my laptop working.
I'd like to get these into 6.7,
Dave.
On Thu, 14 Dec 2023 at 19:26, Jon Hunter wrote:
>
>
>
> On 08/12/2023 10:46, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not
> > preserved across suspend") uses container_of() to cast from struct
> > nvkm_memory to struct
On Mon, 4 Dec 2023 at 05:04, Paul Dufresne wrote:
>
> In https://nouveau.freedesktop.org/KernelModuleParameters.html, there is:
> Here is a list of engines:
> DEVICE
> DMAOBJ
> PBSP
> PCE0
> PCE1
> PCE2
> PCRYPT
> PDISP
> PFIFO
> PGRAPH
> PMPEG
>
On Mon, 4 Dec 2023 at 02:51, Paul Dufresne wrote:
>
> According to:
> https://nouveau.freedesktop.org/InstallNouveau.html
> the project use the kernel at:
> https://gitlab.freedesktop.org/drm/nouveau
> but history shows that it stalled at August 30:
>
These were leftover debug, if we need to bring them back do so
for debugging later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau
From: Dave Airlie
These can happen in normal operations esp with auxch transactions.
Gets rid of
nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073 ctrl cmd:0x00731341
failed: 0x
in logs.
Cc: Lyude
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
Add NULL callbacks for some things GSP calls that we don't handle, but know
about
so we avoid the logging.
v2: Timur suggested allowing null fn.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff
On Tue, 5 Dec 2023 at 09:07, Timur Tabi wrote:
>
> On Tue, 2023-12-05 at 08:55 +1000, Dave Airlie wrote:
> > +static int
> > +r535_gsp_msg_ucode_libos_print(void *priv, u32 fn, void *repv, u32 repc)
> > +{
> > + /* work out what we should do
These seem to get called, but it doesn't look like we have to care too much
at this point.
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 24 ++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp
From: Dave Airlie
This is a hackaround a bug exposed with the GSP code, I'm not sure
what it happening exactly, but it appears some of our flushes don't
result in proper tlb invalidation for out BAR2 and we get a BAR2
fault from GSP and it all dies.
Signed-off-by: Dave Airlie
---
drivers/gpu
On Tue, 28 Nov 2023 at 06:48, Timur Tabi wrote:
>
> On Tue, Oct 31, 2023 at 12:20 AM Dave Airlie wrote:
> > rpc->size = sizeof(*rpc);
> > - rpc->numEntries = 1;
> > - rpc->entries[0].nameOffset = offsetof(typeof(*rpc), entries[1]);
>
On Tue, 14 Nov 2023 at 10:27, Danilo Krummrich wrote:
>
> Make use of the scheduler's credit limit and scheduler job's credit
> count to account for the actual size of a job, such that we fill up the
> ring efficiently.
For the two:
Reviewed-by: Dave Airlie
>
> Signed-off-by
urrent brute force approach of iterating all mappings
> in order to lock and validate the GPUVM's GEM objects. Hence, make us of
> it.
>
> Signed-off-by: Danilo Krummrich
Reviewed-by: Dave Airlie
> ---
> Originally, this patch was part of [1]. However, while applying the serie
Self NAK, this isn't sufficient to fix events.
On Mon, 20 Nov 2023 at 12:07, Dave Airlie wrote:
>
> From: Dave Airlie
>
> The fence code uses the total number of channel ids to allocate a
> bunch of memory for fencing. This is probably not the best way to
> do this, but it's
From: Dave Airlie
This probably isn't the ideal fix, but we ended up using chids
sparsely, and lots of things rely on indexing into the full range,
so just allocate the full range up front.
The GSP code fixes 8 channels into a userd page, but we end up using
a single userd page per channel so
From: Dave Airlie
The fence code uses the total number of channel ids to allocate a
bunch of memory for fencing. This is probably not the best way to
do this, but it's hard to fix right now.
The GSP code realises it can fit 8 channels into a USERD
page, so it claims it can support 256 channels
On Wed, 15 Nov 2023 at 05:54, Danilo Krummrich wrote:
>
> On 11/5/23 21:37, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > If we get back ENODEV don't fail load.
>
> Maybe worth to note why this is OK in this case, might not be obvious
> to future readers of t
On Wed, 8 Nov 2023 at 04:51, Timur Tabi wrote:
>
> On Tue, 2023-10-31 at 15:18 +1000, Dave Airlie wrote:
>
> + strings = (char *)>entries[NV_GSP_REG_NUM_ENTRIES];
>
>
> I get a UBSAN index-out-of-bounds error on boot at this line.
>
> [ 17.765746] nouveau 0
From: Dave Airlie
This allows it to break the following circular locking dependency.
Aug 10 07:01:29 dg1test kernel:
==
Aug 10 07:01:29 dg1test kernel: WARNING: possible circular locking dependency
detected
Aug 10 07:01:29 dg1test kernel
From: Dave Airlie
If we get back ENODEV don't fail load.
Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/270
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_display.c | 5 +
1 file
On Fri, 3 Nov 2023 at 12:41, Danilo Krummrich wrote:
>
> Do not return from gf100_gr_chan_new() with fecs mutex held when failing
> to create the golden context image.
Reviewed-by: Dave Airlie
>
> Cc: # v6.2+
> Fixes: ca081fff6ecc ("drm/nouveau/gr/gf100-: generat
urrent brute force approach of iterating all mappings
> in order to lock and validate the GPUVM's GEM objects. Hence, make us of
> it.
>
> Signed-off-by: Danilo Krummrich
Reviewed-by: Dave Airlie
Dave.
On Thu, 2 Nov 2023 at 09:31, Danilo Krummrich wrote:
>
> Use drm_gpuvm_range_valid() in order to validate userspace requests.
>
> Signed-off-by: Danilo Krummrich
Reviewed-by: Dave Airlie
uvmm_ioctl_vm_init() and perform some minor cleanups.
>
> Signed-off-by: Danilo Krummrich
Reviewed-by: Dave Airlie
On Wed, 1 Nov 2023 at 11:46, Luben Tuikov wrote:
>
> On 2023-10-31 09:33, Danilo Krummrich wrote:
> >
> > On 10/26/23 19:25, Luben Tuikov wrote:
> >> On 2023-10-26 12:39, Danilo Krummrich wrote:
> >>> On 10/23/23 05:22, Luben Tuikov wrote:
> The GPU scheduler has now a variable number of
On Wed, 1 Nov 2023 at 01:53, Timur Tabi wrote:
>
> On Tue, Oct 31, 2023 at 12:20 AM Dave Airlie wrote:
> > +#define NV_GSP_REG_NUM_ENTRIES 2
> > +
> > +static const struct nv_gsp_registry_entries
> > r535_registry_entries[NV_GSP_REG_NUM_ENTRIES] = {
> >
From: Dave Airlie
This original one was backwards, compared to traces from nvidia driver.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers
From: Dave Airlie
The nvidia driver sets these two basic registry entries always,
so copy it.
Signed-off-by: Dave Airlie
---
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 45 ++-
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm
From: Dave Airlie
This moves the initial effort to the latest 535 firmware.
The gsp msg structs have changed, and the message passing also.
The wpr also seems to have some struct changes.
This version of the firmware will be what we are stuck on for a while,
until we can refactor the driver
This moves Ben's work to the latest GSP stable firmware 535.113.01.
We will be stuck on this for a while.
There is also a fix for a message signature, and additions of two
registry entries, which seem to help recover from crashes.
Dave.
From: Dave Airlie
This needs the proper division macros.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
b/drivers/gpu/drm/nouveau/nvkm/engine
From: Dave Airlie
This converts a bunch of divides into the proper macros.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers
On Wed, 11 Oct 2023 at 17:07, Christian König wrote:
>
> Am 10.10.23 um 22:23 schrieb Dave Airlie:
> >> I think we're then optimizing for different scenarios. Our compute
> >> driver will use mostly external objects only, and if shared, I don't
> >> forsee them
> I think we're then optimizing for different scenarios. Our compute
> driver will use mostly external objects only, and if shared, I don't
> forsee them bound to many VMs. What saves us currently here is that in
> compute mode we only really traverse the extobj list after a preempt
> fence wait,
>
> There's a bunch of nouveau kernel details I don't know here but the
> interface looks good and I prefer it to a #define in the header.
>
> Acked-by: Faith Ekstrand
For the series
Reviewed-by: Dave Airlie
we should probably land this in drm-misc-fixes, since it would be
On Thu, 21 Sept 2023 at 00:44, Danilo Krummrich wrote:
>
> Rename struct drm_gpuvm within struct nouveau_uvmm from 'umgr' to base.
>
> Signed-off-by: Danilo Krummrich
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
> drivers/gpu/drm/n
ewed-by: Christian König
> Signed-off-by: Danilo Krummrich
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/Kconfig | 7 +++
> drivers/gpu/drm/Makefile| 2 +-
> drivers/gpu/drm/drm_gpuvm.c | 3 +++
> drivers/gpu/drm/nouveau/Kconfig | 1 +
>
rse, but from the handling I
> suggest to have this patch separately pushed to drm-misc-next.
>
> Feel free to add my Acked-by for pushing this.
>
Acked-by: Dave Airlie
> Regards,
> Christian.
>
> > ---
> > drivers/gpu/drm/Makefile
own the channel.
Reviewed-by: Dave Airlie
>
> Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
> Signed-off-by: Danilo Krummrich
> ---
> drivers/gpu/drm/nouveau/nouveau_exec.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_sched.c | 12 +---
>
; @@ got struct nouveau_channel [noderef] __rcu *channel
Reviewed-by: Dave Airlie
>
> We're just about to emit the fence, there is nothing to protect against
> yet, hence it is safe to just cast __rcu away.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kern
>
> As you may have gathered from the MAINTAINERS patch I just sent out, I
> have resigned from my position at Red Hat, and will be stepping back
> from nouveau development.
>
> This is a personal decision that I've been mulling over for a number
> of years now, and I feel that with GSP-RM greatly
On Wed, 13 Sept 2023 at 17:03, Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 18:20:32 +0200
> Thomas Hellström wrote:
>
> > > +/**
> > > + * get_next_vm_bo_from_list() - get the next vm_bo element
> > > + * @__gpuvm: The GPU VM
> > > + * @__list_name: The name of the list we're iterating on
> >
ing up allocation end emit wasn't a good idea in the first place.
> Hence, limit it to the places where we actually need to pre-allocate.
>
> Fixes: 7f2a0b50b2b2 ("drm/nouveau: fence: separate fence alloc and emit")
> Signed-off-by: Danilo Krummrich
nice find,
Reviewed-by: D
Reviewed-by: Dave Airlie
On Mon, 21 Aug 2023 at 08:29, Danilo Krummrich wrote:
>
> Transfer the region pointer of a uvma to the new uvma(s) on re-map to
> prevent potential shader faults when the re-mapped uvma(s) are unmapped.
>
> Signed-off-by: Danilo Krummrich
> ---
From: Dave Airlie
With the new uapi we don't have the comp flags on the allocation,
so we shouldn't be using the first size that works, we should be
iterating until we get the correct one.
This reduces allocations from 2MB to 64k in lots of places.
Fixes dEQP
From: Dave Airlie
I think there are limit checks in places for most things but the
new api wants to not have them.
Add a limit check and use the vmemdup_user helper instead.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 19 +--
1 file changed, 5
From: Dave Airlie
I think there are limit checks in places for most things but the
new api wants to not have them.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
For the series:
Reviewed-by: Dave Airlie
On Tue, 8 Aug 2023 at 02:32, Danilo Krummrich wrote:
>
> The patch series provides a few fixes for the recently merged VM_BIND uAPI
> mostly addressing a couple of warnings.
>
> It also contains one patch to slightly reduce the m
about things you wrote 10 years ago.
Otherwise for the series:
Reviewed-by: Dave Airlie
Dave.
From: Dave Airlie
nouveau > 10 years ago had a plan for new multiplexer inside a multiplexer
API using nvif. It never fully reached fruition, fast forward 10 years,
and the new vulkan driver is avoiding libdrm and calling ioctls, and
these 3 ioctls, getparam, channel alloc + free don't s
ush buffers via MME macros.
seems sane,
Reviewed-by: Dave Airlie
>
> v2: drop code for gm200 and newer.
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: nouveau@lists.freedesktop.org
> Cc: sta...@vger.kernel.org
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouv
From: Dave Airlie
nouveau > 10 years ago had a plan for new multiplexer inside a multiplexer
API using nvif. It never fully reached fruition, fast forward 10 years,
and the new vulkan driver is avoiding libdrm and calling ioctls, and
these 3 ioctls, getparam, channel alloc + free don't s
On Sun, 23 Jul 2023 at 01:12, Faith Ekstrand wrote:
>
> On Wed, Jul 19, 2023 at 7:15 PM Danilo Krummrich wrote:
>>
>> This commit provides the implementation for the new uapi motivated by the
>> Vulkan API. It allows user mode drivers (UMDs) to:
>>
>> 1) Initialize a GPU virtual address (VA)
m/subdev/acr/base.c
> > @@ -224,7 +224,7 @@ nvkm_acr_oneinit(struct nvkm_subdev *subdev)
> > u64 falcons;
> > int ret, i;
> >
> > - if (list_empty(>hsfw)) {
> > + if (list_empty(>hsfw) || !acr->func->wpr_layout) {
>
> Now t
> > As pointed out by Christian, this would optimize the "get all mappings
> > backed by a specific BO from a given VM" use case.
> >
> > The question for me is, do other drivers than amdgpu commonly need this?
>
> I have no idea.
>
> >
> > And what does amdgpu need this for? Maybe amdgpu does
On Tue, 20 Jun 2023 at 17:06, Oded Gabbay wrote:
>
> On Tue, Jun 20, 2023 at 7:05 AM Dave Airlie wrote:
> >
> > Since this is feature is nouveau only currently and doesn't disturb
> > the current nouveau code paths, I'd like to try and get this work in
> > tree
ntext
> > for GEM buffers) by Christian König. Since the patch implementing drm_exec
> > was
> > not yet merged into drm-next it is part of this series, as well as a small
> > fix
> > for this patch, which was found while testing this series.
> >
> > This
1 - 100 of 176 matches
Mail list logo
