There isn't really any architecture specific code in this page table
walk implementation, so drop the dependencies.
Signed-off-by: Christoph Hellwig
---
mm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 56cec636a1fc..b18782be969c 10064
Stub out the whole function when CONFIG_TRANSPARENT_HUGEPAGE is not set
to make the function easier to read.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 4d3bd41b6522..f4e90ea5779f 1
There is only a single place where the pgmap is passed over a function
call, so replace it with local variables in the places where we deal
with the pgmap.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 62
1 file changed, 27 insertions(+
The pagewalk code already passes the value as the hmask parameter.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index f26d6abc4ed2..88b77a4a6a1e 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -771,19 +771,16
Stub out the whole function and assign NULL to the .hugetlb_entry method
if CONFIG_HUGETLB_PAGE is not set, as the method won't ever be called in
that case.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm
pte_index is an internal arch helper in various architectures,
without consistent semantics. Open code that calculation of a PMD
index based on the virtual address instead.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hmm.c
The start, end and page_shift values are all saved in the range
structure, so we might as well use that for argument passing.
Signed-off-by: Christoph Hellwig
---
Documentation/vm/hmm.rst| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +--
drivers/gpu/drm/nouveau/nouvea
All users pass PAGE_SIZE here, and if we wanted to support single
entries for huge pages we should really just add a HMM_FAULT_HUGEPAGE
flag instead that uses the huge page size instead of having the
caller calculate that size once, just for the hmm code to verify it.
Signed-off-by: Christoph Hell
The list is used to add the range to another list as an entry in the
core hmm code, so there is no need to initialize it in a driver.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_m
Signed-off-by: Christoph Hellwig
---
include/linux/hmm.h | 1 -
mm/hmm.c| 2 --
2 files changed, 3 deletions(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 82265118d94a..59be0aa2476d 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -422,7 +422,6 @@ long
Hi Jérôme, Ben, Felxi and Jason,
below is a series against the hmm tree which cleans up various minor
bits and allows HMM_MIRROR to be built on all architectures.
Diffstat:
7 files changed, 81 insertions(+), 171 deletions(-)
A git tree is also available at:
git://git.infradead.org/us
We only need the special pud_entry walker if PUD-sized hugepages and
pte mappings are supported, else the common pagewalk code will take
care of the iteration. Not implementing this callback reduced the
amount of code compiled for non-x86 platforms, and also fixes compile
failures with other archi
hmm_range_fault can only return -EAGAIN if called with the block
argument set to false, so remove the special handling for it.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a
This avoid having to abuse the vma field in struct hmm_range to unlock
the mmap_sem.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouve
On Mon, Jul 29, 2019 at 07:30:44PM -0400, Jerome Glisse wrote:
> On Mon, Jul 29, 2019 at 05:28:43PM +0300, Christoph Hellwig wrote:
> > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> > where it can be replaced with a simple boolean local variable.
> >
> > Signed-off-by: C
On Mon, Jul 29, 2019 at 04:42:01PM -0700, Ralph Campbell wrote:
>
> On 7/29/19 7:28 AM, Christoph Hellwig wrote:
> > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> > where it can be replaced with a simple boolean local variable.
> >
> > Signed-off-by: Christoph Hellwig
On Mon, Jul 29, 2019 at 05:28:35PM +0300, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma. Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks. This removes a lot
> of boilerp
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
where it can be replaced with a simple boolean local variable.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
mm/migrate.
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
No one ever checks this flag, and we could easily get that information
from the page if needed.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
include/linux/migrate.h
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor the main copy page to vram routine out into a helper that acts
on a single page and which doesn't require the nouveau_dmem_migrate
structure for argument passing. As an added benefit the new version
only allocates the dma address array once an
On Mon, Jul 29, 2019 at 05:28:43PM +0300, Christoph Hellwig wrote:
> The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> where it can be replaced with a simple boolean local variable.
>
> Signed-off-by: Christoph Hellwig
NAK that flag is useful, for instance a anonymous vma
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
We don't use this flag anymore, so remove it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
inde
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor the main copy page to ram routine out into a helper that acts on
a single page and which doesn't require the nouveau_dmem_fault
structure for argument passing. Also remove the loop over multiple
pages as we only handle one at the moment, alth
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor out the end of fencing logic from the two migration routines.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 33 --
1 file changed, 15 insertions(+), 1
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor out the repeated device memory address calculation into
a helper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 42 +++---
1 file changed, 17 insertions(+
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
When we start a new batch of dma_map operations we need to reset dma_nr,
as we start filling a newly allocated array.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
1 file chan
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
There isn't any good reason to pass callbacks to migrate_vma. Instead
we can just export the three steps done by this function to drivers and
let them sequence the operation without callbacks. This removes a lot
of boilerplate code as-is, and will
https://bugs.freedesktop.org/show_bug.cgi?id=111213
--- Comment #12 from Ilia Mirkin ---
(In reply to KJ Liew from comment #11)
> $ LIBVA_DRIVER_NAME=nouveau chromium
> nve4_set_surface_info:969 - unsupported surface format, try
> is_format_supported() !
This means someone's trying to use an ima
https://bugs.freedesktop.org/show_bug.cgi?id=111213
--- Comment #11 from KJ Liew ---
$ LIBVA_DRIVER_NAME=nouveau chromium
nve4_set_surface_info:969 - unsupported surface format, try
is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try
is_format_supported() !
nve4_se
No one ever checks this flag, and we could easily get that information
from the page if needed.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
include/linux/migrate.h| 1 -
mm/migrate.c | 4 ++--
3 files changed, 3 i
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which starts revamping the
migrate_vma functionality. The prime idea is to export three slightly
lower level functions and thus avoid the need for migrate_vma_ops
callbacks.
Diffstat:
4 files changed, 285 insertions(+), 602 de
The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
where it can be replaced with a simple boolean local variable.
Signed-off-by: Christoph Hellwig
---
include/linux/migrate.h | 1 -
mm/migrate.c| 9 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff
We don't use this flag anymore, so remove it.
Signed-off-by: Christoph Hellwig
---
include/linux/migrate.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 093d67fcf6dd..229153c2c496 100644
--- a/include/linux/migrate.h
+++ b/include/linu
Factor out the end of fencing logic from the two migration routines.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 33 --
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/
Factor the main copy page to ram routine out into a helper that acts on
a single page and which doesn't require the nouveau_dmem_fault
structure for argument passing. Also remove the loop over multiple
pages as we only handle one at the moment, although the structure of
the main worker function ma
Factor the main copy page to vram routine out into a helper that acts
on a single page and which doesn't require the nouveau_dmem_migrate
structure for argument passing. As an added benefit the new version
only allocates the dma address array once and reuses it for each
subsequent chunk of work.
Factor out the repeated device memory address calculation into
a helper.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 42 +++---
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/
When we start a new batch of dma_map operations we need to reset dma_nr,
as we start filling a newly allocated array.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/
There isn't any good reason to pass callbacks to migrate_vma. Instead
we can just export the three steps done by this function to drivers and
let them sequence the operation without callbacks. This removes a lot
of boilerplate code as-is, and will allow the drivers to drastically
improve code flo
https://bugs.freedesktop.org/show_bug.cgi?id=111213
--- Comment #10 from Ilia Mirkin ---
I've pushed a number of changes which make vdpau work, at least on a GK208.
Didn't get a chance to test pre-fermi.
Someone who has the correct quantity of gst installed can test out whether that
works now to
https://bugs.freedesktop.org/show_bug.cgi?id=111217
Ilia Mirkin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Mon, Jul 29, 2019 at 7:29 AM Solerman Kaplon wrote:
>
> Às 14:46 de 27/07/2019, Ilia Mirkin escreveu:
> > On Sat, Jul 27, 2019 at 7:37 AM Ralph Corderoy
> > wrote:
> >> The video plays, CPU load is less (my aim), but there's ‘tearing’ of the
> >> picture as if small rectangles that are update
Às 14:46 de 27/07/2019, Ilia Mirkin escreveu:
On Sat, Jul 27, 2019 at 7:37 AM Ralph Corderoy wrote:
The video plays, CPU load is less (my aim), but there's ‘tearing’ of the
picture as if small rectangles that are updates are appearing in the
wrong location, off by a little. If I step through t
43 matches
Mail list logo
