https://bugs.freedesktop.org/show_bug.cgi?id=110931
--- Comment #5 from Andrey Taranov ---
Created attachment 144584
--> https://bugs.freedesktop.org/attachment.cgi?id=144584=edit
VBIOS
Produced with
# cp /sys/kernel/debug/dri/1/vbios.rom .
In my case, it is dri/1:
# cat
https://bugs.freedesktop.org/show_bug.cgi?id=110931
--- Comment #4 from Andrey Taranov ---
Created attachment 144583
--> https://bugs.freedesktop.org/attachment.cgi?id=144583=edit
Successful Xorg log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110931
--- Comment #3 from Andrey Taranov ---
Created attachment 144582
--> https://bugs.freedesktop.org/attachment.cgi?id=144582=edit
Successful kernel log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110931
--- Comment #2 from Andrey Taranov ---
Created attachment 144581
--> https://bugs.freedesktop.org/attachment.cgi?id=144581=edit
Failing Xorg log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110931
Andrey Taranov changed:
What|Removed |Added
Attachment #144579|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110931
Bug ID: 110931
Summary: Timeout initializing Falcon after cold boot
Product: xorg
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Mon, Jun 17, 2019 at 12:59 PM Christoph Hellwig wrote:
>
> On Mon, Jun 17, 2019 at 10:51:35AM -0700, Dan Williams wrote:
> > > - struct dev_pagemap *pgmap = _pgmap;
> >
> > Whoops, needed to keep this line to avoid:
> >
> > tools/testing/nvdimm/test/iomap.c:109:11: error: ‘pgmap’
On Mon, Jun 17, 2019 at 12:59 PM Christoph Hellwig wrote:
>
> On Mon, Jun 17, 2019 at 12:02:09PM -0700, Dan Williams wrote:
> > Need a lead in patch that introduces MEMORY_DEVICE_DEVDAX, otherwise:
>
> Or maybe a MEMORY_DEVICE_DEFAULT = 0 shared by fsdax and p2pdma?
I thought about that, but it
On Mon, Jun 17, 2019 at 02:08:14PM -0600, Logan Gunthorpe wrote:
> I just noticed this is missing a line to set pgmap->ops to
> pci_p2pdma_pagemap_ops. I must have gotten confused by the other users
> in my original review. Though I'm not sure how this compiles as the new
> struct is static and
On 2019-06-17 6:27 a.m., Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> p2pdma.c.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
I also did a quick test with the full patch-set to ensure that the setup
and tear down paths
On Mon, Jun 17, 2019 at 10:51:35AM -0700, Dan Williams wrote:
> > - struct dev_pagemap *pgmap = _pgmap;
>
> Whoops, needed to keep this line to avoid:
>
> tools/testing/nvdimm/test/iomap.c:109:11: error: ‘pgmap’ undeclared
> (first use in this function); did you mean ‘_pgmap’?
So I really
On Sat, Jun 08, 2019 at 12:14:50AM +0530, Souptick Joarder wrote:
> Hi Jason,
>
> On Tue, May 21, 2019 at 12:27 AM Souptick Joarder
> wrote:
> >
> > Convert to use hmm_range_fault().
> >
> > Signed-off-by: Souptick Joarder
>
> Would you like to take it through your new hmm tree or do I
> need
On Mon, Jun 17, 2019 at 12:02:09PM -0700, Dan Williams wrote:
> Need a lead in patch that introduces MEMORY_DEVICE_DEVDAX, otherwise:
Or maybe a MEMORY_DEVICE_DEFAULT = 0 shared by fsdax and p2pdma?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
On Mon, Jun 17, 2019 at 5:28 AM Christoph Hellwig wrote:
>
> Just check if there is a ->page_free operation set and take care of the
> static key enable, as well as the put using device managed resources.
> Also check that a ->page_free is provided for the pgmaps types that
> require it, and
On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> Most pgmap types are only supported when certain config options are
> enabled. Check for a type that is valid for the current configuration
> before setting up the pagemap.
>
> Signed-off-by: Christoph Hellwig
> ---
>
On 2019/06/14, Daniel Vetter wrote:
> Split out to make the functional changes stick out more.
>
Since this patch flew-by, as standalone one (intentionally or not) I'd
add, anything vaguely like:
"Core users of DRIVER_PRIME were removed from core with prior patches."
HTH
Emil
On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> The dev_pagemap is a growing too many callbacks. Move them into a
> separate ops structure so that they are not duplicated for multiple
> instances, and an attacker can't easily overwrite them.
>
> Signed-off-by: Christoph Hellwig
>
On Mon, Jun 17, 2019 at 07:40:18PM +0200, Christoph Hellwig wrote:
> On Mon, Jun 17, 2019 at 10:37:12AM -0700, Dan Williams wrote:
> > > +struct resource *devm_request_free_mem_region(struct device *dev,
> > > + struct resource *base, unsigned long size);
> >
> > This appears to
On Mon, Jun 17, 2019 at 10:37:12AM -0700, Dan Williams wrote:
> > +struct resource *devm_request_free_mem_region(struct device *dev,
> > + struct resource *base, unsigned long size);
>
> This appears to need a 'static inline' helper stub in the
> CONFIG_DEVICE_PRIVATE=n case,
On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> Keep the physical address allocation that hmm_add_device does with the
> rest of the resource code, and allow future reuse of it without the hmm
> wrapper.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Jason Gunthorpe
>
Split out to make the functional changes stick out more.
v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE.
v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE.
v4: Don't add a space in i915_drv.c (Sam)
Cc: Sam Ravnborg
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc:
The functionality is identical to the one currently open coded in
p2pdma.c.
Signed-off-by: Christoph Hellwig
---
drivers/pci/p2pdma.c | 56
1 file changed, 4 insertions(+), 52 deletions(-)
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
hmm_vma_alloc_locked_page is scheduled to go away, use the proper
mm function directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Just use devm_memremap_pages instead of hmm_devmem_add pages to allow
killing that wrapper which doesn't provide a whole lot of benefits.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 82 --
1 file changed, 38 insertions(+), 44
All the mm/hmm.c code is better keyed off HMM_MIRROR. Also let nouveau
depend on it instead of the mix of a dummy dependency symbol plus the
actually selected one. Drop various odd dependencies, as the code is
pretty portable.
Signed-off-by: Christoph Hellwig
---
There isn't really much value add in the hmm_devmem_add wrapper and
more, as using devm_memremap_pages directly now is just as simple.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 26
include/linux/hmm.h | 129
The ZONE_DEVICE support doesn't depend on anything HMM related, just on
various bits of arch support as indicated by the architecture. Also
don't select the option from nouveau as it isn't present in many setups,
and depend on it instead.
Signed-off-by: Christoph Hellwig
---
Remove the clumsy hmm_devmem_page_{get,set}_drvdata helpers, and
instead just access the page directly. Also make the page data
a void pointer, and thus much easier to use.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 18 +++--
include/linux/hmm.h
The only user of it has just been removed, and there wasn't really any need
to wrap a basic memory allocator to start with.
Signed-off-by: Christoph Hellwig
---
include/linux/hmm.h | 3 ---
mm/hmm.c| 14 --
2 files changed, 17 deletions(-)
diff --git
The code hasn't been used since it was added to the tree, and doesn't
appear to actually be usable. Mark it as BROKEN until either a user
comes along or we finally give up on it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
mm/Kconfig | 1 +
1 file changed, 1 insertion(+)
The migrate_vma helper is only used by noveau to migrate device private
pages around. Other HMM_MIRROR users like amdgpu or infiniband don't
need it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/Kconfig | 1 +
mm/Kconfig | 1 -
The functionality is identical to the one currently open coded in
device-dax.
Signed-off-by: Christoph Hellwig
---
drivers/dax/dax-private.h | 4
drivers/dax/device.c | 43 ---
2 files changed, 47 deletions(-)
diff --git
This replaces the hacky ->fault callback, which is currently directly
called from common code through a hmm specific data structure as an
exercise in layering violations.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/hmm.h | 6 --
Just check if there is a ->page_free operation set and take care of the
static key enable, as well as the put using device managed resources.
Also check that a ->page_free is provided for the pgmaps types that
require it, and check for a valid type as well while we are at it.
Note that this also
This code is a trivial wrapper around device model helpers, which
should have been integrated into the driver device model usage from
the start. Assuming it actually had users, which it never had since
the code was added more than 1 1/2 years ago.
Signed-off-by: Christoph Hellwig
Reviewed-by:
Add a flags field to struct dev_pagemap to replace the altmap_valid
boolean to be a little more extensible. Also add a pgmap_altmap() helper
to find the optional altmap and clean up the code using the altmap using
it.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/mm/mem.c | 10
Keep the physical address allocation that hmm_add_device does with the
rest of the resource code, and allow future reuse of it without the hmm
wrapper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: John Hubbard
---
include/linux/ioport.h | 2 ++
kernel/resource.c
The dev_pagemap is a growing too many callbacks. Move them into a
separate ops structure so that they are not duplicated for multiple
instances, and an attacker can't easily overwrite them.
Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
Reviewed-by: Jason Gunthorpe
---
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
mm/Kconfig | 10 --
1 file changed, 10 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index f0c76ba47695..0d2ba7e1f43e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -675,16 +675,6 @@ config ARCH_HAS_HMM_MIRROR
Provide an internal refcounting logic if no ->ref field is provided
in the pagemap passed into devm_memremap_pages so that callers don't
have to reinvent it poorly.
Signed-off-by: Christoph Hellwig
---
include/linux/memremap.h | 4 ++
kernel/memremap.c | 64
struct dev_pagemap is always embedded into a containing structure, so
there is no need to an additional private data field.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/nvdimm/pmem.c| 2 +-
include/linux/memremap.h | 3 +--
kernel/memremap.c| 2 +-
Passing the actual typed structure leads to more understandable code
vs just passing the ref member.
Reported-by: Logan Gunthorpe
Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
Reviewed-by: Jason Gunthorpe
Reviewed-by: Dan Williams
---
drivers/dax/device.c | 12
->mapping isn't even used by HMM users, and the field at the same offset
in the zone_device part of the union is declared as pad. (Which btw is
rather confusing, as DAX uses ->pgmap and ->mapping from two different
sides of the union, but DAX doesn't use hmm_devmem_free).
Signed-off-by:
nouveau is currently using this through an odd hmm wrapper, and I plan
to switch it to the real thing later in this series.
Signed-off-by: Christoph Hellwig
Reviewed-by: John Hubbard
---
mm/mempolicy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index
Most pgmap types are only supported when certain config options are
enabled. Check for a type that is valid for the current configuration
before setting up the pagemap.
Signed-off-by: Christoph Hellwig
---
kernel/memremap.c | 27 +++
1 file changed, 27 insertions(+)
This function has never been used since it was first added to the kernel
more than a year and a half ago, and if we ever grow a consumer of the
MEMORY_DEVICE_PUBLIC infrastructure it can easily use devm_memremap_pages
directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Hi Dan, Jérôme and Jason,
below is a series that cleans up the dev_pagemap interface so that
it is more easily usable, which removes the need to wrap it in hmm
and thus allowing to kill a lot of code
Note: this series is on top of the rdma/hmm branch + the dev_pagemap
releas fix series from Dan
47 matches
Mail list logo
