Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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

RE: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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:

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

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