On 09/02/18 09:56 AM, Christian König wrote:
Am 09.02.2018 um 15:51 schrieb Tom St Denis:
On 09/02/18 09:12 AM, Christian König wrote:
No, there is simply no need to initialize the system domain. What are
the values of p->mapping and adev->mman.bdev.dev_mapping when they
don't match? Maybe we
Am 09.02.2018 um 15:51 schrieb Tom St Denis:
On 09/02/18 09:12 AM, Christian König wrote:
No, there is simply no need to initialize the system domain. What are
the values of p->mapping and adev->mman.bdev.dev_mapping when they
don't match? Maybe we are allocating memory before initializing
ade
On 09/02/18 09:12 AM, Christian König wrote:
No, there is simply no need to initialize the system domain. What are
the values of p->mapping and adev->mman.bdev.dev_mapping when they don't
match? Maybe we are allocating memory before initializing
adev->mman.bdev.dev_mapping.
In my test setup I
Am 09.02.2018 um 15:02 schrieb Tom St Denis:
On 09/02/18 08:56 AM, Christian König wrote:
Am 09.02.2018 um 14:32 schrieb Tom St Denis:
On 02/02/18 02:09 PM, Christian König wrote:
[SNIP]
+ if (p->mapping != adev->mman.bdev.dev_mapping)
+ return -EPERM;
This comparison fails
On 09/02/18 08:56 AM, Christian König wrote:
Am 09.02.2018 um 14:32 schrieb Tom St Denis:
On 02/02/18 02:09 PM, Christian König wrote:
[SNIP]
+ if (p->mapping != adev->mman.bdev.dev_mapping)
+ return -EPERM;
This comparison fails for both IOMMU and non-IOMMU devices in my
c
Am 09.02.2018 um 14:32 schrieb Tom St Denis:
On 02/02/18 02:09 PM, Christian König wrote:
[SNIP]
+ if (p->mapping != adev->mman.bdev.dev_mapping)
+ return -EPERM;
This comparison fails for both IOMMU and non-IOMMU devices in my
carrizo+polaris10 box.
The address being read
On 02/02/18 02:09 PM, Christian König wrote:
This allows access to pages allocated through the driver with optional
IOMMU mapping.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 57 -
1 file changed, 35 insertions(+), 22 deletions
Attached is a patch for umr{master} which should in theory support both
iova and iomem.
I can add the write method if you want since ya it should be fairly
simple to copy/pasta that up.
Cheers,
Tom
On 05/02/18 07:07 AM, Christian König wrote:
Well adding write support is trivial.
What I'm
Well adding write support is trivial.
What I'm more concerned about is if setting page->mapping during
allocation of the page could have any negative effect?
I of hand don't see any since the page isn't reclaimable directly
anyway, but I'm not 100% sure of that.
Christian.
Am 05.02.2018 um
Another thing that occurred to me is this will break write access to GPU
bound memory. Previously we relied on iova to translate the address and
then /dev/mem or /dev/fmem to read/write it. But since this is
literally a read only method obviously there's no write support.
Tom
On 04/02/18 0
Patch1 & 2 & 4, Reviewed-by: Roger He
Patch 5: Acked-by: Roger He
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Saturday, February 03, 2018 3:10 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.
I haven't tried the patch but just like to point out this breaks umr :-) I'll
have to craft something on Monday to support this and iova in parallel until
the iova kernels are realistically EOL'ed.
On the other hand I support this idea since it eliminates the need for an fmem
hack. So much ap
12 matches
Mail list logo