Re: [Nouveau] [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 12:02 PM Christoph Hellwig wrote: > > On Fri, Jun 28, 2019 at 11:59:19AM -0700, Dan Williams wrote: > > It's a bug that the call to put_devmap_managed_page() was gated by > > MEMORY_DEVICE_PUBLIC in release_pages(). That path is also applicable > > to MEMORY_DEVICE_FSDAX because it needs to trigger the ->page_free() > > callback to wake up wait_on_var() via fsdax_pagefree(). > > > > So I guess you could argue that the MEMORY_DEVICE_PUBLIC removal patch > > left the original bug in place. In that sense we're no worse off, but > > since we know about the bug, the fix and the patches have not been > > applied yet, why not fix it now? > > The fix it now would simply be to apply Ira original patch now, but > given that we are at -rc6 is this really a good time? And if we don't > apply it now based on the quilt based -mm worflow it just seems a lot > easier to apply it after my series. Unless we want to include it in > the series, in which case I can do a quick rebase, we'd just need to > make sure Andrew pulls it from -mm. I believe -mm auto drops patches when they appear in the -next baseline. So it should "just work" to pull it into the series and send it along for -next inclusion. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 11:59:19AM -0700, Dan Williams wrote: > It's a bug that the call to put_devmap_managed_page() was gated by > MEMORY_DEVICE_PUBLIC in release_pages(). That path is also applicable > to MEMORY_DEVICE_FSDAX because it needs to trigger the ->page_free() > callback to wake up wait_on_var() via fsdax_pagefree(). > > So I guess you could argue that the MEMORY_DEVICE_PUBLIC removal patch > left the original bug in place. In that sense we're no worse off, but > since we know about the bug, the fix and the patches have not been > applied yet, why not fix it now? The fix it now would simply be to apply Ira original patch now, but given that we are at -rc6 is this really a good time? And if we don't apply it now based on the quilt based -mm worflow it just seems a lot easier to apply it after my series. Unless we want to include it in the series, in which case I can do a quick rebase, we'd just need to make sure Andrew pulls it from -mm. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 11:52 AM Christoph Hellwig wrote: > > On Fri, Jun 28, 2019 at 11:44:35AM -0700, Dan Williams wrote: > > There is a problem with the series in CH's tree. It removes the > > ->page_free() callback from the release_pages() path because it goes > > too far and removes the put_devmap_managed_page() call. > > release_pages only called put_devmap_managed_page for device public > pages. So I can't see how that is in any way a problem. It's a bug that the call to put_devmap_managed_page() was gated by MEMORY_DEVICE_PUBLIC in release_pages(). That path is also applicable to MEMORY_DEVICE_FSDAX because it needs to trigger the ->page_free() callback to wake up wait_on_var() via fsdax_pagefree(). So I guess you could argue that the MEMORY_DEVICE_PUBLIC removal patch left the original bug in place. In that sense we're no worse off, but since we know about the bug, the fix and the patches have not been applied yet, why not fix it now?
Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 11:44:35AM -0700, Dan Williams wrote: > There is a problem with the series in CH's tree. It removes the > ->page_free() callback from the release_pages() path because it goes > too far and removes the put_devmap_managed_page() call. release_pages only called put_devmap_managed_page for device public pages. So I can't see how that is in any way a problem.
Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 11:29 AM Jason Gunthorpe wrote: > > On Fri, Jun 28, 2019 at 10:10:12AM -0700, Dan Williams wrote: > > On Fri, Jun 28, 2019 at 10:08 AM Dan Williams > > wrote: > > > > > > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe > > > wrote: > > > > > > > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > > > > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe > > > > > wrote: > > > > > > > > > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > > > > > > The functionality is identical to the one currently open coded in > > > > > > > device-dax. > > > > > > > > > > > > > > Signed-off-by: Christoph Hellwig > > > > > > > Reviewed-by: Ira Weiny > > > > > > > drivers/dax/dax-private.h | 4 > > > > > > > drivers/dax/device.c | 43 > > > > > > > --- > > > > > > > 2 files changed, 47 deletions(-) > > > > > > > > > > > > DanW: I think this series has reached enough review, did you want > > > > > > to ack/test any further? > > > > > > > > > > > > This needs to land in hmm.git soon to make the merge window. > > > > > > > > > > I was awaiting a decision about resolving the collision with Ira's > > > > > patch before testing the final result again [1]. You can go ahead and > > > > > add my reviewed-by for the series, but my tested-by should be on the > > > > > final state of the series. > > > > > > > > The conflict looks OK to me, I think we can let Andrew and Linus > > > > resolve it. > > > > > > Andrew's tree effectively always rebases since it's a quilt series. > > > I'd recommend pulling Ira's patch out of -mm and applying it with the > > > rest of hmm reworks. Any other git tree I'd agree with just doing the > > > late conflict resolution, but I'm not clear on what's the best > > > practice when conflicting with -mm. > > What happens depends on timing as things arrive to Linus. I promised > to send hmm.git early, so I understand that Andrew will quilt rebase > his tree to Linus's and fix the conflict in Ira's patch before he > sends it. > > > Regardless the patch is buggy. If you want to do the conflict > > resolution it should be because the DEVICE_PUBLIC removal effectively > > does the same fix otherwise we're knowingly leaving a broken point in > > the history. > > I'm not sure I understand your concern, is there something wrong with > CH's series as it stands? hmm is a non-rebasing git tree, so as long > as the series is correct *when I apply it* there is no broken history. > > I assumed the conflict resolution for Ira's patch was to simply take > the deletion of the if block from CH's series - right? > > If we do need to take Ira's patch into hmm.git it will go after CH's > series (and Ira will have to rebase/repost it), so I think there is > nothing to do at this moment - unless you are saying there is a > problem with the series in CH's git tree? There is a problem with the series in CH's tree. It removes the ->page_free() callback from the release_pages() path because it goes too far and removes the put_devmap_managed_page() call.
Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 10:10:12AM -0700, Dan Williams wrote: > On Fri, Jun 28, 2019 at 10:08 AM Dan Williams > wrote: > > > > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe wrote: > > > > > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > > > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe > > > > wrote: > > > > > > > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > > > > > The functionality is identical to the one currently open coded in > > > > > > device-dax. > > > > > > > > > > > > Signed-off-by: Christoph Hellwig > > > > > > Reviewed-by: Ira Weiny > > > > > > drivers/dax/dax-private.h | 4 > > > > > > drivers/dax/device.c | 43 > > > > > > --- > > > > > > 2 files changed, 47 deletions(-) > > > > > > > > > > DanW: I think this series has reached enough review, did you want > > > > > to ack/test any further? > > > > > > > > > > This needs to land in hmm.git soon to make the merge window. > > > > > > > > I was awaiting a decision about resolving the collision with Ira's > > > > patch before testing the final result again [1]. You can go ahead and > > > > add my reviewed-by for the series, but my tested-by should be on the > > > > final state of the series. > > > > > > The conflict looks OK to me, I think we can let Andrew and Linus > > > resolve it. > > > > Andrew's tree effectively always rebases since it's a quilt series. > > I'd recommend pulling Ira's patch out of -mm and applying it with the > > rest of hmm reworks. Any other git tree I'd agree with just doing the > > late conflict resolution, but I'm not clear on what's the best > > practice when conflicting with -mm. What happens depends on timing as things arrive to Linus. I promised to send hmm.git early, so I understand that Andrew will quilt rebase his tree to Linus's and fix the conflict in Ira's patch before he sends it. > Regardless the patch is buggy. If you want to do the conflict > resolution it should be because the DEVICE_PUBLIC removal effectively > does the same fix otherwise we're knowingly leaving a broken point in > the history. I'm not sure I understand your concern, is there something wrong with CH's series as it stands? hmm is a non-rebasing git tree, so as long as the series is correct *when I apply it* there is no broken history. I assumed the conflict resolution for Ira's patch was to simply take the deletion of the if block from CH's series - right? If we do need to take Ira's patch into hmm.git it will go after CH's series (and Ira will have to rebase/repost it), so I think there is nothing to do at this moment - unless you are saying there is a problem with the series in CH's git tree? Regards, Jason
Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 10:08 AM Dan Williams wrote: > > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe wrote: > > > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe wrote: > > > > > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > > > > The functionality is identical to the one currently open coded in > > > > > device-dax. > > > > > > > > > > Signed-off-by: Christoph Hellwig > > > > > Reviewed-by: Ira Weiny > > > > > drivers/dax/dax-private.h | 4 > > > > > drivers/dax/device.c | 43 > > > > > --- > > > > > 2 files changed, 47 deletions(-) > > > > > > > > DanW: I think this series has reached enough review, did you want > > > > to ack/test any further? > > > > > > > > This needs to land in hmm.git soon to make the merge window. > > > > > > I was awaiting a decision about resolving the collision with Ira's > > > patch before testing the final result again [1]. You can go ahead and > > > add my reviewed-by for the series, but my tested-by should be on the > > > final state of the series. > > > > The conflict looks OK to me, I think we can let Andrew and Linus > > resolve it. > > > > Andrew's tree effectively always rebases since it's a quilt series. > I'd recommend pulling Ira's patch out of -mm and applying it with the > rest of hmm reworks. Any other git tree I'd agree with just doing the > late conflict resolution, but I'm not clear on what's the best > practice when conflicting with -mm. Regardless the patch is buggy. If you want to do the conflict resolution it should be because the DEVICE_PUBLIC removal effectively does the same fix otherwise we're knowingly leaving a broken point in the history.
Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe wrote: > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe wrote: > > > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > > > The functionality is identical to the one currently open coded in > > > > device-dax. > > > > > > > > Signed-off-by: Christoph Hellwig > > > > Reviewed-by: Ira Weiny > > > > drivers/dax/dax-private.h | 4 > > > > drivers/dax/device.c | 43 --- > > > > 2 files changed, 47 deletions(-) > > > > > > DanW: I think this series has reached enough review, did you want > > > to ack/test any further? > > > > > > This needs to land in hmm.git soon to make the merge window. > > > > I was awaiting a decision about resolving the collision with Ira's > > patch before testing the final result again [1]. You can go ahead and > > add my reviewed-by for the series, but my tested-by should be on the > > final state of the series. > > The conflict looks OK to me, I think we can let Andrew and Linus > resolve it. > Andrew's tree effectively always rebases since it's a quilt series. I'd recommend pulling Ira's patch out of -mm and applying it with the rest of hmm reworks. Any other git tree I'd agree with just doing the late conflict resolution, but I'm not clear on what's the best practice when conflicting with -mm.
Re: [Nouveau] [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote: > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe wrote: > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > > The functionality is identical to the one currently open coded in > > > device-dax. > > > > > > Signed-off-by: Christoph Hellwig > > > Reviewed-by: Ira Weiny > > > drivers/dax/dax-private.h | 4 > > > drivers/dax/device.c | 43 --- > > > 2 files changed, 47 deletions(-) > > > > DanW: I think this series has reached enough review, did you want > > to ack/test any further? > > > > This needs to land in hmm.git soon to make the merge window. > > I was awaiting a decision about resolving the collision with Ira's > patch before testing the final result again [1]. You can go ahead and > add my reviewed-by for the series, but my tested-by should be on the > final state of the series. The conflict looks OK to me, I think we can let Andrew and Linus resolve it. Thanks, Jason ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe wrote: > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > > The functionality is identical to the one currently open coded in > > device-dax. > > > > Signed-off-by: Christoph Hellwig > > Reviewed-by: Ira Weiny > > --- > > drivers/dax/dax-private.h | 4 > > drivers/dax/device.c | 43 --- > > 2 files changed, 47 deletions(-) > > DanW: I think this series has reached enough review, did you want > to ack/test any further? > > This needs to land in hmm.git soon to make the merge window. I was awaiting a decision about resolving the collision with Ira's patch before testing the final result again [1]. You can go ahead and add my reviewed-by for the series, but my tested-by should be on the final state of the series. [1]: https://lore.kernel.org/lkml/CAPcyv4gTOf+EWzSGrFrh2GrTZt5HVR=e+xicukepiy57px8...@mail.gmail.com/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote: > The functionality is identical to the one currently open coded in > device-dax. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Ira Weiny > --- > drivers/dax/dax-private.h | 4 > drivers/dax/device.c | 43 --- > 2 files changed, 47 deletions(-) DanW: I think this series has reached enough review, did you want to ack/test any further? This needs to land in hmm.git soon to make the merge window. Thanks, Jason ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 110955] Mesa 18.2.8 implementation error: Invalid GLSL version in shading_language_version()
https://bugs.freedesktop.org/show_bug.cgi?id=110955 Emil Velikov changed: What|Removed |Added CC||emil.l.veli...@gmail.com --- Comment #3 from Emil Velikov --- Created attachment 144675 --> https://bugs.freedesktop.org/attachment.cgi?id=144675&action=edit Print GL profile and unknown GLSL version. Forgot the more constructive parts: - please attach (plain-text) the output of glxinfo - if you can build mesa - what's the output of wine with the attached patch -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[PATCH v3 08/18] drm/ttm: use gem vma_node
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
include/drm/ttm/ttm_bo_api.h | 4
drivers/gpu/drm/drm_gem_vram_helper.c | 5 +
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 8
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c| 9 +
drivers/gpu/drm/virtio/virtgpu_prime.c | 3 ---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c| 4 ++--
14 files changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index a80a9972ad16..a68d85bd8fab 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -191,7 +191,7 @@ static inline unsigned amdgpu_bo_gpu_page_alignment(struct
amdgpu_bo *bo)
*/
static inline u64 amdgpu_bo_mmap_offset(struct amdgpu_bo *bo)
{
- return drm_vma_node_offset_addr(&bo->tbo.vma_node);
+ return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
/**
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index b812d4ae9d0d..8ae54ba7857c 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -60,7 +60,7 @@ static inline unsigned long qxl_bo_size(struct qxl_bo *bo)
static inline u64 qxl_bo_mmap_offset(struct qxl_bo *bo)
{
- return drm_vma_node_offset_addr(&bo->tbo.vma_node);
+ return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
static inline int qxl_bo_wait(struct qxl_bo *bo, u32 *mem_type,
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 9ffd8215d38a..e5554bf9140e 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -116,7 +116,7 @@ static inline unsigned radeon_bo_gpu_page_alignment(struct
radeon_bo *bo)
*/
static inline u64 radeon_bo_mmap_offset(struct radeon_bo *bo)
{
- return drm_vma_node_offset_addr(&bo->tbo.vma_node);
+ return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
extern int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 9e2d3062b01d..7146ba00fd5b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -396,7 +396,7 @@ static inline void virtio_gpu_object_unref(struct
virtio_gpu_object **bo)
static inline u64 virtio_gpu_object_mmap_offset(struct virtio_gpu_object *bo)
{
- return drm_vma_node_offset_addr(&bo->tbo.vma_node);
+ return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
static inline int virtio_gpu_object_reserve(struct virtio_gpu_object *bo,
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index fa050f0328ab..7ffc50a3303d 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -152,7 +152,6 @@ struct ttm_tt;
* @ddestroy: List head for the delayed destroy list.
* @swap: List head for swap LRU list.
* @moving: Fence set when BO is moving
- * @vma_node: Address space manager node.
* @offset: The current GPU offset, which can have different meanings
* depending on the memory type. For SYSTEM type memory, it should be 0.
* @cur_placement: Hint of current placement.
@@ -219,9 +218,6 @@ struct ttm_buffer_object {
*/
struct dma_fence *moving;
-
- struct drm_vma_offset_node vma_node;
-
unsigned priority;
/**
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 61d9520cc15f..2e474dee30df 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -163,7 +163,7 @@ EXPORT_SYMBOL(drm_gem_vram_put);
*/
u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo)
{
- return drm_vma_node_offset_addr(&gbo->bo.vma_node);
+ return drm_vma_node_offset_addr(&gbo->bo.base.vma_node);
}
EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
@@ -633,9 +633,6 @@ EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_vunmap);
int drm_gem_vram_driver_gem_prime_mmap(struct drm_gem_object *gem,
struct vm_area_struct *vma)
{
- struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
-
- gbo->bo.base.vma_node.vm_node.start = gbo->bo.vma_node.vm_node.start;
return drm_gem_prime_mmap(gem, vma);
}
EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_mmap);
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
[Nouveau] [PATCH v3 15/18] drm/nouveau: switch driver from bo->resv to bo->base.resv
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 5 ++---
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 283ff690350e..89f8e76a2d7d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -457,7 +457,7 @@ nv50_wndw_prepare_fb(struct drm_plane *plane, struct
drm_plane_state *state)
asyw->image.handle[0] = ctxdma->object.handle;
}
- asyw->state.fence = reservation_object_get_excl_rcu(fb->nvbo->bo.resv);
+ asyw->state.fence =
reservation_object_get_excl_rcu(fb->nvbo->bo.base.resv);
asyw->image.offset[0] = fb->nvbo->bo.offset;
if (wndw->func->prepare) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index abbbabd12241..99e391be9370 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -299,7 +299,6 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
type, &nvbo->placement,
align >> PAGE_SHIFT, false, acc_size, sg,
robj, nouveau_bo_del_ttm);
- nvbo->bo.base.resv = nvbo->bo.resv;
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
@@ -1325,7 +1324,7 @@ nouveau_bo_vm_cleanup(struct ttm_buffer_object *bo,
{
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct drm_device *dev = drm->dev;
- struct dma_fence *fence = reservation_object_get_excl(bo->resv);
+ struct dma_fence *fence = reservation_object_get_excl(bo->base.resv);
nv10_bo_put_tile_region(dev, *old_tile, fence);
*old_tile = new_tile;
@@ -1656,7 +1655,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
void
nouveau_bo_fence(struct nouveau_bo *nvbo, struct nouveau_fence *fence, bool
exclusive)
{
- struct reservation_object *resv = nvbo->bo.resv;
+ struct reservation_object *resv = nvbo->bo.base.resv;
if (exclusive)
reservation_object_add_excl_fence(resv, &fence->base);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index d4964f3397a1..e5f249ab216a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -335,7 +335,7 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
nouveau_channel *chan, bool e
{
struct nouveau_fence_chan *fctx = chan->fence;
struct dma_fence *fence;
- struct reservation_object *resv = nvbo->bo.resv;
+ struct reservation_object *resv = nvbo->bo.base.resv;
struct reservation_object_list *fobj;
struct nouveau_fence *f;
int ret = 0, i;
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index b1e4852810ed..c7368aa0bdec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -887,7 +887,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
return -ENOENT;
nvbo = nouveau_gem_object(gem);
- lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true,
+ lret = reservation_object_wait_timeout_rcu(nvbo->bo.base.resv, write,
true,
no_wait ? 0 : 30 * HZ);
if (!lret)
ret = -EBUSY;
--
2.18.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v3 06/18] drm/nouveau: use embedded gem object
Drop drm_gem_object from nouveau_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
Acked-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.h | 5 -
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_display.c | 8
drivers/gpu/drm/nouveau/nouveau_gem.c | 15 ---
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++--
7 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 846f4bdec0de..40f01b9a07d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -35,11 +35,6 @@ struct nouveau_bo {
struct nouveau_drm_tile *tile;
- /* Only valid if allocated via nouveau_gem_new() and iff you hold a
-* gem reference to it! For debugging, use gem.filp != NULL to test
-* whether it is valid. */
- struct drm_gem_object gem;
-
/* protect by the ttm reservation lock */
int pin_refcnt;
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index 9dea015387fd..59af7c223c5f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -10,7 +10,7 @@
static inline struct nouveau_bo *
nouveau_gem_object(struct drm_gem_object *gem)
{
- return gem ? container_of(gem, struct nouveau_bo, gem) : NULL;
+ return gem ? container_of(gem, struct nouveau_bo, bo.base) : NULL;
}
/* nouveau_gem.c */
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index c3fd5dd39ed9..94387e62b338 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -139,7 +139,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
if (chan->ntfy) {
nouveau_vma_del(&chan->ntfy_vma);
nouveau_bo_unpin(chan->ntfy);
- drm_gem_object_put_unlocked(&chan->ntfy->gem);
+ drm_gem_object_put_unlocked(&chan->ntfy->bo.base);
}
if (chan->heap.block_size)
@@ -345,7 +345,7 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
goto done;
}
- ret = drm_gem_handle_create(file_priv, &chan->ntfy->gem,
+ ret = drm_gem_handle_create(file_priv, &chan->ntfy->bo.base,
&init->notifier_handle);
if (ret)
goto done;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 6f1217b3e6b9..abbbabd12241 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -136,7 +136,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct drm_device *dev = drm->dev;
struct nouveau_bo *nvbo = nouveau_bo(bo);
- if (unlikely(nvbo->gem.filp))
+ if (unlikely(nvbo->bo.base.filp))
DRM_ERROR("bo %p still attached to GEM object\n", bo);
WARN_ON(nvbo->pin_refcnt > 0);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
@@ -299,7 +299,7 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
type, &nvbo->placement,
align >> PAGE_SHIFT, false, acc_size, sg,
robj, nouveau_bo_del_ttm);
- nvbo->gem.resv = nvbo->bo.resv;
+ nvbo->bo.base.resv = nvbo->bo.resv;
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
@@ -1402,7 +1402,7 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo,
struct file *filp)
{
struct nouveau_bo *nvbo = nouveau_bo(bo);
- return drm_vma_node_verify_access(&nvbo->gem.vma_node,
+ return drm_vma_node_verify_access(&nvbo->bo.base.vma_node,
filp->private_data);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 832da8e0020d..fc8f5bb73ca8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -201,7 +201,7 @@ nouveau_user_framebuffer_destroy(struct drm_framebuffer
*drm_fb)
struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
if (fb->nvbo)
- drm_gem_object_put_unlocked(&fb->nvbo->gem);
+ drm_gem_object_put_unlocked(&fb->nvbo->bo.base);
drm_framebuffer_cleanup(drm_fb);
kfree(fb);
@@ -214,7 +214,7 @@ nouveau_user_framebuffer_create_handle(struct
drm_framebuffer *drm_fb,
{
struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
- return drm_gem_handle_create(file_priv, &fb->nvbo->gem, handle);
+ return drm_gem_handle_create(file_priv, &fb->nvbo->bo.base, handle);
}
static const struct
