Displaying 20 results from an estimated 4000 matches similar to: "[PATCH AUTOSEL 5.4 48/84] drm/nouveau/svm: check for SVM initialized before migrating"
2020 Apr 15
0
[PATCH AUTOSEL 5.6 077/129] drm/nouveau/svm: check for SVM initialized before migrating
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit 822cab6150d3002952407a8297ff5a0d32bb7b54 ]
When migrating system memory to GPU memory, check that SVM has been
enabled. Even though most errors can be ignored since migration is
a performance optimization, return an error because this is a violation
of the API.
Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>
2020 Apr 15
0
[PATCH AUTOSEL 5.5 065/106] drm/nouveau/svm: check for SVM initialized before migrating
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit 822cab6150d3002952407a8297ff5a0d32bb7b54 ]
When migrating system memory to GPU memory, check that SVM has been
enabled. Even though most errors can be ignored since migration is
a performance optimization, return an error because this is a violation
of the API.
Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>
2020 Apr 15
0
[PATCH AUTOSEL 5.4 49/84] drm/nouveau/svm: fix vma range check for migration
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit b92103b559c77abc5f8b7bec269230a219c880b7 ]
find_vma_intersection(mm, start, end) only guarantees that end is greater
than or equal to vma->vm_start but doesn't guarantee that start is
greater than or equal to vma->vm_start. The calculation for the
intersecting range in nouveau_svmm_bind() isn't accounting for
2020 Apr 15
0
[PATCH AUTOSEL 5.6 078/129] drm/nouveau/svm: fix vma range check for migration
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit b92103b559c77abc5f8b7bec269230a219c880b7 ]
find_vma_intersection(mm, start, end) only guarantees that end is greater
than or equal to vma->vm_start but doesn't guarantee that start is
greater than or equal to vma->vm_start. The calculation for the
intersecting range in nouveau_svmm_bind() isn't accounting for
2020 Apr 15
0
[PATCH AUTOSEL 5.5 066/106] drm/nouveau/svm: fix vma range check for migration
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit b92103b559c77abc5f8b7bec269230a219c880b7 ]
find_vma_intersection(mm, start, end) only guarantees that end is greater
than or equal to vma->vm_start but doesn't guarantee that start is
greater than or equal to vma->vm_start. The calculation for the
intersecting range in nouveau_svmm_bind() isn't accounting for
2020 Nov 03
0
[PATCH AUTOSEL 5.4 22/24] drm/nouveau/nouveau: fix the start/end range for migration
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ]
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell <rcampbell
2020 Nov 03
0
[PATCH AUTOSEL 5.9 33/35] drm/nouveau/nouveau: fix the start/end range for migration
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ]
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell <rcampbell
2020 Nov 03
0
[PATCH AUTOSEL 5.8 27/29] drm/nouveau/nouveau: fix the start/end range for migration
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ]
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell <rcampbell
2020 Jul 23
0
[PATCH v4 4/6] nouveau/svm: use the new migration invalidation
Use the new MMU_NOTIFY_MIGRATE event to skip GPU MMU invalidations of
device private memory and handle the invalidation in the driver as part
of migrating device private memory.
Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 15 ++++++++++++---
drivers/gpu/drm/nouveau/nouveau_svm.c | 21 +++++++++------------
2019 Oct 15
0
[PATCH hmm 10/15] nouveau: use mmu_notifier directly for invalidate_range_start
From: Jason Gunthorpe <jgg at mellanox.com>
There is no reason to get the invalidate_range_start() callback via an
indirection through hmm_mirror, just register a normal notifier directly.
Cc: Ben Skeggs <bskeggs at redhat.com>
Cc: dri-devel at lists.freedesktop.org
Cc: nouveau at lists.freedesktop.org
Cc: Ralph Campbell <rcampbell at nvidia.com>
Signed-off-by: Jason Gunthorpe
2024 Jan 10
2
[PATCH 2/6] drm/nouveau/svm: remove unused but set variables
Fix the W=1 warning -Wunused-but-set-variable.
Cc: Karol Herbst <kherbst at redhat.com>
Cc: Lyude Paul <lyude at redhat.com>
Cc: Danilo Krummrich <dakr at redhat.com>
Cc: nouveau at lists.freedesktop.org
Signed-off-by: Jani Nikula <jani.nikula at intel.com>
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff
2019 Aug 13
0
[PATCH] nouveau/hmm: map pages after migration
On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote:
> When memory is migrated to the GPU it is likely to be accessed by GPU
> code soon afterwards. Instead of waiting for a GPU fault, map the
> migrated memory into the GPU page tables with the same access permissions
> as the source CPU page table entries. This preserves copy on write
> semantics.
>
>
2019 Jul 26
0
[PATCH AUTOSEL 5.2 85/85] drm/nouveau/dmem: missing mutex_lock in error path
From: Ralph Campbell <rcampbell at nvidia.com>
[ Upstream commit d304654bd79332ace9ac46b9a3d8de60acb15da3 ]
In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before
calling nouveau_dmem_chunk_alloc() as shown when CONFIG_PROVE_LOCKING
is enabled:
[ 1294.871933] =====================================
[ 1294.876656] WARNING: bad unlock balance detected!
[ 1294.881375]
2020 Mar 03
1
[PATCH v2] nouveau/hmm: map pages after migration
On 3/3/20 4:42 AM, Jason Gunthorpe wrote:
> On Mon, Mar 02, 2020 at 05:00:23PM -0800, Ralph Campbell wrote:
>> When memory is migrated to the GPU, it is likely to be accessed by GPU
>> code soon afterwards. Instead of waiting for a GPU fault, map the
>> migrated memory into the GPU page tables with the same access permissions
>> as the source CPU page table entries. This
2020 Mar 03
2
[PATCH v2] nouveau/hmm: map pages after migration
When memory is migrated to the GPU, it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the same access permissions
as the source CPU page table entries. This preserves copy on write
semantics.
Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>
Cc: Christoph Hellwig <hch at lst.de>
Cc:
2020 Aug 31
1
[PATCH v2] nouveau: fix the start/end range for migration
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>
---
This is for Ben Skegg's nouveau tree.
I have been working with Karol Herbst on the
2020 Oct 26
0
[PATCH v2] nouveau: fix the start/end range for migration
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>
---
I thought I sent this out earlier but I don't see any record of that so
I'm resending
2020 Aug 27
2
[PATCH] nouveau: fix the start/end range for migration
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>
---
This is for Ben Skegg's nouveau tree.
I have been working with Karol Herbst on the
2019 Aug 07
4
[PATCH] nouveau/hmm: map pages after migration
When memory is migrated to the GPU it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the same access permissions
as the source CPU page table entries. This preserves copy on write
semantics.
Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>
Cc: Christoph Hellwig <hch at lst.de>
Cc:
2019 Jul 03
1
[PATCH 20/22] mm: move hmm_vma_fault to nouveau
On 6/30/19 11:20 PM, Christoph Hellwig wrote:
> hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
> the current nouvea flow. Move it to the only user in preparation for
I didn't quite parse the phrase "quite suites the current nouvea flow."
s/nouvea/nouveau/
> fixing a locking bug involving caller and callee.
>
> Signed-off-by: Christoph