Re: [PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
Am 14.04.21 um 08:48 schrieb Felix Kuehling:
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
Going to pick that one up for inclusion in drm-misc-next.
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5d8820725b75..e8b8c3257392 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
- atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
atomic_long_read(&ttm_dma32_pages_allocated) >
@@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
return 0;
error:
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_tt_populate);
@@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
ttm_tt *ttm)
else
ttm_pool_free(&bdev->pool, ttm);
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] Implement multi-GPU DMA mappings for KFD
Sorry for the spam. I mis-spelled the amd-gfx list on the To: line of this patch series. Please ignore this and see the patch series I sent a minute later. Regards, Felix On 2021-04-14 2:46 a.m., Felix Kuehling wrote: This patch series fixes DMA-mappings of system memory (GTT and userptr) for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per GPU is needed to maintain the DMA mappings of each BO. I ran into some reservation issues when unmapping or freeing DMA-buf imports. There are a few FIXME comments in this patch series where I'm hoping for some expert advice. Patches 8 and 9 are some related fixes in TTM and amdgpu_ttm. I'm pretty sure patch 9 is not the right way to do this. Felix Kuehling (9): drm/amdgpu: Rename kfd_bo_va_list to kfd_mem_attachment drm/amdgpu: Keep a bo-reference per-attachment drm/amdgpu: Simplify AQL queue mapping drm/amdgpu: Add multi-GPU DMA mapping helpers drm/amdgpu: DMA map/unmap when updating GPU mappings drm/amdgpu: Move kfd_mem_attach outside reservation drm/amdgpu: Add DMA mapping of GTT BOs drm/ttm: Don't count pages in SG BOs against pages_limit drm/amdgpu: Lock the attached dmabuf in unpopulate drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 18 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 535 -- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 + drivers/gpu/drm/ttm/ttm_tt.c | 27 +- 4 files changed, 420 insertions(+), 173 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/amdgpu: Lock the attached dmabuf in unpopulate
amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The dmabuf->resv
must not be held by the caller or dma_buf_detach will deadlock. This is
probably not the right fix. I get a recursive lock warning with the
reservation held in ttm_bo_release. Should unmap_attachment move to
backend_unbind instead?
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 936b3cfdde55..257750921eed 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1216,9 +1216,22 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device
*bdev,
if (ttm->sg && gtt->gobj->import_attach) {
struct dma_buf_attachment *attach;
+ bool locked;
attach = gtt->gobj->import_attach;
+ /* FIXME: unpopulate can be called during bo_destroy.
+* The dmabuf->resv must not be held by the caller or
+* dma_buf_detach will deadlock. This is probably not
+* the right fix. I get a recursive lock warning with the
+* reservation held in ttm_bo_releas.. Should
+* unmap_attachment move to backend_unbind instead?
+*/
+ locked = dma_resv_is_locked(attach->dmabuf->resv);
+ if (!locked)
+ dma_resv_lock(attach->dmabuf->resv, NULL);
dma_buf_unmap_attachment(attach, ttm->sg, DMA_BIDIRECTIONAL);
+ if (!locked)
+ dma_resv_unlock(attach->dmabuf->resv);
ttm->sg = NULL;
return;
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/amdgpu: Add multi-GPU DMA mapping helpers
Add BO-type specific helpers functions to DMA-map and unmap
kfd_mem_attachments. Implement this functionality for userptrs by creating
one SG BO per GPU and filling it with a DMA mapping of the pages from the
original mem->bo.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 8 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 155 --
2 files changed, 152 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 910c50956e16..fc3514ed1b74 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -38,11 +38,17 @@ extern uint64_t amdgpu_amdkfd_total_mem_size;
struct amdgpu_device;
+enum kfd_mem_attachment_type {
+ KFD_MEM_ATT_SHARED, /* Share kgd_mem->bo or another attachment's */
+ KFD_MEM_ATT_USERPTR,/* SG bo to DMA map pages from a userptr bo */
+};
+
struct kfd_mem_attachment {
struct list_head list;
+ enum kfd_mem_attachment_type type;
+ bool is_mapped;
struct amdgpu_bo_va *bo_va;
struct amdgpu_device *adev;
- bool is_mapped;
uint64_t va;
uint64_t pte_flags;
};
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 114fbf508707..51502a07fc1d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -471,12 +471,117 @@ static uint64_t get_pte_flags(struct amdgpu_device
*adev, struct kgd_mem *mem)
return pte_flags;
}
+static int
+kfd_mem_dmamap_userptr(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ enum dma_data_direction direction =
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+ struct amdgpu_device *adev = attachment->adev;
+ struct ttm_tt *src_ttm = mem->bo->tbo.ttm;
+ struct ttm_tt *ttm = bo->tbo.ttm;
+ int ret;
+
+ ttm->sg = kmalloc(sizeof(*ttm->sg), GFP_KERNEL);
+ if (unlikely(!ttm->sg))
+ return -ENOMEM;
+
+ if (WARN_ON(ttm->num_pages != src_ttm->num_pages))
+ return -EINVAL;
+
+ /* Same sequence as in amdgpu_ttm_tt_pin_userptr */
+ ret = sg_alloc_table_from_pages(ttm->sg, src_ttm->pages,
+ ttm->num_pages, 0,
+ (u64)ttm->num_pages << PAGE_SHIFT,
+ GFP_KERNEL);
+ if (unlikely(ret))
+ goto release_sg;
+
+ ret = dma_map_sgtable(adev->dev, ttm->sg, direction, 0);
+ if (unlikely(ret))
+ goto release_sg;
+
+ drm_prime_sg_to_dma_addr_array(ttm->sg, ttm->dma_address,
+ ttm->num_pages);
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ ret = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+ if (ret)
+ goto release_sg;
+
+ return 0;
+
+release_sg:
+ pr_err("DMA map userptr failed: %d\n", ret);
+ sg_free_table(ttm->sg);
+ kfree(ttm->sg);
+ ttm->sg = NULL;
+ return ret;
+}
+
+static int
+kfd_mem_dmamap_attachment(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ switch (attachment->type) {
+ case KFD_MEM_ATT_SHARED:
+ return 0;
+ case KFD_MEM_ATT_USERPTR:
+ return kfd_mem_dmamap_userptr(mem, attachment);
+ default:
+ WARN_ON_ONCE(1);
+ }
+ return -EINVAL;
+}
+
+static void
+kfd_mem_dmaunmap_userptr(struct kgd_mem *mem,
+struct kfd_mem_attachment *attachment)
+{
+ enum dma_data_direction direction =
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
+ struct ttm_operation_ctx ctx = {.interruptible = false};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+ struct amdgpu_device *adev = attachment->adev;
+ struct ttm_tt *ttm = bo->tbo.ttm;
+
+ if (unlikely(!ttm->sg))
+ return;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
+ ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+
+ dma_unmap_sgtable(adev->dev, ttm->sg, direction, 0);
+ sg_free_table(ttm->sg);
+ ttm->sg = NULL;
+}
+
+static void
+kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ switch (attachment->type) {
+ case KFD_MEM_ATT_SHARED:
+ break;
+ case KFD_MEM_ATT_USERPTR:
+ kfd_mem_dmaunmap_userptr(mem, attachment);
+
[PATCH 7/9] drm/amdgpu: Add DMA mapping of GTT BOs
Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 74 ++-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index fc3514ed1b74..3ea51982b720 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -41,6 +41,7 @@ struct amdgpu_device;
enum kfd_mem_attachment_type {
KFD_MEM_ATT_SHARED, /* Share kgd_mem->bo or another attachment's */
KFD_MEM_ATT_USERPTR,/* SG bo to DMA map pages from a userptr bo */
+ KFD_MEM_ATT_DMABUF, /* DMAbuf to DMA map TTM BOs */
};
struct kfd_mem_attachment {
@@ -56,6 +57,7 @@ struct kfd_mem_attachment {
struct kgd_mem {
struct mutex lock;
struct amdgpu_bo *bo;
+ struct dma_buf *dmabuf;
struct list_head attachments;
/* protected by amdkfd_process_info.lock */
struct ttm_validate_buffer validate_list;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 1416f3c03f1d..bb3a96ab8f20 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -522,6 +522,16 @@ kfd_mem_dmamap_userptr(struct kgd_mem *mem,
return ret;
}
+static int
+kfd_mem_dmamap_dmabuf(struct kfd_mem_attachment *attachment)
+{
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ return ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+}
+
static int
kfd_mem_dmamap_attachment(struct kgd_mem *mem,
struct kfd_mem_attachment *attachment)
@@ -531,6 +541,8 @@ kfd_mem_dmamap_attachment(struct kgd_mem *mem,
return 0;
case KFD_MEM_ATT_USERPTR:
return kfd_mem_dmamap_userptr(mem, attachment);
+ case KFD_MEM_ATT_DMABUF:
+ return kfd_mem_dmamap_dmabuf(attachment);
default:
WARN_ON_ONCE(1);
}
@@ -560,6 +572,19 @@ kfd_mem_dmaunmap_userptr(struct kgd_mem *mem,
ttm->sg = NULL;
}
+static void
+kfd_mem_dmaunmap_dmabuf(struct kfd_mem_attachment *attachment)
+{
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
+ ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+ /* FIXME: This does not guarantee that amdgpu_ttm_tt_unpopulate is
+* called
+*/
+}
+
static void
kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
struct kfd_mem_attachment *attachment)
@@ -570,6 +595,9 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
case KFD_MEM_ATT_USERPTR:
kfd_mem_dmaunmap_userptr(mem, attachment);
break;
+ case KFD_MEM_ATT_DMABUF:
+ kfd_mem_dmaunmap_dmabuf(attachment);
+ break;
default:
WARN_ON_ONCE(1);
}
@@ -601,6 +629,36 @@ kfd_mem_attach_userptr(struct amdgpu_device *adev, struct
kgd_mem *mem,
return 0;
}
+static int
+kfd_mem_attach_dmabuf(struct amdgpu_device *adev, struct kgd_mem *mem,
+ struct amdgpu_bo **bo)
+{
+ struct drm_gem_object *gobj;
+
+ if (!mem->dmabuf) {
+ mem->dmabuf = amdgpu_gem_prime_export(&mem->bo->tbo.base,
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DRM_RDWR : 0);
+ if (IS_ERR(mem->dmabuf)) {
+ mem->dmabuf = NULL;
+ return PTR_ERR(mem->dmabuf);
+ }
+ }
+
+ gobj = amdgpu_gem_prime_import(&adev->ddev, mem->dmabuf);
+ if (IS_ERR(gobj))
+ return PTR_ERR(gobj);
+
+ /* Import takes an extra reference on the dmabuf. Drop it now to
+* avoid leaking it. We only need the one reference in
+* kgd_mem->dmabuf.
+*/
+ dma_buf_put(mem->dmabuf);
+
+ *bo = gem_to_amdgpu_bo(gobj);
+ return 0;
+}
+
/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
@@ -658,8 +716,20 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
ret = kfd_mem_attach_userptr(adev, mem, &bo[i]);
if (ret)
goto unwind;
+ } else if (mem->domain == AMDGPU_GEM_DOMAIN_GTT &&
+ mem->bo->tbo.type != ttm_bo_type_sg) {
+ /* GTT BOs use DMA-mapping ability of dynamic-attach
+
[PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5d8820725b75..e8b8c3257392 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
- atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
atomic_long_read(&ttm_dma32_pages_allocated) >
@@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
return 0;
error:
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_tt_populate);
@@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
ttm_tt *ttm)
else
ttm_pool_free(&bdev->pool, ttm);
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/amdgpu: Move kfd_mem_attach outside reservation
This is needed to avoid deadlocks with DMA buf import in the next patch.
Also move PT/PD validation out of kfd_mem_attach, that way the caller
can bo this unconditionally.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 72 +++
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 3bb2ae185bbb..1416f3c03f1d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -575,6 +575,32 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
}
}
+static int
+kfd_mem_attach_userptr(struct amdgpu_device *adev, struct kgd_mem *mem,
+ struct amdgpu_bo **bo)
+{
+ unsigned long bo_size = mem->bo->tbo.base.size;
+ struct drm_gem_object *gobj;
+ int ret;
+
+ ret = amdgpu_bo_reserve(mem->bo, false);
+ if (ret)
+ return ret;
+
+ ret = amdgpu_gem_object_create(adev, bo_size, 1,
+ AMDGPU_GEM_DOMAIN_CPU,
+ 0, ttm_bo_type_sg,
+ mem->bo->tbo.base.resv,
+ &gobj);
+ if (ret)
+ return ret;
+
+ amdgpu_bo_unreserve(mem->bo);
+
+ *bo = gem_to_amdgpu_bo(gobj);
+ return 0;
+}
+
/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
@@ -596,7 +622,6 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
uint64_t va = mem->va;
struct kfd_mem_attachment *attachment[2] = {NULL, NULL};
struct amdgpu_bo *bo[2] = {NULL, NULL};
- struct drm_gem_object *gobj;
int i, ret;
if (!va) {
@@ -630,14 +655,9 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
} else if (amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm)) {
/* Create an SG BO to DMA-map userptrs on other GPUs */
attachment[i]->type = KFD_MEM_ATT_USERPTR;
- ret = amdgpu_gem_object_create(adev, bo_size, 1,
- AMDGPU_GEM_DOMAIN_CPU,
- 0, ttm_bo_type_sg,
- mem->bo->tbo.base.resv,
- &gobj);
+ ret = kfd_mem_attach_userptr(adev, mem, &bo[i]);
if (ret)
goto unwind;
- bo[i] = gem_to_amdgpu_bo(gobj);
} else {
/* FIXME: Need to DMA-map other BO types */
attachment[i]->type = KFD_MEM_ATT_SHARED;
@@ -662,13 +682,6 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
va += bo_size;
}
- /* Allocate validate page tables if needed */
- ret = vm_validate_pt_pd_bos(vm);
- if (unlikely(ret)) {
- pr_err("validate_pt_pd_bos() failed\n");
- goto unwind;
- }
-
return 0;
unwind:
@@ -1516,12 +1529,12 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
pr_debug("Release VA 0x%llx - 0x%llx\n", mem->va,
mem->va + bo_size * (1 + mem->aql_queue));
+ ret = unreserve_bo_and_vms(&ctx, false, false);
+
/* Remove from VM internal data structures */
list_for_each_entry_safe(entry, tmp, &mem->attachments, list)
kfd_mem_detach(mem, entry);
- ret = unreserve_bo_and_vms(&ctx, false, false);
-
/* Free the sync object */
amdgpu_sync_free(&mem->sync);
@@ -1597,6 +1610,12 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
mem->va + bo_size * (1 + mem->aql_queue),
vm, domain_string(domain));
+ if (!kfd_mem_is_attached(avm, mem)) {
+ ret = kfd_mem_attach(adev, mem, avm, mem->aql_queue);
+ if (ret)
+ goto out;
+ }
+
ret = reserve_bo_and_vm(mem, vm, &ctx);
if (unlikely(ret))
goto out;
@@ -1610,15 +1629,9 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
is_invalid_userptr = true;
- if (!kfd_mem_is_attached(avm, mem)) {
- ret = kfd_mem_attach(adev, mem, avm, mem->aql_queue);
- if (ret)
- goto attach_failed;
- } else {
- ret = vm_validate_pt_pd_bos(avm);
- if (unlikely(ret))
- goto attach_failed;
- }
+ ret = vm_validate_pt_pd_bos(avm);
+ if (unlikely(ret))
+ goto out_unreserve;
if (mem->mapped_to_gpu_memor
[PATCH 5/9] drm/amdgpu: DMA map/unmap when updating GPU mappings
DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
with the BO and page tables reserved, so we can safely update the DMA
mapping.
DMA unmap when a BO is unmapped from a GPU and before updating mappings
in restore workers.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 56 ++-
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 51502a07fc1d..3bb2ae185bbb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -964,11 +964,12 @@ static int unreserve_bo_and_vms(struct
bo_vm_reservation_context *ctx,
return ret;
}
-static int unmap_bo_from_gpuvm(struct amdgpu_device *adev,
+static void unmap_bo_from_gpuvm(struct kgd_mem *mem,
struct kfd_mem_attachment *entry,
struct amdgpu_sync *sync)
{
struct amdgpu_bo_va *bo_va = entry->bo_va;
+ struct amdgpu_device *adev = entry->adev;
struct amdgpu_vm *vm = bo_va->base.vm;
amdgpu_vm_bo_unmap(adev, bo_va, entry->va);
@@ -977,15 +978,20 @@ static int unmap_bo_from_gpuvm(struct amdgpu_device *adev,
amdgpu_sync_fence(sync, bo_va->last_pt_update);
- return 0;
+ kfd_mem_dmaunmap_attachment(mem, entry);
}
-static int update_gpuvm_pte(struct amdgpu_device *adev,
- struct kfd_mem_attachment *entry,
- struct amdgpu_sync *sync)
+static int update_gpuvm_pte(struct kgd_mem *mem,
+ struct kfd_mem_attachment *entry,
+ struct amdgpu_sync *sync)
{
- int ret;
struct amdgpu_bo_va *bo_va = entry->bo_va;
+ struct amdgpu_device *adev = entry->adev;
+ int ret;
+
+ ret = kfd_mem_dmamap_attachment(mem, entry);
+ if (ret)
+ return ret;
/* Update the page tables */
ret = amdgpu_vm_bo_update(adev, bo_va, false);
@@ -997,14 +1003,15 @@ static int update_gpuvm_pte(struct amdgpu_device *adev,
return amdgpu_sync_fence(sync, bo_va->last_pt_update);
}
-static int map_bo_to_gpuvm(struct amdgpu_device *adev,
- struct kfd_mem_attachment *entry, struct amdgpu_sync *sync,
- bool no_update_pte)
+static int map_bo_to_gpuvm(struct kgd_mem *mem,
+ struct kfd_mem_attachment *entry,
+ struct amdgpu_sync *sync,
+ bool no_update_pte)
{
int ret;
/* Set virtual address for the allocation */
- ret = amdgpu_vm_bo_map(adev, entry->bo_va, entry->va, 0,
+ ret = amdgpu_vm_bo_map(entry->adev, entry->bo_va, entry->va, 0,
amdgpu_bo_size(entry->bo_va->base.bo),
entry->pte_flags);
if (ret) {
@@ -1016,7 +1023,7 @@ static int map_bo_to_gpuvm(struct amdgpu_device *adev,
if (no_update_pte)
return 0;
- ret = update_gpuvm_pte(adev, entry, sync);
+ ret = update_gpuvm_pte(mem, entry, sync);
if (ret) {
pr_err("update_gpuvm_pte() failed\n");
goto update_gpuvm_pte_failed;
@@ -1025,7 +1032,7 @@ static int map_bo_to_gpuvm(struct amdgpu_device *adev,
return 0;
update_gpuvm_pte_failed:
- unmap_bo_from_gpuvm(adev, entry, sync);
+ unmap_bo_from_gpuvm(mem, entry, sync);
return ret;
}
@@ -1633,7 +1640,7 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
pr_debug("\t map VA 0x%llx - 0x%llx in entry %p\n",
entry->va, entry->va + bo_size, entry);
- ret = map_bo_to_gpuvm(adev, entry, ctx.sync,
+ ret = map_bo_to_gpuvm(mem, entry, ctx.sync,
is_invalid_userptr);
if (ret) {
pr_err("Failed to map bo to gpuvm\n");
@@ -1672,7 +1679,6 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, void *vm)
{
- struct amdgpu_device *adev = get_amdgpu_device(kgd);
struct amdkfd_process_info *process_info =
((struct amdgpu_vm *)vm)->process_info;
unsigned long bo_size = mem->bo->tbo.base.size;
@@ -1707,13 +1713,8 @@ int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
pr_debug("\t unmap VA 0x%llx - 0x%llx from entry %p\n",
entry->va, entry->va + bo_size, entry);
- ret = unmap_bo_from_gpuvm(adev, entry, ctx.sync);
- if (ret == 0) {
- entry->is_mapped = false;
- } else {
- pr_err("failed to unmap VA 0x%llx\n", mem->va);
- goto unreserve_out;
- }
+ unmap_bo_from_gpuvm(mem,
[PATCH 1/9] drm/amdgpu: Rename kfd_bo_va_list to kfd_mem_attachment
This name is more fitting, especially for the changes coming next to
support multi-GPU systems with proper DMA mappings. Cleaned up the code
and renamed some related functions and variables to improve readability.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 8 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 209 +-
2 files changed, 104 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 14f68c028126..910c50956e16 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -38,10 +38,10 @@ extern uint64_t amdgpu_amdkfd_total_mem_size;
struct amdgpu_device;
-struct kfd_bo_va_list {
- struct list_head bo_list;
+struct kfd_mem_attachment {
+ struct list_head list;
struct amdgpu_bo_va *bo_va;
- void *kgd_dev;
+ struct amdgpu_device *adev;
bool is_mapped;
uint64_t va;
uint64_t pte_flags;
@@ -50,7 +50,7 @@ struct kfd_bo_va_list {
struct kgd_mem {
struct mutex lock;
struct amdgpu_bo *bo;
- struct list_head bo_va_list;
+ struct list_head attachments;
/* protected by amdkfd_process_info.lock */
struct ttm_validate_buffer validate_list;
struct ttm_validate_buffer resv_list;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 6622695a5eed..d021152314ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -75,16 +75,16 @@ static inline struct amdgpu_device
*get_amdgpu_device(struct kgd_dev *kgd)
return (struct amdgpu_device *)kgd;
}
-static bool check_if_add_bo_to_vm(struct amdgpu_vm *avm,
+static bool kfd_mem_is_attached(struct amdgpu_vm *avm,
struct kgd_mem *mem)
{
- struct kfd_bo_va_list *entry;
+ struct kfd_mem_attachment *entry;
- list_for_each_entry(entry, &mem->bo_va_list, bo_list)
+ list_for_each_entry(entry, &mem->attachments, list)
if (entry->bo_va->base.vm == avm)
- return false;
+ return true;
- return true;
+ return false;
}
/* Set memory usage limits. Current, limits are
@@ -471,7 +471,7 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
return pte_flags;
}
-/* add_bo_to_vm - Add a BO to a VM
+/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
* to a VM. It can later be mapped and unmapped many times without
@@ -483,15 +483,14 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
* 4. Alloc page tables and directories if needed
* 4a. Validate new page tables and directories
*/
-static int add_bo_to_vm(struct amdgpu_device *adev, struct kgd_mem *mem,
+static int kfd_mem_attach(struct amdgpu_device *adev, struct kgd_mem *mem,
struct amdgpu_vm *vm, bool is_aql,
- struct kfd_bo_va_list **p_bo_va_entry)
+ struct kfd_mem_attachment **p_attachment)
{
int ret;
- struct kfd_bo_va_list *bo_va_entry;
+ struct kfd_mem_attachment *attachment;
struct amdgpu_bo *bo = mem->bo;
uint64_t va = mem->va;
- struct list_head *list_bo_va = &mem->bo_va_list;
unsigned long bo_size = bo->tbo.base.size;
if (!va) {
@@ -502,29 +501,29 @@ static int add_bo_to_vm(struct amdgpu_device *adev,
struct kgd_mem *mem,
if (is_aql)
va += bo_size;
- bo_va_entry = kzalloc(sizeof(*bo_va_entry), GFP_KERNEL);
- if (!bo_va_entry)
+ attachment = kzalloc(sizeof(*attachment), GFP_KERNEL);
+ if (!attachment)
return -ENOMEM;
pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
va + bo_size, vm);
/* Add BO to VM internal data structures*/
- bo_va_entry->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
- if (!bo_va_entry->bo_va) {
+ attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
+ if (!attachment->bo_va) {
ret = -EINVAL;
pr_err("Failed to add BO object to VM. ret == %d\n",
ret);
goto err_vmadd;
}
- bo_va_entry->va = va;
- bo_va_entry->pte_flags = get_pte_flags(adev, mem);
- bo_va_entry->kgd_dev = (void *)adev;
- list_add(&bo_va_entry->bo_list, list_bo_va);
+ attachment->va = va;
+ attachment->pte_flags = get_pte_flags(adev, mem);
+ attachment->adev = adev;
+ list_add(&attachment->list, &mem->attachments);
- if (p_bo_va_entry)
- *p_bo_va_entry = bo_va_entry;
+ if (p_attachment)
+ *p_attachment = attachment;
/* Allocate validate pag
[PATCH 3/9] drm/amdgpu: Simplify AQL queue mapping
Do AQL queue double-mapping with a single attach call. That will make it
easier to create per-GPU BOs later, to be shared between the two BO VA
mappings on the same GPU.
Freeing the attachments is not necessary if map_to_gpu fails. These will be
cleaned up when the kdg_mem object is destroyed in
amdgpu_amdkfd_gpuvm_free_memory_of_gpu.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 103 --
1 file changed, 48 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 40a296ca37b9..114fbf508707 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -484,70 +484,76 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
* 4a. Validate new page tables and directories
*/
static int kfd_mem_attach(struct amdgpu_device *adev, struct kgd_mem *mem,
- struct amdgpu_vm *vm, bool is_aql,
- struct kfd_mem_attachment **p_attachment)
+ struct amdgpu_vm *vm, bool is_aql)
{
unsigned long bo_size = mem->bo->tbo.base.size;
uint64_t va = mem->va;
- struct kfd_mem_attachment *attachment;
- struct amdgpu_bo *bo;
- int ret;
+ struct kfd_mem_attachment *attachment[2] = {NULL, NULL};
+ struct amdgpu_bo *bo[2] = {NULL, NULL};
+ int i, ret;
if (!va) {
pr_err("Invalid VA when adding BO to VM\n");
return -EINVAL;
}
- if (is_aql)
- va += bo_size;
-
- attachment = kzalloc(sizeof(*attachment), GFP_KERNEL);
- if (!attachment)
- return -ENOMEM;
+ for (i = 0; i <= is_aql; i++) {
+ attachment[i] = kzalloc(sizeof(*attachment[i]), GFP_KERNEL);
+ if (unlikely(!attachment[i])) {
+ ret = -ENOMEM;
+ goto unwind;
+ }
- pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
- va + bo_size, vm);
+ pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
+va + bo_size, vm);
- /* FIXME: For now all attachments use the same BO. This is incorrect
-* because one BO can only have one DMA mapping for one GPU. We need
-* one BO per GPU, e.g. a DMABuf import with dynamic attachment. This
-* will be addressed one BO-type at a time in subsequent patches.
-*/
- bo = mem->bo;
- drm_gem_object_get(&bo->tbo.base);
+ /* FIXME: For now all attachments use the same BO. This is
+* incorrect because one BO can only have one DMA mapping
+* for one GPU. We need one BO per GPU, e.g. a DMABuf
+* import with dynamic attachment. This will be addressed
+* one BO-type at a time in subsequent patches.
+*/
+ bo[i] = mem->bo;
+ drm_gem_object_get(&bo[i]->tbo.base);
- /* Add BO to VM internal data structures*/
- attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
- if (!attachment->bo_va) {
- ret = -EINVAL;
- pr_err("Failed to add BO object to VM. ret == %d\n",
- ret);
- goto err_vmadd;
- }
+ /* Add BO to VM internal data structures */
+ attachment[i]->bo_va = amdgpu_vm_bo_add(adev, vm, bo[i]);
+ if (unlikely(!attachment[i]->bo_va)) {
+ ret = -ENOMEM;
+ pr_err("Failed to add BO object to VM. ret == %d\n",
+ ret);
+ goto unwind;
+ }
- attachment->va = va;
- attachment->pte_flags = get_pte_flags(adev, mem);
- attachment->adev = adev;
- list_add(&attachment->list, &mem->attachments);
+ attachment[i]->va = va;
+ attachment[i]->pte_flags = get_pte_flags(adev, mem);
+ attachment[i]->adev = adev;
+ list_add(&attachment[i]->list, &mem->attachments);
- if (p_attachment)
- *p_attachment = attachment;
+ va += bo_size;
+ }
/* Allocate validate page tables if needed */
ret = vm_validate_pt_pd_bos(vm);
if (unlikely(ret)) {
pr_err("validate_pt_pd_bos() failed\n");
- goto err_alloc_pts;
+ goto unwind;
}
return 0;
-err_alloc_pts:
- amdgpu_vm_bo_rmv(adev, attachment->bo_va);
- list_del(&attachment->list);
-err_vmadd:
- drm_gem_object_put(&bo->tbo.base);
- kfree(attachment);
+unwind:
+ for (; i >= 0; i--) {
+ if (!attachment[i])
+ continue;
+ if (attachment[i]->bo_va) {
+ amdgpu_vm_bo_rmv(adev,
[PATCH 2/9] drm/amdgpu: Keep a bo-reference per-attachment
For now they all reference the same BO. For correct DMA mappings they will
refer to different BOs per-GPU.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d021152314ad..40a296ca37b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -487,11 +487,11 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
struct amdgpu_vm *vm, bool is_aql,
struct kfd_mem_attachment **p_attachment)
{
- int ret;
- struct kfd_mem_attachment *attachment;
- struct amdgpu_bo *bo = mem->bo;
+ unsigned long bo_size = mem->bo->tbo.base.size;
uint64_t va = mem->va;
- unsigned long bo_size = bo->tbo.base.size;
+ struct kfd_mem_attachment *attachment;
+ struct amdgpu_bo *bo;
+ int ret;
if (!va) {
pr_err("Invalid VA when adding BO to VM\n");
@@ -508,6 +508,14 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
va + bo_size, vm);
+ /* FIXME: For now all attachments use the same BO. This is incorrect
+* because one BO can only have one DMA mapping for one GPU. We need
+* one BO per GPU, e.g. a DMABuf import with dynamic attachment. This
+* will be addressed one BO-type at a time in subsequent patches.
+*/
+ bo = mem->bo;
+ drm_gem_object_get(&bo->tbo.base);
+
/* Add BO to VM internal data structures*/
attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
if (!attachment->bo_va) {
@@ -527,7 +535,7 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
/* Allocate validate page tables if needed */
ret = vm_validate_pt_pd_bos(vm);
- if (ret) {
+ if (unlikely(ret)) {
pr_err("validate_pt_pd_bos() failed\n");
goto err_alloc_pts;
}
@@ -538,15 +546,19 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
amdgpu_vm_bo_rmv(adev, attachment->bo_va);
list_del(&attachment->list);
err_vmadd:
+ drm_gem_object_put(&bo->tbo.base);
kfree(attachment);
return ret;
}
static void kfd_mem_detach(struct kfd_mem_attachment *attachment)
{
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
pr_debug("\t remove VA 0x%llx in entry %p\n",
attachment->va, attachment);
amdgpu_vm_bo_rmv(attachment->adev, attachment->bo_va);
+ drm_gem_object_put(&bo->tbo.base);
list_del(&attachment->list);
kfree(attachment);
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] Implement multi-GPU DMA mappings for KFD
This patch series fixes DMA-mappings of system memory (GTT and userptr) for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per GPU is needed to maintain the DMA mappings of each BO. I ran into some reservation issues when unmapping or freeing DMA-buf imports. There are a few FIXME comments in this patch series where I'm hoping for some expert advice. Patches 8 and 9 are some related fixes in TTM and amdgpu_ttm. I'm pretty sure patch 9 is not the right way to do this. Felix Kuehling (9): drm/amdgpu: Rename kfd_bo_va_list to kfd_mem_attachment drm/amdgpu: Keep a bo-reference per-attachment drm/amdgpu: Simplify AQL queue mapping drm/amdgpu: Add multi-GPU DMA mapping helpers drm/amdgpu: DMA map/unmap when updating GPU mappings drm/amdgpu: Move kfd_mem_attach outside reservation drm/amdgpu: Add DMA mapping of GTT BOs drm/ttm: Don't count pages in SG BOs against pages_limit drm/amdgpu: Lock the attached dmabuf in unpopulate drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 18 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 535 -- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 + drivers/gpu/drm/ttm/ttm_tt.c | 27 +- 4 files changed, 420 insertions(+), 173 deletions(-) -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm/amdgpu: Add DMA mapping of GTT BOs
Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 74 ++-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index fc3514ed1b74..3ea51982b720 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -41,6 +41,7 @@ struct amdgpu_device;
enum kfd_mem_attachment_type {
KFD_MEM_ATT_SHARED, /* Share kgd_mem->bo or another attachment's */
KFD_MEM_ATT_USERPTR,/* SG bo to DMA map pages from a userptr bo */
+ KFD_MEM_ATT_DMABUF, /* DMAbuf to DMA map TTM BOs */
};
struct kfd_mem_attachment {
@@ -56,6 +57,7 @@ struct kfd_mem_attachment {
struct kgd_mem {
struct mutex lock;
struct amdgpu_bo *bo;
+ struct dma_buf *dmabuf;
struct list_head attachments;
/* protected by amdkfd_process_info.lock */
struct ttm_validate_buffer validate_list;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 1416f3c03f1d..bb3a96ab8f20 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -522,6 +522,16 @@ kfd_mem_dmamap_userptr(struct kgd_mem *mem,
return ret;
}
+static int
+kfd_mem_dmamap_dmabuf(struct kfd_mem_attachment *attachment)
+{
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ return ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+}
+
static int
kfd_mem_dmamap_attachment(struct kgd_mem *mem,
struct kfd_mem_attachment *attachment)
@@ -531,6 +541,8 @@ kfd_mem_dmamap_attachment(struct kgd_mem *mem,
return 0;
case KFD_MEM_ATT_USERPTR:
return kfd_mem_dmamap_userptr(mem, attachment);
+ case KFD_MEM_ATT_DMABUF:
+ return kfd_mem_dmamap_dmabuf(attachment);
default:
WARN_ON_ONCE(1);
}
@@ -560,6 +572,19 @@ kfd_mem_dmaunmap_userptr(struct kgd_mem *mem,
ttm->sg = NULL;
}
+static void
+kfd_mem_dmaunmap_dmabuf(struct kfd_mem_attachment *attachment)
+{
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
+ ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+ /* FIXME: This does not guarantee that amdgpu_ttm_tt_unpopulate is
+* called
+*/
+}
+
static void
kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
struct kfd_mem_attachment *attachment)
@@ -570,6 +595,9 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
case KFD_MEM_ATT_USERPTR:
kfd_mem_dmaunmap_userptr(mem, attachment);
break;
+ case KFD_MEM_ATT_DMABUF:
+ kfd_mem_dmaunmap_dmabuf(attachment);
+ break;
default:
WARN_ON_ONCE(1);
}
@@ -601,6 +629,36 @@ kfd_mem_attach_userptr(struct amdgpu_device *adev, struct
kgd_mem *mem,
return 0;
}
+static int
+kfd_mem_attach_dmabuf(struct amdgpu_device *adev, struct kgd_mem *mem,
+ struct amdgpu_bo **bo)
+{
+ struct drm_gem_object *gobj;
+
+ if (!mem->dmabuf) {
+ mem->dmabuf = amdgpu_gem_prime_export(&mem->bo->tbo.base,
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DRM_RDWR : 0);
+ if (IS_ERR(mem->dmabuf)) {
+ mem->dmabuf = NULL;
+ return PTR_ERR(mem->dmabuf);
+ }
+ }
+
+ gobj = amdgpu_gem_prime_import(&adev->ddev, mem->dmabuf);
+ if (IS_ERR(gobj))
+ return PTR_ERR(gobj);
+
+ /* Import takes an extra reference on the dmabuf. Drop it now to
+* avoid leaking it. We only need the one reference in
+* kgd_mem->dmabuf.
+*/
+ dma_buf_put(mem->dmabuf);
+
+ *bo = gem_to_amdgpu_bo(gobj);
+ return 0;
+}
+
/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
@@ -658,8 +716,20 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
ret = kfd_mem_attach_userptr(adev, mem, &bo[i]);
if (ret)
goto unwind;
+ } else if (mem->domain == AMDGPU_GEM_DOMAIN_GTT &&
+ mem->bo->tbo.type != ttm_bo_type_sg) {
+ /* GTT BOs use DMA-mapping ability of dynamic-attach
+
[PATCH 9/9] drm/amdgpu: Lock the attached dmabuf in unpopulate
amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The dmabuf->resv
must not be held by the caller or dma_buf_detach will deadlock. This is
probably not the right fix. I get a recursive lock warning with the
reservation held in ttm_bo_release. Should unmap_attachment move to
backend_unbind instead?
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 936b3cfdde55..257750921eed 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1216,9 +1216,22 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device
*bdev,
if (ttm->sg && gtt->gobj->import_attach) {
struct dma_buf_attachment *attach;
+ bool locked;
attach = gtt->gobj->import_attach;
+ /* FIXME: unpopulate can be called during bo_destroy.
+* The dmabuf->resv must not be held by the caller or
+* dma_buf_detach will deadlock. This is probably not
+* the right fix. I get a recursive lock warning with the
+* reservation held in ttm_bo_releas.. Should
+* unmap_attachment move to backend_unbind instead?
+*/
+ locked = dma_resv_is_locked(attach->dmabuf->resv);
+ if (!locked)
+ dma_resv_lock(attach->dmabuf->resv, NULL);
dma_buf_unmap_attachment(attach, ttm->sg, DMA_BIDIRECTIONAL);
+ if (!locked)
+ dma_resv_unlock(attach->dmabuf->resv);
ttm->sg = NULL;
return;
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5d8820725b75..e8b8c3257392 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
- atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
atomic_long_read(&ttm_dma32_pages_allocated) >
@@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
return 0;
error:
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_tt_populate);
@@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
ttm_tt *ttm)
else
ttm_pool_free(&bdev->pool, ttm);
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/amdgpu: Move kfd_mem_attach outside reservation
This is needed to avoid deadlocks with DMA buf import in the next patch.
Also move PT/PD validation out of kfd_mem_attach, that way the caller
can bo this unconditionally.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 72 +++
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 3bb2ae185bbb..1416f3c03f1d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -575,6 +575,32 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
}
}
+static int
+kfd_mem_attach_userptr(struct amdgpu_device *adev, struct kgd_mem *mem,
+ struct amdgpu_bo **bo)
+{
+ unsigned long bo_size = mem->bo->tbo.base.size;
+ struct drm_gem_object *gobj;
+ int ret;
+
+ ret = amdgpu_bo_reserve(mem->bo, false);
+ if (ret)
+ return ret;
+
+ ret = amdgpu_gem_object_create(adev, bo_size, 1,
+ AMDGPU_GEM_DOMAIN_CPU,
+ 0, ttm_bo_type_sg,
+ mem->bo->tbo.base.resv,
+ &gobj);
+ if (ret)
+ return ret;
+
+ amdgpu_bo_unreserve(mem->bo);
+
+ *bo = gem_to_amdgpu_bo(gobj);
+ return 0;
+}
+
/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
@@ -596,7 +622,6 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
uint64_t va = mem->va;
struct kfd_mem_attachment *attachment[2] = {NULL, NULL};
struct amdgpu_bo *bo[2] = {NULL, NULL};
- struct drm_gem_object *gobj;
int i, ret;
if (!va) {
@@ -630,14 +655,9 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
} else if (amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm)) {
/* Create an SG BO to DMA-map userptrs on other GPUs */
attachment[i]->type = KFD_MEM_ATT_USERPTR;
- ret = amdgpu_gem_object_create(adev, bo_size, 1,
- AMDGPU_GEM_DOMAIN_CPU,
- 0, ttm_bo_type_sg,
- mem->bo->tbo.base.resv,
- &gobj);
+ ret = kfd_mem_attach_userptr(adev, mem, &bo[i]);
if (ret)
goto unwind;
- bo[i] = gem_to_amdgpu_bo(gobj);
} else {
/* FIXME: Need to DMA-map other BO types */
attachment[i]->type = KFD_MEM_ATT_SHARED;
@@ -662,13 +682,6 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
va += bo_size;
}
- /* Allocate validate page tables if needed */
- ret = vm_validate_pt_pd_bos(vm);
- if (unlikely(ret)) {
- pr_err("validate_pt_pd_bos() failed\n");
- goto unwind;
- }
-
return 0;
unwind:
@@ -1516,12 +1529,12 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
pr_debug("Release VA 0x%llx - 0x%llx\n", mem->va,
mem->va + bo_size * (1 + mem->aql_queue));
+ ret = unreserve_bo_and_vms(&ctx, false, false);
+
/* Remove from VM internal data structures */
list_for_each_entry_safe(entry, tmp, &mem->attachments, list)
kfd_mem_detach(mem, entry);
- ret = unreserve_bo_and_vms(&ctx, false, false);
-
/* Free the sync object */
amdgpu_sync_free(&mem->sync);
@@ -1597,6 +1610,12 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
mem->va + bo_size * (1 + mem->aql_queue),
vm, domain_string(domain));
+ if (!kfd_mem_is_attached(avm, mem)) {
+ ret = kfd_mem_attach(adev, mem, avm, mem->aql_queue);
+ if (ret)
+ goto out;
+ }
+
ret = reserve_bo_and_vm(mem, vm, &ctx);
if (unlikely(ret))
goto out;
@@ -1610,15 +1629,9 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
is_invalid_userptr = true;
- if (!kfd_mem_is_attached(avm, mem)) {
- ret = kfd_mem_attach(adev, mem, avm, mem->aql_queue);
- if (ret)
- goto attach_failed;
- } else {
- ret = vm_validate_pt_pd_bos(avm);
- if (unlikely(ret))
- goto attach_failed;
- }
+ ret = vm_validate_pt_pd_bos(avm);
+ if (unlikely(ret))
+ goto out_unreserve;
if (mem->mapped_to_gpu_memor
[PATCH 4/9] drm/amdgpu: Add multi-GPU DMA mapping helpers
Add BO-type specific helpers functions to DMA-map and unmap
kfd_mem_attachments. Implement this functionality for userptrs by creating
one SG BO per GPU and filling it with a DMA mapping of the pages from the
original mem->bo.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 8 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 155 --
2 files changed, 152 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 910c50956e16..fc3514ed1b74 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -38,11 +38,17 @@ extern uint64_t amdgpu_amdkfd_total_mem_size;
struct amdgpu_device;
+enum kfd_mem_attachment_type {
+ KFD_MEM_ATT_SHARED, /* Share kgd_mem->bo or another attachment's */
+ KFD_MEM_ATT_USERPTR,/* SG bo to DMA map pages from a userptr bo */
+};
+
struct kfd_mem_attachment {
struct list_head list;
+ enum kfd_mem_attachment_type type;
+ bool is_mapped;
struct amdgpu_bo_va *bo_va;
struct amdgpu_device *adev;
- bool is_mapped;
uint64_t va;
uint64_t pte_flags;
};
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 114fbf508707..51502a07fc1d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -471,12 +471,117 @@ static uint64_t get_pte_flags(struct amdgpu_device
*adev, struct kgd_mem *mem)
return pte_flags;
}
+static int
+kfd_mem_dmamap_userptr(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ enum dma_data_direction direction =
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+ struct amdgpu_device *adev = attachment->adev;
+ struct ttm_tt *src_ttm = mem->bo->tbo.ttm;
+ struct ttm_tt *ttm = bo->tbo.ttm;
+ int ret;
+
+ ttm->sg = kmalloc(sizeof(*ttm->sg), GFP_KERNEL);
+ if (unlikely(!ttm->sg))
+ return -ENOMEM;
+
+ if (WARN_ON(ttm->num_pages != src_ttm->num_pages))
+ return -EINVAL;
+
+ /* Same sequence as in amdgpu_ttm_tt_pin_userptr */
+ ret = sg_alloc_table_from_pages(ttm->sg, src_ttm->pages,
+ ttm->num_pages, 0,
+ (u64)ttm->num_pages << PAGE_SHIFT,
+ GFP_KERNEL);
+ if (unlikely(ret))
+ goto release_sg;
+
+ ret = dma_map_sgtable(adev->dev, ttm->sg, direction, 0);
+ if (unlikely(ret))
+ goto release_sg;
+
+ drm_prime_sg_to_dma_addr_array(ttm->sg, ttm->dma_address,
+ ttm->num_pages);
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ ret = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+ if (ret)
+ goto release_sg;
+
+ return 0;
+
+release_sg:
+ pr_err("DMA map userptr failed: %d\n", ret);
+ sg_free_table(ttm->sg);
+ kfree(ttm->sg);
+ ttm->sg = NULL;
+ return ret;
+}
+
+static int
+kfd_mem_dmamap_attachment(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ switch (attachment->type) {
+ case KFD_MEM_ATT_SHARED:
+ return 0;
+ case KFD_MEM_ATT_USERPTR:
+ return kfd_mem_dmamap_userptr(mem, attachment);
+ default:
+ WARN_ON_ONCE(1);
+ }
+ return -EINVAL;
+}
+
+static void
+kfd_mem_dmaunmap_userptr(struct kgd_mem *mem,
+struct kfd_mem_attachment *attachment)
+{
+ enum dma_data_direction direction =
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
+ struct ttm_operation_ctx ctx = {.interruptible = false};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+ struct amdgpu_device *adev = attachment->adev;
+ struct ttm_tt *ttm = bo->tbo.ttm;
+
+ if (unlikely(!ttm->sg))
+ return;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
+ ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+
+ dma_unmap_sgtable(adev->dev, ttm->sg, direction, 0);
+ sg_free_table(ttm->sg);
+ ttm->sg = NULL;
+}
+
+static void
+kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ switch (attachment->type) {
+ case KFD_MEM_ATT_SHARED:
+ break;
+ case KFD_MEM_ATT_USERPTR:
+ kfd_mem_dmaunmap_userptr(mem, attachment);
+
[PATCH 5/9] drm/amdgpu: DMA map/unmap when updating GPU mappings
DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
with the BO and page tables reserved, so we can safely update the DMA
mapping.
DMA unmap when a BO is unmapped from a GPU and before updating mappings
in restore workers.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 56 ++-
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 51502a07fc1d..3bb2ae185bbb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -964,11 +964,12 @@ static int unreserve_bo_and_vms(struct
bo_vm_reservation_context *ctx,
return ret;
}
-static int unmap_bo_from_gpuvm(struct amdgpu_device *adev,
+static void unmap_bo_from_gpuvm(struct kgd_mem *mem,
struct kfd_mem_attachment *entry,
struct amdgpu_sync *sync)
{
struct amdgpu_bo_va *bo_va = entry->bo_va;
+ struct amdgpu_device *adev = entry->adev;
struct amdgpu_vm *vm = bo_va->base.vm;
amdgpu_vm_bo_unmap(adev, bo_va, entry->va);
@@ -977,15 +978,20 @@ static int unmap_bo_from_gpuvm(struct amdgpu_device *adev,
amdgpu_sync_fence(sync, bo_va->last_pt_update);
- return 0;
+ kfd_mem_dmaunmap_attachment(mem, entry);
}
-static int update_gpuvm_pte(struct amdgpu_device *adev,
- struct kfd_mem_attachment *entry,
- struct amdgpu_sync *sync)
+static int update_gpuvm_pte(struct kgd_mem *mem,
+ struct kfd_mem_attachment *entry,
+ struct amdgpu_sync *sync)
{
- int ret;
struct amdgpu_bo_va *bo_va = entry->bo_va;
+ struct amdgpu_device *adev = entry->adev;
+ int ret;
+
+ ret = kfd_mem_dmamap_attachment(mem, entry);
+ if (ret)
+ return ret;
/* Update the page tables */
ret = amdgpu_vm_bo_update(adev, bo_va, false);
@@ -997,14 +1003,15 @@ static int update_gpuvm_pte(struct amdgpu_device *adev,
return amdgpu_sync_fence(sync, bo_va->last_pt_update);
}
-static int map_bo_to_gpuvm(struct amdgpu_device *adev,
- struct kfd_mem_attachment *entry, struct amdgpu_sync *sync,
- bool no_update_pte)
+static int map_bo_to_gpuvm(struct kgd_mem *mem,
+ struct kfd_mem_attachment *entry,
+ struct amdgpu_sync *sync,
+ bool no_update_pte)
{
int ret;
/* Set virtual address for the allocation */
- ret = amdgpu_vm_bo_map(adev, entry->bo_va, entry->va, 0,
+ ret = amdgpu_vm_bo_map(entry->adev, entry->bo_va, entry->va, 0,
amdgpu_bo_size(entry->bo_va->base.bo),
entry->pte_flags);
if (ret) {
@@ -1016,7 +1023,7 @@ static int map_bo_to_gpuvm(struct amdgpu_device *adev,
if (no_update_pte)
return 0;
- ret = update_gpuvm_pte(adev, entry, sync);
+ ret = update_gpuvm_pte(mem, entry, sync);
if (ret) {
pr_err("update_gpuvm_pte() failed\n");
goto update_gpuvm_pte_failed;
@@ -1025,7 +1032,7 @@ static int map_bo_to_gpuvm(struct amdgpu_device *adev,
return 0;
update_gpuvm_pte_failed:
- unmap_bo_from_gpuvm(adev, entry, sync);
+ unmap_bo_from_gpuvm(mem, entry, sync);
return ret;
}
@@ -1633,7 +1640,7 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
pr_debug("\t map VA 0x%llx - 0x%llx in entry %p\n",
entry->va, entry->va + bo_size, entry);
- ret = map_bo_to_gpuvm(adev, entry, ctx.sync,
+ ret = map_bo_to_gpuvm(mem, entry, ctx.sync,
is_invalid_userptr);
if (ret) {
pr_err("Failed to map bo to gpuvm\n");
@@ -1672,7 +1679,6 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, void *vm)
{
- struct amdgpu_device *adev = get_amdgpu_device(kgd);
struct amdkfd_process_info *process_info =
((struct amdgpu_vm *)vm)->process_info;
unsigned long bo_size = mem->bo->tbo.base.size;
@@ -1707,13 +1713,8 @@ int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
pr_debug("\t unmap VA 0x%llx - 0x%llx from entry %p\n",
entry->va, entry->va + bo_size, entry);
- ret = unmap_bo_from_gpuvm(adev, entry, ctx.sync);
- if (ret == 0) {
- entry->is_mapped = false;
- } else {
- pr_err("failed to unmap VA 0x%llx\n", mem->va);
- goto unreserve_out;
- }
+ unmap_bo_from_gpuvm(mem,
[PATCH 3/9] drm/amdgpu: Simplify AQL queue mapping
Do AQL queue double-mapping with a single attach call. That will make it
easier to create per-GPU BOs later, to be shared between the two BO VA
mappings on the same GPU.
Freeing the attachments is not necessary if map_to_gpu fails. These will be
cleaned up when the kdg_mem object is destroyed in
amdgpu_amdkfd_gpuvm_free_memory_of_gpu.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 103 --
1 file changed, 48 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 40a296ca37b9..114fbf508707 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -484,70 +484,76 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
* 4a. Validate new page tables and directories
*/
static int kfd_mem_attach(struct amdgpu_device *adev, struct kgd_mem *mem,
- struct amdgpu_vm *vm, bool is_aql,
- struct kfd_mem_attachment **p_attachment)
+ struct amdgpu_vm *vm, bool is_aql)
{
unsigned long bo_size = mem->bo->tbo.base.size;
uint64_t va = mem->va;
- struct kfd_mem_attachment *attachment;
- struct amdgpu_bo *bo;
- int ret;
+ struct kfd_mem_attachment *attachment[2] = {NULL, NULL};
+ struct amdgpu_bo *bo[2] = {NULL, NULL};
+ int i, ret;
if (!va) {
pr_err("Invalid VA when adding BO to VM\n");
return -EINVAL;
}
- if (is_aql)
- va += bo_size;
-
- attachment = kzalloc(sizeof(*attachment), GFP_KERNEL);
- if (!attachment)
- return -ENOMEM;
+ for (i = 0; i <= is_aql; i++) {
+ attachment[i] = kzalloc(sizeof(*attachment[i]), GFP_KERNEL);
+ if (unlikely(!attachment[i])) {
+ ret = -ENOMEM;
+ goto unwind;
+ }
- pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
- va + bo_size, vm);
+ pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
+va + bo_size, vm);
- /* FIXME: For now all attachments use the same BO. This is incorrect
-* because one BO can only have one DMA mapping for one GPU. We need
-* one BO per GPU, e.g. a DMABuf import with dynamic attachment. This
-* will be addressed one BO-type at a time in subsequent patches.
-*/
- bo = mem->bo;
- drm_gem_object_get(&bo->tbo.base);
+ /* FIXME: For now all attachments use the same BO. This is
+* incorrect because one BO can only have one DMA mapping
+* for one GPU. We need one BO per GPU, e.g. a DMABuf
+* import with dynamic attachment. This will be addressed
+* one BO-type at a time in subsequent patches.
+*/
+ bo[i] = mem->bo;
+ drm_gem_object_get(&bo[i]->tbo.base);
- /* Add BO to VM internal data structures*/
- attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
- if (!attachment->bo_va) {
- ret = -EINVAL;
- pr_err("Failed to add BO object to VM. ret == %d\n",
- ret);
- goto err_vmadd;
- }
+ /* Add BO to VM internal data structures */
+ attachment[i]->bo_va = amdgpu_vm_bo_add(adev, vm, bo[i]);
+ if (unlikely(!attachment[i]->bo_va)) {
+ ret = -ENOMEM;
+ pr_err("Failed to add BO object to VM. ret == %d\n",
+ ret);
+ goto unwind;
+ }
- attachment->va = va;
- attachment->pte_flags = get_pte_flags(adev, mem);
- attachment->adev = adev;
- list_add(&attachment->list, &mem->attachments);
+ attachment[i]->va = va;
+ attachment[i]->pte_flags = get_pte_flags(adev, mem);
+ attachment[i]->adev = adev;
+ list_add(&attachment[i]->list, &mem->attachments);
- if (p_attachment)
- *p_attachment = attachment;
+ va += bo_size;
+ }
/* Allocate validate page tables if needed */
ret = vm_validate_pt_pd_bos(vm);
if (unlikely(ret)) {
pr_err("validate_pt_pd_bos() failed\n");
- goto err_alloc_pts;
+ goto unwind;
}
return 0;
-err_alloc_pts:
- amdgpu_vm_bo_rmv(adev, attachment->bo_va);
- list_del(&attachment->list);
-err_vmadd:
- drm_gem_object_put(&bo->tbo.base);
- kfree(attachment);
+unwind:
+ for (; i >= 0; i--) {
+ if (!attachment[i])
+ continue;
+ if (attachment[i]->bo_va) {
+ amdgpu_vm_bo_rmv(adev,
[PATCH 0/9] Implement multi-GPU DMA mappings for KFD
This patch series fixes DMA-mappings of system memory (GTT and userptr) for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per GPU is needed to maintain the DMA mappings of each BO. I ran into some reservation issues when unmapping or freeing DMA-buf imports. There are a few FIXME comments in this patch series where I'm hoping for some expert advice. Patches 8 and 9 are some related fixes in TTM and amdgpu_ttm. I'm pretty sure patch 9 is not the right way to do this. Felix Kuehling (9): drm/amdgpu: Rename kfd_bo_va_list to kfd_mem_attachment drm/amdgpu: Keep a bo-reference per-attachment drm/amdgpu: Simplify AQL queue mapping drm/amdgpu: Add multi-GPU DMA mapping helpers drm/amdgpu: DMA map/unmap when updating GPU mappings drm/amdgpu: Move kfd_mem_attach outside reservation drm/amdgpu: Add DMA mapping of GTT BOs drm/ttm: Don't count pages in SG BOs against pages_limit drm/amdgpu: Lock the attached dmabuf in unpopulate drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 18 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 535 -- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 + drivers/gpu/drm/ttm/ttm_tt.c | 27 +- 4 files changed, 420 insertions(+), 173 deletions(-) -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/amdgpu: Keep a bo-reference per-attachment
For now they all reference the same BO. For correct DMA mappings they will
refer to different BOs per-GPU.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d021152314ad..40a296ca37b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -487,11 +487,11 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
struct amdgpu_vm *vm, bool is_aql,
struct kfd_mem_attachment **p_attachment)
{
- int ret;
- struct kfd_mem_attachment *attachment;
- struct amdgpu_bo *bo = mem->bo;
+ unsigned long bo_size = mem->bo->tbo.base.size;
uint64_t va = mem->va;
- unsigned long bo_size = bo->tbo.base.size;
+ struct kfd_mem_attachment *attachment;
+ struct amdgpu_bo *bo;
+ int ret;
if (!va) {
pr_err("Invalid VA when adding BO to VM\n");
@@ -508,6 +508,14 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
va + bo_size, vm);
+ /* FIXME: For now all attachments use the same BO. This is incorrect
+* because one BO can only have one DMA mapping for one GPU. We need
+* one BO per GPU, e.g. a DMABuf import with dynamic attachment. This
+* will be addressed one BO-type at a time in subsequent patches.
+*/
+ bo = mem->bo;
+ drm_gem_object_get(&bo->tbo.base);
+
/* Add BO to VM internal data structures*/
attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
if (!attachment->bo_va) {
@@ -527,7 +535,7 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
/* Allocate validate page tables if needed */
ret = vm_validate_pt_pd_bos(vm);
- if (ret) {
+ if (unlikely(ret)) {
pr_err("validate_pt_pd_bos() failed\n");
goto err_alloc_pts;
}
@@ -538,15 +546,19 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
amdgpu_vm_bo_rmv(adev, attachment->bo_va);
list_del(&attachment->list);
err_vmadd:
+ drm_gem_object_put(&bo->tbo.base);
kfree(attachment);
return ret;
}
static void kfd_mem_detach(struct kfd_mem_attachment *attachment)
{
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
pr_debug("\t remove VA 0x%llx in entry %p\n",
attachment->va, attachment);
amdgpu_vm_bo_rmv(attachment->adev, attachment->bo_va);
+ drm_gem_object_put(&bo->tbo.base);
list_del(&attachment->list);
kfree(attachment);
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/amdgpu: Rename kfd_bo_va_list to kfd_mem_attachment
This name is more fitting, especially for the changes coming next to
support multi-GPU systems with proper DMA mappings. Cleaned up the code
and renamed some related functions and variables to improve readability.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 8 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 209 +-
2 files changed, 104 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 14f68c028126..910c50956e16 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -38,10 +38,10 @@ extern uint64_t amdgpu_amdkfd_total_mem_size;
struct amdgpu_device;
-struct kfd_bo_va_list {
- struct list_head bo_list;
+struct kfd_mem_attachment {
+ struct list_head list;
struct amdgpu_bo_va *bo_va;
- void *kgd_dev;
+ struct amdgpu_device *adev;
bool is_mapped;
uint64_t va;
uint64_t pte_flags;
@@ -50,7 +50,7 @@ struct kfd_bo_va_list {
struct kgd_mem {
struct mutex lock;
struct amdgpu_bo *bo;
- struct list_head bo_va_list;
+ struct list_head attachments;
/* protected by amdkfd_process_info.lock */
struct ttm_validate_buffer validate_list;
struct ttm_validate_buffer resv_list;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 6622695a5eed..d021152314ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -75,16 +75,16 @@ static inline struct amdgpu_device
*get_amdgpu_device(struct kgd_dev *kgd)
return (struct amdgpu_device *)kgd;
}
-static bool check_if_add_bo_to_vm(struct amdgpu_vm *avm,
+static bool kfd_mem_is_attached(struct amdgpu_vm *avm,
struct kgd_mem *mem)
{
- struct kfd_bo_va_list *entry;
+ struct kfd_mem_attachment *entry;
- list_for_each_entry(entry, &mem->bo_va_list, bo_list)
+ list_for_each_entry(entry, &mem->attachments, list)
if (entry->bo_va->base.vm == avm)
- return false;
+ return true;
- return true;
+ return false;
}
/* Set memory usage limits. Current, limits are
@@ -471,7 +471,7 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
return pte_flags;
}
-/* add_bo_to_vm - Add a BO to a VM
+/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
* to a VM. It can later be mapped and unmapped many times without
@@ -483,15 +483,14 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
* 4. Alloc page tables and directories if needed
* 4a. Validate new page tables and directories
*/
-static int add_bo_to_vm(struct amdgpu_device *adev, struct kgd_mem *mem,
+static int kfd_mem_attach(struct amdgpu_device *adev, struct kgd_mem *mem,
struct amdgpu_vm *vm, bool is_aql,
- struct kfd_bo_va_list **p_bo_va_entry)
+ struct kfd_mem_attachment **p_attachment)
{
int ret;
- struct kfd_bo_va_list *bo_va_entry;
+ struct kfd_mem_attachment *attachment;
struct amdgpu_bo *bo = mem->bo;
uint64_t va = mem->va;
- struct list_head *list_bo_va = &mem->bo_va_list;
unsigned long bo_size = bo->tbo.base.size;
if (!va) {
@@ -502,29 +501,29 @@ static int add_bo_to_vm(struct amdgpu_device *adev,
struct kgd_mem *mem,
if (is_aql)
va += bo_size;
- bo_va_entry = kzalloc(sizeof(*bo_va_entry), GFP_KERNEL);
- if (!bo_va_entry)
+ attachment = kzalloc(sizeof(*attachment), GFP_KERNEL);
+ if (!attachment)
return -ENOMEM;
pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
va + bo_size, vm);
/* Add BO to VM internal data structures*/
- bo_va_entry->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
- if (!bo_va_entry->bo_va) {
+ attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
+ if (!attachment->bo_va) {
ret = -EINVAL;
pr_err("Failed to add BO object to VM. ret == %d\n",
ret);
goto err_vmadd;
}
- bo_va_entry->va = va;
- bo_va_entry->pte_flags = get_pte_flags(adev, mem);
- bo_va_entry->kgd_dev = (void *)adev;
- list_add(&bo_va_entry->bo_list, list_bo_va);
+ attachment->va = va;
+ attachment->pte_flags = get_pte_flags(adev, mem);
+ attachment->adev = adev;
+ list_add(&attachment->list, &mem->attachments);
- if (p_bo_va_entry)
- *p_bo_va_entry = bo_va_entry;
+ if (p_attachment)
+ *p_attachment = attachment;
/* Allocate validate pag
Re: [PATCH 3/4] drm/amdkfd: Allow access for mmapping KFD BOs
Am 08.04.21 um 01:12 schrieb Felix Kuehling:
DRM allows access automatically when it creates a GEM handle for a BO.
KFD BOs don't have GEM handles, so KFD needs to manage access manually.
Ok, double checking the code that makes sense.
Signed-off-by: Felix Kuehling
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 19 ++-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 8 +---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 7 ---
4 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 0d59bebd92af..7c8c5e469707 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -245,7 +245,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
void *drm_priv, struct kgd_mem **mem,
uint64_t *offset, uint32_t flags);
int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size);
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
+ uint64_t *size);
int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 95442bcd60fb..e7d61ec966b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1232,6 +1232,12 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
domain_string(alloc_domain), ret);
goto err_bo_create;
}
+ ret = drm_vma_node_allow(&gobj->vma_node, drm_priv);
+ if (ret) {
+ pr_debug("Failed to allow vma node access. ret %d\n",
+ret);
+ goto err_node_allow;
+ }
bo = gem_to_amdgpu_bo(gobj);
if (bo_type == ttm_bo_type_sg) {
bo->tbo.sg = sg;
@@ -1261,6 +1267,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
allocate_init_user_pages_failed:
remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
+ drm_vma_node_revoke(&gobj->vma_node, drm_priv);
+err_node_allow:
amdgpu_bo_unref(&bo);
/* Don't unreserve system mem limit twice */
goto err_reserve_limit;
@@ -1278,7 +1286,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
}
int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size)
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
+ uint64_t *size)
{
struct amdkfd_process_info *process_info = mem->process_info;
unsigned long bo_size = mem->bo->tbo.base.size;
@@ -1355,6 +1364,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
}
/* Free the BO*/
+ drm_vma_node_revoke(&mem->bo->tbo.base.vma_node, drm_priv);
drm_gem_object_put(&mem->bo->tbo.base);
mutex_destroy(&mem->lock);
kfree(mem);
@@ -1666,6 +1676,7 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
struct drm_gem_object *obj;
struct amdgpu_bo *bo;
+ int ret;
if (dma_buf->ops != &amdgpu_dmabuf_ops)
/* Can't handle non-graphics buffers */
@@ -1686,6 +1697,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev
*kgd,
if (!*mem)
return -ENOMEM;
+ ret = drm_vma_node_allow(&obj->vma_node, drm_priv);
+ if (ret) {
+ kfree(mem);
+ return ret;
+ }
+
if (size)
*size = amdgpu_bo_size(bo);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 43de260b2230..8fc18de7cff4 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1328,7 +1328,8 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file
*filep,
return 0;
err_free:
- amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem,
NULL);
+ amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem,
+ pdd->vm, NULL);
err_unlock:
mutex_unlock(&p->mutex);
return err;
@@ -1365,7 +1366,7 @@ static int kfd_ioctl_free_memory_of_gpu(struct file
*filep,
}
ret = amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd,
- (struct kgd_mem *)mem, &size);
+ (struct kgd_mem *)mem, pdd->vm, &size);
/* If freeing the buffer failed, leave the handle in place for
* clean-up during process tear
Re: [PATCH] drm/i915: Fix "mitigations" parsing if i915 is builtin
Hi Ville,
On Tue, 13 Apr 2021 19:59:34 +0300 Ville Syrjälä wrote:
>
>
> On Tue, Apr 13, 2021 at 05:02:40PM +0800, Jisheng Zhang wrote:
> > I met below error during boot with i915 builtin if pass
> > "i915.mitigations=off":
> > [0.015589] Booting kernel: `off' invalid for parameter
> > `i915.mitigations'
> >
> > The reason is slab subsystem isn't ready at that time, so kstrdup()
> > returns NULL. Fix this issue by using stack var instead of kstrdup().
> >
> > Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
> > mitigations")
> > Signed-off-by: Jisheng Zhang
> > ---
> > drivers/gpu/drm/i915/i915_mitigations.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
> > b/drivers/gpu/drm/i915/i915_mitigations.c
> > index 84f12598d145..7dadf41064e0 100644
> > --- a/drivers/gpu/drm/i915/i915_mitigations.c
> > +++ b/drivers/gpu/drm/i915/i915_mitigations.c
> > @@ -29,15 +29,13 @@ bool i915_mitigate_clear_residuals(void)
> > static int mitigations_set(const char *val, const struct kernel_param *kp)
> > {
> > unsigned long new = ~0UL;
> > - char *str, *sep, *tok;
> > + char str[64], *sep, *tok;
> > bool first = true;
> > int err = 0;
> >
> > BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
> >
> > - str = kstrdup(val, GFP_KERNEL);
> > - if (!str)
> > - return -ENOMEM;
> > + strncpy(str, val, sizeof(str) - 1);
>
> I don't think strncpy() guarantees that the string is properly
> terminated.
>
> Also commit b1b6bed3b503 ("usb: core: fix quirks_param_set() writing to
> a const pointer") looks broken as well given your findings, and
> arch/um/drivers/virtio_uml.c seems to suffer from this as well.
> kernel/params.c itself seems to have some slab_is_available() magic
> around kmalloc().
Just tried the "usbcore.quirks" with usb builtin, I can't reproduce the
issue. Futher investigation shows that device_param_cb() macro is the
key, or the "6" in __level_param_cb(name, ops, arg, perm, 6) is the key.
While i915.mitigations uses module_param_cb_unsafe(), in which the level
will be "-1"
arch/um/drivers/virtio_uml.c also makes use of device_param_cb()
thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v3)
Hi Gerd,
Speaking of the modifier, we notice that the virtio-gpu driver's
mode_config.allow_fb_modifiers = false, which means virtio-gpu doesn't support
modifier. With mode_config.allow_fb_modifiers=false, the DRM Modifier API would
fail.
So, do you know if there is any concern about letting virito-gpu allow
modifiers? Thanks.
BR,
Tina
> -Original Message-
> From: dri-devel On Behalf Of
> Vivek Kasireddy
> Sent: Tuesday, April 13, 2021 1:26 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Kasireddy, Vivek ; Gerd Hoffmann
>
> Subject: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v3)
>
> If support for Blob resources is available, then dumb BOs created by the
> driver can be considered as guest Blobs.
>
> v2: Don't skip transfer and flush commands as part of plane update as the
> device may have created a shared mapping. (Gerd)
>
> v3: Don't create dumb BOs as Guest blobs if Virgl is enabled. (Gurchetan)
>
> Cc: Gerd Hoffmann
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/gpu/drm/virtio/virtgpu_gem.c| 8
> drivers/gpu/drm/virtio/virtgpu_object.c | 3 +++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index 8502400b2f9c..2de61b63ef91 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -64,6 +64,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file
> *file_priv, {
> struct drm_gem_object *gobj;
> struct virtio_gpu_object_params params = { 0 };
> + struct virtio_gpu_device *vgdev = dev->dev_private;
> int ret;
> uint32_t pitch;
>
> @@ -79,6 +80,13 @@ int virtio_gpu_mode_dumb_create(struct drm_file
> *file_priv,
> params.height = args->height;
> params.size = args->size;
> params.dumb = true;
> +
> + if (vgdev->has_resource_blob && !vgdev->has_virgl_3d) {
> + params.blob_mem = VIRTGPU_BLOB_MEM_GUEST;
> + params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE;
> + params.blob = true;
> + }
> +
> ret = virtio_gpu_gem_create(file_priv, dev, ¶ms, &gobj,
> &args->handle);
> if (ret)
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index 4ff1ec28e630..f648b0e24447 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -254,6 +254,9 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> }
>
> if (params->blob) {
> + if (params->blob_mem == VIRTGPU_BLOB_MEM_GUEST)
> + bo->guest_blob = true;
> +
> virtio_gpu_cmd_resource_create_blob(vgdev, bo, params,
> ents, nents);
> } else if (params->virgl) {
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/dp: Use slow and wide link training for DPCP rev < 1.4
Screen flickers on Innolux panel when clock rate 54 is in use. According to the panel vendor, though clock rate 54 is advertised, but the max clock rate it really supports is 27. So use slow and wide training for panels with DPCP rev < 1.4 to resolve the issue. User also confirmed the new strategy doesn't introduce regression on XPS 9380. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3384 References: https://gitlab.freedesktop.org/drm/intel/-/issues/272 Signed-off-by: Kai-Heng Feng --- drivers/gpu/drm/i915/display/intel_dp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 775d89b6c3fc..ca73e2179659 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -1461,12 +1461,12 @@ intel_dp_compute_link_config(struct intel_encoder *encoder, intel_dp_can_bigjoiner(intel_dp)) pipe_config->bigjoiner = true; - if (intel_dp_is_edp(intel_dp)) + if (intel_dp_is_edp(intel_dp) && intel_dp->dpcd[DP_DPCD_REV] > 0x13) /* -* Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4 -* section A.1: "It is recommended that the minimum number of -* lanes be used, using the minimum link rate allowed for that -* lane configuration." +* Optimize for fast and narrow on DP 1.4. eDP 1.3 section 3.3 +* and eDP 1.4 section A.1: "It is recommended that the minimum +* number of lanes be used, using the minimum link rate allowed +* for that lane configuration." * * Note that we fall back to the max clock and lane count for eDP * panels that fail with the fast optimal settings (see -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/i915/gt: Fix a lockdep warning on RT kernel
Don`t simple disable all the HD-irq, should race the region in the
intel_breadcrumbs_disarm_irq() only.
BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:969
#0: 89c4c00ca970 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x1cf/0x6d0
#1: a433c1f53e60 ((work_completion)(&engine->retire_work)){+.+.}-{0:0},
at: process_one_work+0x1cf 0x6d
#2: 89c4ccb0a0a8 (kernel_context){+.+.}-{0:0}, at:
engine_retire+0x62/0x110 [i915]
#3: 89c4cf682300 (wakeref.mutex#3){+.+.}-{0:0}, at:
__intel_wakeref_put_last+0x20/0x60 [i915]
#4: 89c4ccb08398 (&b->irq_lock){+.+.}-{0:0}, at:
intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915]
irq event stamp: 2126
hardirqs last enabled at (2125): []
cancel_delayed_work+0xa9/0xc0
hardirqs last disabled at (2126): []
__intel_breadcrumbs_park+0x76/0x80 [i915]
softirqs last enabled at (0): [] copy_process+0x63e/0x1630
softirqs last disabled at (0): [<>] 0x0
CPU: 3 PID: 281 Comm: kworker/3:3 Not tainted 5.10.27-rt34-yocto-preempt-rt #1
Hardware name: Intel(R) Client Systems NUC7i5DNKE/NUC7i5DNB, BIOS
DNKBLi5v.86A.0064.2019.0523.1933 05/23 2019
Workqueue: events engine_retire [i915]
Call Trace:
show_stack+0x52/0x58
dump_stack+0x7d/0x9f
___might_sleep.cold+0xe3/0xf4
rt_spin_lock+0x3f/0xc0
? intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915]
intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915]
signal_irq_work+0x241/0x660 [i915]
? __this_cpu_preempt_check+0x13/0x20
? lockdep_hardirqs_off+0x106/0x120
__intel_breadcrumbs_park+0x3f/0x80 [i915]
__engine_park+0xbd/0xe0 [i915]
intel_wakeref_put_last+0x22/0x60 [i915]
__intel_wakeref_put_last+0x50/0x60 [i915]
intel_context_exit_engine+0x5f/0x70 [i915]
i915_request_retire+0x139/0x2d0 [i915]
engine_retire+0xb0/0x110 [i915]
process_one_work+0x26d/0x6d0
worker_thread+0x53/0x330
kthread+0x1b0/0x1d0
? process_one_work+0x6d0/0x6d0
? __kthread_parkme+0xc0/0xc0
ret_from_fork+0x22/0x30
Fixes: 9d5612ca165a ("drm/i915/gt: Defer enabling the breadcrumb interrupt to
after submission")
Signed-off-by: Jun Miao
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 0040b4765a54..89c2874ecc76 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -103,10 +103,11 @@ static void __intel_breadcrumbs_disarm_irq(struct
intel_breadcrumbs *b)
static void intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
- spin_lock(&b->irq_lock);
+ unsigned long flags;
+ spin_lock_irqsave(&b->irq_lock,flags);
if (b->irq_armed)
__intel_breadcrumbs_disarm_irq(b);
- spin_unlock(&b->irq_lock);
+ spin_unlock_irqrestore(&b->irq_lock,flags);
}
static void add_signaling_context(struct intel_breadcrumbs *b,
@@ -342,9 +343,7 @@ void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
/* Kick the work once more to drain the signalers */
irq_work_sync(&b->irq_work);
while (unlikely(READ_ONCE(b->irq_armed))) {
- local_irq_disable();
signal_irq_work(&b->irq_work);
- local_irq_enable();
cond_resched();
}
GEM_BUG_ON(!list_empty(&b->signalers));
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/1] drm/i915/gt: Fix a lockdep warnning on RT kernel
Hi,all This lockdep warning is only in the RT kernel. Which is introduced by this path:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c?h=v5.12-rc7&id=9d5612ca165a58aacc160465532e7998b9aab270 Fix it. Jun Miao (1): drm/i915/gt: Fix a lockdep warnning on RT kernel drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
Hi, Le 13/04/2021 à 22:56, Paul Cercueil a écrit : > Hi Neil, > > I get build failures locally: > > drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_hw_reset’: > drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit declaration of > function ‘gpiod_set_value’ [-Werror=implicit-function-declaration] > 242 | gpiod_set_value(ctx->gpio_reset, 1); > | ^~~ > drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_probe’: > drivers/gpu/drm/bridge/ite-it66121.c:1016:16: error: implicit declaration of > function ‘FIELD_GET’; did you mean ‘FOLL_GET’? > [-Werror=implicit-function-declaration] > 1016 | revision_id = FIELD_GET(IT66121_REVISION_MASK, device_ids[1]); > | ^ > | FOLL_GET > > Nothing difficult to fix, but the includes should be added nonetheless. Exact, I got the CI build failures, I'll fix these for v4. Were you able to test on your setup ? The v2 always forced DDR mode, with this v3, I also switch to normal 24input mode, but totally untested. Thanks, Neil > > Cheers, > -Paul > > > Le lun. 12 avril 2021 à 17:46, Neil Armstrong a > écrit : >> From: Phong LE >> >> This commit is a simple driver for bridge HMDI it66121. >> The input format is RBG and there is no color conversion. >> Audio, HDCP and CEC are not supported yet. >> >> Signed-off-by: Phong LE >> Signed-off-by: Neil Armstrong >> --- >> drivers/gpu/drm/bridge/Kconfig | 8 + >> drivers/gpu/drm/bridge/Makefile | 1 + >> drivers/gpu/drm/bridge/ite-it66121.c | 1081 ++ >> 3 files changed, 1090 insertions(+) >> create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c >> >> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig >> index e4110d6ca7b3..6915c38fa459 100644 >> --- a/drivers/gpu/drm/bridge/Kconfig >> +++ b/drivers/gpu/drm/bridge/Kconfig >> @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC >> HDMI signals >> Please say Y if you have such hardware. >> >> +config DRM_ITE_IT66121 >> + tristate "ITE IT66121 HDMI bridge" >> + depends on OF >> + select DRM_KMS_HELPER >> + select REGMAP_I2C >> + help >> + Support for ITE IT66121 HDMI bridge. >> + >> config DRM_LVDS_CODEC >> tristate "Transparent LVDS encoders and decoders support" >> depends on OF >> diff --git a/drivers/gpu/drm/bridge/Makefile >> b/drivers/gpu/drm/bridge/Makefile >> index 86e7acc76f8d..4f725753117c 100644 >> --- a/drivers/gpu/drm/bridge/Makefile >> +++ b/drivers/gpu/drm/bridge/Makefile >> @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o >> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o >> obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o >> obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o >> +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o >> >> obj-y += analogix/ >> obj-y += cadence/ >> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c >> b/drivers/gpu/drm/bridge/ite-it66121.c >> new file mode 100644 >> index ..73af49b29dfa >> --- /dev/null >> +++ b/drivers/gpu/drm/bridge/ite-it66121.c >> @@ -0,0 +1,1081 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Copyright (C) 2020 BayLibre, SAS >> + * Author: Phong LE >> + * Copyright (C) 2018-2019, Artem Mygaiev >> + * Copyright (C) 2017, Fresco Logic, Incorporated. >> + * >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define IT66121_VENDOR_ID0_REG 0x00 >> +#define IT66121_VENDOR_ID1_REG 0x01 >> +#define IT66121_DEVICE_ID0_REG 0x02 >> +#define IT66121_DEVICE_ID1_REG 0x03 >> + >> +#define IT66121_VENDOR_ID0 0x54 >> +#define IT66121_VENDOR_ID1 0x49 >> +#define IT66121_DEVICE_ID0 0x12 >> +#define IT66121_DEVICE_ID1 0x06 >> +#define IT66121_REVISION_MASK GENMASK(7, 4) >> +#define IT66121_DEVICE_ID1_MASK GENMASK(3, 0) >> + >> +#define IT66121_MASTER_SEL_REG 0x10 >> +#define IT66121_MASTER_SEL_HOST BIT(0) >> + >> +#define IT66121_AFE_DRV_REG 0x61 >> +#define IT66121_AFE_DRV_RST BIT(4) >> +#define IT66121_AFE_DRV_PWD BIT(5) >> + >> +#define IT66121_INPUT_MODE_REG 0x70 >> +#define IT66121_INPUT_MODE_RGB (0 << 6) >> +#define IT66121_INPUT_MODE_YUV422 BIT(6) >> +#define IT66121_INPUT_MODE_YUV444 (2 << 6) >> +#define IT66121_INPUT_MODE_CCIR656 BIT(4) >> +#define IT66121_INPUT_MODE_SYNCEMB BIT(3) >> +#define IT66121_INPUT_MODE_DDR BIT(2) >> + >> +#define IT66121_INPUT_CSC_REG 0x72 >> +#define IT66121_INPUT_CSC_ENDITHER BIT(7) >> +#define IT66121_INPUT_CSC_ENUDFILTER BIT(6) >> +#define IT66121_INPUT_CSC_DNFREE_GO BIT(5) >> +#define IT66121_INPUT_CSC_RGB_TO_YUV 0x02 >> +#define IT
Re: [PATCH] drm/i915: Fix "mitigations" parsing if i915 is builtin
On Tue, 13 Apr 2021 19:59:34 +0300 Ville Syrjälä wrote:
>
> On Tue, Apr 13, 2021 at 05:02:40PM +0800, Jisheng Zhang wrote:
> > I met below error during boot with i915 builtin if pass
> > "i915.mitigations=off":
> > [0.015589] Booting kernel: `off' invalid for parameter
> > `i915.mitigations'
> >
> > The reason is slab subsystem isn't ready at that time, so kstrdup()
> > returns NULL. Fix this issue by using stack var instead of kstrdup().
> >
> > Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
> > mitigations")
> > Signed-off-by: Jisheng Zhang
> > ---
> > drivers/gpu/drm/i915/i915_mitigations.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
> > b/drivers/gpu/drm/i915/i915_mitigations.c
> > index 84f12598d145..7dadf41064e0 100644
> > --- a/drivers/gpu/drm/i915/i915_mitigations.c
> > +++ b/drivers/gpu/drm/i915/i915_mitigations.c
> > @@ -29,15 +29,13 @@ bool i915_mitigate_clear_residuals(void)
> > static int mitigations_set(const char *val, const struct kernel_param *kp)
> > {
> > unsigned long new = ~0UL;
> > - char *str, *sep, *tok;
> > + char str[64], *sep, *tok;
> > bool first = true;
> > int err = 0;
> >
> > BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
> >
> > - str = kstrdup(val, GFP_KERNEL);
> > - if (!str)
> > - return -ENOMEM;
> > + strncpy(str, val, sizeof(str) - 1);
>
> I don't think strncpy() guarantees that the string is properly
> terminated.
>
> Also commit b1b6bed3b503 ("usb: core: fix quirks_param_set() writing to
> a const pointer") looks broken as well given your findings, and
> arch/um/drivers/virtio_uml.c seems to suffer from this as well.
wow thank you so much. I will send out patches to fix them as well.
> kernel/params.c itself seems to have some slab_is_available() magic
> around kmalloc().
>
> I used the following cocci snippet to find these:
Nice cocci script.
> @find@
> identifier O, F;
> position PS;
> @@
> struct kernel_param_ops O = {
> ...,
> .set = F@PS
> ,...
> };
>
> @alloc@
> identifier ALLOC =~ "^k.*(alloc|dup)";
> identifier find.F;
> position PA;
> @@
> F(...) {
> <+...
> ALLOC@PA(...)
> ...+>
> }
>
> @script:python depends on alloc@
> ps << find.PS;
> pa << alloc.PA;
> @@
> coccilib.report.print_report(ps[0], "struct")
> coccilib.report.print_report(pa[0], "alloc")
>
> That could of course miss a bunch more if they allocate
> via some other function I didn't consider.
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
Hi Rob,
Le 13/04/2021 à 22:21, Robert Foss a écrit :
> Hey Neil & Phong,
>
> Thanks for submitting this series!
>
>> +
>> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
>> + .attach = it66121_bridge_attach,
>> + .enable = it66121_bridge_enable,
>> + .disable = it66121_bridge_disable,
>> + .mode_set = it66121_bridge_mode_set,
>> + .mode_valid = it66121_bridge_mode_valid,
>> + .detect = it66121_bridge_detect,
>> + .get_edid = it66121_bridge_get_edid,
>> + .atomic_get_output_bus_fmts =
>> it66121_bridge_atomic_get_output_bus_fmts,
>> + .atomic_get_input_bus_fmts =
>> it66121_bridge_atomic_get_input_bus_fmts,
>> +};
>
> I would like to see an implementation of HPD, since it is supported by
> the hardware[1] (and required by the documentation). IRQ status bit 0
> seems to be the responsible for notifying us about hot plug detection
> events.
It's implemented in the IRQ handler with the IT66121_INT_STATUS1_HPD_STATUS
event.
Neil
>
> [1] https://rockchip.fr/radxa/IT66121_Programming_Guide.v1.05.pdf
>
>
> Rob.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vmwgfx: remove unused variable
Fix the following gcc warning:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:456:31: warning: variable ‘vcs’ set
but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 9a89f65..9293dc1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -453,10 +453,9 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane
*plane,
if (!ret && new_fb) {
struct drm_crtc *crtc = state->crtc;
- struct vmw_connector_state *vcs;
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
- vcs = vmw_connector_state_to_vcs(du->connector.state);
+ vmw_connector_state_to_vcs(du->connector.state);
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915: Fix "mitigations" parsing if i915 is builtin
I met below error during boot with i915 builtin if pass
"i915.mitigations=off":
[0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
The reason is slab subsystem isn't ready at that time, so kstrdup()
returns NULL. Fix this issue by using stack var instead of kstrdup().
Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
mitigations")
Signed-off-by: Jisheng Zhang
---
Since v1:
- Ensure "str" is properly terminated. Thanks Ville for pointing this out.
drivers/gpu/drm/i915/i915_mitigations.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
b/drivers/gpu/drm/i915/i915_mitigations.c
index 84f12598d145..231aad5ff46c 100644
--- a/drivers/gpu/drm/i915/i915_mitigations.c
+++ b/drivers/gpu/drm/i915/i915_mitigations.c
@@ -29,15 +29,14 @@ bool i915_mitigate_clear_residuals(void)
static int mitigations_set(const char *val, const struct kernel_param *kp)
{
unsigned long new = ~0UL;
- char *str, *sep, *tok;
+ char str[64], *sep, *tok;
bool first = true;
int err = 0;
BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
- str = kstrdup(val, GFP_KERNEL);
- if (!str)
- return -ENOMEM;
+ strncpy(str, val, sizeof(str) - 1);
+ str[sizeof(str) - 1] = '\0';
for (sep = str; (tok = strsep(&sep, ","));) {
bool enable = true;
@@ -86,7 +85,6 @@ static int mitigations_set(const char *val, const struct
kernel_param *kp)
break;
}
}
- kfree(str);
if (err)
return err;
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: fix an error code in intel_overlay_do_put_image()
This code should propagate the error from intel_overlay_pin_fb()
but currently it returns success.
Fixes: 1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/display/intel_overlay.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index e477b6114a60..e5dadde422f7 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -803,8 +803,10 @@ static int intel_overlay_do_put_image(struct intel_overlay
*overlay,
atomic_inc(&dev_priv->gpu_error.pending_fb_pin);
vma = intel_overlay_pin_fb(new_bo);
- if (IS_ERR(vma))
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
goto out_pin_section;
+ }
i915_gem_object_flush_frontbuffer(new_bo, ORIGIN_DIRTYFB);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gvt: Fix error code in intel_gvt_init_device()
The intel_gvt_init_vgpu_type_groups() function is only called from
intel_gvt_init_device(). If it fails then the intel_gvt_init_device()
prints the error code and propagates it back again. That's a bug
because false is zero/success. The fix is to modify it to return zero
or negative error codes and make everything consistent.
Fixes: c5d71cb31723 ("drm/i915/gvt: Move vGPU type related code into gvt file")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gvt/gvt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 2ecb8534930b..1deb253ffe80 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -126,7 +126,7 @@ static bool intel_get_gvt_attrs(struct attribute_group
***intel_vgpu_type_groups
return true;
}
-static bool intel_gvt_init_vgpu_type_groups(struct intel_gvt *gvt)
+static int intel_gvt_init_vgpu_type_groups(struct intel_gvt *gvt)
{
int i, j;
struct intel_vgpu_type *type;
@@ -144,7 +144,7 @@ static bool intel_gvt_init_vgpu_type_groups(struct
intel_gvt *gvt)
gvt_vgpu_type_groups[i] = group;
}
- return true;
+ return 0;
unwind:
for (j = 0; j < i; j++) {
@@ -152,7 +152,7 @@ static bool intel_gvt_init_vgpu_type_groups(struct
intel_gvt *gvt)
kfree(group);
}
- return false;
+ return -ENOMEM;
}
static void intel_gvt_cleanup_vgpu_type_groups(struct intel_gvt *gvt)
@@ -373,7 +373,7 @@ int intel_gvt_init_device(struct drm_i915_private *i915)
goto out_clean_thread;
ret = intel_gvt_init_vgpu_type_groups(gvt);
- if (ret == false) {
+ if (ret) {
gvt_err("failed to init vgpu type groups: %d\n", ret);
goto out_clean_types;
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/amdgpu: fix an error code in init_pmu_entry_by_type_and_add()
If the kmemdup() fails then this should return a negative error code
but it currently returns success
Fixes: b4a7db71ea06 ("drm/amdgpu: add per device user friendly xgmi events for
vega20")
Signed-off-by: Dan Carpenter
---
v2: I sent this patch in Feb but I accidentally added an unrelated
hunk from nouveau to the commit. Now both hunks are have been sent to
the correct lists.
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c
index 19c0a3655228..82e9ecf84352 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c
@@ -519,8 +519,10 @@ static int init_pmu_entry_by_type_and_add(struct
amdgpu_pmu_entry *pmu_entry,
pmu_entry->pmu.attr_groups = kmemdup(attr_groups, sizeof(attr_groups),
GFP_KERNEL);
- if (!pmu_entry->pmu.attr_groups)
+ if (!pmu_entry->pmu.attr_groups) {
+ ret = -ENOMEM;
goto err_attr_group;
+ }
snprintf(pmu_name, PMU_NAME_SIZE, "%s_%d", pmu_entry->pmu_file_prefix,
adev_to_drm(pmu_entry->adev)->primary->index);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: fix an error code in nouveau_backlight_init()
If nouveau_get_backlight_name() fails then this should return -ENOMEM
but currently it returns success.
Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
Signed-off-by: Dan Carpenter
---
This is from static analysis. In the original commit db1a0ae21461
("drm/nouveau/bl: Assign different names to interfaces") then returning
zero seemed to be a very deliberate choice. I do think it was wrong
though and -ENOMEM is the currect return.
drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 72f35a2babcb..3786b1c85182 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -274,6 +274,7 @@ nouveau_backlight_init(struct drm_connector *connector)
if (!nouveau_get_backlight_name(backlight_name, bl)) {
NV_ERROR(drm, "Failed to retrieve a unique name for the
backlight interface\n");
+ ret = -ENOMEM;
goto fail_alloc;
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/vmwgfx: Make sure bo's are unpinned before putting them back
Hi, Zack,
On 4/13/21 10:59 PM, Zack Rusin wrote:
During cotable resize we pin the backup buffer to make sure the
trylock doesn't fail. We were never unpinning the backup buffer
resulting in every subsequent cotable resize trying to release a
pinned bo. After we copy the old backup to the new we can release
the pin.
Mob's are always pinned so we just have to make sure we unpin
them before releasing them.
Cc: Martin Krastev
Cc: Roland Scheidegger
Fixes: d1a73c641afd ("drm/vmwgfx: Make sure we unpin no longer needed buffers")
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Zack Rusin
LGTM,
Reviewed-by: Thomas Hellström (Intel)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/msm/dp: do not re initialize of audio_comp at display_disable()
Quoting Kuogee Hsieh (2021-04-13 16:11:30)
> At dongle unplug, dp initializes audio_comp followed by sending disconnect
> event notification to audio and to make sure audio had shutdown completely
> by wait for audio completion notification at display_disable(). This patch
Is this dp_display_disable()? Doubtful that display_disable() is the
function we're talking about.
> will not re initialize audio_comp at display_disable() if audio shutdown
> is triggered by dongle unplugged.
This commit text seems to say the why before the what, where why is "dp
initializes audio_comp followed by sending disconnect.." and the what is
"this patch will no re-initialized audio_comp...". Can you reorder this
so the what comes before the why?
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 0ba71c7..1d71c95 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -894,8 +894,10 @@ static int dp_display_disable(struct dp_display_private
> *dp, u32 data)
> /* wait only if audio was enabled */
> if (dp_display->audio_enabled) {
> /* signal the disconnect event */
> - reinit_completion(&dp->audio_comp);
> - dp_display_handle_plugged_change(dp_display, false);
> + if (dp->hpd_state != ST_DISCONNECT_PENDING) {
> + reinit_completion(&dp->audio_comp);
Why is this reinitialized here at all? Wouldn't it make more sense to
initialize the completion once at cable plug in and then not initialize
the completion anywhere else? Or initialize the completion whenever
dp_display->audio_enabled is set to true and then only wait for the
completion here if that boolean is true? Or initialize the completion
when dp_display_handle_plugged_change() is passed true for the 'plugged'
argument?
I started reading the code and quickly got lost figuring out how
dp_display_handle_plugged_change() worked and the interaction between
the dp display code and the audio codec embedded in here. There seem to
be a couple of conditions that cut off things early, like
dp_display->audio_enabled and audio->engine_on. Why? Why does
dp_display_signal_audio_complete() call complete_all() vs. just
complete()? Please help! :(
> + dp_display_handle_plugged_change(dp_display, false);
I think it's this way because dp_hpd_unplug_handle() is the function
that sets the hpd_state to ST_DISCONNECT_PENDING and then reinitializes
the completion (why?) and calls dp_display_handle_plugged_change(). So
the commit text could say that reinitializing the completion again here
at dp_display_disable() is racing with the audio code in the case that
dp_hpd_unplug_handle() already called
dp_display_handle_plugged_change() and it would make more sense. But the
question still stands why that race even exists in the first place vs.
initializing the completion variable in only one place unconditionally
when the cable is connected, in dp_hpd_plug_handle() or
dp_display_post_enable().
> + }
> if (!wait_for_completion_timeout(&dp->audio_comp,
> HZ * 5))
> DRM_ERROR("audio comp timeout\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/msm/dp: check sink_count before update is_connected status
Quoting Kuogee Hsieh (2021-04-13 16:11:10)
> Link status is different from display connected status in the case
> of something like an Apple dongle where the type-c plug can be
> connected, and therefore the link is connected, but no sink is
> connected until an HDMI cable is plugged into the dongle.
> The sink_count of DPCD of dongle will increase to 1 once an HDMI
> cable is plugged into the dongle so that display connected status
> will become true. This checking also apply at pm_resume.
>
> Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and
> pm_resume")
> Reported-by: Stephen Boyd
> Signed-off-by: Kuogee Hsieh
> ---
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
Hi Daniel, On Tue, 2021-04-13 at 16:14 +0200, Lucas Stach wrote: > Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter: > > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > > > Since > > > > > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > > > Author: Paul Kocialkowski > > > > Date: Fri Jan 4 09:56:10 2019 +0100 > > > > > > > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > > > > > > > this is done automatically as part of plane init, if drivers set the > > > > modifier list correctly. Which is the case here. > > > > > > > > This one actually set it twice on top of what drm_plane_init does, so > > > > double-redundant! > > > > > > That's not true. imx-dcss and imx-drm are two totally separate drivers. > > > Maybe we should move imx-drm into its own ipuv3 directory one day to > > > make this more clear. Change is still correct, though. > > > > Hm I greeped for drm_universal_plane_init and didn't find anythinf for the > > imx main driver ... where are planes set up for that? Need to review that > > they have the modifiers listed in all cases. > > That's in drivers/gpu/drm/imx/ipuv3-plane.c and modifiers are always > set on plane init. > > Regards, > Lucas > > > > Reviewed-by: Lucas Stach > > > > > > > Signed-off-by: Daniel Vetter > > > > Cc: Philipp Zabel > > > > Cc: Shawn Guo > > > > Cc: Sascha Hauer > > > > Cc: Pengutronix Kernel Team > > > > Cc: Fabio Estevam > > > > Cc: NXP Linux Team > > > > Cc: linux-arm-ker...@lists.infradead.org > > > > --- > > > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > > > > drivers/gpu/drm/imx/imx-drm-core.c | 1 - Nit: Since this patch touches two totally separate drivers(imx-dcss and imx-drm), it would be good to split it into two patches. Thanks, Liu Ying > > > > 2 files changed, 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > > index b549ce5e7607..37ae68a7fba5 100644 > > > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct > > > > dcss_kms_dev *kms) > > > > config->min_height = 1; > > > > config->max_width = 4096; > > > > config->max_height = 4096; > > > > - config->allow_fb_modifiers = true; > > > > config->normalize_zpos = true; > > > > > > > > > > > > > > > > > > > > config->funcs = &dcss_drm_mode_config_funcs; > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > > > b/drivers/gpu/drm/imx/imx-drm-core.c > > > > index 2ded8e4f32d0..8be4edaec958 100644 > > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) > > > > drm->mode_config.max_height = 4096; > > > > drm->mode_config.funcs = &imx_drm_mode_config_funcs; > > > > drm->mode_config.helper_private = &imx_drm_mode_config_helpers; > > > > - drm->mode_config.allow_fb_modifiers = true; > > > > drm->mode_config.normalize_zpos = true; > > > > > > > > > > > > > > > > > > > > ret = drmm_mode_config_init(drm); > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2, 3/5] Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value"
On Wed, 2021-04-14 at 07:38 +0800, Chun-Kuang Hu wrote: > Hi, Yongqiang: > > Yongqiang Niu 於 2021年4月12日 週一 下午7:19寫道： > > > > This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f. > > > > Signed-off-by: Yongqiang Niu > > --- > > Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > index 7771eca..cf48cd8 100644 > > --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > > @@ -47,7 +47,7 @@ Example: > > interrupts = ; > > clocks = <&infracfg CLK_INFRA_GCE>; > > clock-names = "gce"; > > - #mbox-cells = <2>; > > + #mbox-cells = <3>; > > I think we should not change the binding just to fix software bug. > I think there are many temporary solution to fix drm bug. If drm bug > is caused by cursor plane, you could temporarily let drm not support > cursor plane to fix it (in [1], do not return DRM_PLANE_TYPE_CURSOR). > But I would like you to find out the correct solution rather than a > temporary solution because this bug is not so urgent. (For me, bug of > build fail, boot fail, black screen is urgent). > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mediatek/mtk_drm_crtc.c?h=v5.12-rc7#n699 > > Regards, > Chun-Kuang. this not drm bug, but caused by cmdq patch https://patchwork.kernel.org/project/linux-mediatek/patch/20200214043325.16618-3-bibby.hs...@mediatek.com/ before this patch, drm cursor and ui works well after this patch, ui will flash when move cursor this is critical issue, > > > }; > > > > Example for a client device: > > -- > > 1.8.1.1.dirty > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2, 3/5] Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value"
Hi, Yongqiang: Yongqiang Niu 於 2021年4月12日 週一 下午7:19寫道： > > This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f. > > Signed-off-by: Yongqiang Niu > --- > Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > index 7771eca..cf48cd8 100644 > --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > @@ -47,7 +47,7 @@ Example: > interrupts = ; > clocks = <&infracfg CLK_INFRA_GCE>; > clock-names = "gce"; > - #mbox-cells = <2>; > + #mbox-cells = <3>; I think we should not change the binding just to fix software bug. I think there are many temporary solution to fix drm bug. If drm bug is caused by cursor plane, you could temporarily let drm not support cursor plane to fix it (in [1], do not return DRM_PLANE_TYPE_CURSOR). But I would like you to find out the correct solution rather than a temporary solution because this bug is not so urgent. (For me, bug of build fail, boot fail, black screen is urgent). [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mediatek/mtk_drm_crtc.c?h=v5.12-rc7#n699 Regards, Chun-Kuang. > }; > > Example for a client device: > -- > 1.8.1.1.dirty > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/msm/dp: check main link status before start aux read
Make sure main link is in connection state before start aux
read/write operation to avoid unnecessary long delay due to
main link had been unplugged.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
drivers/gpu/drm/msm/dp/dp_link.c | 20 +++-
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 7c22bfe..fae3806 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
mutex_lock(&aux->mutex);
+ if (!dp_catalog_link_is_connected(aux->catalog)) {
+ ret = -ETIMEDOUT;
+ goto unlock_exit;
+ }
+
aux->native = msg->request & (DP_AUX_NATIVE_WRITE & DP_AUX_NATIVE_READ);
/* Ignore address only message */
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index be986da..d35b18e 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -737,18 +737,25 @@ static int dp_link_parse_sink_count(struct dp_link
*dp_link)
return 0;
}
-static void dp_link_parse_sink_status_field(struct dp_link_private *link)
+static int dp_link_parse_sink_status_field(struct dp_link_private *link)
{
int len = 0;
link->prev_sink_count = link->dp_link.sink_count;
- dp_link_parse_sink_count(&link->dp_link);
+ len = dp_link_parse_sink_count(&link->dp_link);
+ if (len < 0) {
+ DRM_ERROR("DP lparse sink count failed\n");
+ return len;
+ }
len = drm_dp_dpcd_read_link_status(link->aux,
link->link_status);
- if (len < DP_LINK_STATUS_SIZE)
+ if (len < DP_LINK_STATUS_SIZE) {
DRM_ERROR("DP link status read failed\n");
- dp_link_parse_request(link);
+ return len;
+ }
+
+ return dp_link_parse_request(link);
}
/**
@@ -1032,7 +1039,10 @@ int dp_link_process_request(struct dp_link *dp_link)
dp_link_reset_data(link);
- dp_link_parse_sink_status_field(link);
+ ret = dp_link_parse_sink_status_field(link);
+ if (ret) {
+ return ret;
+ }
if (link->request.test_requested == DP_TEST_LINK_EDID_READ) {
dp_link->sink_request |= DP_TEST_LINK_EDID_READ;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/msm/dp: do not re initialize of audio_comp at display_disable()
At dongle unplug, dp initializes audio_comp followed by sending disconnect
event notification to audio and to make sure audio had shutdown completely
by wait for audio completion notification at display_disable(). This patch
will not re initialize audio_comp at display_disable() if audio shutdown
is triggered by dongle unplugged.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 0ba71c7..1d71c95 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -894,8 +894,10 @@ static int dp_display_disable(struct dp_display_private
*dp, u32 data)
/* wait only if audio was enabled */
if (dp_display->audio_enabled) {
/* signal the disconnect event */
- reinit_completion(&dp->audio_comp);
- dp_display_handle_plugged_change(dp_display, false);
+ if (dp->hpd_state != ST_DISCONNECT_PENDING) {
+ reinit_completion(&dp->audio_comp);
+ dp_display_handle_plugged_change(dp_display, false);
+ }
if (!wait_for_completion_timeout(&dp->audio_comp,
HZ * 5))
DRM_ERROR("audio comp timeout\n");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/msm/dp: check sink_count before update is_connected status
Link status is different from display connected status in the case
of something like an Apple dongle where the type-c plug can be
connected, and therefore the link is connected, but no sink is
connected until an HDMI cable is plugged into the dongle.
The sink_count of DPCD of dongle will increase to 1 once an HDMI
cable is plugged into the dongle so that display connected status
will become true. This checking also apply at pm_resume.
Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and
pm_resume")
Reported-by: Stephen Boyd
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6..0ba71c7 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -586,10 +586,8 @@ static int dp_connect_pending_timeout(struct
dp_display_private *dp, u32 data)
mutex_lock(&dp->event_mutex);
state = dp->hpd_state;
- if (state == ST_CONNECT_PENDING) {
- dp_display_enable(dp, 0);
+ if (state == ST_CONNECT_PENDING)
dp->hpd_state = ST_CONNECTED;
- }
mutex_unlock(&dp->event_mutex);
@@ -669,10 +667,8 @@ static int dp_disconnect_pending_timeout(struct
dp_display_private *dp, u32 data
mutex_lock(&dp->event_mutex);
state = dp->hpd_state;
- if (state == ST_DISCONNECT_PENDING) {
- dp_display_disable(dp, 0);
+ if (state == ST_DISCONNECT_PENDING)
dp->hpd_state = ST_DISCONNECTED;
- }
mutex_unlock(&dp->event_mutex);
@@ -1272,7 +1268,12 @@ static int dp_pm_resume(struct device *dev)
status = dp_catalog_link_is_connected(dp->catalog);
- if (status)
+ /*
+* can not declared display is connected unless
+* HDMI cable is plugged in and sink_count of
+* dongle become 1
+*/
+ if (status && dp->link->sink_count)
dp->dp_display.is_connected = true;
else
dp->dp_display.is_connected = false;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] efifb: Check efifb_pci_dev before using it
On Tue, Apr 13, 2021 at 2:37 PM Daniel Vetter wrote:
>
> On Tue, Apr 13, 2021 at 8:02 PM Alex Deucher wrote:
> >
> > On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng
> > wrote:
> > >
> > > On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
> > > a PCI device.
> > >
> > > So make sure efifb_pci_dev is found before using it.
> > >
> > > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at
> > > PCI D0")
> > > BugLink: https://bugs.launchpad.net/bugs/1922403
> > > Signed-off-by: Kai-Heng Feng
> >
> > Reviewed-by: Alex Deucher
>
> fbdev is in drm-misc, so maybe you can push this one too?
Yes, pushed. Thanks!
Alex
> -Daniel
>
> >
> > > ---
> > > drivers/video/fbdev/efifb.c | 6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > > index f58a545b3bf3..8ea8f079cde2 100644
> > > --- a/drivers/video/fbdev/efifb.c
> > > +++ b/drivers/video/fbdev/efifb.c
> > > @@ -575,7 +575,8 @@ static int efifb_probe(struct platform_device *dev)
> > > goto err_fb_dealoc;
> > > }
> > > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > > - pm_runtime_get_sync(&efifb_pci_dev->dev);
> > > + if (efifb_pci_dev)
> > > + pm_runtime_get_sync(&efifb_pci_dev->dev);
> > > return 0;
> > >
> > > err_fb_dealoc:
> > > @@ -602,7 +603,8 @@ static int efifb_remove(struct platform_device *pdev)
> > > unregister_framebuffer(info);
> > > sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
> > > framebuffer_release(info);
> > > - pm_runtime_put(&efifb_pci_dev->dev);
> > > + if (efifb_pci_dev)
> > > + pm_runtime_put(&efifb_pci_dev->dev);
> > >
> > > return 0;
> > > }
> > > --
> > > 2.30.2
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] drm/msm: drm-msm-next for 5.13
On Sun, Apr 11, 2021 at 05:53:32PM -0700, Rob Clark wrote: > Hi Dave&Daniel, > > This time around a bit larger than usual, but a large part of that is > Dmitry's dsi phy/pll refactor (which is itself a pretty large negative > diffstat). The dsi phy/pll refactor includes a couple clk patches a-b > the maintainer. (For folks actually trying to boot msm-next, there is > one clk fix required, which should hopefully land in 5.12 but not in > msm-next.. https://patchwork.freedesktop.org/patch/427412/) > > * Big DSI phy/pll cleanup > * Initial support for sc7280 > * compatibles fixes for sm8150/sm8250 > * cleanups for all dpu gens to use same bandwidth scaling paths (\o/) > * various shrinker path lock contention optimizations > * unpin/swap support for GEM objects (disabled by default, enable with > msm.enable_eviction=1 .. due to various combinations of iommu drivers > with older gens I want to get more testing on hw I don't have in front > of me before enabling by default) > * The usual assortment of misc fixes and cleanups > > The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0: > > Linux 5.12-rc3 (2021-03-14 14:41:02 -0700) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2021-04-11 > > for you to fetch changes up to a29c8c0241654d5f3165d52e9307e4feff955621: > > drm/msm/disp/dpu1: fix display underruns during modeset. (2021-04-09 Pulled into drm-next, thanks for your pull. Maybe to make this even easier for us: Pull summary in the tag is nice :-) Dave, I've done a backmerge of drm-fixes into drm-next first since this was on a newer baseline. I asked Alex to double-check the result just in case. -Daniel > 12:02:35 -0700) > > > Abhinav Kumar (3): > drm/msm/dp: Fix indentation kbot warnings in DP driver > drm/msm/dp: Fix incorrect NULL check kbot warnings in DP driver > drm/msm/dp: delete unnecessary debugfs error handling > > Akhil P Oommen (2): > drm/msm/a6xx: Fix perfcounter oob timeout > drm/msm: Select CONFIG_NVMEM > > AngeloGioacchino Del Regno (2): > drm/msm/dsi: Uncomment core_mmss clock for MSM8996 > drm/msm/mdp5: Disable pingpong autorefresh at tearcheck init > > Bernard Zhao (1): > gpu/drm/msm: remove redundant pr_err() when devm_kzalloc failed > > Bhaskar Chowdhury (1): > drivers: gpu: drm: msn: disp: dpu1: Fixed couple of spellings in > the file dpu_hw_top.h > > Bjorn Andersson (1): > drm/msm: Remove need for reiterating the compatibles > > Colin Ian King (1): > drm/msm: Fix spelling mistake "Purgable" -> "Purgeable" > > Dmitry Baryshkov (32): > drm/msm/dsi: fix check-before-set in the 7nm dsi_pll code > drm/msm/dsi_pll_7nm: Solve TODO for multiplier frac_bits assignment > drm/msm/dsi_pll_7nm: Fix variable usage for pll_lockdet_rate > drm/msm: fix shutdown hook in case GPU components failed to bind > drm/msm: a6xx: fix version check for the A650 SQE microcode > clk: mux: provide devm_clk_hw_register_mux() > clk: divider: add devm_clk_hw_register_divider > drm/msm/dsi: replace PHY's init callback with configurable data > drm/msm/dsi: fuse dsi_pll_* code into dsi_phy_* code > drm/msm/dsi: drop multiple pll enable_seq support > drm/msm/dsi: move all PLL callbacks into PHY config struct > drm/msm/dsi: drop global msm_dsi_phy_type enumaration > drm/msm/dsi: move min/max PLL rate to phy config > drm/msm/dsi: remove msm_dsi_pll_set_usecase > drm/msm/dsi: push provided clocks handling into a generic code > drm/msm/dsi: use devm_clk_*register to registe DSI PHY clocks > drm/msm/dsi: use devm_of_clk_add_hw_provider > drm/msm/dsi: make save/restore_state phy-level functions > drm/msm/dsi: drop vco_delay setting from 7nm, 10nm, 14nm drivers > drm/msm/dsi: simplify vco_delay handling in dsi_phy_28nm driver > drm/msi/dsi: inline msm_dsi_pll_helper_clk_prepare/unprepare > drm/msm/dsi: make save_state/restore_state callbacks accept msm_dsi_phy > drm/msm/dsi: drop msm_dsi_pll abstraction > drm/msm/dsi: drop PLL accessor functions > drm/msm/dsi: move ioremaps to dsi_phy_driver_probe > drm/msm/dsi: remove duplicate fields from dsi_pll_Nnm instances > drm/msm/dsi: remove temp data from global pll structure > drm/msm/dsi: inline msm_dsi_phy_set_src_pll > drm/msm/dsi: stop passing src_pll_id to the phy_enable call > drm/msm/dpu: enable DPU_SSPP_QOS_8LVL for SM8250 > drm/msm/dpu: fill missing details in hw catalog for sdm845 and sm8[12]50 > drm/msm/dpu: always use mdp device to scale bandwidth > > Douglas Anderson (1): > drm/msm: Fix speed-bin support not to access outside valid memory > > Fabio Estevam (1): > drm/msm: Fix suspend/resume on i.MX5 > > John Stultz (1): > drm/
Re: [pull] amdgpu, radeon drm-next-5.13
On Mon, Apr 12, 2021 at 06:07:32PM -0400, Alex Deucher wrote: > Hi Dave, Daniel, > > Same PR as last week plus a few accumulated fixes, rebased on drm-next > to resolve the dependencies between ttm and scheduler with changes in amdgpu. > > The following changes since commit c103b850721e4a79ff9578f131888129c37a4679: > > Merge tag 'drm-misc-next-2021-04-09' of > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2021-04-10 05:46:35 > +1000) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/agd5f/linux.git > tags/amd-drm-next-5.13-2021-04-12 > > for you to fetch changes up to cbb8f989d5a07cb3e39e9c149a6f89d6c83432aa: > > drm/amdgpu: page retire over debugfs mechanism (2021-04-09 16:58:28 -0400) Applied to drm-next, thanks. -Daniel > > > amd-drm-next-5.13-2021-04-12: > > amdgpu: > - Re-enable GPU reset on VanGogh > - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME > - Disentangle HG from vga_switcheroo > - S0ix fixes > - W=1 fixes > - Resource iterator fixes > - DMCUB updates > - UBSAN fixes > - More PM API cleanup > - Aldebaran updates > - Modifier fixes > - Enable VCN load balancing with asymmetric engines > - Rework BO structs > - Aldebaran reset support > - Initial LTTPR display work > - Display MALL fixes > - Fall back to YCbCr420 when YCbCr444 fails > - SR-IOV fixes > - RAS updates > - Misc cleanups and fixes > > radeon: > - Typo fixes > - Fix error handling for firmware on r6xx > - Fix a missing check in DP MST handling > > > Alex Deucher (22): > drm/amdgpu/display/dm: add missing parameter documentation > drm/amdgpu: Add additional Sienna Cichlid PCI ID > drm/amdgpu: add a dev_pm_ops prepare callback (v2) > drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND > flags (v2) > drm/amdgpu: disentangle HG systems from vgaswitcheroo > drm/amdgpu: rework S3/S4/S0ix state handling > drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) > drm/amdgpu: clean up non-DC suspend/resume handling > drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) > drm/amdgpu: re-enable suspend phase 2 for S0ix > drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend > drm/amdgpu: update comments about s0ix suspend/resume > drm/amdgpu: drop S0ix checks around CG/PG in suspend > drm/amdgpu: skip kfd suspend/resume for S0ix > drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x > drm/amdgpu/display: fix memory leak for dimgrey cavefish > drm/amdgpu/pm: mark pcie link/speed arrays as const > drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend > drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in > suspend > drm/amdgpu/display: fix warning on 32 bit in dmub > drm/amdgpu: drop some unused atombios functions > drm/amdgpu/smu7: fix CAC setting on TOPAZ > > Alex Sierra (2): > drm/amdgpu: replace per_device_list by array > drm/amdgpu: ih reroute for newer asics than vega20 > > Alvin Lee (1): > drm/amd/display: Change input parameter for set_drr > > Amber Lin (1): > drm/amdkfd: Avoid null pointer in SMI event > > Anson Jacob (2): > drm/amd/display: Fix UBSAN: shift-out-of-bounds warning > drm/amd/display: Removing unused code from dmub_cmd.h > > Anthony Koo (3): > drm/amd/display: [FW Promotion] Release 0.0.57 > drm/amd/display: [FW Promotion] Release 0.0.58 > drm/amd/display: [FW Promotion] Release 0.0.59 > > Aric Cyr (3): > drm/amd/display: 3.2.128 > drm/amd/display: 3.2.129 > drm/amd/display: 3.2.130 > > Arnd Bergmann (3): > amdgpu: avoid incorrect %hu format string > amdgpu: fix gcc -Wrestrict warning > amdgpu: securedisplay: simplify i2c hexdump output > > Aurabindo Pillai (1): > drm/amd/display: Add debugfs entry for LTTPR register status > > Bernard Zhao (2): > drm/amd: use kmalloc_array over kmalloc with multiply > drm/amd: cleanup coding style a bit > > Bhaskar Chowdhury (6): > drm/amdgpu: Fix a typo > drm/amdgpu: Fix a typo > drm/atomic: Couple of typo fixes > drm/radeon/r600_cs: Few typo fixes > drm/amd/amdgpu/gfx_v7_0: Trivial typo fixes > drm/amd: Fix a typo in two different sentences > > Bindu Ramamurthy (1): > drm/amd/display: Allow idle optimization based on vblank. > > Chengming Gui (1): > drm/amd/amdgpu: set MP1 state to UNLOAD before reload its FW for > vega20/ALDEBARAN > > Chris Park (1): > drm/amd/display: Disable MALL when SMU not present > > Christian König (4): > drm/amdgpu: remove irq_src->data handling > drm/amdgpu: add the sched_score to amdgpu_ring_init > drm/amdgpu: share scheduler score on VCN3 instances > drm/amdgpu: lo
[PATCH v3] drm/vmwgfx: Make sure bo's are unpinned before putting them back
During cotable resize we pin the backup buffer to make sure the
trylock doesn't fail. We were never unpinning the backup buffer
resulting in every subsequent cotable resize trying to release a
pinned bo. After we copy the old backup to the new we can release
the pin.
Mob's are always pinned so we just have to make sure we unpin
them before releasing them.
Cc: Martin Krastev
Cc: Roland Scheidegger
Fixes: d1a73c641afd ("drm/vmwgfx: Make sure we unpin no longer needed buffers")
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 4
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 +
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 18 ++
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index ba658fa9cf6c..183571c387b7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -481,11 +481,15 @@ static int vmw_cotable_resize(struct vmw_resource *res,
size_t new_size)
vmw_bo_unreference(&old_buf);
res->id = vcotbl->type;
+ /* Release the pin acquired in vmw_bo_init */
+ ttm_bo_unpin(bo);
+
return 0;
out_map_new:
ttm_bo_kunmap(&old_map);
out_wait:
+ ttm_bo_unpin(bo);
ttm_bo_unreserve(bo);
vmw_bo_unreference(&buf);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 8087a9013455..eb76a6b9ebca 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1522,11 +1522,8 @@ static inline void vmw_bo_unreference(struct
vmw_buffer_object **buf)
struct vmw_buffer_object *tmp_buf = *buf;
*buf = NULL;
- if (tmp_buf != NULL) {
- if (tmp_buf->base.pin_count > 0)
- ttm_bo_unpin(&tmp_buf->base);
+ if (tmp_buf != NULL)
ttm_bo_put(&tmp_buf->base);
- }
}
static inline struct vmw_buffer_object *
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
index a0b53141dded..f2d625415458 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
@@ -94,6 +94,16 @@ static void vmw_mob_pt_setup(struct vmw_mob *mob,
struct vmw_piter data_iter,
unsigned long num_data_pages);
+
+static inline void vmw_bo_unpin_unlocked(struct ttm_buffer_object *bo)
+{
+ int ret = ttm_bo_reserve(bo, false, true, NULL);
+ BUG_ON(ret != 0);
+ ttm_bo_unpin(bo);
+ ttm_bo_unreserve(bo);
+}
+
+
/*
* vmw_setup_otable_base - Issue an object table base setup command to
* the device
@@ -277,7 +287,7 @@ static int vmw_otable_batch_setup(struct vmw_private
*dev_priv,
&batch->otables[i]);
}
- ttm_bo_unpin(batch->otable_bo);
+ vmw_bo_unpin_unlocked(batch->otable_bo);
ttm_bo_put(batch->otable_bo);
batch->otable_bo = NULL;
return ret;
@@ -341,9 +351,9 @@ static void vmw_otable_batch_takedown(struct vmw_private
*dev_priv,
BUG_ON(ret != 0);
vmw_bo_fence_single(bo, NULL);
+ ttm_bo_unpin(bo);
ttm_bo_unreserve(bo);
- ttm_bo_unpin(batch->otable_bo);
ttm_bo_put(batch->otable_bo);
batch->otable_bo = NULL;
}
@@ -530,7 +540,7 @@ static void vmw_mob_pt_setup(struct vmw_mob *mob,
void vmw_mob_destroy(struct vmw_mob *mob)
{
if (mob->pt_bo) {
- ttm_bo_unpin(mob->pt_bo);
+ vmw_bo_unpin_unlocked(mob->pt_bo);
ttm_bo_put(mob->pt_bo);
mob->pt_bo = NULL;
}
@@ -646,7 +656,7 @@ int vmw_mob_bind(struct vmw_private *dev_priv,
out_no_cmd_space:
vmw_fifo_resource_dec(dev_priv);
if (pt_set_up) {
- ttm_bo_unpin(mob->pt_bo);
+ vmw_bo_unpin_unlocked(mob->pt_bo);
ttm_bo_put(mob->pt_bo);
mob->pt_bo = NULL;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
Hi Neil, I get build failures locally: drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_hw_reset’: drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit declaration of function ‘gpiod_set_value’ [-Werror=implicit-function-declaration] 242 | gpiod_set_value(ctx->gpio_reset, 1); | ^~~ drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_probe’: drivers/gpu/drm/bridge/ite-it66121.c:1016:16: error: implicit declaration of function ‘FIELD_GET’; did you mean ‘FOLL_GET’? [-Werror=implicit-function-declaration] 1016 | revision_id = FIELD_GET(IT66121_REVISION_MASK, device_ids[1]); | ^ | FOLL_GET Nothing difficult to fix, but the includes should be added nonetheless. Cheers, -Paul Le lun. 12 avril 2021 à 17:46, Neil Armstrong a écrit : From: Phong LE This commit is a simple driver for bridge HMDI it66121. The input format is RBG and there is no color conversion. Audio, HDCP and CEC are not supported yet. Signed-off-by: Phong LE Signed-off-by: Neil Armstrong --- drivers/gpu/drm/bridge/Kconfig |8 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/ite-it66121.c | 1081 ++ 3 files changed, 1090 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3..6915c38fa459 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC HDMI signals Please say Y if you have such hardware. +config DRM_ITE_IT66121 + tristate "ITE IT66121 HDMI bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + help + Support for ITE IT66121 HDMI bridge. + config DRM_LVDS_CODEC tristate "Transparent LVDS encoders and decoders support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 86e7acc76f8d..4f725753117c 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o obj-y += analogix/ obj-y += cadence/ diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c new file mode 100644 index ..73af49b29dfa --- /dev/null +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -0,0 +1,1081 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2020 BayLibre, SAS + * Author: Phong LE + * Copyright (C) 2018-2019, Artem Mygaiev + * Copyright (C) 2017, Fresco Logic, Incorporated. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#define IT66121_VENDOR_ID0_REG 0x00 +#define IT66121_VENDOR_ID1_REG 0x01 +#define IT66121_DEVICE_ID0_REG 0x02 +#define IT66121_DEVICE_ID1_REG 0x03 + +#define IT66121_VENDOR_ID0 0x54 +#define IT66121_VENDOR_ID1 0x49 +#define IT66121_DEVICE_ID0 0x12 +#define IT66121_DEVICE_ID1 0x06 +#define IT66121_REVISION_MASK GENMASK(7, 4) +#define IT66121_DEVICE_ID1_MASKGENMASK(3, 0) + +#define IT66121_MASTER_SEL_REG 0x10 +#define IT66121_MASTER_SEL_HOSTBIT(0) + +#define IT66121_AFE_DRV_REG0x61 +#define IT66121_AFE_DRV_RSTBIT(4) +#define IT66121_AFE_DRV_PWDBIT(5) + +#define IT66121_INPUT_MODE_REG 0x70 +#define IT66121_INPUT_MODE_RGB (0 << 6) +#define IT66121_INPUT_MODE_YUV422 BIT(6) +#define IT66121_INPUT_MODE_YUV444 (2 << 6) +#define IT66121_INPUT_MODE_CCIR656 BIT(4) +#define IT66121_INPUT_MODE_SYNCEMB BIT(3) +#define IT66121_INPUT_MODE_DDR BIT(2) + +#define IT66121_INPUT_CSC_REG 0x72 +#define IT66121_INPUT_CSC_ENDITHER BIT(7) +#define IT66121_INPUT_CSC_ENUDFILTER BIT(6) +#define IT66121_INPUT_CSC_DNFREE_GOBIT(5) +#define IT66121_INPUT_CSC_RGB_TO_YUV 0x02 +#define IT66121_INPUT_CSC_YUV_TO_RGB 0x03 +#define IT66121_INPUT_CSC_NO_CONV 0x00 + +#define IT66121_AFE_XP_REG 0x62 +#define IT66121_AFE_XP_GAINBIT BIT(7) +#define IT66121_AFE_XP_PWDPLL BIT(6) +#define IT66121_AFE_XP_ENI BIT(5) +#define IT66121_AFE_XP_ENO BIT(4) +#define IT66121_AFE_XP_RESETB BIT(3) +#define IT6612
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
Hey Neil & Phong,
Thanks for submitting this series!
> +
> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
> + .attach = it66121_bridge_attach,
> + .enable = it66121_bridge_enable,
> + .disable = it66121_bridge_disable,
> + .mode_set = it66121_bridge_mode_set,
> + .mode_valid = it66121_bridge_mode_valid,
> + .detect = it66121_bridge_detect,
> + .get_edid = it66121_bridge_get_edid,
> + .atomic_get_output_bus_fmts =
> it66121_bridge_atomic_get_output_bus_fmts,
> + .atomic_get_input_bus_fmts = it66121_bridge_atomic_get_input_bus_fmts,
> +};
I would like to see an implementation of HPD, since it is supported by
the hardware[1] (and required by the documentation). IRQ status bit 0
seems to be the responsible for notifying us about hot plug detection
events.
[1] https://rockchip.fr/radxa/IT66121_Programming_Guide.v1.05.pdf
Rob.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings
Hi Paul,
On Tue, Apr 13, 2021 at 07:09:17PM +0100, Paul Cercueil wrote:
> Le lun. 12 avril 2021 à 17:46, Neil Armstrong a écrit :
> > From: Phong LE
> >
> > Add the ITE bridge HDMI it66121 bindings.
> >
> > Signed-off-by: Phong LE
> > Signed-off-by: Neil Armstrong
> > ---
> > .../bindings/display/bridge/ite,it66121.yaml | 123 ++
> > 1 file changed, 123 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
> > b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
> > new file mode 100644
> > index ..61ed6dc7740b
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
> > @@ -0,0 +1,123 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ITE it66121 HDMI bridge Device Tree Bindings
> > +
> > +maintainers:
> > + - Phong LE
> > + - Neil Armstrong
> > +
> > +description: |
> > + The IT66121 is a high-performance and low-power single channel HDMI
> > + transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward
> > compatible
> > + to DVI 1.0 specifications.
> > +
> > +properties:
> > + compatible:
> > +const: ite,it66121
> > +
> > + reg:
> > +maxItems: 1
> > +description: base I2C address of the device
> > +
> > + reset-gpios:
> > +maxItems: 1
> > +description: GPIO connected to active low reset
> > +
> > + vrf12-supply:
> > +description: Regulator for 1.2V analog core power.
> > +
> > + vcn33-supply:
> > +description: Regulator for 3.3V digital core power.
> > +
> > + vcn18-supply:
> > +description: Regulator for 1.8V IO core power.
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +
> > +properties:
> > + port@0:
> > +$ref: /schemas/graph.yaml#/$defs/port-base
> > +unevaluatedProperties: false
> > +description: DPI input port.
> > +
> > +properties:
> > + endpoint:
> > +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> > +unevaluatedProperties: false
> > +
> > +properties:
> > + bus-width:
> > +description:
> > + Endpoint bus width.
> > +enum:
> > + - 12 # 12 data lines connected and dual-edge mode
> > + - 24 # 24 data lines connected and single-edge
> > mode
> > +default: 24
> > +
> > + port@1:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: HDMI Connector port.
> > +
> > +required:
> > + - port@0
> > + - port@1
>
> Should port@1 really be required? Since the chip itself handles the
> hotplug detection and stuff like DCC, I'm not sure what to connect here.
It should be connected to a DT node that models the connector
(Documentation/devicetree/bindings/display/connector/*).
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reset-gpios
> > + - vrf12-supply
> > + - vcn33-supply
> > + - vcn18-supply
> > + - interrupts
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + it66121hdmitx: it66121hdmitx@4c {
> > +compatible = "ite,it66121";
> > +pinctrl-names = "default";
> > +pinctrl-0 = <&ite_pins_default>;
> > +vcn33-supply = <&mt6358_vcn33_wifi_reg>;
> > +vcn18-supply = <&mt6358_vcn18_reg>;
> > +vrf12-supply = <&mt6358_vrf12_reg>;
> > +reset-gpios = <&pio 160 1 /* GPIO_ACTIVE_LOW */>;
> > +interrupt-parent = <&pio>;
> > +interrupts = <4 8 /* IRQ_TYPE_LEVEL_LOW */>;
> > +reg = <0x4c>;
> > +
> > +ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > +reg = <0>;
> > +it66121_in: endpoint {
> > + bus-width = <12>;
> > + remote-endpoint = <&display_out>;
> > +};
> > + };
> > +
> > + port@1 {
> > +reg = <1>;
> > +hdmi_conn_out: endpoint {
> > + remote-endpoint = <&hdmi_conn_in>;
> > +};
> > + };
> > +};
> > + };
> > +};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] efifb: Check efifb_pci_dev before using it
On Tue, Apr 13, 2021 at 8:02 PM Alex Deucher wrote:
>
> On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng
> wrote:
> >
> > On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
> > a PCI device.
> >
> > So make sure efifb_pci_dev is found before using it.
> >
> > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> > D0")
> > BugLink: https://bugs.launchpad.net/bugs/1922403
> > Signed-off-by: Kai-Heng Feng
>
> Reviewed-by: Alex Deucher
fbdev is in drm-misc, so maybe you can push this one too?
-Daniel
>
> > ---
> > drivers/video/fbdev/efifb.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > index f58a545b3bf3..8ea8f079cde2 100644
> > --- a/drivers/video/fbdev/efifb.c
> > +++ b/drivers/video/fbdev/efifb.c
> > @@ -575,7 +575,8 @@ static int efifb_probe(struct platform_device *dev)
> > goto err_fb_dealoc;
> > }
> > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > - pm_runtime_get_sync(&efifb_pci_dev->dev);
> > + if (efifb_pci_dev)
> > + pm_runtime_get_sync(&efifb_pci_dev->dev);
> > return 0;
> >
> > err_fb_dealoc:
> > @@ -602,7 +603,8 @@ static int efifb_remove(struct platform_device *pdev)
> > unregister_framebuffer(info);
> > sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
> > framebuffer_release(info);
> > - pm_runtime_put(&efifb_pci_dev->dev);
> > + if (efifb_pci_dev)
> > + pm_runtime_put(&efifb_pci_dev->dev);
> >
> > return 0;
> > }
> > --
> > 2.30.2
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings
Hi Neil,
Le lun. 12 avril 2021 à 17:46, Neil Armstrong
a écrit :
From: Phong LE
Add the ITE bridge HDMI it66121 bindings.
Signed-off-by: Phong LE
Signed-off-by: Neil Armstrong
---
.../bindings/display/bridge/ite,it66121.yaml | 123
++
1 file changed, 123 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
new file mode 100644
index ..61ed6dc7740b
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE it66121 HDMI bridge Device Tree Bindings
+
+maintainers:
+ - Phong LE
+ - Neil Armstrong
+
+description: |
+ The IT66121 is a high-performance and low-power single channel HDMI
+ transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward
compatible
+ to DVI 1.0 specifications.
+
+properties:
+ compatible:
+const: ite,it66121
+
+ reg:
+maxItems: 1
+description: base I2C address of the device
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active low reset
+
+ vrf12-supply:
+description: Regulator for 1.2V analog core power.
+
+ vcn33-supply:
+description: Regulator for 3.3V digital core power.
+
+ vcn18-supply:
+description: Regulator for 1.8V IO core power.
+
+ interrupts:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: DPI input port.
+
+properties:
+ endpoint:
+$ref: /schemas/graph.yaml#/$defs/endpoint-base
+unevaluatedProperties: false
+
+properties:
+ bus-width:
+description:
+ Endpoint bus width.
+enum:
+ - 12 # 12 data lines connected and dual-edge mode
+ - 24 # 24 data lines connected and single-edge
mode
+default: 24
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: HDMI Connector port.
+
+required:
+ - port@0
+ - port@1
Should port@1 really be required? Since the chip itself handles the
hotplug detection and stuff like DCC, I'm not sure what to connect here.
Cheers,
-Paul
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vrf12-supply
+ - vcn33-supply
+ - vcn18-supply
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ it66121hdmitx: it66121hdmitx@4c {
+compatible = "ite,it66121";
+pinctrl-names = "default";
+pinctrl-0 = <&ite_pins_default>;
+vcn33-supply = <&mt6358_vcn33_wifi_reg>;
+vcn18-supply = <&mt6358_vcn18_reg>;
+vrf12-supply = <&mt6358_vrf12_reg>;
+reset-gpios = <&pio 160 1 /* GPIO_ACTIVE_LOW */>;
+interrupt-parent = <&pio>;
+interrupts = <4 8 /* IRQ_TYPE_LEVEL_LOW */>;
+reg = <0x4c>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+it66121_in: endpoint {
+ bus-width = <12>;
+ remote-endpoint = <&display_out>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+hdmi_conn_out: endpoint {
+ remote-endpoint = <&hdmi_conn_in>;
+};
+ };
+};
+ };
+};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] efifb: Check efifb_pci_dev before using it
On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng
wrote:
>
> On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
> a PCI device.
>
> So make sure efifb_pci_dev is found before using it.
>
> Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> D0")
> BugLink: https://bugs.launchpad.net/bugs/1922403
> Signed-off-by: Kai-Heng Feng
Reviewed-by: Alex Deucher
> ---
> drivers/video/fbdev/efifb.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index f58a545b3bf3..8ea8f079cde2 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -575,7 +575,8 @@ static int efifb_probe(struct platform_device *dev)
> goto err_fb_dealoc;
> }
> fb_info(info, "%s frame buffer device\n", info->fix.id);
> - pm_runtime_get_sync(&efifb_pci_dev->dev);
> + if (efifb_pci_dev)
> + pm_runtime_get_sync(&efifb_pci_dev->dev);
> return 0;
>
> err_fb_dealoc:
> @@ -602,7 +603,8 @@ static int efifb_remove(struct platform_device *pdev)
> unregister_framebuffer(info);
> sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
> framebuffer_release(info);
> - pm_runtime_put(&efifb_pci_dev->dev);
> + if (efifb_pci_dev)
> + pm_runtime_put(&efifb_pci_dev->dev);
>
> return 0;
> }
> --
> 2.30.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] MAINTAINERS: add it66121 HDMI bridge driver entry
On Mon, 12 Apr 2021 at 17:47, Neil Armstrong wrote: > > On 12/04/2021 17:46, Neil Armstrong wrote: > > From: Phong LE > > > > Add Neil Armstrong and myself as maintainers > > > > Signed-off-by: Phong LE > > Obviously: > Signed-off-by: Neil Armstrong > > > --- > > MAINTAINERS | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 9ae8444c96b4..ff6450c83049 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9515,6 +9515,14 @@ Q: > > http://patchwork.linuxtv.org/project/linux-media/list/ > > T: git git://linuxtv.org/anttip/media_tree.git > > F: drivers/media/tuners/it913x* > > > > +ITE IT66121 HDMI BRIDGE DRIVER > > +M: Phong LE > > +M: Neil Armstrong > > +S: Maintained > > +F: drivers/gpu/drm/bridge/ite-it66121.c > > +T: git git://anongit.freedesktop.org/drm/drm-misc I'm getting a checkpatch --strict warning here. The two above lines should switch places. WARNING: Misordered MAINTAINERS entry - list 'T:' before 'F:' #27: FILE: MAINTAINERS:9537: +F:drivers/gpu/drm/bridge/ite-it66121.c +T:git git://anongit.freedesktop.org/drm/drm-misc With this warning silenced, feel free to add my r-b. Reviewed-by: Robert Foss > > +F: Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml > > + > > IVTV VIDEO4LINUX DRIVER > > M: Andy Walls > > L: linux-me...@vger.kernel.org > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] efifb: Check efifb_pci_dev before using it
On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
a PCI device.
So make sure efifb_pci_dev is found before using it.
Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0")
BugLink: https://bugs.launchpad.net/bugs/1922403
Signed-off-by: Kai-Heng Feng
---
drivers/video/fbdev/efifb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index f58a545b3bf3..8ea8f079cde2 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -575,7 +575,8 @@ static int efifb_probe(struct platform_device *dev)
goto err_fb_dealoc;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
- pm_runtime_get_sync(&efifb_pci_dev->dev);
+ if (efifb_pci_dev)
+ pm_runtime_get_sync(&efifb_pci_dev->dev);
return 0;
err_fb_dealoc:
@@ -602,7 +603,8 @@ static int efifb_remove(struct platform_device *pdev)
unregister_framebuffer(info);
sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
framebuffer_release(info);
- pm_runtime_put(&efifb_pci_dev->dev);
+ if (efifb_pci_dev)
+ pm_runtime_put(&efifb_pci_dev->dev);
return 0;
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge/sii8620: fix dependency on extcon
Hey Randy, Thanks for looking at this! On Fri, 9 Apr 2021 at 18:38, Randy Dunlap wrote: > > On 4/8/21 6:07 AM, Robert Foss wrote: > > The DRM_SIL_SII8620 kconfig has a weak `imply` dependency > > on EXTCON, which causes issues when sii8620 is built > > as a builtin and EXTCON is built as a module. > > > > The symptoms are 'undefined reference' errors caused > > by the symbols in EXTCON not being available > > to the sii8620 driver. > > > > Signed-off-by: Robert Foss > > Reported-by: kernel test robot > > --- > > > > Changes since v1: > > - Fix typo on comment > > > > drivers/gpu/drm/bridge/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index 22a467abd3e9..2289b44613af 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -169,7 +169,7 @@ config DRM_SIL_SII8620 > > tristate "Silicon Image SII8620 HDMI/MHL bridge" > > depends on OF > > select DRM_KMS_HELPER > > - imply EXTCON > > + depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in > > depends on RC_CORE || !RC_CORE > > help > > Silicon Image SII8620 HDMI/MHL bridge chip driver. > > > > That gives me: (on linux-next 20210409) > > drivers/gpu/drm/Kconfig:77:error: recursive dependency detected! > drivers/gpu/drm/Kconfig:77: symbol DRM_KMS_HELPER is selected by > DRM_SIL_SII8620 > drivers/gpu/drm/bridge/Kconfig:168: symbol DRM_SIL_SII8620 depends on > EXTCON > drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER > drivers/power/supply/Kconfig:499: symbol CHARGER_MANAGER depends on > POWER_SUPPLY > drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by > OLPC_XO1_SCI > arch/x86/Kconfig:2757: symbol OLPC_XO1_SCI depends on GPIO_CS5535 > drivers/gpio/Kconfig:1156: symbol GPIO_CS5535 depends on GPIOLIB > drivers/gpio/Kconfig:14:symbol GPIOLIB is selected by I2C_MUX_LTC4306 > drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C > drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC > drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB > drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER > drivers/gpu/drm/Kconfig:83: symbol DRM_KMS_FB_HELPER depends on > DRM_KMS_HELPER > For a resolution refer to Documentation/kbuild/kconfig-language.rst > subsection "Kconfig recursive dependency limitations" I'm not sure how to avoid this circular dependency. The above solution is what I've seen w/r to issues like [1]. Clearly it doesn't work in this situation. `select EXTCON` doesn't seem to cause this dependency error, but I'm not sure it accurately represents the dependency sii8620 has on extcon. [1] https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix "mitigations" parsing if i915 is builtin
On Tue, Apr 13, 2021 at 05:02:40PM +0800, Jisheng Zhang wrote:
> I met below error during boot with i915 builtin if pass
> "i915.mitigations=off":
> [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
>
> The reason is slab subsystem isn't ready at that time, so kstrdup()
> returns NULL. Fix this issue by using stack var instead of kstrdup().
>
> Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
> mitigations")
> Signed-off-by: Jisheng Zhang
> ---
> drivers/gpu/drm/i915/i915_mitigations.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
> b/drivers/gpu/drm/i915/i915_mitigations.c
> index 84f12598d145..7dadf41064e0 100644
> --- a/drivers/gpu/drm/i915/i915_mitigations.c
> +++ b/drivers/gpu/drm/i915/i915_mitigations.c
> @@ -29,15 +29,13 @@ bool i915_mitigate_clear_residuals(void)
> static int mitigations_set(const char *val, const struct kernel_param *kp)
> {
> unsigned long new = ~0UL;
> - char *str, *sep, *tok;
> + char str[64], *sep, *tok;
> bool first = true;
> int err = 0;
>
> BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
>
> - str = kstrdup(val, GFP_KERNEL);
> - if (!str)
> - return -ENOMEM;
> + strncpy(str, val, sizeof(str) - 1);
I don't think strncpy() guarantees that the string is properly
terminated.
Also commit b1b6bed3b503 ("usb: core: fix quirks_param_set() writing to
a const pointer") looks broken as well given your findings, and
arch/um/drivers/virtio_uml.c seems to suffer from this as well.
kernel/params.c itself seems to have some slab_is_available() magic
around kmalloc().
I used the following cocci snippet to find these:
@find@
identifier O, F;
position PS;
@@
struct kernel_param_ops O = {
...,
.set = F@PS
,...
};
@alloc@
identifier ALLOC =~ "^k.*(alloc|dup)";
identifier find.F;
position PA;
@@
F(...) {
<+...
ALLOC@PA(...)
...+>
}
@script:python depends on alloc@
ps << find.PS;
pa << alloc.PA;
@@
coccilib.report.print_report(ps[0], "struct")
coccilib.report.print_report(pa[0], "alloc")
That could of course miss a bunch more if they allocate
via some other function I didn't consider.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm/ttm: minor range manager coding style clean ups
On Tue, 13 Apr 2021 at 14:53, Christian König wrote: > > No functional changes, just removing the leftovers from the redesign. > > Signed-off-by: Christian König Reviewed-by: Matthew Auld ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/7] drm/amdgpu: check base size instead of mem.num_pages
On Tue, 13 Apr 2021 at 14:52, Christian König wrote: > > Drop some ussage of mem in the code. usage > > Signed-off-by: Christian König Reviewed-by: Matthew Auld ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings
Hi Neil,
Thank you for the patch.
On Mon, Apr 12, 2021 at 05:46:46PM +0200, Neil Armstrong wrote:
> From: Phong LE
>
> Add the ITE bridge HDMI it66121 bindings.
>
> Signed-off-by: Phong LE
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/bridge/ite,it66121.yaml | 123 ++
> 1 file changed, 123 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
> b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
> new file mode 100644
> index ..61ed6dc7740b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
> @@ -0,0 +1,123 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ITE it66121 HDMI bridge Device Tree Bindings
> +
> +maintainers:
> + - Phong LE
> + - Neil Armstrong
> +
> +description: |
> + The IT66121 is a high-performance and low-power single channel HDMI
> + transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward
> compatible
> + to DVI 1.0 specifications.
> +
> +properties:
> + compatible:
> +const: ite,it66121
> +
> + reg:
> +maxItems: 1
> +description: base I2C address of the device
You can drop the description.
> +
> + reset-gpios:
> +maxItems: 1
> +description: GPIO connected to active low reset
> +
> + vrf12-supply:
> +description: Regulator for 1.2V analog core power.
> +
> + vcn33-supply:
> +description: Regulator for 3.3V digital core power.
> +
> + vcn18-supply:
> +description: Regulator for 1.8V IO core power.
> +
> + interrupts:
> +maxItems: 1
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +unevaluatedProperties: false
> +description: DPI input port.
> +
> +properties:
> + endpoint:
> +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> +unevaluatedProperties: false
> +
> +properties:
> + bus-width:
> +description:
> + Endpoint bus width.
> +enum:
> + - 12 # 12 data lines connected and dual-edge mode
> + - 24 # 24 data lines connected and single-edge mode
> +default: 24
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: HDMI Connector port.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> + - vrf12-supply
> + - vcn33-supply
> + - vcn18-supply
> + - interrupts
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
It's customary to indent DT examples with 4 spaces.
> +
> + it66121hdmitx: it66121hdmitx@4c {
> +compatible = "ite,it66121";
> +pinctrl-names = "default";
> +pinctrl-0 = <&ite_pins_default>;
> +vcn33-supply = <&mt6358_vcn33_wifi_reg>;
> +vcn18-supply = <&mt6358_vcn18_reg>;
> +vrf12-supply = <&mt6358_vrf12_reg>;
> +reset-gpios = <&pio 160 1 /* GPIO_ACTIVE_LOW */>;
You can #include the necessary headers at the top of the example, and
use GPIO_ACTIVE_LOW and IRQ_TYPE_LEVEL_LOW to replace the numerical
values.
Reviewed-by: Laurent Pinchart
> +interrupt-parent = <&pio>;
> +interrupts = <4 8 /* IRQ_TYPE_LEVEL_LOW */>;
> +reg = <0x4c>;
> +
> +ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> +reg = <0>;
> +it66121_in: endpoint {
> + bus-width = <12>;
> + remote-endpoint = <&display_out>;
> +};
> + };
> +
> + port@1 {
> +reg = <1>;
> +hdmi_conn_out: endpoint {
> + remote-endpoint = <&hdmi_conn_in>;
> +};
> + };
> +};
> + };
> +};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/nouveau: use bo->base.size instead of mem->num_pages
On Tue, 13 Apr 2021 at 14:52, Christian König
wrote:
>
> Change a couple of cases where it makes more sense to use the base size
> instead of the number of pages in the resource.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c| 9 -
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_gem.c | 4 ++--
> 3 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 2d5d68fc15c2..6dbcbe2fa55f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -302,7 +302,6 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
> align, u32 domain,
> int type = sg ? ttm_bo_type_sg : ttm_bo_type_device;
> int ret;
>
> - nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
So this was redundant, since ttm_bo_init_reserved() already did this for us?
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(&nvbo->io_reserve_lru);
>
> @@ -364,12 +363,12 @@ static void
> set_placement_range(struct nouveau_bo *nvbo, uint32_t domain)
> {
> struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
> - u32 vram_pages = drm->client.device.info.ram_size >> PAGE_SHIFT;
> + u64 vram_size = drm->client.device.info.ram_size;
> unsigned i, fpfn, lpfn;
>
> if (drm->client.device.info.family == NV_DEVICE_INFO_V0_CELSIUS &&
> nvbo->mode && (domain & NOUVEAU_GEM_DOMAIN_VRAM) &&
> - nvbo->bo.mem.num_pages < vram_pages / 4) {
> + nvbo->bo.base.size < vram_size / 4) {
> /*
> * Make sure that the color and depth buffers are handled
> * by independent memory controller units. Up to a 9x
> @@ -377,11 +376,11 @@ set_placement_range(struct nouveau_bo *nvbo, uint32_t
> domain)
> * at the same time.
> */
> if (nvbo->zeta) {
> - fpfn = vram_pages / 2;
> + fpfn = (vram_size / 2) >> PAGE_SHIFT;
> lpfn = ~0;
> } else {
> fpfn = 0;
> - lpfn = vram_pages / 2;
> + lpfn = (vram_size / 2) >> PAGE_SHIFT;
> }
> for (i = 0; i < nvbo->placement.num_placement; ++i) {
> nvbo->placements[i].fpfn = fpfn;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index 4fc0fa696461..93ac78bda750 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -379,10 +379,10 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
> FBINFO_HWACCEL_IMAGEBLIT;
> info->fbops = &nouveau_fbcon_sw_ops;
> info->fix.smem_start = nvbo->bo.mem.bus.offset;
> - info->fix.smem_len = nvbo->bo.mem.num_pages << PAGE_SHIFT;
> + info->fix.smem_len = nvbo->bo.base.size;
Is byte level granularity a thing in general? I would have assumed
that base.size is always aligned to PAGE_SIZE or whatever? At least in
ttm_bo_init_reserved() we first align the size and then calculate the
num_pages, so not sure. Hopefully this is not a concern, and should be
equivalent.
Reviewed-by: Matthew Auld
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tuesday, April 13th, 2021 at 11:49 AM, Daniel Vetter wrote: > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver Prepend an ampersand like so and a hyperlink will be rendered: Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings
On Mon, 12 Apr 2021 17:46:46 +0200, Neil Armstrong wrote: > From: Phong LE > > Add the ITE bridge HDMI it66121 bindings. > > Signed-off-by: Phong LE > Signed-off-by: Neil Armstrong > --- > .../bindings/display/bridge/ite,it66121.yaml | 123 ++ > 1 file changed, 123 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] drm/vc4: crtc: Skip the TXP
The vc4_set_crtc_possible_masks is meant to run over all the encoders
and then set their possible_crtcs mask to their associated pixelvalve.
However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into
a CRTC of its own"), the TXP has been turned to a CRTC and encoder of
its own, and while it does indeed register an encoder, it no longer has
an associated pixelvalve. The code will thus run over the TXP encoder
and set a bogus possible_crtcs mask, overriding the one set in the TXP
bind function.
In order to fix this, let's skip any virtual encoder.
Cc: # v5.9+
Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own")
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 269390bc586e..f1f2e8cbce79 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -1018,6 +1018,9 @@ static void vc4_set_crtc_possible_masks(struct drm_device
*drm,
struct vc4_encoder *vc4_encoder;
int i;
+ if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
+ continue;
+
vc4_encoder = to_vc4_encoder(encoder);
for (i = 0; i < ARRAY_SIZE(pv_data->encoder_types); i++) {
if (vc4_encoder->type == encoder_types[i]) {
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] drm/vc4: hdmi: Enable the scrambler
The HDMI controller on the BCM2711 includes a scrambler in order to
reach the HDMI 2.0 modes that require it. Let's add the support for it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 64 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 ++
2 files changed, 67 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 01d24ce8a795..bda12fea0dce 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,8 @@
#define VC5_HDMI_VERTB_VSPO_SHIFT 16
#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
+#define VC5_HDMI_SCRAMBLER_CTL_ENABLE BIT(0)
+
#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10, 8)
@@ -462,6 +465,64 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
+static bool vc4_hdmi_supports_scrambling(struct drm_encoder *encoder,
+struct drm_display_mode *mode)
+{
+ struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ struct drm_display_info *display = &vc4_hdmi->connector.display_info;
+
+ if (!vc4_encoder->hdmi_monitor)
+ return false;
+
+ if (!display->hdmi.scdc.supported ||
+ !display->hdmi.scdc.scrambling.supported)
+ return false;
+
+ return true;
+}
+
+static void vc4_hdmi_enable_scrambling(struct drm_encoder *encoder)
+{
+ struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+
+ if (!vc4_hdmi_supports_scrambling(encoder, mode))
+ return;
+
+ if (!vc4_hdmi_mode_needs_scrambling(mode))
+ return;
+
+ drm_scdc_set_high_tmds_clock_ratio(vc4_hdmi->ddc, true);
+ drm_scdc_set_scrambling(vc4_hdmi->ddc, true);
+
+ HDMI_WRITE(HDMI_SCRAMBLER_CTL, HDMI_READ(HDMI_SCRAMBLER_CTL) |
+ VC5_HDMI_SCRAMBLER_CTL_ENABLE);
+}
+
+static void vc4_hdmi_disable_scrambling(struct drm_encoder *encoder)
+{
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ struct drm_crtc *crtc = encoder->crtc;
+
+ /*
+* At boot, encoder->crtc will be NULL. Since we don't know the
+* state of the scrambler and in order to avoid any
+* inconsistency, let's disable it all the time.
+*/
+ if (crtc && !vc4_hdmi_supports_scrambling(encoder, &crtc->mode))
+ return;
+
+ if (crtc && !vc4_hdmi_mode_needs_scrambling(&crtc->mode))
+ return;
+
+ HDMI_WRITE(HDMI_SCRAMBLER_CTL, HDMI_READ(HDMI_SCRAMBLER_CTL) &
+ ~VC5_HDMI_SCRAMBLER_CTL_ENABLE);
+
+ drm_scdc_set_scrambling(vc4_hdmi->ddc, false);
+ drm_scdc_set_high_tmds_clock_ratio(vc4_hdmi->ddc, false);
+}
+
static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
@@ -474,6 +535,8 @@ static void vc4_hdmi_encoder_post_crtc_disable(struct
drm_encoder *encoder,
HDMI_WRITE(HDMI_VID_CTL,
HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_BLANKPIX);
+
+ vc4_hdmi_disable_scrambling(encoder);
}
static void vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder,
@@ -924,6 +987,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct
drm_encoder *encoder,
}
vc4_hdmi_recenter_fifo(vc4_hdmi);
+ vc4_hdmi_enable_scrambling(encoder);
}
static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
index e1b58eac766f..19d2fdc446bc 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
@@ -100,6 +100,7 @@ enum vc4_hdmi_field {
HDMI_RM_FORMAT,
HDMI_RM_OFFSET,
HDMI_SCHEDULER_CONTROL,
+ HDMI_SCRAMBLER_CTL,
HDMI_SW_RESET_CONTROL,
HDMI_TX_PHY_CHANNEL_SWAP,
HDMI_TX_PHY_CLK_DIV,
@@ -238,6 +239,7 @@ static const struct vc4_hdmi_register __maybe_unused
vc5_hdmi_hdmi0_fields[] = {
VC4_HDMI_REG(HDMI_GCP_CONFIG, 0x178),
VC4_HDMI_REG(HDMI_GCP_WORD_1, 0x17c),
VC4_HDMI_REG(HDMI_HOTPLUG, 0x1a8),
+ VC4_HDMI_REG(HDMI_SCRAMBLER_CTL, 0x1c4),
VC5_DVP_REG(HDMI_CLOCK_STOP, 0x0bc),
VC5_DVP_REG(HDMI_VEC_INTERFACE_XBAR, 0x0f0),
@@ -317,6 +319,7 @@ static const struct vc4_hdmi_register __maybe_unused
vc5_hdmi_hdmi1_fields[] = {
VC4_HDMI_REG(HDMI_GCP_CONFIG, 0x178),
VC4_HDMI_REG(HDMI_GCP_WORD_1, 0x17c),
[PATCH v3 9/9] drm/vc4: hdmi: Raise the maximum clock rate
Now that we have the infrastructure in place, we can raise the maximum
pixel rate we can reach for HDMI0 on the BCM2711.
HDMI1 is left untouched since its pixelvalve has a smaller FIFO and
would need a clock faster than what we can provide to support the same
modes.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index bda12fea0dce..aecda5766a9c 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -2212,7 +2212,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi0_variant = {
.encoder_type = VC4_ENCODER_TYPE_HDMI0,
.debugfs_name = "hdmi0_regs",
.card_name = "vc4-hdmi-0",
- .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
+ .max_pixel_clock= 6,
.registers = vc5_hdmi_hdmi0_fields,
.num_registers = ARRAY_SIZE(vc5_hdmi_hdmi0_fields),
.phy_lane_mapping = {
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/9] drm/vc4: hdmi: Properly compute the BVB clock rate
The BVB clock rate computation doesn't take into account a mode clock of
594MHz that we're going to need to support 4k60.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9c919472ae84..c50dc5a59b2f 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -91,7 +91,6 @@
# define VC4_HD_M_ENABLE BIT(0)
#define CEC_CLOCK_FREQ 4
-#define VC4_HSM_MID_CLOCK 149985000
#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
@@ -739,7 +738,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
- unsigned long pixel_rate, hsm_rate;
+ unsigned long bvb_rate, pixel_rate, hsm_rate;
int ret;
ret = pm_runtime_get_sync(&vc4_hdmi->pdev->dev);
@@ -793,12 +792,14 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
vc4_hdmi_cec_update_clk_div(vc4_hdmi);
- /*
-* FIXME: When the pixel freq is 594MHz (4k60), this needs to be setup
-* at 300MHz.
-*/
- ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock,
- (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 :
7500));
+ if (pixel_rate > 29700)
+ bvb_rate = 3;
+ else if (pixel_rate > 14850)
+ bvb_rate = 15000;
+ else
+ bvb_rate = 7500;
+
+ ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock, bvb_rate);
if (ret) {
DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/9] drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies
In order to reach the frequencies needed to output at 594MHz, the
firmware needs to be configured with the appropriate parameters in the
config.txt file (enable_hdmi_4kp60 and force_turbo).
Let's detect it at bind time, warn the user if we can't, and filter out
the relevant modes.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 31 +++
drivers/gpu/drm/vc4/vc4_hdmi.h | 8
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index c50dc5a59b2f..01d24ce8a795 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -94,6 +94,11 @@
#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
+static bool vc4_hdmi_mode_needs_scrambling(const struct drm_display_mode *mode)
+{
+ return (mode->clock * 1000) > HDMI_14_MAX_TMDS_CLK;
+}
+
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
@@ -210,6 +215,18 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
+ if (vc4_hdmi->disable_4kp60) {
+ struct drm_device *drm = connector->dev;
+ struct drm_display_mode *mode;
+
+ list_for_each_entry(mode, &connector->probed_modes, head) {
+ if (vc4_hdmi_mode_needs_scrambling(mode)) {
+ drm_warn_once(drm, "The core clock cannot reach
frequencies high enough to support 4k @ 60Hz.");
+ drm_warn_once(drm, "Please change your
config.txt file to add hdmi_enable_4kp60.");
+ }
+ }
+ }
+
return ret;
}
@@ -959,6 +976,9 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ if (vc4_hdmi->disable_4kp60 && (pixel_rate > HDMI_14_MAX_TMDS_CLK))
+ return -EINVAL;
+
vc4_state->pixel_rate = pixel_rate;
return 0;
@@ -978,6 +998,9 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
if ((mode->clock * 1000) > vc4_hdmi->variant->max_pixel_clock)
return MODE_CLOCK_HIGH;
+ if (vc4_hdmi->disable_4kp60 && vc4_hdmi_mode_needs_scrambling(mode))
+ return MODE_CLOCK_HIGH;
+
return MODE_OK;
}
@@ -1993,6 +2016,14 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
vc4_hdmi->disable_wifi_frequencies =
of_property_read_bool(dev->of_node, "wifi-2.4ghz-coexistence");
+ if (variant->max_pixel_clock == 6) {
+ struct vc4_dev *vc4 = to_vc4_dev(drm);
+ long max_rate = clk_round_rate(vc4->hvs->core_clk, 55000);
+
+ if (max_rate < 55000)
+ vc4_hdmi->disable_4kp60 = true;
+ }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 3cebd1fd00fc..3cd021136402 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -154,6 +154,14 @@ struct vc4_hdmi {
*/
bool disable_wifi_frequencies;
+ /*
+* Even if HDMI0 on the RPi4 can output modes requiring a pixel
+* rate higher than 297MHz, it needs some adjustments in the
+* config.txt file to be able to do so and thus won't always be
+* available.
+*/
+ bool disable_4kp60;
+
struct cec_adapter *cec_adap;
struct cec_msg cec_rx_msg;
bool cec_tx_ok;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] drm/vc4: Rework the encoder retrieval code
Due to a FIFO that cannot be flushed between the pixelvalve and the HDMI
controllers on BCM2711, we need to carefully disable both at boot time
if they were left enabled by the firmware.
However, at the time we're running that code, the struct drm_connector
encoder pointer isn't set yet, and thus we cannot retrieve the encoder
associated to our CRTC.
We can however make use of the fact that we have a less flexible setup
than what DRM allows where we have a 1:1 relationship between our CRTCs
and encoders (and connectors), and thus store the crtc associated to our
encoder at boot time.
We cannot do that at the time the encoders are probed though, since the
CRTCs won't be probed yet and thus we don't know at that time which CRTC
index we're going to get, so let's do this in two passes: we can first
bind all the components and then once they all are bound, we can iterate
over all the encoders to find their associated CRTC and set the pointer.
This is similar to what we're doing to set the possible_crtcs field.
Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 25 +--
drivers/gpu/drm/vc4/vc4_drv.c | 36 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 ++
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index f1f2e8cbce79..2bcd7c4e0fc7 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -255,6 +255,19 @@ static u32 vc4_crtc_get_fifo_full_level_bits(struct
vc4_crtc *vc4_crtc,
PV_CONTROL_FIFO_LEVEL);
}
+static struct drm_encoder *vc4_get_connector_encoder(struct drm_connector
*connector)
+{
+ struct drm_encoder *encoder;
+
+ if (drm_WARN_ON(connector->dev, hweight32(connector->possible_encoders)
!= 1))
+ return NULL;
+
+ drm_connector_for_each_possible_encoder(connector, encoder)
+ return encoder;
+
+ return NULL;
+}
+
/*
* Returns the encoder attached to the CRTC.
*
@@ -269,9 +282,17 @@ static struct drm_encoder *vc4_get_crtc_encoder(struct
drm_crtc *crtc)
drm_connector_list_iter_begin(crtc->dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
- if (connector->state->crtc == crtc) {
+ struct drm_encoder *encoder;
+ struct vc4_encoder *vc4_encoder;
+
+ encoder = vc4_get_connector_encoder(connector);
+ if (!encoder)
+ continue;
+
+ vc4_encoder = to_vc4_encoder(encoder);
+ if (vc4_encoder->crtc == crtc) {
drm_connector_list_iter_end(&conn_iter);
- return connector->encoder;
+ return encoder;
}
}
drm_connector_list_iter_end(&conn_iter);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 556ad0f02a0d..cd1fb75c66a7 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -199,6 +199,41 @@ static int compare_dev(struct device *dev, void *data)
return dev == data;
}
+static struct drm_crtc *vc4_drv_find_crtc(struct drm_device *drm,
+ struct drm_encoder *encoder)
+{
+ struct drm_crtc *crtc;
+
+ if (WARN_ON(hweight32(encoder->possible_crtcs) != 1))
+ return NULL;
+
+ drm_for_each_crtc(crtc, drm) {
+ if (!drm_encoder_crtc_ok(encoder, crtc))
+ continue;
+
+ return crtc;
+ }
+
+ return NULL;
+}
+
+static void vc4_drv_set_encoder_data(struct drm_device *drm)
+{
+ struct drm_encoder *encoder;
+
+ drm_for_each_encoder(encoder, drm) {
+ struct vc4_encoder *vc4_encoder;
+ struct drm_crtc *crtc;
+
+ crtc = vc4_drv_find_crtc(drm, encoder);
+ if (WARN_ON(!crtc))
+ return;
+
+ vc4_encoder = to_vc4_encoder(encoder);
+ vc4_encoder->crtc = crtc;
+ }
+}
+
static void vc4_match_add_drivers(struct device *dev,
struct component_match **match,
struct platform_driver *const *drivers,
@@ -261,6 +296,7 @@ static int vc4_drm_bind(struct device *dev)
ret = component_bind_all(dev, drm);
if (ret)
return ret;
+ vc4_drv_set_encoder_data(drm);
ret = vc4_plane_create_additional_planes(drm);
if (ret)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index a7500716cf3f..a22e49665d9c 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -438,6 +438,16 @@ enum vc4_encoder_type {
struct vc4_encoder {
struct drm_encoder base;
+
+ /*
+* At boot t
[PATCH v3 5/9] drm/vc4: hvs: Make the HVS bind first
We'll need to have the HVS binding before the HDMI controllers so that
we can check whether the firmware allows to run in 4kp60. Reorder a bit
the component list, and document the current constraints we're aware of.
Acked-by: Dave Stevenson
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index cd1fb75c66a7..fef31d6eea60 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -339,12 +339,21 @@ static const struct component_master_ops vc4_drm_ops = {
.unbind = vc4_drm_unbind,
};
+/*
+ * This list determines the binding order of our components, and we have
+ * a few constraints:
+ * - The TXP driver needs to be bound before the PixelValves (CRTC)
+ * but after the HVS to set the possible_crtc field properly
+ * - The HDMI driver needs to be bound after the HVS so that we can
+ * lookup the HVS maximum core clock rate and figure out if we
+ * support 4kp60 or not.
+ */
static struct platform_driver *const component_drivers[] = {
+ &vc4_hvs_driver,
&vc4_hdmi_driver,
&vc4_vec_driver,
&vc4_dpi_driver,
&vc4_dsi_driver,
- &vc4_hvs_driver,
&vc4_txp_driver,
&vc4_crtc_driver,
&vc4_v3d_driver,
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/9] drm/vc4: txp: Properly set the possible_crtcs mask
The current code does a binary OR on the possible_crtcs variable of the
TXP encoder, while we want to set it to that value instead.
Cc: # v5.9+
Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own")
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index c0122d83b651..2fc7f4b5fa09 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -507,7 +507,7 @@ static int vc4_txp_bind(struct device *dev, struct device
*master, void *data)
return ret;
encoder = &txp->connector.encoder;
- encoder->possible_crtcs |= drm_crtc_mask(crtc);
+ encoder->possible_crtcs = drm_crtc_mask(crtc);
ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
dev_name(dev), txp);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/9] drm/vc4: hdmi: Prevent clock unbalance
Since we fixed the hooks to disable the encoder at boot, we now have an
unbalanced clk_disable call at boot since we never enabled them in the
first place.
Let's mimic the state of the hardware and enable the clocks at boot if
the controller is enabled to get the use-count right.
Cc: # v5.10+
Fixes: 09c438139b8f ("drm/vc4: hdmi: Implement finer-grained hooks")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 1fda574579af..9c919472ae84 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1995,6 +1995,14 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
+ if ((of_device_is_compatible(dev->of_node, "brcm,bcm2711-hdmi0") ||
+of_device_is_compatible(dev->of_node, "brcm,bcm2711-hdmi1")) &&
+ HDMI_READ(HDMI_VID_CTL) & VC4_HD_VID_CTL_ENABLE) {
+ clk_prepare_enable(vc4_hdmi->pixel_clock);
+ clk_prepare_enable(vc4_hdmi->hsm_clock);
+ clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+ }
+
pm_runtime_enable(dev);
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/9] drm/vc4: hdmi: Support the 4k @ 60Hz modes
Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 option. The firmware also has a glitch at the moment and will not properly release the BSC controllers, which will make the EDID retrieval fail. We can work around this using the following config.txt options: disable_fw_kms_setup=1 hdmi_edid_file:0=1 hdmi_edid_filename:0=1366x768.bin hdmi_ignore_edid:0=1 hdmi_edid_file:1=1 hdmi_edid_filename:1=1366x768.bin hdmi_ignore_edid:1=1 A fix will come for the firmware eventually. Let me know what you think, Maxime --- Changes from v2: - Gathered the various tags - Added Cc stable when relevant - Split out the check to test whether the scrambler is required into an helper - Fixed a bug where the scrambler state wouldn't be tracked properly if it was enabled at boot Changes from v1: - Dropped the range accessors - Drop the mention of force_turbo - Reordered the SCRAMBLER_CTL register to match the offset - Removed duplicate HDMI_14_MAX_TMDS_CLK define - Warn about enable_hdmi_4kp60 only if there's some modes that can't be reached - Rework the BVB clock computation Maxime Ripard (9): drm/vc4: txp: Properly set the possible_crtcs mask drm/vc4: crtc: Skip the TXP drm/vc4: Rework the encoder retrieval code drm/vc4: hdmi: Prevent clock unbalance drm/vc4: hvs: Make the HVS bind first drm/vc4: hdmi: Properly compute the BVB clock rate drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies drm/vc4: hdmi: Enable the scrambler drm/vc4: hdmi: Raise the maximum clock rate drivers/gpu/drm/vc4/vc4_crtc.c | 28 ++- drivers/gpu/drm/vc4/vc4_drv.c | 47 ++- drivers/gpu/drm/vc4/vc4_drv.h | 10 +++ drivers/gpu/drm/vc4/vc4_hdmi.c | 122 ++-- drivers/gpu/drm/vc4/vc4_hdmi.h | 8 ++ drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 + drivers/gpu/drm/vc4/vc4_txp.c | 2 +- 7 files changed, 207 insertions(+), 13 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, Apr 13, 2021 at 04:11:29PM +0200, Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Apr 2021 11:49:03 +0200
> > Daniel Vetter wrote:
> >
> > > It's very confusing for userspace to have to deal with inconsistencies
> > > here, and some drivers screwed this up a bit. Most just ommitted the
> > > format list when they meant to say that only linear modifier is
> > > allowed, but some also meant that only implied modifiers are
> > > acceptable (because actually none of the planes registered supported
> > > modifiers).
> > >
> > > Now that this is all done consistently across all drivers, document
> > > the rules and enforce it in the drm core.
> > >
> > > Cc: Pekka Paalanen
> > > Signed-off-by: Daniel Vetter
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: Thomas Zimmermann
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_plane.c | 16 +++-
> > > include/drm/drm_mode_config.h | 2 ++
> > > 2 files changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > index 0dd43882fe7c..16a7e3e57f7f 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -128,6 +128,11 @@
> > > * pairs supported by this plane. The blob is a struct
> > > * drm_format_modifier_blob. Without this property the plane doesn't
> > > * support buffers with modifiers. Userspace cannot change this
> > > property.
> > > + *
> > > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> > > + * capability for general modifier support. If this flag is set then
> > > every
> > > + * plane will have the IN_FORMATS property, even when it only
> > > supports
> > > + * DRM_FORMAT_MOD_LINEAR.
> >
> > Ooh, that's even better. But isn't that changing the meaning of the
> > cap? Isn't the cap older than IN_FORMATS?
>
> Hm indeed. But also how exactly are you going to user modifiers without
> IN_FORMATS ... it's a bit hard. I think this is all because we've enabled
> modifiers piece-by-piece and never across the entire thing (e.g. with
> compositor and protocols), so the missing pieces only became apparent
> later on.
Ok I worked git log -Gallow_fb_modifiers and there's 3 drivers which
enabled modifiers before IN_FORMATS was merged:
- i915
- msm/mdp4 (for the tiled NV12 format thing)
- tegra
> I'm not sure whether compositors really want to support this, I guess
> worst case we could disable the cap on these old kernels.
>
> > What about the opposite? Is it allowed to have even a single IN_FORMATS
> > if you don't have the cap?
>
> That direction is enforced since 5.1, because some drivers screwed it up
> and confusion in userspace ensued.
>
> Should I add a bug that on kernels older than 5.1 the situation is more
> murky and there's lots of bugs?
I guess we should recommend to userspace that if they spot an
inconsistency between IN_FORMATS across planes and the cap then maybe they
want to disable modifier support because it might be all kinds of broken?
-Daniel
>
> >
> > > */
> > >
> > > static unsigned int drm_num_planes(struct drm_device *dev)
> > > @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct
> > > drm_device *dev,
> > > format_modifier_count++;
> > > }
> > >
> > > - if (format_modifier_count)
> > > + /* autoset the cap and check for consistency across all planes */
> > > + if (format_modifier_count) {
> > > + WARN_ON(!config->allow_fb_modifiers &&
> > > + !list_empty(&config->plane_list));
> >
> > What does this mean?
>
> If allow_fb_modifiers isn't set yet (we do that in the line below) and we
> are _not_ the first plane that gets added to the driver (that's done
> towards the end of the function) then that means there's already a plane
> registered without modifiers and hence IN_FORMAT. Which we then warn
> about.
>
> >
> > > config->allow_fb_modifiers = true;
> > > + } else {
> > > + WARN_ON(config->allow_fb_modifiers);
>
> This warning here checks the other case of an earlier plane with
> modifiers, but the one we're adding now doesn't have them.
> -Daniel
>
> > > + }
> > >
> > > plane->modifier_count = format_modifier_count;
> > > plane->modifiers = kmalloc_array(format_modifier_count,
> > > @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct
> > > drm_device *dev,
> > > * drm_universal_plane_init() to let the DRM managed resource
> > > infrastructure
> > > * take care of cleanup and deallocation.
> > > *
> > > + * Drivers supporting modifiers must set @format_modifiers on all their
> > > planes,
> > > + * even those that only support DRM_FORMAT_MOD_LINEAR.
> >
> > Good.
> >
> > > + *
> > > * Returns:
> > > * Zero on success, error code on failure.
> > > */
> > > diff --git a/include/drm/drm_mode_config.h b/include/drm
Re: [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, Apr 13, 2021 at 01:54:00PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
> > format list when they meant to say that only linear modifier is
> > allowed, but some also meant that only implied modifiers are
> > acceptable (because actually none of the planes registered supported
> > modifiers).
>
> For a lot of the embedded display drivers that never had any out-of-
> band tiling meta shared with the GPU part, the implied modifier is
> actually DRM_FORMAT_MOD_LINEAR, so maybe that's where some of the
> confusion about needing to specify the modifier list comes from.
Yeah that entire discussion last few days is why I wanted to audit all the
drivers and make sure that going forward we're more explicit&consistent
with all this. There's huge confusion around implied modifier vs "no
IN_FORMATS blob property" and what that exactly means.
-Daniel
> > Now that this is all done consistently across all drivers, document
> > the rules and enforce it in the drm core.
>
> This clarification looks good to me.
>
> Reviewed-by: Lucas Stach
>
> > Cc: Pekka Paalanen
> > Signed-off-by: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_plane.c | 16 +++-
> > include/drm/drm_mode_config.h | 2 ++
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 0dd43882fe7c..16a7e3e57f7f 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -128,6 +128,11 @@
> > * pairs supported by this plane. The blob is a struct
> > * drm_format_modifier_blob. Without this property the plane doesn't
> > * support buffers with modifiers. Userspace cannot change this
> > property.
> > + *
> > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> > + * capability for general modifier support. If this flag is set then
> > every
> > + * plane will have the IN_FORMATS property, even when it only supports
> > + * DRM_FORMAT_MOD_LINEAR.
> > */
> >
> >
> >
> >
> >
> >
> >
> >
> > static unsigned int drm_num_planes(struct drm_device *dev)
> > @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct
> > drm_device *dev,
> > format_modifier_count++;
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> > - if (format_modifier_count)
> > + /* autoset the cap and check for consistency across all planes */
> > + if (format_modifier_count) {
> > + WARN_ON(!config->allow_fb_modifiers &&
> > + !list_empty(&config->plane_list));
> > config->allow_fb_modifiers = true;
> > + } else {
> > + WARN_ON(config->allow_fb_modifiers);
> > + }
> >
> >
> >
> >
> >
> >
> >
> >
> > plane->modifier_count = format_modifier_count;
> > plane->modifiers = kmalloc_array(format_modifier_count,
> > @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
> > *dev,
> > * drm_universal_plane_init() to let the DRM managed resource
> > infrastructure
> > * take care of cleanup and deallocation.
> > *
> > + * Drivers supporting modifiers must set @format_modifiers on all their
> > planes,
> > + * even those that only support DRM_FORMAT_MOD_LINEAR.
> > + *
> > * Returns:
> > * Zero on success, error code on failure.
> > */
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index ab424ddd7665..1ddf7783fdf7 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -909,6 +909,8 @@ struct drm_mode_config {
> > * @allow_fb_modifiers:
> > *
> > * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > +* Note that drivers should not set this directly, it is automatically
> > +* set in drm_universal_plane_init().
> > *
> > * IMPORTANT:
> > *
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter: > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > > Since > > > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > > Author: Paul Kocialkowski > > > Date: Fri Jan 4 09:56:10 2019 +0100 > > > > > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > > > > > this is done automatically as part of plane init, if drivers set the > > > modifier list correctly. Which is the case here. > > > > > > This one actually set it twice on top of what drm_plane_init does, so > > > double-redundant! > > > > That's not true. imx-dcss and imx-drm are two totally separate drivers. > > Maybe we should move imx-drm into its own ipuv3 directory one day to > > make this more clear. Change is still correct, though. > > Hm I greeped for drm_universal_plane_init and didn't find anythinf for the > imx main driver ... where are planes set up for that? Need to review that > they have the modifiers listed in all cases. That's in drivers/gpu/drm/imx/ipuv3-plane.c and modifiers are always set on plane init. Regards, Lucas > > > > > Reviewed-by: Lucas Stach > > > > > Signed-off-by: Daniel Vetter > > > Cc: Philipp Zabel > > > Cc: Shawn Guo > > > Cc: Sascha Hauer > > > Cc: Pengutronix Kernel Team > > > Cc: Fabio Estevam > > > Cc: NXP Linux Team > > > Cc: linux-arm-ker...@lists.infradead.org > > > --- > > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > > > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > > > 2 files changed, 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > index b549ce5e7607..37ae68a7fba5 100644 > > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct > > > dcss_kms_dev *kms) > > > config->min_height = 1; > > > config->max_width = 4096; > > > config->max_height = 4096; > > > - config->allow_fb_modifiers = true; > > > config->normalize_zpos = true; > > > > > > > > > > > > > > > config->funcs = &dcss_drm_mode_config_funcs; > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > > b/drivers/gpu/drm/imx/imx-drm-core.c > > > index 2ded8e4f32d0..8be4edaec958 100644 > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) > > > drm->mode_config.max_height = 4096; > > > drm->mode_config.funcs = &imx_drm_mode_config_funcs; > > > drm->mode_config.helper_private = &imx_drm_mode_config_helpers; > > > - drm->mode_config.allow_fb_modifiers = true; > > > drm->mode_config.normalize_zpos = true; > > > > > > > > > > > > > > > ret = drmm_mode_config_init(drm); > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> On Tue, 13 Apr 2021 11:49:03 +0200
> Daniel Vetter wrote:
>
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
> > format list when they meant to say that only linear modifier is
> > allowed, but some also meant that only implied modifiers are
> > acceptable (because actually none of the planes registered supported
> > modifiers).
> >
> > Now that this is all done consistently across all drivers, document
> > the rules and enforce it in the drm core.
> >
> > Cc: Pekka Paalanen
> > Signed-off-by: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_plane.c | 16 +++-
> > include/drm/drm_mode_config.h | 2 ++
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 0dd43882fe7c..16a7e3e57f7f 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -128,6 +128,11 @@
> > * pairs supported by this plane. The blob is a struct
> > * drm_format_modifier_blob. Without this property the plane doesn't
> > * support buffers with modifiers. Userspace cannot change this
> > property.
> > + *
> > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> > + * capability for general modifier support. If this flag is set then
> > every
> > + * plane will have the IN_FORMATS property, even when it only supports
> > + * DRM_FORMAT_MOD_LINEAR.
>
> Ooh, that's even better. But isn't that changing the meaning of the
> cap? Isn't the cap older than IN_FORMATS?
Hm indeed. But also how exactly are you going to user modifiers without
IN_FORMATS ... it's a bit hard. I think this is all because we've enabled
modifiers piece-by-piece and never across the entire thing (e.g. with
compositor and protocols), so the missing pieces only became apparent
later on.
I'm not sure whether compositors really want to support this, I guess
worst case we could disable the cap on these old kernels.
> What about the opposite? Is it allowed to have even a single IN_FORMATS
> if you don't have the cap?
That direction is enforced since 5.1, because some drivers screwed it up
and confusion in userspace ensued.
Should I add a bug that on kernels older than 5.1 the situation is more
murky and there's lots of bugs?
>
> > */
> >
> > static unsigned int drm_num_planes(struct drm_device *dev)
> > @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct
> > drm_device *dev,
> > format_modifier_count++;
> > }
> >
> > - if (format_modifier_count)
> > + /* autoset the cap and check for consistency across all planes */
> > + if (format_modifier_count) {
> > + WARN_ON(!config->allow_fb_modifiers &&
> > + !list_empty(&config->plane_list));
>
> What does this mean?
If allow_fb_modifiers isn't set yet (we do that in the line below) and we
are _not_ the first plane that gets added to the driver (that's done
towards the end of the function) then that means there's already a plane
registered without modifiers and hence IN_FORMAT. Which we then warn
about.
>
> > config->allow_fb_modifiers = true;
> > + } else {
> > + WARN_ON(config->allow_fb_modifiers);
This warning here checks the other case of an earlier plane with
modifiers, but the one we're adding now doesn't have them.
-Daniel
> > + }
> >
> > plane->modifier_count = format_modifier_count;
> > plane->modifiers = kmalloc_array(format_modifier_count,
> > @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
> > *dev,
> > * drm_universal_plane_init() to let the DRM managed resource
> > infrastructure
> > * take care of cleanup and deallocation.
> > *
> > + * Drivers supporting modifiers must set @format_modifiers on all their
> > planes,
> > + * even those that only support DRM_FORMAT_MOD_LINEAR.
>
> Good.
>
> > + *
> > * Returns:
> > * Zero on success, error code on failure.
> > */
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index ab424ddd7665..1ddf7783fdf7 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -909,6 +909,8 @@ struct drm_mode_config {
> > * @allow_fb_modifiers:
> > *
> > * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > +* Note that drivers should not set this directly, it is automatically
> > +* set in drm_universal_plane_init().
> > *
> > * IMPORTANT:
> > *
>
> Thanks,
> pq
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freed
Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > Since > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > Author: Paul Kocialkowski > > Date: Fri Jan 4 09:56:10 2019 +0100 > > > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > > > this is done automatically as part of plane init, if drivers set the > > modifier list correctly. Which is the case here. > > > > This one actually set it twice on top of what drm_plane_init does, so > > double-redundant! > > That's not true. imx-dcss and imx-drm are two totally separate drivers. > Maybe we should move imx-drm into its own ipuv3 directory one day to > make this more clear. Change is still correct, though. Hm I greeped for drm_universal_plane_init and didn't find anythinf for the imx main driver ... where are planes set up for that? Need to review that they have the modifiers listed in all cases. -Daniel > > Reviewed-by: Lucas Stach > > > Signed-off-by: Daniel Vetter > > Cc: Philipp Zabel > > Cc: Shawn Guo > > Cc: Sascha Hauer > > Cc: Pengutronix Kernel Team > > Cc: Fabio Estevam > > Cc: NXP Linux Team > > Cc: linux-arm-ker...@lists.infradead.org > > --- > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > > 2 files changed, 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > index b549ce5e7607..37ae68a7fba5 100644 > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev > > *kms) > > config->min_height = 1; > > config->max_width = 4096; > > config->max_height = 4096; > > - config->allow_fb_modifiers = true; > > config->normalize_zpos = true; > > > > > > > > > > config->funcs = &dcss_drm_mode_config_funcs; > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > b/drivers/gpu/drm/imx/imx-drm-core.c > > index 2ded8e4f32d0..8be4edaec958 100644 > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) > > drm->mode_config.max_height = 4096; > > drm->mode_config.funcs = &imx_drm_mode_config_funcs; > > drm->mode_config.helper_private = &imx_drm_mode_config_helpers; > > - drm->mode_config.allow_fb_modifiers = true; > > drm->mode_config.normalize_zpos = true; > > > > > > > > > > ret = drmm_mode_config_init(drm); > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/ttm: minor range manager coding style clean ups
No functional changes, just removing the leftovers from the redesign.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 35 -
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 707e5c152896..b1e3f30f7e2d 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -48,7 +48,8 @@ struct ttm_range_manager {
spinlock_t lock;
};
-static inline struct ttm_range_manager *to_range_manager(struct
ttm_resource_manager *man)
+static inline struct ttm_range_manager *
+to_range_manager(struct ttm_resource_manager *man)
{
return container_of(man, struct ttm_range_manager, manager);
}
@@ -109,7 +110,21 @@ static void ttm_range_man_free(struct ttm_resource_manager
*man,
}
}
-static const struct ttm_resource_manager_func ttm_range_manager_func;
+static void ttm_range_man_debug(struct ttm_resource_manager *man,
+ struct drm_printer *printer)
+{
+ struct ttm_range_manager *rman = to_range_manager(man);
+
+ spin_lock(&rman->lock);
+ drm_mm_print(&rman->mm, printer);
+ spin_unlock(&rman->lock);
+}
+
+static const struct ttm_resource_manager_func ttm_range_manager_func = {
+ .alloc = ttm_range_man_alloc,
+ .free = ttm_range_man_free,
+ .debug = ttm_range_man_debug
+};
int ttm_range_man_init(struct ttm_device *bdev,
unsigned type, bool use_tt,
@@ -163,19 +178,3 @@ int ttm_range_man_fini(struct ttm_device *bdev,
return 0;
}
EXPORT_SYMBOL(ttm_range_man_fini);
-
-static void ttm_range_man_debug(struct ttm_resource_manager *man,
- struct drm_printer *printer)
-{
- struct ttm_range_manager *rman = to_range_manager(man);
-
- spin_lock(&rman->lock);
- drm_mm_print(&rman->mm, printer);
- spin_unlock(&rman->lock);
-}
-
-static const struct ttm_resource_manager_func ttm_range_manager_func = {
- .alloc = ttm_range_man_alloc,
- .free = ttm_range_man_free,
- .debug = ttm_range_man_debug
-};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm/ttm: rename bo->mem and make it a pointer
When we want to decouble resource management from buffer management we need to
be able to handle resources separately.
Add a resource pointer and rename bo->mem so that all code needs to
change to access the pointer instead.
No functional change.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 8 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 48 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 42
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 12 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
drivers/gpu/drm/drm_gem_ttm_helper.c | 6 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 30 ++--
drivers/gpu/drm/nouveau/nouveau_chan.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 16 +++---
drivers/gpu/drm/nouveau/nouveau_vmm.c | 4 +-
drivers/gpu/drm/nouveau/nv17_fence.c | 2 +-
drivers/gpu/drm/nouveau/nv50_fence.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 6 +--
drivers/gpu/drm/qxl/qxl_object.c | 10 ++--
drivers/gpu/drm/qxl/qxl_ttm.c | 4 +-
drivers/gpu/drm/radeon/radeon_cs.c| 8 +--
drivers/gpu/drm/radeon/radeon_gem.c | 10 ++--
drivers/gpu/drm/radeon/radeon_object.c| 22 -
drivers/gpu/drm/radeon/radeon_object.h| 4 +-
drivers/gpu/drm/radeon/radeon_pm.c| 2 +-
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 8 +--
drivers/gpu/drm/ttm/ttm_bo.c | 39 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 49 ++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 22 -
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 8 +--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 36 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 10 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 12 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 10 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 12 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 8 +--
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 12 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 6 +--
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 6 +--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 10 ++--
include/drm/ttm/ttm_bo_api.h | 3 +-
include/drm/ttm/ttm_bo_driver.h | 6 +--
48 files changed, 269 insertions(+), 264 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9f6b299cbf74..2a6c2a3c7b6d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1423,7 +1423,7 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
* the next restore worker
*/
if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) &&
- bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+ bo->tbo.resource->mem_type == TTM_PL_SYSTEM)
is_invalid_userptr = true;
if (check_if_add_bo_to_vm(avm, mem)) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 33b6e460f481..e4da933aaf4e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4057,9 +4057,9 @@ static int amdgpu_device_recover_vram(struct
amdgpu_device *adev)
list_for_each_entry(shadow, &adev->shadow_list, shadow_list) {
/* No need to recover an evicted BO */
- if (shadow->tbo.mem.mem_type != TTM_PL_TT ||
- shadow->tbo.mem.start == AMDGPU_BO_INVALID_OFFSET ||
- shadow->parent->tbo.mem.mem_type != TTM_PL_VRAM)
+ if (shadow->tbo.resource->mem_type != TTM_PL_TT ||
+ shadow->tbo.resource->start == AMDGPU_BO_INVALID_OFFSET ||
+ shadow->parent->tbo.resource->mem_type != TTM_PL_VRAM)
continue;
r = amdgpu_bo_restore_shadow(shadow, &next);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 47e0b48dc26f..69e4b29203a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -272,12 +272,12 @@ static str
[PATCH 2/7] drm/amdgpu: check base size instead of mem.num_pages
Drop some ussage of mem in the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 984dcf5a475e..e316cebb1fdc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1327,7 +1327,7 @@ vm_fault_t amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct ttm_operation_ctx ctx = { false, false };
struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
- unsigned long offset, size;
+ unsigned long offset;
int r;
/* Remember that this BO was accessed by the CPU */
@@ -1336,9 +1336,8 @@ vm_fault_t amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
if (bo->mem.mem_type != TTM_PL_VRAM)
return 0;
- size = bo->mem.num_pages << PAGE_SHIFT;
offset = bo->mem.start << PAGE_SHIFT;
- if ((offset + size) <= adev->gmc.visible_vram_size)
+ if ((offset + bo->base.size) <= adev->gmc.visible_vram_size)
return 0;
/* Can't move a pinned BO to visible VRAM */
@@ -1363,7 +1362,7 @@ vm_fault_t amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
offset = bo->mem.start << PAGE_SHIFT;
/* this should never happen */
if (bo->mem.mem_type == TTM_PL_VRAM &&
- (offset + size) > adev->gmc.visible_vram_size)
+ (offset + bo->base.size) > adev->gmc.visible_vram_size)
return VM_FAULT_SIGBUS;
ttm_bo_move_to_lru_tail_unlocked(bo);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/nouveau: use bo->base.size instead of mem->num_pages
Change a couple of cases where it makes more sense to use the base size
instead of the number of pages in the resource.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 9 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 ++--
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 2d5d68fc15c2..6dbcbe2fa55f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -302,7 +302,6 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
align, u32 domain,
int type = sg ? ttm_bo_type_sg : ttm_bo_type_device;
int ret;
- nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
nouveau_bo_placement_set(nvbo, domain, 0);
INIT_LIST_HEAD(&nvbo->io_reserve_lru);
@@ -364,12 +363,12 @@ static void
set_placement_range(struct nouveau_bo *nvbo, uint32_t domain)
{
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
- u32 vram_pages = drm->client.device.info.ram_size >> PAGE_SHIFT;
+ u64 vram_size = drm->client.device.info.ram_size;
unsigned i, fpfn, lpfn;
if (drm->client.device.info.family == NV_DEVICE_INFO_V0_CELSIUS &&
nvbo->mode && (domain & NOUVEAU_GEM_DOMAIN_VRAM) &&
- nvbo->bo.mem.num_pages < vram_pages / 4) {
+ nvbo->bo.base.size < vram_size / 4) {
/*
* Make sure that the color and depth buffers are handled
* by independent memory controller units. Up to a 9x
@@ -377,11 +376,11 @@ set_placement_range(struct nouveau_bo *nvbo, uint32_t
domain)
* at the same time.
*/
if (nvbo->zeta) {
- fpfn = vram_pages / 2;
+ fpfn = (vram_size / 2) >> PAGE_SHIFT;
lpfn = ~0;
} else {
fpfn = 0;
- lpfn = vram_pages / 2;
+ lpfn = (vram_size / 2) >> PAGE_SHIFT;
}
for (i = 0; i < nvbo->placement.num_placement; ++i) {
nvbo->placements[i].fpfn = fpfn;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 4fc0fa696461..93ac78bda750 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -379,10 +379,10 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
FBINFO_HWACCEL_IMAGEBLIT;
info->fbops = &nouveau_fbcon_sw_ops;
info->fix.smem_start = nvbo->bo.mem.bus.offset;
- info->fix.smem_len = nvbo->bo.mem.num_pages << PAGE_SHIFT;
+ info->fix.smem_len = nvbo->bo.base.size;
info->screen_base = nvbo_kmap_obj_iovirtual(nvbo);
- info->screen_size = nvbo->bo.mem.num_pages << PAGE_SHIFT;
+ info->screen_size = nvbo->bo.base.size;
drm_fb_helper_fill_info(info, &fbcon->helper, sizes);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index c88cbb85f101..a70e82413fa7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -253,7 +253,7 @@ nouveau_gem_info(struct drm_file *file_priv, struct
drm_gem_object *gem,
rep->offset = vma->addr;
}
- rep->size = nvbo->bo.mem.num_pages << PAGE_SHIFT;
+ rep->size = nvbo->bo.base.size;
rep->map_handle = drm_vma_node_offset_addr(&nvbo->bo.base.vma_node);
rep->tile_mode = nvbo->mode;
rep->tile_flags = nvbo->contig ? 0 : NOUVEAU_GEM_TILE_NONCONTIG;
@@ -638,7 +638,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
nvbo = (void *)(unsigned long)bo[r->reloc_bo_index].user_priv;
if (unlikely(r->reloc_bo_offset + 4 >
-nvbo->bo.mem.num_pages << PAGE_SHIFT)) {
+nvbo->bo.base.size)) {
NV_PRINTK(err, cli, "reloc outside of bo\n");
ret = -EINVAL;
break;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/ttm: add ttm_sys_manager
Add a separate manager for the system domain and make function tables
mandatory.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 2 +-
drivers/gpu/drm/ttm/ttm_device.c | 17 +-
drivers/gpu/drm/ttm/ttm_module.h | 3 ++
drivers/gpu/drm/ttm/ttm_resource.c| 10 ++
drivers/gpu/drm/ttm/ttm_sys_manager.c | 46 +++
5 files changed, 53 insertions(+), 25 deletions(-)
create mode 100644 drivers/gpu/drm/ttm/ttm_sys_manager.c
diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index 40e5e9da7953..f906b22959cf 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
ttm-y := ttm_tt.o ttm_bo.o ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_execbuf_util.o ttm_range_manager.o ttm_resource.o ttm_pool.o \
- ttm_device.o
+ ttm_device.o ttm_sys_manager.o
ttm-$(CONFIG_AGP) += ttm_agp_backend.o
obj-$(CONFIG_DRM_TTM) += ttm.o
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 1f2024164d72..39956e08b4c3 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -165,21 +165,6 @@ int ttm_device_swapout(struct ttm_device *bdev, struct
ttm_operation_ctx *ctx,
}
EXPORT_SYMBOL(ttm_device_swapout);
-static void ttm_init_sysman(struct ttm_device *bdev)
-{
- struct ttm_resource_manager *man = &bdev->sysman;
-
- /*
-* Initialize the system memory buffer type.
-* Other types need to be driver / IOCTL initialized.
-*/
- man->use_tt = true;
-
- ttm_resource_manager_init(man, 0);
- ttm_set_driver_manager(bdev, TTM_PL_SYSTEM, man);
- ttm_resource_manager_set_used(man, true);
-}
-
static void ttm_device_delayed_workqueue(struct work_struct *work)
{
struct ttm_device *bdev =
@@ -222,7 +207,7 @@ int ttm_device_init(struct ttm_device *bdev, struct
ttm_device_funcs *funcs,
bdev->funcs = funcs;
- ttm_init_sysman(bdev);
+ ttm_sys_man_init(bdev);
ttm_pool_init(&bdev->pool, dev, use_dma_alloc, use_dma32);
bdev->vma_manager = vma_manager;
diff --git a/drivers/gpu/drm/ttm/ttm_module.h b/drivers/gpu/drm/ttm/ttm_module.h
index d7cac5d4b835..26564a98958f 100644
--- a/drivers/gpu/drm/ttm/ttm_module.h
+++ b/drivers/gpu/drm/ttm/ttm_module.h
@@ -34,7 +34,10 @@
#define TTM_PFX "[TTM] "
struct dentry;
+struct ttm_device;
extern struct dentry *ttm_debugfs_root;
+int ttm_sys_man_init(struct ttm_device *bdev);
+
#endif /* _TTM_MODULE_H_ */
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 04f2eef653ab..a6900b82f31a 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -33,9 +33,6 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
ttm_manager_type(bo->bdev, res->mem_type);
res->mm_node = NULL;
- if (!man->func || !man->func->alloc)
- return 0;
-
return man->func->alloc(man, bo, place, res);
}
@@ -44,9 +41,7 @@ void ttm_resource_free(struct ttm_buffer_object *bo, struct
ttm_resource *res)
struct ttm_resource_manager *man =
ttm_manager_type(bo->bdev, res->mem_type);
- if (man->func && man->func->free)
- man->func->free(man, res);
-
+ man->func->free(man, res);
res->mm_node = NULL;
res->mem_type = TTM_PL_SYSTEM;
}
@@ -139,7 +134,6 @@ void ttm_resource_manager_debug(struct ttm_resource_manager
*man,
drm_printf(p, " use_type: %d\n", man->use_type);
drm_printf(p, " use_tt: %d\n", man->use_tt);
drm_printf(p, " size: %llu\n", man->size);
- if (man->func && man->func->debug)
- (*man->func->debug)(man, p);
+ man->func->debug(man, p);
}
EXPORT_SYMBOL(ttm_resource_manager_debug);
diff --git a/drivers/gpu/drm/ttm/ttm_sys_manager.c
b/drivers/gpu/drm/ttm/ttm_sys_manager.c
new file mode 100644
index ..32bc16f022f9
--- /dev/null
+++ b/drivers/gpu/drm/ttm/ttm_sys_manager.c
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+
+#include
+#include
+#include
+
+static int ttm_sys_man_alloc(struct ttm_resource_manager *man,
+struct ttm_buffer_object *bo,
+const struct ttm_place *place,
+struct ttm_resource *mem)
+{
+ return 0;
+}
+
+static void ttm_sys_man_free(struct ttm_resource_manager *man,
+struct ttm_resource *mem)
+{
+}
+
+static void ttm_sys_man_debug(struct ttm_resource_manager *man,
+ struct drm_printer *printer)
+{
+}
+
+static const struct ttm_resource_manager_func ttm_sys_manager_func = {
+ .alloc = ttm_sys_man_alloc,
+ .free = ttm_sys_man_free,
+ .debug = ttm_sys_man_debug
+};
+
+int ttm_sys_man_init(struct ttm_device *bdev)
+{
+ struct ttm_resource_manager *man = &b
[PATCH 4/7] drm/ttm: move the page_alignment into the BO
The alignment is a constant property and shouldn't change.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 +++--
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
drivers/gpu/drm/ttm/ttm_range_manager.c | 5 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 15 ---
include/drm/ttm/ttm_bo_api.h | 1 +
include/drm/ttm/ttm_resource.h | 1 -
10 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index b443907afcea..f1c397be383d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -763,7 +763,7 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
void __user *out = u64_to_user_ptr(args->value);
info.bo_size = robj->tbo.base.size;
- info.alignment = robj->tbo.mem.page_alignment << PAGE_SHIFT;
+ info.alignment = robj->tbo.page_alignment << PAGE_SHIFT;
info.domains = robj->preferred_domains;
info.domain_flags = robj->flags;
amdgpu_bo_unreserve(robj);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 8860545344c7..c026972ca9a1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -136,7 +136,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
spin_lock(&mgr->lock);
r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
- mem->page_alignment, 0, place->fpfn,
+ tbo->page_alignment, 0, place->fpfn,
place->lpfn, DRM_MM_INSERT_BEST);
spin_unlock(&mgr->lock);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 9ac37569823f..ae4a68db87c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -184,7 +184,7 @@ static inline unsigned amdgpu_bo_ngpu_pages(struct
amdgpu_bo *bo)
static inline unsigned amdgpu_bo_gpu_page_alignment(struct amdgpu_bo *bo)
{
- return (bo->tbo.mem.page_alignment << PAGE_SHIFT) /
AMDGPU_GPU_PAGE_SIZE;
+ return (bo->tbo.page_alignment << PAGE_SHIFT) / AMDGPU_GPU_PAGE_SIZE;
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 1fc7ec0b8915..38b1995d0d6c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -392,7 +392,8 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
/* default to 2MB */
pages_per_node = (2UL << (20UL - PAGE_SHIFT));
#endif
- pages_per_node = max((uint32_t)pages_per_node,
mem->page_alignment);
+ pages_per_node = max((uint32_t)pages_per_node,
+tbo->page_alignment);
num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
}
@@ -431,7 +432,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
for (; pages_left; ++i) {
unsigned long pages = min(pages_left, pages_per_node);
- uint32_t alignment = mem->page_alignment;
+ uint32_t alignment = tbo->page_alignment;
if (pages == pages_per_node)
alignment = pages_per_node;
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 9896d8231fe5..fd4116bdde0f 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -119,7 +119,7 @@ static inline unsigned radeon_bo_ngpu_pages(struct
radeon_bo *bo)
static inline unsigned radeon_bo_gpu_page_alignment(struct radeon_bo *bo)
{
- return (bo->tbo.mem.page_alignment << PAGE_SHIFT) /
RADEON_GPU_PAGE_SIZE;
+ return (bo->tbo.page_alignment << PAGE_SHIFT) / RADEON_GPU_PAGE_SIZE;
}
/**
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index cfd0b9292397..2efae620759a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -903,7 +903,6 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
memset(&hop, 0, sizeof(hop));
mem.num_pages = PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT;
- mem.page_alignment = bo->mem.page_alignment;
mem.bus.offset = 0;
mem.bus.addr = NULL;
mem.mm_node = NULL;
@@ -1038,10 +1037,10 @@ int ttm_bo_init_reserved(struct ttm_device *bdev
[PATCH 6/7] drm/ttm: always initialize the full ttm_resource
Init all fields in ttm_resource_alloc() when we create a new resource.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 --
drivers/gpu/drm/ttm/ttm_bo.c| 26 -
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++--
drivers/gpu/drm/ttm/ttm_resource.c | 9 +
4 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index a785acc09f20..78ae6ccc8836 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1095,8 +1095,6 @@ int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo)
} else {
/* allocate GART space */
- tmp = bo->mem;
- tmp.mm_node = NULL;
placement.num_placement = 1;
placement.placement = &placements;
placement.num_busy_placement = 1;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2efae620759a..d3580dfa2bc6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -507,11 +507,6 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
return ttm_tt_create(bo, false);
}
- evict_mem = bo->mem;
- evict_mem.mm_node = NULL;
- evict_mem.bus.offset = 0;
- evict_mem.bus.addr = NULL;
-
ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx);
if (ret) {
if (ret != -ERESTARTSYS) {
@@ -867,12 +862,8 @@ static int ttm_bo_bounce_temp_buffer(struct
ttm_buffer_object *bo,
struct ttm_place *hop)
{
struct ttm_placement hop_placement;
+ struct ttm_resource hop_mem;
int ret;
- struct ttm_resource hop_mem = *mem;
-
- hop_mem.mm_node = NULL;
- hop_mem.mem_type = TTM_PL_SYSTEM;
- hop_mem.placement = 0;
hop_placement.num_placement = hop_placement.num_busy_placement = 1;
hop_placement.placement = hop_placement.busy_placement = hop;
@@ -894,19 +885,14 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
struct ttm_placement *placement,
struct ttm_operation_ctx *ctx)
{
- int ret = 0;
struct ttm_place hop;
struct ttm_resource mem;
+ int ret;
dma_resv_assert_held(bo->base.resv);
memset(&hop, 0, sizeof(hop));
- mem.num_pages = PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT;
- mem.bus.offset = 0;
- mem.bus.addr = NULL;
- mem.mm_node = NULL;
-
/*
* Determine where to move the buffer.
*
@@ -1027,6 +1013,7 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
struct dma_resv *resv,
void (*destroy) (struct ttm_buffer_object *))
{
+ static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
bool locked;
int ret = 0;
@@ -1038,13 +1025,8 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
bo->bdev = bdev;
bo->type = type;
bo->page_alignment = page_alignment;
- bo->mem.mem_type = TTM_PL_SYSTEM;
- bo->mem.num_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
- bo->mem.mm_node = NULL;
- bo->mem.bus.offset = 0;
- bo->mem.bus.addr = NULL;
+ ttm_resource_alloc(bo, &sys_mem, &bo->mem);
bo->moving = NULL;
- bo->mem.placement = 0;
bo->pin_count = 0;
bo->sg = sg;
if (resv) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index efb7e9c34ab4..ae8b61460724 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -664,6 +664,7 @@ EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
+ static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
int ret;
@@ -676,8 +677,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
if (ret)
ttm_bo_wait(bo, false, false);
- memset(&bo->mem, 0, sizeof(bo->mem));
- bo->mem.mem_type = TTM_PL_SYSTEM;
+ ttm_resource_alloc(bo, &sys_mem, &bo->mem);
bo->ttm = NULL;
dma_resv_unlock(&ghost->base._resv);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index a6900b82f31a..56c4d3550c86 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -33,6 +33,15 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
ttm_manager_type(bo->bdev, res->mem_type);
res->mm_node = NULL;
+ res->start = 0;
+ res->num_pages = PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT;
+ res->mem_type = place->mem_type;
+ res->placement = place->flags;
+ res->bus.addr = NULL;
+ res->bus.offset
Re: [PATCH v1, 3/3] drm/mediatek: gamma set with cmdq
Hi Yongqiang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on pza/reset/next linus/master v5.12-rc7]
[cannot apply to next-20210413]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Yongqiang-Niu/gamma-set-with-cmdq/20210412-143659
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r023-20210413 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
9829f5e6b1bca9b61efc629770d28bb9014dec45)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/b562bd6c318f4681373221cc292c78d51cb819e6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Yongqiang-Niu/gamma-set-with-cmdq/20210412-143659
git checkout b562bd6c318f4681373221cc292c78d51cb819e6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/mediatek/mtk_disp_gamma.c:76:50: warning: incompatible
>> pointer to integer conversion passing 'void *' to parameter of type
>> 'unsigned int' [-Wint-conversion]
mtk_ddp_write(cmdq_pkt, word, cmdq_reg, regs,
(lut_base + i * 4));
^~
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h:199:19: note: passing argument
to parameter 'offset' here
unsigned int offset);
^
1 warning generated.
vim +76 drivers/gpu/drm/mediatek/mtk_disp_gamma.c
57
58 void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg
*cmdq_reg,
59struct drm_crtc_state *state, struct cmdq_pkt
*cmdq_pkt)
60 {
61 unsigned int i, reg;
62 struct drm_color_lut *lut;
63 void __iomem *lut_base;
64 u32 word;
65
66 if (state->gamma_lut) {
67 reg = readl(regs + DISP_GAMMA_CFG);
68 reg = reg | GAMMA_LUT_EN;
69 mtk_ddp_write(cmdq_pkt, reg, cmdq_reg, regs,
DISP_GAMMA_CFG);
70 lut_base = regs + DISP_GAMMA_LUT;
71 lut = (struct drm_color_lut *)state->gamma_lut->data;
72 for (i = 0; i < MTK_LUT_SIZE; i++) {
73 word = (((lut[i].red >> 6) & LUT_10BIT_MASK) <<
20) +
74 (((lut[i].green >> 6) & LUT_10BIT_MASK)
<< 10) +
75 ((lut[i].blue >> 6) & LUT_10BIT_MASK);
> 76 mtk_ddp_write(cmdq_pkt, word, cmdq_reg, regs,
(lut_base + i * 4));
77 }
78 }
79 }
80
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/vc4: Add HDR metadata property to the VC5 HDMI connectors
From: Dave Stevenson
Now that we can export deeper colour depths, add in the signalling
for HDR metadata.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 53 ++
drivers/gpu/drm/vc4/vc4_hdmi.h | 3 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 1fda574579af..a33fa1662588 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -214,6 +214,31 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
return ret;
}
+static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector_state *old_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_connector_state *new_state =
+ drm_atomic_get_new_connector_state(state, connector);
+ struct drm_crtc *crtc = new_state->crtc;
+
+ if (!crtc)
+ return 0;
+
+ if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ crtc_state->mode_changed = true;
+ }
+
+ return 0;
+}
+
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
struct vc4_hdmi_connector_state *old_state =
@@ -263,6 +288,7 @@ static const struct drm_connector_funcs
vc4_hdmi_connector_funcs = {
static const struct drm_connector_helper_funcs vc4_hdmi_connector_helper_funcs
= {
.get_modes = vc4_hdmi_connector_get_modes,
+ .atomic_check = vc4_hdmi_connector_atomic_check,
};
static int vc4_hdmi_connector_init(struct drm_device *dev,
@@ -299,6 +325,9 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
+ if (vc4_hdmi->variant->supports_hdr)
+ drm_connector_attach_hdr_output_metadata_property(connector);
+
drm_connector_attach_encoder(connector, encoder);
return 0;
@@ -432,6 +461,25 @@ static void vc4_hdmi_set_audio_infoframe(struct
drm_encoder *encoder)
vc4_hdmi_write_infoframe(encoder, &frame);
}
+static void vc4_hdmi_set_hdr_infoframe(struct drm_encoder *encoder)
+{
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ struct drm_connector *connector = &vc4_hdmi->connector;
+ struct drm_connector_state *conn_state = connector->state;
+ union hdmi_infoframe frame;
+
+ if (!vc4_hdmi->variant->supports_hdr)
+ return;
+
+ if (!conn_state->hdr_output_metadata)
+ return;
+
+ if (drm_hdmi_infoframe_set_hdr_metadata(&frame.drm, conn_state))
+ return;
+
+ vc4_hdmi_write_infoframe(encoder, &frame);
+}
+
static void vc4_hdmi_set_infoframes(struct drm_encoder *encoder)
{
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
@@ -444,6 +492,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
*/
if (vc4_hdmi->audio.streaming)
vc4_hdmi_set_audio_infoframe(encoder);
+
+ vc4_hdmi_set_hdr_infoframe(encoder);
}
static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder,
@@ -2102,6 +2152,7 @@ static const struct vc4_hdmi_variant bcm2835_variant = {
.phy_rng_enable = vc4_hdmi_phy_rng_enable,
.phy_rng_disable= vc4_hdmi_phy_rng_disable,
.channel_map= vc4_hdmi_channel_map,
+ .supports_hdr = false,
};
static const struct vc4_hdmi_variant bcm2711_hdmi0_variant = {
@@ -2129,6 +2180,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi0_variant = {
.phy_rng_enable = vc5_hdmi_phy_rng_enable,
.phy_rng_disable= vc5_hdmi_phy_rng_disable,
.channel_map= vc5_hdmi_channel_map,
+ .supports_hdr = true,
};
static const struct vc4_hdmi_variant bcm2711_hdmi1_variant = {
@@ -2156,6 +2208,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi1_variant = {
.phy_rng_enable = vc5_hdmi_phy_rng_enable,
.phy_rng_disable= vc5_hdmi_phy_rng_disable,
.channel_map= vc5_hdmi_channel_map,
+ .supports_hdr = true,
};
static const struct of_device_id vc4_hdmi_dt_match[] = {
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 3cebd1fd00fc..060bcaefbeb5 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -99,6 +99,9 @@ struct vc4_hdmi_variant {
/* Callback to get channel map */
[PATCH v2 5/5] drm/vc4: hdmi: Signal the proper colorimetry info in the infoframe
Our driver while supporting HDR didn't send the proper colorimetry info
in the AVI infoframe.
Let's add the property needed so that the userspace can let us know what
the colorspace is supposed to be.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a33fa1662588..a22e17788074 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -226,7 +226,8 @@ static int vc4_hdmi_connector_atomic_check(struct
drm_connector *connector,
if (!crtc)
return 0;
- if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
+ if (old_state->colorspace != new_state->colorspace ||
+ !drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
struct drm_crtc_state *crtc_state;
crtc_state = drm_atomic_get_crtc_state(state, crtc);
@@ -316,6 +317,11 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
if (ret)
return ret;
+ ret = drm_mode_create_hdmi_colorspace_property(connector);
+ if (ret)
+ return ret;
+
+ drm_connector_attach_colorspace_property(connector);
drm_connector_attach_tv_margin_properties(connector);
drm_connector_attach_max_bpc_property(connector, 8, 12);
@@ -424,7 +430,7 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder
*encoder)
vc4_encoder->limited_rgb_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL);
-
+ drm_hdmi_avi_infoframe_colorspace(&frame.avi, cstate);
drm_hdmi_avi_infoframe_bars(&frame.avi, cstate);
vc4_hdmi_write_infoframe(encoder, &frame);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm/connector: Create a helper to attach the hdr_output_metadata property
All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.
Provide a helper for it as well
Reviewed-by: Harry Wentland
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
- Added the tags
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +--
drivers/gpu/drm/drm_connector.c | 21 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_connector.h | 1 +
5 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 55e39b462a5e..1e22ce718010 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7078,9 +7078,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
- drm_object_attach_property(
- &aconnector->base.base,
- dm->ddev->mode_config.hdr_output_metadata_property, 0);
+
drm_connector_attach_hdr_output_metadata_property(&aconnector->base);
if (!aconnector->mst_port)
drm_connector_attach_vrr_capable_property(&aconnector->base);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..f24bbb840dbf 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2492,8 +2492,7 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
drm_connector_attach_max_bpc_property(connector, 8, 16);
if (hdmi->version >= 0x200a && hdmi->plat_data->use_drm_infoframe)
- drm_object_attach_property(&connector->base,
-
connector->dev->mode_config.hdr_output_metadata_property, 0);
+ drm_connector_attach_hdr_output_metadata_property(connector);
drm_connector_attach_encoder(connector, hdmi->bridge.encoder);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..a4aa2d87af35 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2150,6 +2150,27 @@ int drm_connector_attach_max_bpc_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
+/**
+ * drm_connector_attach_hdr_output_metadata_property - attach
"HDR_OUTPUT_METADA" property
+ * @connector: connector to attach the property on.
+ *
+ * This is used to allow the userspace to send HDR Metadata to the
+ * driver.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_hdr_output_metadata_property(struct drm_connector
*connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop =
dev->mode_config.hdr_output_metadata_property;
+
+ drm_object_attach_property(&connector->base, prop, 0);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
+
/**
* drm_connector_set_vrr_capable_property - sets the variable refresh rate
* capable property for a connector
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 95919d325b0b..f2f1b025e6ba 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2965,8 +2965,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
struct drm_connector *c
drm_connector_attach_content_type_property(connector);
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
- drm_object_attach_property(&connector->base,
-
connector->dev->mode_config.hdr_output_metadata_property, 0);
+ drm_connector_attach_hdr_output_metadata_property(connector);
if (!HAS_GMCH(dev_priv))
drm_connector_attach_max_bpc_property(connector, 8, 12);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..32172dab8427 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1671,6 +1671,7 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
u32 scaling_mode_mask);
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
+int drm_connector_attach_hdr_output_metadata_property(struct drm_connector
*connector);
int drm_mode_create_
[PATCH v2 4/5] drm/connector: Add a helper to attach the colorspace property
The intel driver uses the same logic to attach the Colorspace property
in multiple places and we'll need it in vc4 too. Let's move that common
code in a helper.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/drm_connector.c | 20 +++
.../gpu/drm/i915/display/intel_connector.c| 6 ++
include/drm/drm_connector.h | 1 +
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b13021b1b128..6a20b249e533 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2171,6 +2171,26 @@ int
drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
}
EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
+/**
+ * drm_connector_attach_colorspace_property - attach "Colorspace" property
+ * @connector: connector to attach the property on.
+ *
+ * This is used to allow the userspace to signal the output colorspace
+ * to the driver.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_colorspace_property(struct drm_connector *connector)
+{
+ struct drm_property *prop = connector->colorspace_property;
+
+ drm_object_attach_property(&connector->base, prop,
DRM_MODE_COLORIMETRY_DEFAULT);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
+
/**
* drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
* @old_state: old connector state to compare
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index d5ceb7bdc14b..9bed1ccecea0 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -282,14 +282,12 @@ void
intel_attach_hdmi_colorspace_property(struct drm_connector *connector)
{
if (!drm_mode_create_hdmi_colorspace_property(connector))
- drm_object_attach_property(&connector->base,
- connector->colorspace_property, 0);
+ drm_connector_attach_colorspace_property(connector);
}
void
intel_attach_dp_colorspace_property(struct drm_connector *connector)
{
if (!drm_mode_create_dp_colorspace_property(connector))
- drm_object_attach_property(&connector->base,
- connector->colorspace_property, 0);
+ drm_connector_attach_colorspace_property(connector);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1f51d73ca715..714d1a01c065 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1671,6 +1671,7 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
u32 scaling_mode_mask);
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
+int drm_connector_attach_colorspace_property(struct drm_connector *connector);
int drm_connector_attach_hdr_output_metadata_property(struct drm_connector
*connector);
bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state
*old_state,
struct drm_connector_state
*new_state);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/connector: Add helper to compare HDR metadata
All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.
All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those drivers.
Reviewed-by: Harry Wentland
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
- Added the tags
- Fix build breakage on amdgpu
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +--
drivers/gpu/drm/drm_connector.c | 28 +++
drivers/gpu/drm/i915/display/intel_atomic.c | 13 +
include/drm/drm_connector.h | 2 ++
5 files changed, 34 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1e22ce718010..ed1972fb531d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5967,25 +5967,6 @@ static int fill_hdr_info_packet(const struct
drm_connector_state *state,
return 0;
}
-static bool
-is_hdr_metadata_different(const struct drm_connector_state *old_state,
- const struct drm_connector_state *new_state)
-{
- struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
- struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
- if (old_blob != new_blob) {
- if (old_blob && new_blob &&
- old_blob->length == new_blob->length)
- return memcmp(old_blob->data, new_blob->data,
- old_blob->length);
-
- return true;
- }
-
- return false;
-}
-
static int
amdgpu_dm_connector_atomic_check(struct drm_connector *conn,
struct drm_atomic_state *state)
@@ -6003,7 +5984,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
if (!crtc)
return 0;
- if (is_hdr_metadata_different(old_con_state, new_con_state)) {
+ if (!drm_connector_atomic_hdr_metadata_equal(old_con_state,
new_con_state)) {
struct dc_info_packet hdr_infopacket;
ret = fill_hdr_info_packet(new_con_state, &hdr_infopacket);
@@ -8357,7 +8338,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
dm_old_crtc_state->abm_level;
hdr_changed =
- is_hdr_metadata_different(old_con_state, new_con_state);
+ !drm_connector_atomic_hdr_metadata_equal(old_con_state,
new_con_state);
if (!scaling_changed && !abm_changed && !hdr_changed)
continue;
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f24bbb840dbf..f871e33c2fc9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2395,21 +2395,6 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
return ret;
}
-static bool hdr_metadata_equal(const struct drm_connector_state *old_state,
- const struct drm_connector_state *new_state)
-{
- struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
- struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
- if (!old_blob || !new_blob)
- return old_blob == new_blob;
-
- if (old_blob->length != new_blob->length)
- return false;
-
- return !memcmp(old_blob->data, new_blob->data, old_blob->length);
-}
-
static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
struct drm_atomic_state *state)
{
@@ -2423,7 +2408,7 @@ static int dw_hdmi_connector_atomic_check(struct
drm_connector *connector,
if (!crtc)
return 0;
- if (!hdr_metadata_equal(old_state, new_state)) {
+ if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a4aa2d87af35..b13021b1b128 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2171,6 +2171,34 @@ int
drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
}
EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
+/**
+ * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
+ * @old_state: old connector state to compare
+ * @new_state: new connector
Re: [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, 13 Apr 2021 11:49:03 +0200
Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 16 +++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..16a7e3e57f7f 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,11 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then
> every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR.
Ooh, that's even better. But isn't that changing the meaning of the
cap? Isn't the cap older than IN_FORMATS?
What about the opposite? Is it allowed to have even a single IN_FORMATS
if you don't have the cap?
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
What does this mean?
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their
> planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
Good.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
>* @allow_fb_modifiers:
>*
>* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
>*
>* IMPORTANT:
>*
Thanks,
pq
pgpwYBEp_YeRJ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
For a lot of the embedded display drivers that never had any out-of-
band tiling meta shared with the GPU part, the implied modifier is
actually DRM_FORMAT_MOD_LINEAR, so maybe that's where some of the
confusion about needing to specify the modifier list comes from.
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
This clarification looks good to me.
Reviewed-by: Lucas Stach
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 16 +++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..16a7e3e57f7f 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,11 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then
> every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR.
> */
>
>
>
>
>
>
>
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> format_modifier_count++;
> }
>
>
>
>
>
>
>
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
>
>
>
>
>
>
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their
> planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > Since > > commit 890880ddfdbe256083170866e49c87618b706ac7 > Author: Paul Kocialkowski > Date: Fri Jan 4 09:56:10 2019 +0100 > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > this is done automatically as part of plane init, if drivers set the > modifier list correctly. Which is the case here. > > This one actually set it twice on top of what drm_plane_init does, so > double-redundant! That's not true. imx-dcss and imx-drm are two totally separate drivers. Maybe we should move imx-drm into its own ipuv3 directory one day to make this more clear. Change is still correct, though. Reviewed-by: Lucas Stach > Signed-off-by: Daniel Vetter > Cc: Philipp Zabel > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: linux-arm-ker...@lists.infradead.org > --- > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > index b549ce5e7607..37ae68a7fba5 100644 > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev > *kms) > config->min_height = 1; > config->max_width = 4096; > config->max_height = 4096; > - config->allow_fb_modifiers = true; > config->normalize_zpos = true; > > > > > config->funcs = &dcss_drm_mode_config_funcs; > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > b/drivers/gpu/drm/imx/imx-drm-core.c > index 2ded8e4f32d0..8be4edaec958 100644 > --- a/drivers/gpu/drm/imx/imx-drm-core.c > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) > drm->mode_config.max_height = 4096; > drm->mode_config.funcs = &imx_drm_mode_config_funcs; > drm->mode_config.helper_private = &imx_drm_mode_config_helpers; > - drm->mode_config.allow_fb_modifiers = true; > drm->mode_config.normalize_zpos = true; > > > > > ret = drmm_mode_config_init(drm); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v2] drm/doc/rfc: i915 DG1 uAPI
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Dave Airlie
---
Documentation/gpu/rfc/i915_gem_lmem.h | 151
Documentation/gpu/rfc/i915_gem_lmem.rst | 119 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 274 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
b/Documentation/gpu/rfc/i915_gem_lmem.h
new file mode 100644
index ..6ae13209d7ef
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_gem_lmem.h
@@ -0,0 +1,151 @@
+/* The new query_id for struct drm_i915_query_item */
+#define DRM_I915_QUERY_MEMORY_REGIONS 0xdeadbeaf
+
+/**
+ * enum drm_i915_gem_memory_class
+ */
+enum drm_i915_gem_memory_class {
+ /** @I915_MEMORY_CLASS_SYSTEM: system memory */
+ I915_MEMORY_CLASS_SYSTEM = 0,
+ /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
+ I915_MEMORY_CLASS_DEVICE,
+};
+
+/**
+ * struct drm_i915_gem_memory_class_instance
+ */
+struct drm_i915_gem_memory_class_instance {
+ /** @memory_class: see enum drm_i915_gem_memory_class */
+ __u16 memory_class;
+
+ /** @memory_instance: which instance */
+ __u16 memory_instance;
+};
+
+/**
+ * struct drm_i915_memory_region_info
+ *
+ * Describes one region as known to the driver.
+ */
+struct drm_i915_memory_region_info {
+ /** @region: class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @caps: MBZ */
+ __u64 caps;
+
+ /** @flags: MBZ */
+ __u64 flags;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+ __u64 unallocated_size;
+
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+};
+
+/**
+ * struct drm_i915_query_memory_regions
+ *
+ * Region info query enumerates all regions known to the driver by filling in
+ * an array of struct drm_i915_memory_region_info structures.
+ */
+struct drm_i915_query_memory_regions {
+ /** @num_regions: Number of supported regions */
+ __u32 num_regions;
+
+ /** @rsvd: MBZ */
+ __u32 rsvd[3];
+
+ /** @regions: Info about each supported region */
+ struct drm_i915_memory_region_info regions[];
+};
+
+#define DRM_I915_GEM_CREATE_EXT0xdeadbeaf
+#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext)
+
+/**
+ * struct drm_i915_gem_create_ext
+ */
+struct drm_i915_gem_create_ext {
+ /**
+* @size: Requested size for the object.
+*
+* The (page-aligned) allocated size for the object will be returned.
+*/
+ __u64 size;
+ /**
+* @handle: Returned handle for the object.
+*
+* Object handles are nonzero.
+*/
+ __u32 handle;
+ /** @flags: MBZ */
+ __u32 flags;
+ /**
+* @extensions:
+* For I915_GEM_CREATE_EXT_SETPARAM extension usage see both:
+* struct drm_i915_gem_create_ext_setparam.
+* struct drm_i915_gem_object_param for the possible parameters.
+*/
+#define I915_GEM_CREATE_EXT_SETPARAM 0
+ __u64 extensions;
+};
+
+/**
+ * struct drm_i915_gem_object_param
+ */
+struct drm_i915_gem_object_param {
+ /** @handle: Object handle (0 for I915_GEM_CREATE_EXT_SETPARAM) */
+ __u32 handle;
+
+ /** @size: Data pointer size */
+ __u32 size;
+
+/*
+ * I915_OBJECT_PARAM:
+ *
+ * Select object namespace for the param.
+ */
+#define I915_OBJECT_PARAM (1ull<<32)
+
+/**
+ * @param: select the desired param.
+ *
+ * I915_OBJECT_PARAM_MEMORY_REGIONS:
+ *
+ * Set the data pointer with the desired set of placements in priority
+ * order(each entry must be unique and supported by the device), as an array of
+ * drm_i915_gem_memory_class_instance, or an equivalent layout of
class:instance
+ * pair encodings. See DRM_I915_QUERY_MEMORY_REGIONS for how to query the
+ * supported regions.
+ *
+ * In this case the data pointer size should be the number of
+ * drm_i915_gem_memory_class_instance elements in the placements array.
+ */
+#define I915_PARAM_MEMORY_REGIONS 0
+#define I915_OBJECT_PARAM_MEMORY_REGIONS (I915_OBJECT_PARAM | \
+ I915_PARAM_MEMORY_REGIONS)
+ __u64 param;
+
+ /** @data: Data value or pointer */
+ __u64 data;
+};
+
+/**
+ * struct drm_i915_gem_create_ext_setparam
+ */
+struct drm_i915_gem_create_ext_setparam {
+ /** @base: extension link */
+
Re: [PATCH 10/12] drm/tegra: Don't set allow_fb_modifiers explicitly
On Tue, Apr 13, 2021 at 11:49:01AM +0200, Daniel Vetter wrote:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here.
>
> It was slightly inconsistently though, since planes with only linear
> modifier support haven't listed that explicitly. Fix that, and cc:
> stable to allow userspace to rely on this. Again don't backport
> further than where Paul's patch got added.
>
> Cc: sta...@vger.kernel.org # v5.1 +
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: linux-te...@vger.kernel.org
> ---
> drivers/gpu/drm/tegra/dc.c | 10 --
> drivers/gpu/drm/tegra/drm.c | 2 --
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index c9385cfd0fc1..f9845a50f866 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -959,6 +959,11 @@ static const struct drm_plane_helper_funcs
> tegra_cursor_plane_helper_funcs = {
> .atomic_disable = tegra_cursor_atomic_disable,
> };
>
> +static const uint64_t linear_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
> struct tegra_dc *dc)
> {
> @@ -987,7 +992,7 @@ static struct drm_plane
> *tegra_dc_cursor_plane_create(struct drm_device *drm,
>
> err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
> &tegra_plane_funcs, formats,
> -num_formats, NULL,
> +num_formats, linear_modifiers,
> DRM_PLANE_TYPE_CURSOR, NULL);
> if (err < 0) {
> kfree(plane);
> @@ -1106,7 +,8 @@ static struct drm_plane
> *tegra_dc_overlay_plane_create(struct drm_device *drm,
>
> err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
> &tegra_plane_funcs, formats,
> -num_formats, NULL, type, NULL);
> +num_formats, linear_modifiers,
> +type, NULL);
I think we can do better than linear_modifiers for overlay planes, but
given that this doesn't change existing behaviour, I'll do that in a
separate patch.
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/shmem-helper: Align to page size in dumb_create
Hi
Am 13.04.21 um 11:49 schrieb Daniel Vetter:
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Signed-off-by: Daniel Vetter
Drivers get it more wrong than right. I always felt that we should have
all this in generic code with a few parameters somewhere.
But makes sense.
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6d625cee7a6a..d5e6d4568f99 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -505,13 +505,13 @@ int drm_gem_shmem_dumb_create(struct drm_file *file,
struct drm_device *dev,
if (!args->pitch || !args->size) {
args->pitch = min_pitch;
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
} else {
/* ensure sane minimum values */
if (args->pitch < min_pitch)
args->pitch = min_pitch;
if (args->size < args->pitch * args->height)
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
}
shmem = drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
