On Tue, 1 Sep 2020 at 06:31, Ralph Campbell wrote:
>
> 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.
>
On Wed, 2 Sep 2020 at 09:43, Lyude Paul wrote:
>
> Not entirely sure why this never came up when I originally tested this
> (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> appears to cause the display engine to throw an exception on driver
> init, at least on my ThinkPad
On Wed, 2 Sep 2020 at 01:05, Christian König
wrote:
>
> We are trying to remove the io_lru handling and depend
> on zero init base, offset and addr here.
>
> v2: init addr as well
Looks like the issues I noticed in the previous version have been
dealt with, so, for the series:
Reviewed-by: Ben
On 9/2/20 2:47 PM, Zi Yan wrote:
On 2 Sep 2020, at 12:58, Ralph Campbell wrote:
A migrating transparent huge page has to already be unmapped. Otherwise,
the page could be modified while it is being copied to a new page and
data could be lost. The function __split_huge_pmd() checks for a PMD
On 2 Sep 2020, at 12:58, Ralph Campbell wrote:
> A migrating transparent huge page has to already be unmapped. Otherwise,
> the page could be modified while it is being copied to a new page and
> data could be lost. The function __split_huge_pmd() checks for a PMD
> migration entry before calling
On Wed, Sep 2, 2020 at 9:58 AM Ralph Campbell wrote:
>
> A migrating transparent huge page has to already be unmapped. Otherwise,
> the page could be modified while it is being copied to a new page and
> data could be lost. The function __split_huge_pmd() checks for a PMD
> migration entry before
Support transparent huge page migration to ZONE_DEVICE private memory.
A new selection flag (MIGRATE_VMA_SELECT_COMPOUND) is added to request
THP migration. Otherwise, THPs are split when filling in the source PFN
array. A new flag (MIGRATE_PFN_COMPOUND) is added to the source PFN array
to
Add some basic stand alone self tests for migrating system memory to device
private memory and back.
Signed-off-by: Ralph Campbell
---
lib/test_hmm.c | 439 +
lib/test_hmm_uapi.h| 3 +
tools/testing/selftests/vm/hmm-tests.c |
Transparent huge page allocation policy is controlled by several sysfs
variables. Rather than expose these to each device driver that needs to
allocate THPs, provide a helper function.
Signed-off-by: Ralph Campbell
---
include/linux/gfp.h | 10 ++
mm/huge_memory.c| 14 ++
A migrating transparent huge page has to already be unmapped. Otherwise,
the page could be modified while it is being copied to a new page and
data could be lost. The function __split_huge_pmd() checks for a PMD
migration entry before calling __split_huge_pmd_locked() leading one to
think that
Move the definition of migrate_vma_collect_skip() to make it callable
by migrate_vma_collect_hole(). This helps make the next patch easier
to read.
Signed-off-by: Ralph Campbell
---
mm/migrate.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git
This series adds support for transparent huge page migration to
migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers.
An earlier version was posted previously [1]. This version now
supports splitting a THP midway in the migration process which
led to a number of changes.
The
Add a helper function to allow device drivers to create device private
transparent huge pages. This is intended to help support device private
THP migrations.
Signed-off-by: Ralph Campbell
---
include/linux/huge_mm.h | 5 +
mm/huge_memory.c| 8
2 files changed, 13
Add support for migrating transparent huge pages to and from device
private memory.
Signed-off-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 289 ++---
drivers/gpu/drm/nouveau/nouveau_svm.c | 11 +-
drivers/gpu/drm/nouveau/nouveau_svm.h | 3 +-
3 files
On Tue, Sep 1, 2020, 23:28 Julien Isorce wrote:
> Hi,
>
> Try: DRI_PRIME=1 LIBVA_DRIVER_NAME=nouveau vainfo --display drm --device
> /dev/dri/renderD129
>
> Also try with and without the --device option, the important one is
> --display drm
>
Nada, and nada. Exact same error as before, both
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps
for DP interlacing support").
The bot has tested the following trees: v5.8.5.
v5.8.5: Failed to apply! Possible
16 matches
Mail list logo
