Displaying 15 results from an estimated 15 matches for "if000c".
Did you mean:
if0001
2020 Aug 19
0
[PATCH -next] drm/nouveau/svm: remove duplicate include
Remove nvif/if000c.h which is included more than once
Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wang Hai <wanghai38 at huawei.com>
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/no...
2019 Aug 12
2
[PATCH] nouveau/hmm: map pages after migration
On 8/10/19 4:13 AM, Christoph Hellwig wrote:
> On something vaguely related to this patch:
>
> You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are
> a little odd as we only ever set these bits, but they also don't seem
> to appear to be in values that are directly fed to the hardware.
>
> On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_*
Yes, I see NVKM_VMM_PFN_*
> constants with similar name...
2019 Aug 08
2
[PATCH] nouveau/hmm: map pages after migration
On 8/8/19 12:07 AM, Christoph Hellwig wrote:
> 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.
2019 Aug 10
0
[PATCH] nouveau/hmm: map pages after migration
...uot;?
>
> OK, will do in v2.
> Should I convert to "dma_addrs + nr_dma" too?
I'll fix it up for v3 of the migrate_vma series. This is a leftover
from passing an args structure.
On something vaguely related to this patch:
You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are
a little odd as we only ever set these bits, but they also don't seem
to appear to be in values that are directly fed to the hardware.
On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_*
constants with similar names and identical values, and those are used
in mmu/vmm...
2019 Aug 16
0
[PATCH] nouveau/hmm: map pages after migration
On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote:
>
> On 8/10/19 4:13 AM, Christoph Hellwig wrote:
>> On something vaguely related to this patch:
>>
>> You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are
>> a little odd as we only ever set these bits, but they also don't seem
>> to appear to be in values that are directly fed to the hardware.
>>
>> On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_*
>
> Yes, I see NVKM_VMM_PFN_*
>
>...
2019 Aug 17
1
[PATCH] nouveau/hmm: map pages after migration
...h at lst.de> wrote:
>
> On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote:
> >
> > On 8/10/19 4:13 AM, Christoph Hellwig wrote:
> >> On something vaguely related to this patch:
> >>
> >> You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are
> >> a little odd as we only ever set these bits, but they also don't seem
> >> to appear to be in values that are directly fed to the hardware.
> >>
> >> On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_*
> >
> > Yes,...
2018 Mar 10
17
[RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau
...u: HMM area creation helpers for nouveau client
drm/nouveau: HACK FOR HMM AREA
drivers/gpu/drm/nouveau/Kbuild | 3 +
drivers/gpu/drm/nouveau/include/nvif/class.h | 2 +
drivers/gpu/drm/nouveau/include/nvif/clb069.h | 8 +
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 26 ++
drivers/gpu/drm/nouveau/include/nvif/vmm.h | 4 +
drivers/gpu/drm/nouveau/include/nvkm/core/device.h | 3 +
drivers/gpu/drm/nouveau/include/nvkm/core/memory.h | 8 +
.../gpu/drm/nouveau/include/nvkm/engine/fault.h | 5 +
drivers/gpu/drm/nouveau/include/nvkm/subde...
2020 Mar 16
0
[PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
...drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 0e36345d395c..edfd0805fba4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -28,6 +28,7 @@
#include <nvif/class.h>
#include <nvif/object.h>
+#include <nvif/if000c.h>
#include <nvif/if500b.h>
#include <nvif/if900b.h>
@@ -692,9 +693,8 @@ nouveau_dmem_convert_pfn(struct nouveau_drm *drm,
if (page == NULL)
continue;
- if (!(range->pfns[i] & range->flags[HMM_PFN_DEVICE_PRIVATE])) {
+ if (!is_device_private_page(page))
c...
2019 Aug 07
4
[PATCH] nouveau/hmm: map pages after migration
...25,13 @@
#include "nouveau_dma.h"
#include "nouveau_mem.h"
#include "nouveau_bo.h"
+#include "nouveau_svm.h"
#include <nvif/class.h>
#include <nvif/object.h>
#include <nvif/if500b.h>
#include <nvif/if900b.h>
+#include <nvif/if000c.h>
#include <linux/sched/mm.h>
#include <linux/hmm.h>
@@ -560,11 +562,12 @@ nouveau_dmem_init(struct nouveau_drm *drm)
}
static unsigned long nouveau_dmem_migrate_copy_one(struct nouveau_drm *drm,
- struct vm_area_struct *vma, unsigned long addr,
- unsigned long src, dma_ad...
2020 Mar 16
4
[PATCH 3/4] mm: simplify device private page handling in hmm_range_fault
...m/nouveau/nouveau_dmem.c
> index 0e36345d395c..edfd0805fba4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> @@ -28,6 +28,7 @@
>
> #include <nvif/class.h>
> #include <nvif/object.h>
> +#include <nvif/if000c.h>
> #include <nvif/if500b.h>
> #include <nvif/if900b.h>
>
> @@ -692,9 +693,8 @@ nouveau_dmem_convert_pfn(struct nouveau_drm *drm,
> if (page == NULL)
> continue;
>
> - if (!(range->pfns[i] & range->flags[HMM_PFN_DEVICE_PRIVATE]))...
2019 Aug 13
0
[PATCH] nouveau/hmm: map pages after migration
...> #include "nouveau_mem.h"
> #include "nouveau_bo.h"
> +#include "nouveau_svm.h"
>
> #include <nvif/class.h>
> #include <nvif/object.h>
> #include <nvif/if500b.h>
> #include <nvif/if900b.h>
> +#include <nvif/if000c.h>
>
> #include <linux/sched/mm.h>
> #include <linux/hmm.h>
> @@ -560,11 +562,12 @@ nouveau_dmem_init(struct nouveau_drm *drm)
> }
>
> static unsigned long nouveau_dmem_migrate_copy_one(struct nouveau_drm *drm,
> - struct vm_area_struct *vma, unsigned...
2020 Mar 03
2
[PATCH v2] nouveau/hmm: map pages after migration
...25,13 @@
#include "nouveau_dma.h"
#include "nouveau_mem.h"
#include "nouveau_bo.h"
+#include "nouveau_svm.h"
#include <nvif/class.h>
#include <nvif/object.h>
#include <nvif/if500b.h>
#include <nvif/if900b.h>
+#include <nvif/if000c.h>
#include <linux/sched/mm.h>
#include <linux/hmm.h>
@@ -558,10 +560,11 @@ nouveau_dmem_init(struct nouveau_drm *drm)
}
static unsigned long nouveau_dmem_migrate_copy_one(struct nouveau_drm *drm,
- unsigned long src, dma_addr_t *dma_addr)
+ unsigned long src, dma_addr_t *d...
2020 Mar 04
5
[PATCH v3 0/4] nouveau/hmm: map pages after migration
Originally patch 4 was targeted for Jason's rdma tree since other HMM
related changes were queued there. Now that those have been merged,
these patches just contain changes to nouveau so they could go through
any tree. I guess Ben Skeggs' tree would be appropriate.
Changes since v2:
Added patches 1-3 to fix some minor issues.
Eliminated nouveau_find_svmm() since it is easily found.
2020 Mar 16
14
ensure device private pages have an owner v2
When acting on device private mappings a driver needs to know if the
device (or other entity in case of kvmppc) actually owns this private
mapping. This series adds an owner field and converts the migrate_vma
code over to check it. I looked into doing the same for
hmm_range_fault, but as far as I can tell that code has never been
wired up to actually work for device private memory, so instead of
2020 May 08
11
[PATCH 0/6] nouveau/hmm: add support for mapping large pages
hmm_range_fault() returns an array of page frame numbers and flags for
how the pages are mapped in the requested process' page tables. The PFN
can be used to get the struct page with hmm_pfn_to_page() and the page size
order can be determined with compound_order(page) but if the page is larger
than order 0 (PAGE_SIZE), there is no indication that the page is mapped
using a larger page size. To