Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Wed, 11 Sep 2019 at 07:53, Thierry Reding wrote:
>
> On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote:
> > On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding
> > wrote:
> > >
> > > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> > > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > > > Changing the order doesn't look hard. Patch attached (untested,
> > > > > > > have no
> > > > > > > test hardware). But maybe I missed some detail ...
> > > > > >
> > > > > > I came up with something very similar by splitting up
> > > > > > nouveau_bo_new()
> > > > > > into allocation and initialization steps, so that when necessary
> > > > > > the GEM
> > > > > > object can be initialized in between. I think that's slightly more
> > > > > > flexible and easier to understand than a boolean flag.
> > > > >
> > > > > Yes, that should work too.
> > > > >
> > > > > Acked-by: Gerd Hoffmann
> > > > Acked-by: Ben Skeggs
> > >
> > > Thanks guys, applied to drm-misc-next.
> >
> > Hi Thierry,
> >
> > Initial investigations suggest that this commit currently in drm-next
> >
> > commit 019cbd4a4feb3aa3a917d78e7110e3011bbff6d5
> > Author: Thierry Reding
> > Date: Wed Aug 14 11:00:48 2019 +0200
> >
> > drm/nouveau: Initialize GEM object before TTM object
> >
> > breaks nouveau userspace which tries to allocate GEM objects with a
> > non-page-aligned size. Previously nouveau_gem_new would just call
> > nouveau_bo_init which would call nouveau_bo_fixup_align before
> > initializing the GEM object. With this change, it is done after. What
> > do you think -- OK to just move that bit of logic into the new
> > nouveau_bo_alloc() (and make size/align be pointers so that they can
> > be fixed up?)
>
> Hi Ilia,
>
> sorry, got side-tracked earlier and forgot to send this out. I'll turn
> this into a proper patch, but if you manage to find the time to test
> this while I work out the userspace issues that are preventing me from
> testing this more thoroughly, that'd be great.
I can confirm both I can reproduce the bug, and that the fix here
appears to do the trick nicely.
Ben.
>
> Thierry
>
> --- >8 ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index e918b437af17..7d5ede756711 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -186,8 +186,8 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
> }
>
> struct nouveau_bo *
> -nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 flags, u32 tile_mode,
> -u32 tile_flags)
> +nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 flags,
> +u32 tile_mode, u32 tile_flags)
> {
> struct nouveau_drm *drm = cli->drm;
> struct nouveau_bo *nvbo;
> @@ -195,8 +195,8 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
> flags, u32 tile_mode,
> struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
> int i, pi = -1;
>
> - if (!size) {
> - NV_WARN(drm, "skipped size %016llx\n", size);
> + if (!*size) {
> + NV_WARN(drm, "skipped size %016llx\n", *size);
> return ERR_PTR(-EINVAL);
> }
>
> @@ -266,7 +266,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
> flags, u32 tile_mode,
> pi = i;
>
> /* Stop once the buffer is larger than the current page size.
> */
> - if (size >= 1ULL << vmm->page[i].shift)
> + if (*size >= 1ULL << vmm->page[i].shift)
> break;
> }
>
> @@ -281,6 +281,8 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
> flags, u32 tile_mode,
> }
> nvbo->page = vmm->page[pi].shift;
>
> + nouveau_bo_fixup_align(nvbo, flags, align, size);
> +
> return nvbo;
> }
>
> @@ -292,12 +294,11 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
> align, u32 flags,
> size_t acc_size;
> int ret;
>
> - acc_size = ttm_bo_dma_acc_size(nvbo->bo.bdev, size, sizeof(*nvbo));
> -
> - nouveau_bo_fixup_align(nvbo, flags, , );
> nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
> nouveau_bo_placement_set(nvbo, flags, 0);
>
> + acc_size = ttm_bo_dma_acc_size(nvbo->bo.bdev, size, sizeof(*nvbo));
> +
> ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
> >placement, align >> PAGE_SHIFT, false,
> acc_size, sg, robj, nouveau_bo_del_ttm);
> @@ -318,7 +319,8 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int
> align,
> struct nouveau_bo *nvbo;
> int ret;
>
> - nvbo = nouveau_bo_alloc(cli, size, flags, tile_mode, tile_flags);
> + nvbo = nouveau_bo_alloc(cli, , , flags, tile_mode,
> + tile_flags);
> if (IS_ERR(nvbo))
> return PTR_ERR(nvbo);
Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote:
> On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding
> wrote:
> >
> > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote:
> > > >
> > > > Hi,
> > > >
> > > > > > Changing the order doesn't look hard. Patch attached (untested,
> > > > > > have no
> > > > > > test hardware). But maybe I missed some detail ...
> > > > >
> > > > > I came up with something very similar by splitting up nouveau_bo_new()
> > > > > into allocation and initialization steps, so that when necessary the
> > > > > GEM
> > > > > object can be initialized in between. I think that's slightly more
> > > > > flexible and easier to understand than a boolean flag.
> > > >
> > > > Yes, that should work too.
> > > >
> > > > Acked-by: Gerd Hoffmann
> > > Acked-by: Ben Skeggs
> >
> > Thanks guys, applied to drm-misc-next.
>
> Hi Thierry,
>
> Initial investigations suggest that this commit currently in drm-next
>
> commit 019cbd4a4feb3aa3a917d78e7110e3011bbff6d5
> Author: Thierry Reding
> Date: Wed Aug 14 11:00:48 2019 +0200
>
> drm/nouveau: Initialize GEM object before TTM object
>
> breaks nouveau userspace which tries to allocate GEM objects with a
> non-page-aligned size. Previously nouveau_gem_new would just call
> nouveau_bo_init which would call nouveau_bo_fixup_align before
> initializing the GEM object. With this change, it is done after. What
> do you think -- OK to just move that bit of logic into the new
> nouveau_bo_alloc() (and make size/align be pointers so that they can
> be fixed up?)
Hi Ilia,
sorry, got side-tracked earlier and forgot to send this out. I'll turn
this into a proper patch, but if you manage to find the time to test
this while I work out the userspace issues that are preventing me from
testing this more thoroughly, that'd be great.
Thierry
--- >8 ---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index e918b437af17..7d5ede756711 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -186,8 +186,8 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
}
struct nouveau_bo *
-nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 flags, u32 tile_mode,
-u32 tile_flags)
+nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 flags,
+u32 tile_mode, u32 tile_flags)
{
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
@@ -195,8 +195,8 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
flags, u32 tile_mode,
struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
int i, pi = -1;
- if (!size) {
- NV_WARN(drm, "skipped size %016llx\n", size);
+ if (!*size) {
+ NV_WARN(drm, "skipped size %016llx\n", *size);
return ERR_PTR(-EINVAL);
}
@@ -266,7 +266,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
flags, u32 tile_mode,
pi = i;
/* Stop once the buffer is larger than the current page size. */
- if (size >= 1ULL << vmm->page[i].shift)
+ if (*size >= 1ULL << vmm->page[i].shift)
break;
}
@@ -281,6 +281,8 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
flags, u32 tile_mode,
}
nvbo->page = vmm->page[pi].shift;
+ nouveau_bo_fixup_align(nvbo, flags, align, size);
+
return nvbo;
}
@@ -292,12 +294,11 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
align, u32 flags,
size_t acc_size;
int ret;
- acc_size = ttm_bo_dma_acc_size(nvbo->bo.bdev, size, sizeof(*nvbo));
-
- nouveau_bo_fixup_align(nvbo, flags, , );
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
nouveau_bo_placement_set(nvbo, flags, 0);
+ acc_size = ttm_bo_dma_acc_size(nvbo->bo.bdev, size, sizeof(*nvbo));
+
ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
>placement, align >> PAGE_SHIFT, false,
acc_size, sg, robj, nouveau_bo_del_ttm);
@@ -318,7 +319,8 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
struct nouveau_bo *nvbo;
int ret;
- nvbo = nouveau_bo_alloc(cli, size, flags, tile_mode, tile_flags);
+ nvbo = nouveau_bo_alloc(cli, , , flags, tile_mode,
+ tile_flags);
if (IS_ERR(nvbo))
return PTR_ERR(nvbo);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 62930d834fba..38f9d8350963 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -71,8 +71,8 @@ nouveau_bo_ref(struct nouveau_bo *ref, struct nouveau_bo
**pnvbo)
extern struct ttm_bo_driver nouveau_bo_driver;
void nouveau_bo_move_init(struct nouveau_drm *);
Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding wrote: > > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote: > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote: > > > > > > Hi, > > > > > > > > Changing the order doesn't look hard. Patch attached (untested, have > > > > > no > > > > > test hardware). But maybe I missed some detail ... > > > > > > > > I came up with something very similar by splitting up nouveau_bo_new() > > > > into allocation and initialization steps, so that when necessary the GEM > > > > object can be initialized in between. I think that's slightly more > > > > flexible and easier to understand than a boolean flag. > > > > > > Yes, that should work too. > > > > > > Acked-by: Gerd Hoffmann > > Acked-by: Ben Skeggs > > Thanks guys, applied to drm-misc-next. Hi Thierry, Initial investigations suggest that this commit currently in drm-next commit 019cbd4a4feb3aa3a917d78e7110e3011bbff6d5 Author: Thierry Reding Date: Wed Aug 14 11:00:48 2019 +0200 drm/nouveau: Initialize GEM object before TTM object breaks nouveau userspace which tries to allocate GEM objects with a non-page-aligned size. Previously nouveau_gem_new would just call nouveau_bo_init which would call nouveau_bo_fixup_align before initializing the GEM object. With this change, it is done after. What do you think -- OK to just move that bit of logic into the new nouveau_bo_alloc() (and make size/align be pointers so that they can be fixed up?) Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote: > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote: > > > > Hi, > > > > > > Changing the order doesn't look hard. Patch attached (untested, have no > > > > test hardware). But maybe I missed some detail ... > > > > > > I came up with something very similar by splitting up nouveau_bo_new() > > > into allocation and initialization steps, so that when necessary the GEM > > > object can be initialized in between. I think that's slightly more > > > flexible and easier to understand than a boolean flag. > > > > Yes, that should work too. > > > > Acked-by: Gerd Hoffmann > Acked-by: Ben Skeggs Thanks guys, applied to drm-misc-next. Thierry signature.asc Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote: > > Hi, > > > > Changing the order doesn't look hard. Patch attached (untested, have no > > > test hardware). But maybe I missed some detail ... > > > > I came up with something very similar by splitting up nouveau_bo_new() > > into allocation and initialization steps, so that when necessary the GEM > > object can be initialized in between. I think that's slightly more > > flexible and easier to understand than a boolean flag. > > Yes, that should work too. > > Acked-by: Gerd Hoffmann Acked-by: Ben Skeggs > > cheers, > Gerd > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Mon, Aug 05, 2019 at 04:01:10PM +0200, Gerd Hoffmann wrote:
> 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 | 2 +-
> 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(+), 27 deletions(-)
Hi Gerd,
I've been seeing a regression on Nouveau with recent linux-next releases
and git bisect points at this commit as the first bad one. If I revert
it (there's a tiny conflict with a patch that was merged subsequently),
things are back to normal.
I think the reason for this issue is that Nouveau doesn't use GEM
objects for all buffer objects, and even when it uses GEM objects, the
code will not initialize the GEM object until after the buffer objects
and the backing TTM objects have been created.
I tried to fix that by making sure drm_gem_object_init() gets called by
Nouveau before ttm_bo_init(), but the changes are fairly involved and I
was unable to get the GEM reference counting right. I can look into the
proper fix some more, but it might be worth reverting this patch for
now to get Nouveau working again.
Thierry
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index 645a189d365c..113fb2feb437 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(>tbo.vma_node);
> + return drm_vma_node_offset_addr(>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(>tbo.vma_node);
> + return drm_vma_node_offset_addr(>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(>tbo.vma_node);
> + return drm_vma_node_offset_addr(>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 f4ecea6054ba..e28829661724 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(>tbo.vma_node);
> + return drm_vma_node_offset_addr(>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
Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
Hi, > > Changing the order doesn't look hard. Patch attached (untested, have no > > test hardware). But maybe I missed some detail ... > > I came up with something very similar by splitting up nouveau_bo_new() > into allocation and initialization steps, so that when necessary the GEM > object can be initialized in between. I think that's slightly more > flexible and easier to understand than a boolean flag. Yes, that should work too. Acked-by: Gerd Hoffmann cheers, Gerd ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Wed, Aug 14, 2019 at 07:58:27AM +0200, Gerd Hoffmann wrote:
> > Hi Gerd,
> >
> > I've been seeing a regression on Nouveau with recent linux-next releases
> > and git bisect points at this commit as the first bad one. If I revert
> > it (there's a tiny conflict with a patch that was merged subsequently),
> > things are back to normal.
> >
> > I think the reason for this issue is that Nouveau doesn't use GEM
> > objects for all buffer objects,
>
> That shouldn't be a problem ...
>
> > and even when it uses GEM objects, the
> > code will not initialize the GEM object until after the buffer objects
> > and the backing TTM objects have been created.
>
> ... but the initialization order is.
>
> ttm_bo_uses_embedded_gem_object() assumes gem gets initialized first.
>
> drm_gem_object_init() init calling drm_vma_node_reset() again is
> probably the root cause for the breakage.
>
> > I tried to fix that by making sure drm_gem_object_init() gets called by
> > Nouveau before ttm_bo_init(), but the changes are fairly involved and I
> > was unable to get the GEM reference counting right. I can look into the
> > proper fix some more, but it might be worth reverting this patch for
> > now to get Nouveau working again.
>
> Changing the order doesn't look hard. Patch attached (untested, have no
> test hardware). But maybe I missed some detail ...
>
> The other patch attached works around the issue with a flag, to avoid
> drm_vma_node_reset() being called twice.
I came up with something very similar by splitting up nouveau_bo_new()
into allocation and initialization steps, so that when necessary the GEM
object can be initialized in between. I think that's slightly more
flexible and easier to understand than a boolean flag.
Thierry
From a1130a6affcb7c00133e89f3e498cb6757f5bb51 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Wed, 14 Aug 2019 11:00:48 +0200
Subject: [PATCH] drm/nouveau: Initialize GEM object before TTM object
TTM assumes that drivers initialize the embedded GEM object before
calling the ttm_bo_init() function. This is not currently the case
in the Nouveau driver. Fix this by splitting up nouveau_bo_new()
into nouveau_bo_alloc() and nouveau_bo_init() so that the GEM can
be initialized before TTM BO initialization when necessary.
Fixes: b96f3e7c8069 ("drm/ttm: use gem vma_node")
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 69 -
drivers/gpu/drm/nouveau/nouveau_bo.h| 4 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 29 ++-
drivers/gpu/drm/nouveau/nouveau_prime.c | 16 --
4 files changed, 77 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 99e391be9370..b3d3e07de1af 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -185,31 +185,24 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
*size = roundup_64(*size, PAGE_SIZE);
}
-int
-nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
- uint32_t flags, uint32_t tile_mode, uint32_t tile_flags,
- struct sg_table *sg, struct reservation_object *robj,
- struct nouveau_bo **pnvbo)
+struct nouveau_bo *
+nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 flags, u32 tile_mode,
+u32 tile_flags)
{
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
struct nvif_mmu *mmu = >mmu;
struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
- size_t acc_size;
- int type = ttm_bo_type_device;
- int ret, i, pi = -1;
+ int i, pi = -1;
if (!size) {
NV_WARN(drm, "skipped size %016llx\n", size);
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
- if (sg)
- type = ttm_bo_type_sg;
-
nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL);
if (!nvbo)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(>head);
INIT_LIST_HEAD(>entry);
INIT_LIST_HEAD(>vma_list);
@@ -231,7 +224,7 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
nvbo->kind = (tile_flags & 0xff00) >> 8;
if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
kfree(nvbo);
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
@@ -241,7 +234,7 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
nvbo->comp = (tile_flags & 0x0003) >> 16;
if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
kfree(nvbo);
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
} else {
nvbo->zeta = (tile_flags &
