Re: [PATCH] drm/ttm: some cleanups
Reviewed-by: Dave Airlie
On Wed, 16 Sep 2020 at 00:31, Christian König
wrote:
>
> Unexport ttm_check_under_lowerlimit.
> Make ttm_bo_acc_size static and unexport it.
> Remove ttm_get_kernel_zone_memory_size.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
> drivers/gpu/drm/ttm/ttm_memory.c | 7 ---
> include/drm/ttm/ttm_bo_api.h | 12
> include/drm/ttm/ttm_memory.h | 1 -
> 4 files changed, 3 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index ee2632128d3c..ffbdc20d8e8d 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1254,9 +1254,9 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> }
> EXPORT_SYMBOL(ttm_bo_init);
>
> -size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
> - unsigned long bo_size,
> - unsigned struct_size)
> +static size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
> + unsigned long bo_size,
> + unsigned struct_size)
> {
> unsigned npages = (PAGE_ALIGN(bo_size)) >> PAGE_SHIFT;
> size_t size = 0;
> @@ -1266,7 +1266,6 @@ size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
> size += ttm_round_pot(sizeof(struct ttm_tt));
> return size;
> }
> -EXPORT_SYMBOL(ttm_bo_acc_size);
>
> size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>unsigned long bo_size,
> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
> b/drivers/gpu/drm/ttm/ttm_memory.c
> index acd63b70d814..987aa32c4808 100644
> --- a/drivers/gpu/drm/ttm/ttm_memory.c
> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> @@ -554,7 +554,6 @@ ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
>
> return false;
> }
> -EXPORT_SYMBOL(ttm_check_under_lowerlimit);
>
> static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
> struct ttm_mem_zone *single_zone,
> @@ -682,9 +681,3 @@ size_t ttm_round_pot(size_t size)
> return 0;
> }
> EXPORT_SYMBOL(ttm_round_pot);
> -
> -uint64_t ttm_get_kernel_zone_memory_size(struct ttm_mem_global *glob)
> -{
> - return glob->zone_kernel->max_mem;
> -}
> -EXPORT_SYMBOL(ttm_get_kernel_zone_memory_size);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 36ff64e2736c..fd8d29f5f370 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -352,18 +352,6 @@ void ttm_bo_unlock_delayed_workqueue(struct
> ttm_bo_device *bdev, int resched);
> bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> const struct ttm_place *place);
>
> -/**
> - * ttm_bo_acc_size
> - *
> - * @bdev: Pointer to a ttm_bo_device struct.
> - * @bo_size: size of the buffer object in byte.
> - * @struct_size: size of the structure holding buffer object datas
> - *
> - * Returns size to account for a buffer object
> - */
> -size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
> - unsigned long bo_size,
> - unsigned struct_size);
> size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>unsigned long bo_size,
>unsigned struct_size);
> diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
> index c78ea99c42cf..2d468d7c94e6 100644
> --- a/include/drm/ttm/ttm_memory.h
> +++ b/include/drm/ttm/ttm_memory.h
> @@ -91,7 +91,6 @@ extern int ttm_mem_global_alloc_page(struct ttm_mem_global
> *glob,
> extern void ttm_mem_global_free_page(struct ttm_mem_global *glob,
> struct page *page, uint64_t size);
> extern size_t ttm_round_pot(size_t size);
> -extern uint64_t ttm_get_kernel_zone_memory_size(struct ttm_mem_global *glob);
> extern bool ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
> uint64_t num_pages, struct ttm_operation_ctx *ctx);
> #endif
> --
> 2.17.1
>
> ___
> 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 1/2] drm/ttm: drop special pipeline accel cleanup function.
From: Dave Airlie
The two accel cleanup paths were mostly the same once refactored.
Just pass a bool to say if the evictions are to be pipelined.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 89 +
include/drm/ttm/ttm_bo_driver.h | 17 +
5 files changed, 37 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index a57aaf666340..1ea58ce7c559 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -499,10 +499,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
}
/* Always block for VM page tables before committing the new location */
- if (bo->type == ttm_bo_type_kernel)
- r = ttm_bo_move_accel_cleanup(bo, fence, true, new_mem);
- else
- r = ttm_bo_pipeline_move(bo, fence, evict, new_mem);
+ r = ttm_bo_move_accel_cleanup(bo, fence, true, bo->type !=
ttm_bo_type_kernel, new_mem);
dma_fence_put(fence);
return r;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 56f974c28eb5..2ee75646ad6f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -824,7 +824,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict, bool intr,
if (ret == 0) {
ret = ttm_bo_move_accel_cleanup(bo,
&fence->base,
- evict,
+ evict, false,
new_reg);
nouveau_fence_unref(&fence);
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 99d9ca1087b7..36150b7f31a9 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -200,7 +200,7 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
if (IS_ERR(fence))
return PTR_ERR(fence);
- r = ttm_bo_move_accel_cleanup(bo, &fence->base, evict, new_mem);
+ r = ttm_bo_move_accel_cleanup(bo, &fence->base, evict, false, new_mem);
radeon_fence_unref(&fence);
return r;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 502d334786d2..777f843cdb98 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -581,81 +581,56 @@ static int ttm_bo_move_to_ghost(struct ttm_buffer_object
*bo,
return 0;
}
-int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
- struct dma_fence *fence,
- bool evict,
- struct ttm_resource *new_mem)
+static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo,
+ struct dma_fence *fence)
{
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_resource_manager *man = ttm_manager_type(bdev,
new_mem->mem_type);
- int ret;
+ struct ttm_resource_manager *from = ttm_manager_type(bdev,
bo->mem.mem_type);
- dma_resv_add_excl_fence(bo->base.resv, fence);
- if (evict)
- ret = ttm_bo_wait_free_node(bo, man->use_tt);
- else
- ret = ttm_bo_move_to_ghost(bo, fence, man->use_tt);
- if (ret)
- return ret;
+ /**
+* BO doesn't have a TTM we need to bind/unbind. Just remember
+* this eviction and free up the allocation
+*/
+ spin_lock(&from->move_lock);
+ if (!from->move || dma_fence_is_later(fence, from->move)) {
+ dma_fence_put(from->move);
+ from->move = dma_fence_get(fence);
+ }
+ spin_unlock(&from->move_lock);
- ttm_bo_assign_mem(bo, new_mem);
+ ttm_bo_free_old_node(bo);
- return 0;
+ dma_fence_put(bo->moving);
+ bo->moving = dma_fence_get(fence);
}
-EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
-int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
-struct dma_fence *fence, bool evict,
-struct ttm_resource *new_mem)
+int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
+ struct dma_fence *fence,
+ bool evict,
+ bool pipeline,
+ struct ttm_resource *new_mem)
{
struct ttm_bo_device *bdev = bo->bdev;
-
struct ttm_resource_manager *from = ttm_manager_type(bdev,
bo->mem.mem_type);
- str
[PATCH 2/2] drm/ttm: drop evicted from ttm_bo.
From: Dave Airlie
This was unused.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 4
include/drm/ttm/ttm_bo_api.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 279a0e44a5ed..7562b0844c75 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -298,8 +298,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
moved:
- bo->evicted = false;
-
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
return 0;
@@ -638,9 +636,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
if (ret != -ERESTARTSYS)
pr_err("Buffer eviction failed\n");
ttm_resource_free(bo, &evict_mem);
- goto out;
}
- bo->evicted = true;
out:
return ret;
}
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 36ff64e2736c..03b4761a3ea3 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -141,7 +141,6 @@ struct ttm_buffer_object {
struct ttm_resource mem;
struct file *persistent_swap_storage;
struct ttm_tt *ttm;
- bool evicted;
bool deleted;
/**
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] ttm follow-on cleanups
These two also just fell out and seemed like good cleanups. (based on previous series) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, 16 Sep 2020 at 21:32, Linus Torvalds wrote: > > But something like a driver list walking thing should not be doing > different things behind peoples back depending on whether they hold > spinlocks or not. It should either just work regardless, or there > should be a flag (or special interface) for the "you're being called > in a crtitical region". > > Because dynamically changing behavior really is very confusing. > By the same reasoning, I don't think a generic crypto library should be playing tricks with preemption en/disabling under the hood when iterating over some data that is all directly accessible via the linear map on the platforms that most people care about. And using kmap_atomic() unconditionally achieves exactly that. As I argued before, the fact that kmap_atomic() can be called from an atomic context, and the fact that its implementation on HIGHMEM platforms requires preemption to be disabled until the next kunmap() are two different things, and I don't agree with your assertion that the name kmap_atomic() implies the latter semantics. If we can avoid disabling preemption on HIGHMEM, as Thomas suggests, we surely don't need it on !HIGHMEM either, and given that kmap_atomic() is preferred today anyway, we can just merge the two implementations. Are there any existing debug features that could help us spot [ab]use of things like raw per-CPU data within kmap_atomic regions? Re your point about deprecating HIGHMEM: some work is underway on ARM to implement a 3.75/3.75 GB kernel/user split on recent LPAE capable hardware (which shouldn't suffer from the performance issues that plagued the 4/4 split on i686), and so hopefully, there is a path forward for ARM that does not rely on HIGHMEM as it does today. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Wed, Sep 16, 2020 at 5:31 PM Christian König wrote: > > Am 16.09.20 um 17:24 schrieb Daniel Vetter: > > On Wed, Sep 16, 2020 at 4:14 PM Christian König > > wrote: > >> Am 16.09.20 um 16:07 schrieb Jason Gunthorpe: > >>> On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote: > >>> > But within the driver, we generally need thousands of these, and that > tends to bring fd exhaustion problems with it. That's why all the private > buffer objects which aren't shared with other process or other drivers > are > handles only valid for a specific fd instance of the drm chardev (each > open gets their own namespace), and only for ioctls done on that chardev. > And for mmap we assign fake (but unique across all open fd on it) offsets > within the overall chardev. Hence all the pgoff mangling and re-mangling. > >>> Are they still unique struct files? Just without a fdno? > >> Yes, exactly. > > Not entirely, since dma-buf happened after drm chardev, so for that > > historical reason the underlying struct file is shared, since it's the > > drm chardev. But since that's per-device we don't have a problem in > > practice with different vm_ops, since those are also per-device. But > > yeah we could fish out some entirely hidden per-object struct file if > > that's required for some mm internal reasons. > > Hui? Ok that is just the handling in i915, isn't it? > > As far as I know we create an unique struct file for each DMA-buf. Yes dma-buf, but that gets forwarded to the original drm chardev which originally exported the buffer. It's only there where the forwarding chain stops. The other thing is that iirc we have a singleton anon_inode behind all the dma-buf, so they'd share all the same address_space and so would all alias for unmap_mapping_range (I think at least). -Daniel > > Regards, > Christian. > > > > -Daniel > > > Hence why we'd like to be able to forward aliasing mappings and adjust > the > file and pgoff, while hopefully everything keeps working. I thought this > would work, but Christian noticed it doesn't really. > >>> It seems reasonable to me that the dma buf should be the owner of the > >>> VMA, otherwise like you say, there is a big mess attaching the custom > >>> vma ops and what not to the proper dma buf. > >>> > >>> I don't see anything obviously against this in mmap_region() - why did > >>> Chritian notice it doesn't really work? > >> To clarify I think this might work. > >> > >> I just had the same "Is that legal?", "What about security?", etc.. > >> questions you raised as well. > >> > >> It seems like a source of trouble so I thought better ask somebody more > >> familiar with that. > >> > >> Christian. > >> > >>> Jason > >> ___ > >> 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
[pull] amdgpu, amdkfd, radeon drm-fixes-5.9
Hi Dave, Daniel, Fixes for 5.9. The following changes since commit 7f7a47952c0f981f9c9a6409c8cf8d025d55af64: Merge tag 'drm-misc-fixes-2020-09-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-09-11 09:49:23 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.9-2020-09-17 for you to fetch changes up to 875d369d8f75275d30e59421602d9366426abff7: drm/amd/display: Don't log hdcp module warnings in dmesg (2020-09-17 00:13:34 -0400) amd-drm-fixes-5.9-2020-09-17: amdgpu: - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes amdkfd: - Fix a GPU reset crash - Fix a memory leak radeon: - Revert a PLL fix that broke other boards Andrey Grodzovsky (1): drm/amdgpu: Include sienna_cichlid in USBC PD FW support. Bhawanpreet Lakha (2): drm/amd/display: Don't use DRM_ERROR() for DTM add topology drm/amd/display: Don't log hdcp module warnings in dmesg Christian König (1): drm/radeon: revert "Prefer lower feedback dividers" Dennis Li (2): drm/kfd: fix a system crash issue during GPU recovery drm/amdkfd: fix a memory leak issue Jiansong Chen (2): drm/amd/pm: support runtime pptable update for sienna_cichlid etc. drm/amdgpu: declare ta firmware for navy_flounder Jun Lei (1): drm/amd/display: update nv1x stutter latencies Michel Dänzer (1): drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 2 +- drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 ++- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +++--- .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 +-- .../gpu/drm/amd/display/modules/hdcp/hdcp_log.h| 2 +- .../gpu/drm/amd/display/modules/hdcp/hdcp_psp.c| 2 +- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 12 ++-- drivers/gpu/drm/radeon/radeon_display.c| 2 +- 9 files changed, 29 insertions(+), 33 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm/ttm: make common function for wait/free node path.
From: Dave Airlie
The pipeline and accel cleansups has similiar paths here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 38 ---
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 3c16e303d2e2..502d334786d2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -526,6 +526,20 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+static int ttm_bo_wait_free_node(struct ttm_buffer_object *bo,
+bool dst_use_tt)
+{
+ int ret;
+ ret = ttm_bo_wait(bo, false, false);
+ if (ret)
+ return ret;
+
+ if (!dst_use_tt)
+ ttm_bo_tt_destroy(bo);
+ ttm_bo_free_old_node(bo);
+ return 0;
+}
+
static int ttm_bo_move_to_ghost(struct ttm_buffer_object *bo,
struct dma_fence *fence,
bool dst_use_tt)
@@ -577,19 +591,12 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
*bo,
int ret;
dma_resv_add_excl_fence(bo->base.resv, fence);
- if (evict) {
- ret = ttm_bo_wait(bo, false, false);
- if (ret)
- return ret;
-
- if (!man->use_tt)
- ttm_bo_tt_destroy(bo);
- ttm_bo_free_old_node(bo);
- } else {
+ if (evict)
+ ret = ttm_bo_wait_free_node(bo, man->use_tt);
+ else
ret = ttm_bo_move_to_ghost(bo, fence, man->use_tt);
- if (ret)
- return ret;
- }
+ if (ret)
+ return ret;
ttm_bo_assign_mem(bo, new_mem);
@@ -639,14 +646,9 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
*
* Should never happen in pratice.
*/
-
- ret = ttm_bo_wait(bo, false, false);
+ ret = ttm_bo_wait_free_node(bo, to->use_tt);
if (ret)
return ret;
-
- if (!to->use_tt)
- ttm_bo_tt_destroy(bo);
- ttm_bo_free_old_node(bo);
}
ttm_bo_assign_mem(bo, new_mem);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/ttm: move unbind into the tt destroy.
From: Dave Airlie
This moves unbind into the driver side on destroy paths.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 1 +
drivers/gpu/drm/radeon/radeon_ttm.c| 2 ++
drivers/gpu/drm/ttm/ttm_bo.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 1 +
6 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dbe3f90a0cf6..2028b9e4c25c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1267,6 +1267,7 @@ static void amdgpu_ttm_backend_destroy(struct
ttm_bo_device *bdev,
{
struct amdgpu_ttm_tt *gtt = (void *)ttm;
+ amdgpu_ttm_backend_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
if (gtt->usertask)
put_task_struct(gtt->usertask);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index b239381498c3..4a020a3da3dd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1372,6 +1372,7 @@ nouveau_ttm_tt_destroy(struct ttm_bo_device *bdev,
#if IS_ENABLED(CONFIG_AGP)
struct nouveau_drm *drm = nouveau_bdev(bdev);
if (drm->agp.bridge) {
+ ttm_agp_unbind(ttm);
ttm_tt_destroy_common(bdev, ttm);
ttm_agp_destroy(ttm);
return;
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 0dfaa6fb536e..806d9ec310f5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -20,6 +20,7 @@ nouveau_sgdma_destroy(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm;
if (ttm) {
+ nouveau_sgdma_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
ttm_dma_tt_fini(&nvbe->ttm);
kfree(nvbe);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 76e24c6058ff..03e5ae4e3bf6 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -576,6 +576,7 @@ static void radeon_ttm_backend_destroy(struct ttm_bo_device
*bdev, struct ttm_tt
{
struct radeon_ttm_tt *gtt = (void *)ttm;
+ radeon_ttm_backend_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
ttm_dma_tt_fini(>t->ttm);
@@ -757,6 +758,7 @@ static void radeon_ttm_tt_destroy(struct ttm_bo_device
*bdev,
struct radeon_device *rdev = radeon_get_rdev(bdev);
if (rdev->flags & RADEON_IS_AGP) {
+ ttm_agp_unbind(ttm);
ttm_tt_destroy_common(bdev, ttm);
ttm_agp_destroy(ttm);
return;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 649a7d0a0766..2c527cd20dfa 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1620,7 +1620,6 @@ void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
if (bo->ttm == NULL)
return;
- ttm_bo_tt_unbind(bo);
ttm_tt_destroy(bo->bdev, bo->ttm);
bo->ttm = NULL;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index d46426164577..7454f797d37b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -636,6 +636,7 @@ static void vmw_ttm_destroy(struct ttm_bo_device *bdev,
struct ttm_tt *ttm)
struct vmw_ttm_tt *vmw_be =
container_of(ttm, struct vmw_ttm_tt, dma_ttm.ttm);
+ vmw_ttm_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
vmw_ttm_unmap_dma(vmw_be);
if (vmw_be->dev_priv->map_mode == vmw_dma_alloc_coherent)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/ttm: flip tt destroy ordering.
From: Dave Airlie
Call the driver first and have it call the common code cleanup.
This is useful later to fix unbind.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/drm_gem_vram_helper.c | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 1 +
drivers/gpu/drm/qxl/qxl_ttm.c | 1 +
drivers/gpu/drm/radeon/radeon_ttm.c| 3 +++
drivers/gpu/drm/ttm/ttm_tt.c | 7 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 1 +
include/drm/ttm/ttm_tt.h | 7 +++
9 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 2851cf30091a..dbe3f90a0cf6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1267,6 +1267,7 @@ static void amdgpu_ttm_backend_destroy(struct
ttm_bo_device *bdev,
{
struct amdgpu_ttm_tt *gtt = (void *)ttm;
+ ttm_tt_destroy_common(bdev, ttm);
if (gtt->usertask)
put_task_struct(gtt->usertask);
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index f96321509d7e..50cad0e4a92e 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -922,6 +922,7 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs = {
static void bo_driver_ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt
*tt)
{
+ ttm_tt_destroy_common(bdev, tt);
ttm_tt_fini(tt);
kfree(tt);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 616d8844ba97..b239381498c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1372,6 +1372,7 @@ nouveau_ttm_tt_destroy(struct ttm_bo_device *bdev,
#if IS_ENABLED(CONFIG_AGP)
struct nouveau_drm *drm = nouveau_bdev(bdev);
if (drm->agp.bridge) {
+ ttm_tt_destroy_common(bdev, ttm);
ttm_agp_destroy(ttm);
return;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 21fb92770ea2..0dfaa6fb536e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -20,6 +20,7 @@ nouveau_sgdma_destroy(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm;
if (ttm) {
+ ttm_tt_destroy_common(bdev, ttm);
ttm_dma_tt_fini(&nvbe->ttm);
kfree(nvbe);
}
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index bf3b091d0e2a..fd691fff8394 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -130,6 +130,7 @@ static void qxl_ttm_backend_destroy(struct ttm_bo_device
*bdev,
{
struct qxl_ttm_tt *gtt = (void *)ttm;
+ ttm_tt_destroy_common(bdev, ttm);
ttm_tt_fini(>t->ttm);
kfree(gtt);
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index fc8bbca28b34..76e24c6058ff 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -576,6 +576,8 @@ static void radeon_ttm_backend_destroy(struct ttm_bo_device
*bdev, struct ttm_tt
{
struct radeon_ttm_tt *gtt = (void *)ttm;
+ ttm_tt_destroy_common(bdev, ttm);
+
ttm_dma_tt_fini(>t->ttm);
kfree(gtt);
}
@@ -755,6 +757,7 @@ static void radeon_ttm_tt_destroy(struct ttm_bo_device
*bdev,
struct radeon_device *rdev = radeon_get_rdev(bdev);
if (rdev->flags & RADEON_IS_AGP) {
+ ttm_tt_destroy_common(bdev, ttm);
ttm_agp_destroy(ttm);
return;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index a4f0296effac..f43fa69a1e65 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -207,7 +207,7 @@ int ttm_tt_set_placement_caching(struct ttm_tt *ttm,
uint32_t placement)
}
EXPORT_SYMBOL(ttm_tt_set_placement_caching);
-void ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
+void ttm_tt_destroy_common(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
{
ttm_tt_unpopulate(bdev, ttm);
@@ -216,6 +216,11 @@ void ttm_tt_destroy(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
fput(ttm->swap_storage);
ttm->swap_storage = NULL;
+}
+EXPORT_SYMBOL(ttm_tt_destroy_common);
+
+void ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
+{
bdev->driver->ttm_tt_destroy(bdev, ttm);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 01146b27c9a1..d46426164577 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm
[PATCH 4/7] drm/ttm/drivers: call the bind function directly.
From: Dave Airlie
Now the bind functions have all the protection explicitly the
drivers can just call them directly, and the api can be unexported
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 5 -
drivers/gpu/drm/radeon/radeon_ttm.c | 6 +-
drivers/gpu/drm/ttm/ttm_bo.c| 1 -
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 2028b9e4c25c..a57aaf666340 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -63,6 +63,10 @@
#define AMDGPU_TTM_VRAM_MAX_DW_READ(size_t)128
+static int amdgpu_ttm_backend_bind(struct ttm_bo_device *bdev,
+ struct ttm_tt *ttm,
+ struct ttm_resource *bo_mem);
+
static int amdgpu_ttm_init_on_chip(struct amdgpu_device *adev,
unsigned int type,
uint64_t size)
@@ -552,7 +556,7 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object
*bo, bool evict,
goto out_cleanup;
/* Bind the memory to the GTT space */
- r = ttm_bo_tt_bind(bo, &tmp_mem);
+ r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, &tmp_mem);
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4a020a3da3dd..56f974c28eb5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -44,6 +44,9 @@
#include
#include
+static int nouveau_ttm_tt_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm,
+ struct ttm_resource *reg);
+
/*
* NV10-NV40 tiling helpers
*/
@@ -927,7 +930,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool
evict, bool intr,
if (ret)
goto out;
- ret = ttm_bo_tt_bind(bo, &tmp_reg);
+ ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, &tmp_reg);
if (ret)
goto out;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 03e5ae4e3bf6..99d9ca1087b7 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -56,6 +56,10 @@
static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
+static int radeon_ttm_tt_bind(struct ttm_bo_device *bdev,
+ struct ttm_tt *ttm,
+ struct ttm_resource *bo_mem);
+
struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
{
struct radeon_mman *mman;
@@ -238,7 +242,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object
*bo,
goto out_cleanup;
}
- r = ttm_bo_tt_bind(bo, &tmp_mem);
+ r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, &tmp_mem);
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2c527cd20dfa..279a0e44a5ed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1628,7 +1628,6 @@ int ttm_bo_tt_bind(struct ttm_buffer_object *bo, struct
ttm_resource *mem)
{
return bo->bdev->driver->ttm_tt_bind(bo->bdev, bo->ttm, mem);
}
-EXPORT_SYMBOL(ttm_bo_tt_bind);
void ttm_bo_tt_unbind(struct ttm_buffer_object *bo)
{
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/ttm: move ghost object creation to a common function
From: Dave Airlie
Both accel cleanup and pipeline move had the same code, make
a single function for it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 105 --
1 file changed, 43 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 5a8d77ef504f..3c16e303d2e2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -526,6 +526,47 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+static int ttm_bo_move_to_ghost(struct ttm_buffer_object *bo,
+ struct dma_fence *fence,
+ bool dst_use_tt)
+{
+ struct ttm_buffer_object *ghost_obj;
+ int ret;
+
+ /**
+* This should help pipeline ordinary buffer moves.
+*
+* Hang old buffer memory on a new buffer object,
+* and leave it to be released when the GPU
+* operation has completed.
+*/
+
+ dma_fence_put(bo->moving);
+ bo->moving = dma_fence_get(fence);
+
+ ret = ttm_buffer_object_transfer(bo, &ghost_obj);
+ if (ret)
+ return ret;
+
+ dma_resv_add_excl_fence(&ghost_obj->base._resv, fence);
+
+ /**
+* If we're not moving to fixed memory, the TTM object
+* needs to stay alive. Otherwhise hang it on the ghost
+* bo to be unbound and destroyed.
+*/
+
+ if (dst_use_tt) {
+ ghost_obj->ttm = NULL;
+ } else {
+ bo->ttm = NULL;
+ }
+
+ dma_resv_unlock(&ghost_obj->base._resv);
+ ttm_bo_put(ghost_obj);
+ return 0;
+}
+
int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
struct dma_fence *fence,
bool evict,
@@ -534,7 +575,6 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_resource_manager *man = ttm_manager_type(bdev,
new_mem->mem_type);
int ret;
- struct ttm_buffer_object *ghost_obj;
dma_resv_add_excl_fence(bo->base.resv, fence);
if (evict) {
@@ -546,37 +586,9 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
ttm_bo_tt_destroy(bo);
ttm_bo_free_old_node(bo);
} else {
- /**
-* This should help pipeline ordinary buffer moves.
-*
-* Hang old buffer memory on a new buffer object,
-* and leave it to be released when the GPU
-* operation has completed.
-*/
-
- dma_fence_put(bo->moving);
- bo->moving = dma_fence_get(fence);
-
- ret = ttm_buffer_object_transfer(bo, &ghost_obj);
+ ret = ttm_bo_move_to_ghost(bo, fence, man->use_tt);
if (ret)
return ret;
-
- dma_resv_add_excl_fence(&ghost_obj->base._resv, fence);
-
- /**
-* If we're not moving to fixed memory, the TTM object
-* needs to stay alive. Otherwhise hang it on the ghost
-* bo to be unbound and destroyed.
-*/
-
- if (man->use_tt) {
- ghost_obj->ttm = NULL;
- } else {
- bo->ttm = NULL;
- }
-
- dma_resv_unlock(&ghost_obj->base._resv);
- ttm_bo_put(ghost_obj);
}
ttm_bo_assign_mem(bo, new_mem);
@@ -599,40 +611,9 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
dma_resv_add_excl_fence(bo->base.resv, fence);
if (!evict) {
- struct ttm_buffer_object *ghost_obj;
-
- /**
-* This should help pipeline ordinary buffer moves.
-*
-* Hang old buffer memory on a new buffer object,
-* and leave it to be released when the GPU
-* operation has completed.
-*/
-
- dma_fence_put(bo->moving);
- bo->moving = dma_fence_get(fence);
-
- ret = ttm_buffer_object_transfer(bo, &ghost_obj);
+ ret = ttm_bo_move_to_ghost(bo, fence, to->use_tt);
if (ret)
return ret;
-
- dma_resv_add_excl_fence(&ghost_obj->base._resv, fence);
-
- /**
-* If we're not moving to fixed memory, the TTM object
-* needs to stay alive. Otherwhise hang it on the ghost
-* bo to be unbound and destroyed.
-*/
-
- if (to->use_tt) {
- ghost_obj->ttm = NULL;
- } else {
- bo->ttm = NULL;
- }
-
- dma_resv_unlock(&ghost_obj->base._resv);
- ttm_b
[PATCH 5/7] drm/ttm: add a simple assign mem to bo wrapper
From: Dave Airlie
This pattern is called in a few places, just clean it up.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 18 ++
include/drm/ttm/ttm_bo_driver.h | 10 --
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 919489f6a5a3..5a8d77ef504f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -87,9 +87,7 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
return ret;
}
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
-
+ ttm_bo_assign_mem(bo, new_mem);
return 0;
}
EXPORT_SYMBOL(ttm_bo_move_ttm);
@@ -299,8 +297,8 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
mb();
out2:
old_copy = *old_mem;
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
+
+ ttm_bo_assign_mem(bo, new_mem);
if (!man->use_tt)
ttm_bo_tt_destroy(bo);
@@ -535,7 +533,6 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
{
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_resource_manager *man = ttm_manager_type(bdev,
new_mem->mem_type);
- struct ttm_resource *old_mem = &bo->mem;
int ret;
struct ttm_buffer_object *ghost_obj;
@@ -582,8 +579,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
ttm_bo_put(ghost_obj);
}
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
+ ttm_bo_assign_mem(bo, new_mem);
return 0;
}
@@ -594,9 +590,8 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
struct ttm_resource *new_mem)
{
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_resource *old_mem = &bo->mem;
- struct ttm_resource_manager *from = ttm_manager_type(bdev,
old_mem->mem_type);
+ struct ttm_resource_manager *from = ttm_manager_type(bdev,
bo->mem.mem_type);
struct ttm_resource_manager *to = ttm_manager_type(bdev,
new_mem->mem_type);
int ret;
@@ -673,8 +668,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
ttm_bo_free_old_node(bo);
}
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
+ ttm_bo_assign_mem(bo, new_mem);
return 0;
}
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 7846dfa507f7..25cc932d63f1 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -539,6 +539,13 @@ static inline void ttm_bo_move_to_lru_tail_unlocked(struct
ttm_buffer_object *bo
spin_unlock(&ttm_bo_glob.lru_lock);
}
+static inline void ttm_bo_assign_mem(struct ttm_buffer_object *bo,
+struct ttm_resource *new_mem)
+{
+ bo->mem = *new_mem;
+ new_mem->mm_node = NULL;
+}
+
/**
* ttm_bo_move_null = assign memory for a buffer object.
* @bo: The bo to assign the memory to
@@ -552,8 +559,7 @@ static inline void ttm_bo_move_null(struct
ttm_buffer_object *bo,
struct ttm_resource *old_mem = &bo->mem;
WARN_ON(old_mem->mm_node != NULL);
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
+ ttm_bo_assign_mem(bo, new_mem);
}
/**
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/ttm: protect against reentrant bind in the drivers
From: Dave Airlie
This moves the generic tracking into the drivers and protects
against reentrancy in the drivers. It fixes up radeon and agp
to be able to query the bound status as that is required.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 12 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 5 +++-
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 8 +-
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_mn.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 31 ++
drivers/gpu/drm/ttm/ttm_agp_backend.c | 14 ++
drivers/gpu/drm/ttm/ttm_bo.c | 20 ++
drivers/gpu/drm/ttm/ttm_bo_util.c | 5
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 22 ---
include/drm/ttm/ttm_bo_api.h | 1 -
include/drm/ttm/ttm_bo_driver.h| 14 --
include/drm/ttm/ttm_tt.h | 1 +
13 files changed, 91 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e86f8f6371c4..2851cf30091a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -813,6 +813,7 @@ struct amdgpu_ttm_tt {
uint64_tuserptr;
struct task_struct *usertask;
uint32_tuserflags;
+ boolbound;
#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
struct hmm_range*range;
#endif
@@ -1110,6 +,12 @@ static int amdgpu_ttm_backend_bind(struct ttm_bo_device
*bdev,
uint64_t flags;
int r = 0;
+ if (!bo_mem)
+ return -EINVAL;
+
+ if (gtt->bound)
+ return 0;
+
if (gtt->userptr) {
r = amdgpu_ttm_tt_pin_userptr(bdev, ttm);
if (r) {
@@ -1143,6 +1150,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_bo_device
*bdev,
if (r)
DRM_ERROR("failed to bind %lu pages at 0x%08llX\n",
ttm->num_pages, gtt->offset);
+ gtt->bound = true;
return r;
}
@@ -1236,6 +1244,9 @@ static void amdgpu_ttm_backend_unbind(struct
ttm_bo_device *bdev,
struct amdgpu_ttm_tt *gtt = (void *)ttm;
int r;
+ if (!gtt->bound)
+ return;
+
/* if the pages have userptr pinning then clear that first */
if (gtt->userptr)
amdgpu_ttm_tt_unpin_userptr(bdev, ttm);
@@ -1248,6 +1259,7 @@ static void amdgpu_ttm_backend_unbind(struct
ttm_bo_device *bdev,
if (r)
DRM_ERROR("failed to unbind %lu pages at 0x%08llX\n",
gtt->ttm.ttm.num_pages, gtt->offset);
+ gtt->bound = false;
}
static void amdgpu_ttm_backend_destroy(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index aea201d9c513..616d8844ba97 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -718,7 +718,10 @@ nouveau_ttm_tt_bind(struct ttm_bo_device *bdev, struct
ttm_tt *ttm,
{
#if IS_ENABLED(CONFIG_AGP)
struct nouveau_drm *drm = nouveau_bdev(bdev);
-
+#endif
+ if (!reg)
+ return -EINVAL;
+#if IS_ENABLED(CONFIG_AGP)
if (drm->agp.bridge)
return ttm_agp_bind(ttm, reg);
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 05e542254e1f..21fb92770ea2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -33,6 +33,9 @@ nouveau_sgdma_bind(struct ttm_bo_device *bdev, struct ttm_tt
*ttm, struct ttm_re
struct nouveau_mem *mem = nouveau_mem(reg);
int ret;
+ if (nvbe->mem)
+ return 0;
+
ret = nouveau_mem_host(reg, &nvbe->ttm);
if (ret)
return ret;
@@ -53,7 +56,10 @@ void
nouveau_sgdma_unbind(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
{
struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm;
- nouveau_mem_fini(nvbe->mem);
+ if (nvbe->mem) {
+ nouveau_mem_fini(nvbe->mem);
+ nvbe->mem = NULL;
+ }
}
struct ttm_tt *
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index df6f0b49836b..a6d8de01194a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2820,6 +2820,7 @@ extern int radeon_ttm_tt_set_userptr(struct radeon_device
*rdev,
uint32_t flags);
extern bool radeon_ttm_tt_has_userptr(struct radeon_device *rdev, struct
ttm_tt *ttm);
extern bool radeon_ttm_tt_is_readonly(struct radeon_device *rdev, struct
ttm_tt *ttm);
+bool radeon_ttm_tt_is_bound(struct ttm_bo_device *bdev, struct ttm_tt *ttm);
extern void radeon_vram_location(struct radeon_device *rdev, struct
[PATCH 0/7] drm/ttm: bind/unbind + cleanups
I've pulled a few of the cleaner bits of rework out for review. The first thing is to move all the tt bind tracking into the driver so the core doesn't do it all anymore. Once that is done it's possible to flip over how destroy works so the drivers call some common code instead of vice-versa. With those two done the unbind can be completely moved into drivers, so it happens before the unpopulate in the common code. This removes a lot of unbinds from the core code (only really one left). Then a patch to flip some drivers over to direct calling their bind functions instead of indirect (just a trivial cleanup really) (bind needs a lot more work). Then I just refactored out some common patters in the move code, which should make it easier to pinpoint the codeflow for future bind changes. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v1] powerplay:hwmgr - modify the return value
[AMD Official Use Only - Internal Distribution Only]
Thanks. Reviewed-by: Evan Quan
-Original Message-
From: Xiaoliang Pang
Sent: Thursday, September 17, 2020 11:46 AM
To: Quan, Evan ; Deucher, Alexander
; Koenig, Christian ;
airl...@linux.ie; dan...@ffwll.ch; Feng, Kenneth ;
zhengbi...@huawei.com; pe...@vangils.xyz; yt...@amd.com
Cc: Das, Nirmoy ; Huang, JinHuiEric
; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
tianjia.zh...@linux.alibaba.com; dawning.p...@gmail.com
Subject: [PATCH v1] powerplay:hwmgr - modify the return value
modify the return value is -EINVAL
Fixes: f83a9991648bb("drm/amd/powerplay: add Vega10 powerplay support (v5)")
Fixes: 2cac05dee6e30("drm/amd/powerplay: add the hw manager for vega12 (v4)")
Cc: Eric Huang
Cc: Evan Quan
Signed-off-by: Xiaoliang Pang
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index c378a000c934..7eada3098ffc 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -4659,7 +4659,7 @@ static int
vega10_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
if ((data->water_marks_bitmap & WaterMarksExist) &&
!(data->water_marks_bitmap & WaterMarksLoaded)) {
result = smum_smc_table_manager(hwmgr, (uint8_t *)wm_table, WMTABLE, false);
-PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return EINVAL);
+PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return -EINVAL);
data->water_marks_bitmap |= WaterMarksLoaded;
}
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index a678a67f1c0d..04da52cea824 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -2390,7 +2390,7 @@ static int
vega12_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
!(data->water_marks_bitmap & WaterMarksLoaded)) {
result = smum_smc_table_manager(hwmgr,
(uint8_t *)wm_table, TABLE_WATERMARKS, false);
-PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return EINVAL);
+PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return -EINVAL);
data->water_marks_bitmap |= WaterMarksLoaded;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v3 PATCH] drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp
Replace horizontal_backporch_byte with vm->hback_porch * bpp to aovid
flowing judgement negative number.
if ((vm->hfront_porch * dsi_tmp_buf_bpp + horizontal_backporch_byte) >
data_phy_cycles * dsi->lanes + delta)
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 54 ++
1 file changed, 19 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 16fd99dcdacf..f69ebeaf 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -445,6 +445,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
u32 horizontal_backporch_byte;
u32 horizontal_frontporch_byte;
u32 dsi_tmp_buf_bpp, data_phy_cycles;
+ u32 delta;
struct mtk_phy_timing *timing = &dsi->phy_timing;
struct videomode *vm = &dsi->vm;
@@ -475,42 +476,25 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
data_phy_cycles = timing->lpx + timing->da_hs_prepare +
timing->da_hs_zero + timing->da_hs_exit + 3;
- if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
- if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
- data_phy_cycles * dsi->lanes + 18) {
- horizontal_frontporch_byte =
- vm->hfront_porch * dsi_tmp_buf_bpp -
- (data_phy_cycles * dsi->lanes + 18) *
- vm->hfront_porch /
- (vm->hfront_porch + vm->hback_porch);
-
- horizontal_backporch_byte =
- horizontal_backporch_byte -
- (data_phy_cycles * dsi->lanes + 18) *
- vm->hback_porch /
- (vm->hfront_porch + vm->hback_porch);
- } else {
- DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
- horizontal_frontporch_byte = vm->hfront_porch *
-dsi_tmp_buf_bpp;
- }
+ delta = (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) ? 18 : 12;
+
+ if ((vm->hfront_porch * dsi_tmp_buf_bpp + horizontal_backporch_byte) >
+ data_phy_cycles * dsi->lanes + delta) {
+ horizontal_frontporch_byte =
+ vm->hfront_porch * dsi_tmp_buf_bpp -
+ (data_phy_cycles * dsi->lanes + delta) *
+ vm->hfront_porch /
+ (vm->hfront_porch + vm->hback_porch);
+
+ horizontal_backporch_byte =
+ horizontal_backporch_byte -
+ (data_phy_cycles * dsi->lanes + delta) *
+ vm->hback_porch /
+ (vm->hfront_porch + vm->hback_porch);
} else {
- if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
- data_phy_cycles * dsi->lanes + 12) {
- horizontal_frontporch_byte =
- vm->hfront_porch * dsi_tmp_buf_bpp -
- (data_phy_cycles * dsi->lanes + 12) *
- vm->hfront_porch /
- (vm->hfront_porch + vm->hback_porch);
- horizontal_backporch_byte = horizontal_backporch_byte -
- (data_phy_cycles * dsi->lanes + 12) *
- vm->hback_porch /
- (vm->hfront_porch + vm->hback_porch);
- } else {
- DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
- horizontal_frontporch_byte = vm->hfront_porch *
-dsi_tmp_buf_bpp;
- }
+ DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
+ horizontal_frontporch_byte = vm->hfront_porch *
+dsi_tmp_buf_bpp;
}
writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL FOR v5.10 - v2] R-Car display drivers miscellaneous changes
Hi Dave and Daniel, As the original pull request hasn't been pulled yet, here's an updated version that collects more acks and rb's, and includes an additional patch. The following changes since commit 818280d5adf1d80e78f95821815148abe9407e14: Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11 +0200) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-next-20200917 for you to fetch changes up to ab00111864ee2c9742f6627c5ca1019730c0eedd: drm: rcar-du: Put reference to VSP device (2020-09-17 03:42:17 +0300) Miscellaneous R-Car display driver changes: - R8A7742, R8A774E1 and R8A77961 support - Fixes for pitch of YUV planar formats, non-visible plane handling and VSP device reference count - Kconfig fix to avoid displaying disabled options in .config Biju Das (2): dt-bindings: display: bridge: lvds-codec: Document power-supply property drm/bridge: lvds-codec: Add support for regulator Kuninori Morimoto (4): dt-bindings: display: renesas: du: Document the r8a77961 bindings dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support drm: rcar-du: Add r8a77961 support Lad Prabhakar (5): dt-bindings: display: renesas,du: Document the r8a7742 bindings drm: rcar-du: Add r8a7742 support dt-bindings: display: renesas,lvds: Document r8a7742 bindings drm: rcar-du: lvds: Add r8a7742 support drm: rcar-du: Update description for DRM_RCAR_DW_HDMI Kconfig entry Laurent Pinchart (3): drm: rcar-du: Fix pitch handling for fully planar YUV formats drm: rcar-du: Fix crash when enabling a non-visible plane drm: rcar-du: Put reference to VSP device Marian-Cristian Rotariu (5): dt-bindings: display: renesas,du: Document r8a774e1 bindings drm: rcar-du: Add support for R8A774E1 SoC dt-bindings: display: renesas,lvds: Document r8a774e1 bindings dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support drm: rcar-du: lvds: Add support for R8A774E1 SoC Qian Cai (1): drm: rcar-du: Make DRM_RCAR_WRITEBACK depends on DRM_RCAR_DU .../bindings/display/bridge/lvds-codec.yaml| 3 ++ .../bindings/display/bridge/renesas,dw-hdmi.txt| 4 +- .../bindings/display/bridge/renesas,lvds.yaml | 2 + .../devicetree/bindings/display/renesas,du.txt | 6 +++ drivers/gpu/drm/bridge/lvds-codec.c| 29 drivers/gpu/drm/rcar-du/Kconfig| 5 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 37 ++- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 54 +- drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 14 +- drivers/gpu/drm/rcar-du/rcar_lvds.c| 2 + 11 files changed, 149 insertions(+), 8 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Put reference to VSP device
Hi Kieran,
On Wed, Sep 16, 2020 at 11:26:36AM +0100, Kieran Bingham wrote:
> On 16/09/2020 00:38, Laurent Pinchart wrote:
> > The reference to the VSP device acquired with of_find_device_by_node()
> > in rcar_du_vsp_init() is never released. Fix it with a drmm action,
> > which gets run both in the probe error path and in the remove path.
> >
> > Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS
> > planes")
> > Reported-by: Yu Kuai
> > Signed-off-by: Laurent Pinchart
>
> Looks nice and clean!
>
> Reviewed-by: Kieran Bingham
>
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > index f1a81c9b184d..fa09b3ae8b9d 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > @@ -13,6 +13,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -341,6 +342,13 @@ static const struct drm_plane_funcs
> > rcar_du_vsp_plane_funcs = {
> > .atomic_destroy_state = rcar_du_vsp_plane_atomic_destroy_state,
> > };
> >
> > +static void rcar_du_vsp_cleanup(struct drm_device *dev, void *res)
> > +{
> > + struct rcar_du_vsp *vsp = res;
> > +
> > + put_device(vsp->vsp);
>
> Ugh the asymmetry of the put_device is a bit annoying, because it's not
> initially clear that the of_find_device_by_node() call 'gets' a reference.
>
> (Or at least not until you find:
> https://lore.kernel.org/patchwork/patch/731284/)
>
> It is stated in the commit message though so that's fine, and although I
> thought perhaps a comment here might be useful to declare that it
> releases the reference taken by of_find_device_by_node(), I'm not sure
> it even adds that much value ... so either way.
I think that the fact that drmm_add_action() is called right after
of_find_device_by_node() makes this explicit enough.
> > +}
> > +
> > int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
> > unsigned int crtcs)
> > {
> > @@ -357,6 +365,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
> > device_node *np,
> >
> > vsp->vsp = &pdev->dev;
> >
> > + ret = drmm_add_action(rcdu->ddev, rcar_du_vsp_cleanup, vsp);
> > + if (ret < 0)
> > + return ret;
> > +
> > ret = vsp1_du_init(vsp->vsp);
> > if (ret < 0)
> > return ret;
> >
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: dp-connector: add binding for DisplayPort connector
Hi Tomi,
Thank you for the patch.
On Wed, Sep 16, 2020 at 05:44:40PM +0300, Tomi Valkeinen wrote:
> Add binding for DisplayPort connector. A few notes:
>
> * Similar to hdmi-connector, it has hpd-gpios as an optional property,
> as the HPD could also be handled by, e.g., the DP bridge.
>
> * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it
> is not strictly required: standard DP cables do not even have the pin
> connected.
>
> * No property for the connector type. Full size and mini connectors are
> identical except for the connector size and form, so I believe there
> is no need to include the type in the bindings.
It could be useful to present information about the connector to
userspace. For instance, a GUI could show a picture of the connector
that the user should plug a cable in. This can also be added later, but
I think it would be useful to have it from the start.
> * No eDP. There's really no "eDP connector", as it's always a custom
> made connection between the DP and the DP panel. So possibly there is
> no need for edp-connector binding, but even if there is, I don't want
> to guess what it could look like, and could it be part of the
> dp-connector binding.
Agreed.
> * No DP++. I'm not familiar with DP++, but I think it's all handled by
> the DP bridge, and does not need any new properties to the dp-connector.
I'm not familiar with this either.
> Signed-off-by: Tomi Valkeinen
Possibly with a type property added,
Reviewed-by: Laurent Pinchart
> ---
> .../display/connector/dp-connector.yaml | 48 +++
> 1 file changed, 48 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/connector/dp-connector.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> new file mode 100644
> index ..983be1fe43f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/connector/dp-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: DisplayPort Connector
> +
> +maintainers:
> + - Tomi Valkeinen
> +
> +properties:
> + compatible:
> +const: dp-connector
> +
> + label: true
> +
> + hpd-gpios:
> +description: A GPIO line connected to HPD
> +maxItems: 1
> +
> + dp-pwr-supply:
> +description: Power supply for the DP_PWR pin
> +maxItems: 1
> +
> + port:
> +description: Connection to controller providing DP signals
> +
> +required:
> + - compatible
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +connector {
> +compatible = "dp-connector";
> +label = "dp0";
> +
> +port {
> +dp_connector_in: endpoint {
> +remote-endpoint = <&dp_out>;
> +};
> +};
> +};
> +
> +...
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/23] virtio-gpu api: blob resources
On Tue, Sep 8, 2020 at 11:55 PM Gerd Hoffmann wrote:
> Hi,
>
> > @@ -100,7 +102,7 @@ struct drm_virtgpu_resource_info {
> > __u32 bo_handle;
> > __u32 res_handle;
> > __u32 size;
> > - __u32 stride;
> > + __u32 blob_mem;
> > };
>
> Huh? This is not in the virtio spec update proposed.
>
> > struct drm_virtgpu_3d_box {
> > @@ -117,6 +119,8 @@ struct drm_virtgpu_3d_transfer_to_host {
> > struct drm_virtgpu_3d_box box;
> > __u32 level;
> > __u32 offset;
> > + __u32 stride;
> > + __u32 layer_stride;
> > };
>
> Same here.
>
> > struct drm_virtgpu_3d_transfer_from_host {
> > @@ -124,6 +128,8 @@ struct drm_virtgpu_3d_transfer_from_host {
> > struct drm_virtgpu_3d_box box;
> > __u32 level;
> > __u32 offset;
> > + __u32 stride;
> > + __u32 layer_stride;
> > };
> And here.
>
Separated out the virtio and DRM api changes, as per your recommendation.
The virtio spec changes should match v6 of the proposed spec. Explanations
for these specific DRM changes here are in patch 16 & patch 17 of the v3
implementation.
> take care,
> Gerd
>
> PS: cherry-picked patches 1-3 into drm-misc-next.
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/19] drm/virtio: implement blob resources: refactor UUID code somewhat
For upcoming blob resources, userspace can specify that the
resource will be used for cross-device sharing. This is mainly
for exportable blobs that will only shared with the virtgpu
display but not across devices.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_prime.c | 42 ++
2 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index e1143a00017c5..bbbe28f8b9436 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -432,6 +432,8 @@ bool virtio_gpu_is_shmem(struct virtio_gpu_object *bo);
int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
uint32_t *resid);
/* virtgpu_prime.c */
+int virtio_gpu_resource_assign_uuid(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo);
struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj,
int flags);
struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 3552db128ba3d..1ef1e2f226333 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -59,6 +59,24 @@ const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = {
.get_uuid = virtgpu_virtio_get_uuid,
};
+int virtio_gpu_resource_assign_uuid(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo)
+{
+ int ret;
+ struct virtio_gpu_object_array *objs;
+
+ objs = virtio_gpu_array_alloc(1);
+ if (!objs)
+ return -ENOMEM;
+
+ virtio_gpu_array_add_obj(objs, &bo->base.base);
+ ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, objs);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj,
int flags)
{
@@ -66,22 +84,20 @@ struct dma_buf *virtgpu_gem_prime_export(struct
drm_gem_object *obj,
struct drm_device *dev = obj->dev;
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
- struct virtio_gpu_object_array *objs;
int ret = 0;
+ bool blob = bo->host3d_blob || bo->guest_blob;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
- if (vgdev->has_resource_assign_uuid) {
- objs = virtio_gpu_array_alloc(1);
- if (!objs)
- return ERR_PTR(-ENOMEM);
- virtio_gpu_array_add_obj(objs, &bo->base.base);
-
- ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, objs);
- if (ret)
- return ERR_PTR(ret);
- virtio_gpu_notify(vgdev);
- } else {
- bo->uuid_state = STATE_ERR;
+ if (!blob) {
+ if (vgdev->has_resource_assign_uuid) {
+ ret = virtio_gpu_resource_assign_uuid(vgdev, bo);
+ if (ret)
+ return ERR_PTR(ret);
+
+ virtio_gpu_notify(vgdev);
+ } else {
+ bo->uuid_state = STATE_ERR;
+ }
}
exp_info.ops = &virtgpu_dmabuf_ops.ops;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/19] virtio-gpu api: blob resources
From: Gerd Hoffmann
A blob resource is a container for:
- VIRTIO_GPU_BLOB_MEM_GUEST: a guest memory allocation
(referred to as a "guest-only blob resource")
- VIRTIO_GPU_BLOB_MEM_HOST3D: a host3d memory allocation
(referred to as a "host-only blob resource")
- VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST: a guest + host3d memory allocation
(referred to as a "default blob resource").
The memory properties of the blob resource must be described by
`blob_mem`.
For default and guest only blob resources set, `nents` guest system
pages are assigned to the resource. For default blob resources,
these guest pages are used for transfer operations. Attach/detach is
also possible to allow swap-in/swap-out, but isn't required since it
may not be applicable to future blob mem types
(shared guest/guest vram).
Host allocations depend on whether the 3D is supported. If 3D is not
supported, the only valid field for `blob_mem` is
VIRTIO_GPU_BLOB_MEM_GUEST.
If 3D is supported, the virtio-gpu resource is created from the
context local object identified by the `blob_id`. The actual host
allocation done by the CMD_SUBMIT_3D.
Userspace must specify if the blob resource is intended to be used
for userspace mapping, sharing between virtio-gpu contexts and/or
sharing between virtio devices. This is done via `blob_flags`.
For 3D hosts, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D and
VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update
the host resource. There is no restriction on the image/buffer
view the guest/host userspace has on the blob resource.
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB / VIRTIO_GPU_CMD_RESOURCE_FLUSH may
be used with blob resources as well. The modifier is intentionally
left out of SCANOUT_BLOB, and auxilary blobs are also left out
as a simplification.
The use case for blob resources is zero-copy, needed for coherent
memory in virglrenderer. Host only blob resources are not mappable
without the feature described in the next patch, but are shareable.
Future work:
- Emulated coherent `blob_mem` type for QEMU/vhost-user
- A `blob_mem` type for guest-only resources imported in
cache-coherent FOSS GPU/display drivers.
- Display integration involving the blob model using seamless
Wayland windows.
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
Acked-by: Chia-I Wu
Acked-by: Lingfeng Yang
Link: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/374
---
include/uapi/linux/virtio_gpu.h | 43 +
1 file changed, 43 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index 747a5c5cc4e60..4ddf2fe342ed0 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux/virtio_gpu.h
@@ -55,6 +55,11 @@
*/
#define VIRTIO_GPU_F_RESOURCE_UUID 2
+/*
+ * VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB
+ */
+#define VIRTIO_GPU_F_RESOURCE_BLOB 3
+
enum virtio_gpu_ctrl_type {
VIRTIO_GPU_UNDEFINED = 0,
@@ -71,6 +76,8 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_GET_CAPSET,
VIRTIO_GPU_CMD_GET_EDID,
VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
+ VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
+ VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
/* 3d commands */
VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -359,4 +366,40 @@ struct virtio_gpu_resp_resource_uuid {
__u8 uuid[16];
};
+/* VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB */
+struct virtio_gpu_resource_create_blob {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __le32 resource_id;
+#define VIRTIO_GPU_BLOB_MEM_GUEST 0x0001
+#define VIRTIO_GPU_BLOB_MEM_HOST3D0x0002
+#define VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST 0x0003
+
+#define VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE 0x0001
+#define VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE0x0002
+#define VIRTIO_GPU_BLOB_FLAG_USE_CROSS_DEVICE 0x0004
+ /* zero is invalid blob mem */
+ __le32 blob_mem;
+ __le32 blob_flags;
+ __le64 blob_id;
+ __le64 size;
+ __le32 nr_entries;
+ /*
+* sizeof(nr_entries * virtio_gpu_mem_entry) bytes follow
+*/
+};
+
+/* VIRTIO_GPU_CMD_SET_SCANOUT_BLOB */
+struct virtio_gpu_set_scanout_blob {
+ struct virtio_gpu_ctrl_hdr hdr;
+ struct virtio_gpu_rect r;
+ __le32 scanout_id;
+ __le32 resource_id;
+ __le32 width;
+ __le32 height;
+ __le32 format;
+ __le32 padding;
+ __le32 strides[4];
+ __le32 offsets[4];
+};
+
#endif
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/19] drm/virtio: implement blob resources: fix stride discrepancy
The old transfer ioctls may work on blob resources, and there is no
TRANSFER_BLOB hypercall now for simplicity.
The guest may have a image view on the blob resources such that the
stride is not equal to width * bytes_per_pixel.
For host-only blobs, we can repurpose the transfer ioctls to synchronize
caches as well. For guest-only blobs, these operations are undefined
for now so leave them out.
Also, with seamless Wayland integration between guest/host looking
increasingly attractive, it also makes sense to keep track of
one value for stride.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 35 +++---
drivers/gpu/drm/virtio/virtgpu_vq.c| 14 +--
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index bbbe28f8b9436..ad16cef9a39b8 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -351,12 +351,16 @@ void virtio_gpu_cmd_submit(struct virtio_gpu_device
*vgdev,
void virtio_gpu_cmd_transfer_from_host_3d(struct virtio_gpu_device *vgdev,
uint32_t ctx_id,
uint64_t offset, uint32_t level,
+ uint32_t stride,
+ uint32_t layer_stride,
struct drm_virtgpu_3d_box *box,
struct virtio_gpu_object_array *objs,
struct virtio_gpu_fence *fence);
void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev,
uint32_t ctx_id,
uint64_t offset, uint32_t level,
+ uint32_t stride,
+ uint32_t layer_stride,
struct drm_virtgpu_3d_box *box,
struct virtio_gpu_object_array *objs,
struct virtio_gpu_fence *fence);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index c8da7adc6b307..0bf789f2bfdec 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -312,6 +312,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
drm_device *dev,
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
struct drm_virtgpu_3d_transfer_from_host *args = data;
+ struct virtio_gpu_object *bo;
struct virtio_gpu_object_array *objs;
struct virtio_gpu_fence *fence;
int ret;
@@ -325,6 +326,17 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
drm_device *dev,
if (objs == NULL)
return -ENOENT;
+ bo = gem_to_virtio_gpu_obj(objs->objs[0]);
+ if (bo->guest_blob && !bo->host3d_blob) {
+ ret = -EINVAL;
+ goto err_put_free;
+ }
+
+ if (!bo->host3d_blob && (args->stride || args->layer_stride)) {
+ ret = -EINVAL;
+ goto err_put_free;
+ }
+
ret = virtio_gpu_array_lock_resv(objs);
if (ret != 0)
goto err_put_free;
@@ -334,9 +346,10 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
drm_device *dev,
ret = -ENOMEM;
goto err_unlock;
}
+
virtio_gpu_cmd_transfer_from_host_3d
- (vgdev, vfpriv->ctx_id, offset, args->level,
-&args->box, objs, fence);
+ (vgdev, vfpriv->ctx_id, offset, args->level, args->stride,
+args->layer_stride, &args->box, objs, fence);
dma_fence_put(&fence->f);
virtio_gpu_notify(vgdev);
return 0;
@@ -354,6 +367,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
drm_device *dev, void *data,
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
struct drm_virtgpu_3d_transfer_to_host *args = data;
+ struct virtio_gpu_object *bo;
struct virtio_gpu_object_array *objs;
struct virtio_gpu_fence *fence;
int ret;
@@ -363,6 +377,12 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
drm_device *dev, void *data,
if (objs == NULL)
return -ENOENT;
+ bo = gem_to_virtio_gpu_obj(objs->objs[0]);
+ if (bo->guest_blob && !bo->host3d_blob) {
+ ret = -EINVAL;
+ goto err_put_free;
+ }
+
if (!vgdev->has_virgl_3d) {
virtio_gpu_cmd_transfer_to_host_2d
(vgdev, offset,
@@ -370,6 +390,12 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
drm_d
[PATCH v3 10/19] drm/virtio: implement blob resources: expose virtio_gpu_resource_id_get
VRAM object will need it.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 2 ++
drivers/gpu/drm/virtio/virtgpu_object.c | 3 +--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 391637f0b362d..674a525df9bcc 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -384,6 +384,8 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
bool virtio_gpu_is_shmem(struct virtio_gpu_object *bo);
+int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
+ uint32_t *resid);
/* virtgpu_prime.c */
struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj,
int flags);
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 4c107b53e81a0..9469ddda523e9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -31,8 +31,7 @@
static int virtio_gpu_virglrenderer_workaround = 1;
module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int, 0400);
-static int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
- uint32_t *resid)
+int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t
*resid)
{
if (virtio_gpu_virglrenderer_workaround) {
/*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 19/19] drm/virtio: advertise features to userspace
New api changes are now available to userspace. Also, the
comparison to true is redundant, so remove it.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 3ede098c1d280..5417f365d1a39 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -212,11 +212,20 @@ static int virtio_gpu_getparam_ioctl(struct drm_device
*dev, void *data,
switch (param->param) {
case VIRTGPU_PARAM_3D_FEATURES:
- value = vgdev->has_virgl_3d == true ? 1 : 0;
+ value = vgdev->has_virgl_3d ? 1 : 0;
break;
case VIRTGPU_PARAM_CAPSET_QUERY_FIX:
value = 1;
break;
+ case VIRTGPU_PARAM_RESOURCE_BLOB:
+ value = vgdev->has_resource_blob ? 1 : 0;
+ break;
+ case VIRTGPU_PARAM_HOST_VISIBLE:
+ value = vgdev->has_host_visible ? 1 : 0;
+ break;
+ case VIRTGPU_PARAM_CROSS_DEVICE:
+ value = vgdev->has_resource_assign_uuid ? 1 : 0;
+ break;
default:
return -EINVAL;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/19] drm/virtgpu api: host visible feature
This exposes the host visible feature to userspace. Without it,
it is an error to specify BLOB_MEM_HOST3D with
BLOG_FLAG_USE_MAPPABLE.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
Acked-by: Lingfeng Yang
---
include/uapi/drm/virtgpu_drm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
index bb224f604c9e3..e1b1518f9acc5 100644
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -73,6 +73,7 @@ struct drm_virtgpu_execbuffer {
#define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
#define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */
#define VIRTGPU_PARAM_RESOURCE_BLOB 3 /* DRM_VIRTGPU_RESOURCE_CREATE_BLOB */
+#define VIRTGPU_PARAM_HOST_VISIBLE 4 /* Host blob resources are mappable */
struct drm_virtgpu_getparam {
__u64 param;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 18/19] drm/virtio: implement blob resources: resource create blob ioctl
From: Gerd Hoffmann
Implement resource create blob as specified.
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 4 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 136
drivers/gpu/drm/virtio/virtgpu_object.c | 5 +-
drivers/gpu/drm/virtio/virtgpu_vram.c | 2 +
4 files changed, 144 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index ad16cef9a39b8..3c0e17212c336 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -257,8 +257,8 @@ struct virtio_gpu_fpriv {
struct mutex context_lock;
};
-/* virtgpu_ioctl.c */
-#define DRM_VIRTIO_NUM_IOCTLS 10
+/* virtio_ioctl.c */
+#define DRM_VIRTIO_NUM_IOCTLS 11
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index b0c9dd171ad8a..3ede098c1d280 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -34,6 +34,10 @@
#include "virtgpu_drv.h"
+#define VIRTGPU_BLOB_FLAG_USE_MASK (VIRTGPU_BLOB_FLAG_USE_MAPPABLE | \
+ VIRTGPU_BLOB_FLAG_USE_SHAREABLE | \
+ VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE)
+
void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
@@ -521,6 +525,134 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device
*dev,
return 0;
}
+static int verify_blob(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_fpriv *vfpriv,
+ struct virtio_gpu_object_params *params,
+ struct drm_virtgpu_resource_create_blob *rc_blob,
+ bool *guest_blob, bool *host3d_blob)
+{
+ if (!vgdev->has_resource_blob)
+ return -EINVAL;
+
+ if ((rc_blob->blob_flags & ~VIRTGPU_BLOB_FLAG_USE_MASK) ||
+ !rc_blob->blob_flags)
+ return -EINVAL;
+
+ if (rc_blob->blob_flags & VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE) {
+ if (!vgdev->has_resource_assign_uuid)
+ return -EINVAL;
+ }
+
+ switch (rc_blob->blob_mem) {
+ case VIRTGPU_BLOB_MEM_GUEST:
+ *guest_blob = true;
+ break;
+ case VIRTGPU_BLOB_MEM_HOST3D_GUEST:
+ *guest_blob = true;
+ fallthrough;
+ case VIRTGPU_BLOB_MEM_HOST3D:
+ *host3d_blob = true;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (*host3d_blob) {
+ if (!vgdev->has_virgl_3d)
+ return -EINVAL;
+
+ /* Must be dword aligned. */
+ if (rc_blob->cmd_size % 4 != 0)
+ return -EINVAL;
+
+ params->ctx_id = vfpriv->ctx_id;
+ params->blob_id = rc_blob->blob_id;
+ } else {
+ if (rc_blob->blob_id != 0)
+ return -EINVAL;
+
+ if (rc_blob->cmd_size != 0)
+ return -EINVAL;
+ }
+
+ params->blob_mem = rc_blob->blob_mem;
+ params->size = rc_blob->size;
+ params->blob = true;
+ params->blob_flags = rc_blob->blob_flags;
+ return 0;
+}
+
+static int virtio_gpu_resource_create_blob(struct drm_device *dev,
+ void *data, struct drm_file *file)
+{
+ int ret = 0;
+ uint32_t handle = 0;
+ bool guest_blob = false;
+ bool host3d_blob = false;
+ struct drm_gem_object *obj;
+ struct virtio_gpu_object *bo;
+ struct virtio_gpu_object_params params = { 0 };
+ struct virtio_gpu_device *vgdev = dev->dev_private;
+ struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
+ struct drm_virtgpu_resource_create_blob *rc_blob = data;
+
+ if (verify_blob(vgdev, vfpriv, ¶ms, rc_blob,
+ &guest_blob, &host3d_blob))
+ return -EINVAL;
+
+ if (vgdev->has_virgl_3d)
+ virtio_gpu_create_context(dev, file);
+
+ if (rc_blob->cmd_size) {
+ void *buf;
+
+ buf = memdup_user(u64_to_user_ptr(rc_blob->cmd),
+ rc_blob->cmd_size);
+
+ if (IS_ERR(buf))
+ return PTR_ERR(buf);
+
+ virtio_gpu_cmd_submit(vgdev, buf, rc_blob->cmd_size,
+ vfpriv->ctx_id, NULL, NULL);
+ }
+
+ if (guest_blob)
+ ret = virtio_gpu_object_create(vgdev, ¶ms, &bo, NULL);
+ else if (!guest_blob && host3d_blob)
+ ret = vi
[PATCH v3 14/19] drm/virtio: implement blob resources: blob display integration
SCANOUT_BLOB forwards the DRM framebuffer metadata to the host. The
modifier is intentionally left out -- it may be possible to query
the host for that.
We also assume one blob resource per DRM framebuffer. That too is
an intentional simplification.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 6a311cd934403..42ac08ed1442e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -174,12 +174,23 @@ static void virtio_gpu_primary_plane_update(struct
drm_plane *plane,
plane->state->src_h >> 16,
plane->state->src_x >> 16,
plane->state->src_y >> 16);
- virtio_gpu_cmd_set_scanout(vgdev, output->index,
- bo->hw_res_handle,
- plane->state->src_w >> 16,
- plane->state->src_h >> 16,
- plane->state->src_x >> 16,
- plane->state->src_y >> 16);
+
+ if (bo->host3d_blob || bo->guest_blob) {
+ virtio_gpu_cmd_set_scanout_blob
+ (vgdev, output->index, bo,
+plane->state->fb,
+plane->state->src_w >> 16,
+plane->state->src_h >> 16,
+plane->state->src_x >> 16,
+plane->state->src_y >> 16);
+ } else {
+ virtio_gpu_cmd_set_scanout(vgdev, output->index,
+ bo->hw_res_handle,
+ plane->state->src_w >> 16,
+ plane->state->src_h >> 16,
+ plane->state->src_x >> 16,
+ plane->state->src_y >> 16);
+ }
}
virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/19] drm/virtio: implement blob resources: probe for host visible region
From: Gerd Hoffmann
The availability of the host visible region means host 3D
allocations can be directly mapped in the guest.
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 5 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_kms.c | 27 ++--
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index 6b9b8376613f0..a2cdd267914ac 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -52,6 +52,11 @@ static int virtio_gpu_features(struct seq_file *m, void
*data)
virtio_add_bool(m, "blob resources", vgdev->has_resource_blob);
virtio_add_int(m, "cap sets", vgdev->num_capsets);
virtio_add_int(m, "scanouts", vgdev->num_scanouts);
+ if (vgdev->host_visible_region.len) {
+ seq_printf(m, "%-16s : 0x%lx +0x%lx\n", "host visible region",
+ (unsigned long)vgdev->host_visible_region.addr,
+ (unsigned long)vgdev->host_visible_region.len);
+ }
return 0;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index b53478a6a3c08..391637f0b362d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -209,6 +209,8 @@ struct virtio_gpu_device {
bool has_indirect;
bool has_resource_assign_uuid;
bool has_resource_blob;
+ bool has_host_visible;
+ struct virtio_shm_region host_visible_region;
struct work_struct config_changed_work;
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 0678e56100dae..6239cc984958f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -155,11 +155,27 @@ int virtio_gpu_init(struct drm_device *dev)
if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_BLOB)) {
vgdev->has_resource_blob = true;
}
+ if (virtio_get_shm_region(vgdev->vdev, &vgdev->host_visible_region,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE)) {
+ if (!devm_request_mem_region(&vgdev->vdev->dev,
+vgdev->host_visible_region.addr,
+vgdev->host_visible_region.len,
+dev_name(&vgdev->vdev->dev))) {
+ DRM_ERROR("Could not reserve host visible region\n");
+ goto err_vqs;
+ }
+
+ DRM_INFO("Host memory window: 0x%lx +0x%lx\n",
+(unsigned long)vgdev->host_visible_region.addr,
+(unsigned long)vgdev->host_visible_region.len);
+ vgdev->has_host_visible = true;
+ }
- DRM_INFO("features: %cvirgl %cedid %cresource_blob\n",
+ DRM_INFO("features: %cvirgl %cedid %cresource_blob %chost_visible\n",
vgdev->has_virgl_3d? '+' : '-',
vgdev->has_edid? '+' : '-',
-vgdev->has_resource_blob ? '+' : '-');
+vgdev->has_resource_blob ? '+' : '-',
+vgdev->has_host_visible ? '+' : '-');
ret = virtio_find_vqs(vgdev->vdev, 2, vqs, callbacks, names, NULL);
if (ret) {
@@ -247,6 +263,13 @@ void virtio_gpu_release(struct drm_device *dev)
virtio_gpu_free_vbufs(vgdev);
virtio_gpu_cleanup_cap_cache(vgdev);
kfree(vgdev->capsets);
+
+ if (vgdev->has_host_visible) {
+ devm_release_mem_region(&vgdev->vdev->dev,
+ vgdev->host_visible_region.addr,
+ vgdev->host_visible_region.len);
+ }
+
kfree(vgdev);
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/19] drm/virtio: implement blob resources: add new fields to internal structs
Useful for upcoming blob resources.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 674a525df9bcc..bddf06b8fb684 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -54,13 +54,16 @@
#define STATE_ERR 2
struct virtio_gpu_object_params {
- uint32_t format;
- uint32_t width;
- uint32_t height;
unsigned long size;
bool dumb;
/* 3d */
bool virgl;
+ bool blob;
+
+ /* classic resources only */
+ uint32_t format;
+ uint32_t width;
+ uint32_t height;
uint32_t target;
uint32_t bind;
uint32_t depth;
@@ -68,6 +71,12 @@ struct virtio_gpu_object_params {
uint32_t last_level;
uint32_t nr_samples;
uint32_t flags;
+
+ /* blob resources only */
+ uint32_t ctx_id;
+ uint32_t blob_mem;
+ uint32_t blob_flags;
+ uint64_t blob_id;
};
struct virtio_gpu_object {
@@ -75,6 +84,8 @@ struct virtio_gpu_object {
uint32_t hw_res_handle;
bool dumb;
bool created;
+ bool host3d_blob, guest_blob;
+ uint32_t blob_mem, blob_flags;
int uuid_state;
uuid_t uuid;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/19] drm/virtgpu api: cross-device feature
This feature was recently added to virtio-gpu, lets make
it userspace queryable. It's an error to use
BLOB_FLAG_USE_CROSS_DEVICE when this feature is not present.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
include/uapi/drm/virtgpu_drm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
index e1b1518f9acc5..b9ec26e9c6463 100644
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -74,6 +74,7 @@ struct drm_virtgpu_execbuffer {
#define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */
#define VIRTGPU_PARAM_RESOURCE_BLOB 3 /* DRM_VIRTGPU_RESOURCE_CREATE_BLOB */
#define VIRTGPU_PARAM_HOST_VISIBLE 4 /* Host blob resources are mappable */
+#define VIRTGPU_PARAM_CROSS_DEVICE 5 /* Cross virtio-device resource sharing
*/
struct drm_virtgpu_getparam {
__u64 param;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/19] drm/virtio: blob prep: refactor getting pages and attaching backing
Useful for upcoming blob resources.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_object.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 842f8b61aa897..4c107b53e81a0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -228,22 +228,22 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
goto err_put_objs;
}
+ ret = virtio_gpu_object_shmem_init(vgdev, bo, &ents, &nents);
+ if (ret != 0) {
+ virtio_gpu_free_object(&shmem_obj->base);
+ return ret;
+ }
+
if (params->virgl) {
virtio_gpu_cmd_resource_create_3d(vgdev, bo, params,
objs, fence);
+ virtio_gpu_object_attach(vgdev, bo, ents, nents);
} else {
virtio_gpu_cmd_create_resource(vgdev, bo, params,
objs, fence);
+ virtio_gpu_object_attach(vgdev, bo, ents, nents);
}
- ret = virtio_gpu_object_shmem_init(vgdev, bo, &ents, &nents);
- if (ret != 0) {
- virtio_gpu_free_object(&shmem_obj->base);
- return ret;
- }
-
- virtio_gpu_object_attach(vgdev, bo, ents, nents);
-
*bo_ptr = bo;
return 0;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/19] drm/virtio: implement blob resources: implement vram object
From: Gerd Hoffmann
A virtio-gpu vram object is based on range-based allocation.
No guest shmemfs backing, so we call drm_gem_private_object_init.
This is for host memory without any guest backing (atleast initially).
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/Makefile | 2 +-
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 20 ++-
drivers/gpu/drm/virtio/virtgpu_drv.h | 26 +++-
drivers/gpu/drm/virtio/virtgpu_kms.c | 8 ++
drivers/gpu/drm/virtio/virtgpu_object.c | 12 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 66 +
drivers/gpu/drm/virtio/virtgpu_vram.c| 162 +++
7 files changed, 293 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/virtio/virtgpu_vram.c
diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index 92aa2b3d349d9..b99fa4a73b68e 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -3,7 +3,7 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_gem.o \
+virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_gem.o virtgpu_vram.o \
virtgpu_display.o virtgpu_vq.o \
virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
virtgpu_ioctl.o virtgpu_prime.o virtgpu_trace_points.o
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index a2cdd267914ac..f336a8fa7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -42,7 +42,7 @@ static void virtio_add_int(struct seq_file *m, const char
*name,
static int virtio_gpu_features(struct seq_file *m, void *data)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = (struct drm_info_node *)m->private;
struct virtio_gpu_device *vgdev = node->minor->dev->dev_private;
virtio_add_bool(m, "virgl", vgdev->has_virgl_3d);
@@ -72,9 +72,27 @@ virtio_gpu_debugfs_irq_info(struct seq_file *m, void *data)
return 0;
}
+static int
+virtio_gpu_debugfs_host_visible_mm(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *)m->private;
+ struct virtio_gpu_device *vgdev = node->minor->dev->dev_private;
+ struct drm_printer p;
+
+ if (!vgdev->has_host_visible) {
+ seq_puts(m, "Host allocations not visible to guest\n");
+ return 0;
+ }
+
+ p = drm_seq_file_printer(m);
+ drm_mm_print(&vgdev->host_visible_mm, &p);
+ return 0;
+}
+
static struct drm_info_list virtio_gpu_debugfs_list[] = {
{ "virtio-gpu-features", virtio_gpu_features },
{ "virtio-gpu-irq-fence", virtio_gpu_debugfs_irq_info, 0, NULL },
+ { "virtio-gpu-host-visible-mm", virtio_gpu_debugfs_host_visible_mm },
};
#define VIRTIO_GPU_DEBUGFS_ENTRIES ARRAY_SIZE(virtio_gpu_debugfs_list)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index bddf06b8fb684..7c9cf6960a92f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -99,9 +99,19 @@ struct virtio_gpu_object_shmem {
uint32_t mapped;
};
+struct virtio_gpu_object_vram {
+ struct virtio_gpu_object base;
+ uint32_t map_state;
+ uint32_t map_info;
+ struct drm_mm_node vram_node;
+};
+
#define to_virtio_gpu_shmem(virtio_gpu_object) \
container_of((virtio_gpu_object), struct virtio_gpu_object_shmem, base)
+#define to_virtio_gpu_vram(virtio_gpu_object) \
+ container_of((virtio_gpu_object), struct virtio_gpu_object_vram, base)
+
struct virtio_gpu_object_array {
struct ww_acquire_ctx ticket;
struct list_head next;
@@ -222,6 +232,7 @@ struct virtio_gpu_device {
bool has_resource_blob;
bool has_host_visible;
struct virtio_shm_region host_visible_region;
+ struct drm_mm host_visible_mm;
struct work_struct config_changed_work;
@@ -233,8 +244,10 @@ struct virtio_gpu_device {
uint32_t num_capsets;
struct list_head cap_cache;
- /* protects resource state when exporting */
+ /* protects uuid state when exporting */
spinlock_t resource_export_lock;
+ /* protects map state and host_visible_mm */
+ spinlock_t host_visible_lock;
};
struct virtio_gpu_fpriv {
@@ -365,6 +378,12 @@ int
virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object_array *objs);
+int virtio_gpu_cmd_map(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object_array *objs, uint64_t offset);
+
+void virtio_gpu_cmd_unmap(struct virtio_gpu_device *
[PATCH v3 02/19] drm/virtio: blob prep: make CPU responses more generic
RESOURCE_MAP_BLOB / RESOURCE_UNMAP_BLOB can use this.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++---
drivers/gpu/drm/virtio/virtgpu_prime.c | 6 +++---
drivers/gpu/drm/virtio/virtgpu_vq.c| 10 +-
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 55c34b4fc3e99..272abe177ded6 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -49,9 +49,9 @@
#define DRIVER_MINOR 1
#define DRIVER_PATCHLEVEL 0
-#define UUID_INITIALIZING 0
-#define UUID_INITIALIZED 1
-#define UUID_INITIALIZATION_FAILED 2
+#define STATE_INITIALIZING 0
+#define STATE_OK 1
+#define STATE_ERR 2
struct virtio_gpu_object_params {
uint32_t format;
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index acd14ef73d563..3552db128ba3d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -34,8 +34,8 @@ static int virtgpu_virtio_get_uuid(struct dma_buf *buf,
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
struct virtio_gpu_device *vgdev = obj->dev->dev_private;
- wait_event(vgdev->resp_wq, bo->uuid_state != UUID_INITIALIZING);
- if (bo->uuid_state != UUID_INITIALIZED)
+ wait_event(vgdev->resp_wq, bo->uuid_state != STATE_INITIALIZING);
+ if (bo->uuid_state != STATE_OK)
return -ENODEV;
uuid_copy(uuid, &bo->uuid);
@@ -81,7 +81,7 @@ struct dma_buf *virtgpu_gem_prime_export(struct
drm_gem_object *obj,
return ERR_PTR(ret);
virtio_gpu_notify(vgdev);
} else {
- bo->uuid_state = UUID_INITIALIZATION_FAILED;
+ bo->uuid_state = STATE_ERR;
}
exp_info.ops = &virtgpu_dmabuf_ops.ops;
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index a7550044b8b2e..55529ed97d9c7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -1127,14 +1127,14 @@ static void virtio_gpu_cmd_resource_uuid_cb(struct
virtio_gpu_device *vgdev,
uint32_t resp_type = le32_to_cpu(resp->hdr.type);
spin_lock(&vgdev->resource_export_lock);
- WARN_ON(obj->uuid_state != UUID_INITIALIZING);
+ WARN_ON(obj->uuid_state != STATE_INITIALIZING);
if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID &&
- obj->uuid_state == UUID_INITIALIZING) {
+ obj->uuid_state == STATE_INITIALIZING) {
memcpy(&obj->uuid.b, resp->uuid, sizeof(obj->uuid.b));
- obj->uuid_state = UUID_INITIALIZED;
+ obj->uuid_state = STATE_OK;
} else {
- obj->uuid_state = UUID_INITIALIZATION_FAILED;
+ obj->uuid_state = STATE_ERR;
}
spin_unlock(&vgdev->resource_export_lock);
@@ -1153,7 +1153,7 @@ virtio_gpu_cmd_resource_assign_uuid(struct
virtio_gpu_device *vgdev,
resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL);
if (!resp_buf) {
spin_lock(&vgdev->resource_export_lock);
- bo->uuid_state = UUID_INITIALIZATION_FAILED;
+ bo->uuid_state = STATE_ERR;
spin_unlock(&vgdev->resource_export_lock);
virtio_gpu_array_put_free(objs);
return -ENOMEM;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/19] drm/virtio: implement blob resources: probe for the feature.
From: Gerd Hoffmann
Let's proble for VIRTIO_GPU_F_RESOURCE_BLOB.
Signed-off-by: Gerd Hoffmann
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 10 +++---
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index d5b0c543bd6d7..6b9b8376613f0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -49,6 +49,7 @@ static int virtio_gpu_features(struct seq_file *m, void *data)
virtio_add_bool(m, "edid", vgdev->has_edid);
virtio_add_bool(m, "indirect", vgdev->has_indirect);
virtio_add_bool(m, "resource uuid", vgdev->has_resource_assign_uuid);
+ virtio_add_bool(m, "blob resources", vgdev->has_resource_blob);
virtio_add_int(m, "cap sets", vgdev->num_capsets);
virtio_add_int(m, "scanouts", vgdev->num_scanouts);
return 0;
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index b039f493bda99..3d04e428be140 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -166,6 +166,7 @@ static unsigned int features[] = {
#endif
VIRTIO_GPU_F_EDID,
VIRTIO_GPU_F_RESOURCE_UUID,
+ VIRTIO_GPU_F_RESOURCE_BLOB,
};
static struct virtio_driver virtio_gpu_driver = {
.feature_table = features,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 272abe177ded6..b53478a6a3c08 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -208,6 +208,7 @@ struct virtio_gpu_device {
bool has_edid;
bool has_indirect;
bool has_resource_assign_uuid;
+ bool has_resource_blob;
struct work_struct config_changed_work;
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index eed57a9313098..0678e56100dae 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -152,10 +152,14 @@ int virtio_gpu_init(struct drm_device *dev)
if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
vgdev->has_resource_assign_uuid = true;
}
+ if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_BLOB)) {
+ vgdev->has_resource_blob = true;
+ }
- DRM_INFO("features: %cvirgl %cedid\n",
-vgdev->has_virgl_3d ? '+' : '-',
-vgdev->has_edid ? '+' : '-');
+ DRM_INFO("features: %cvirgl %cedid %cresource_blob\n",
+vgdev->has_virgl_3d? '+' : '-',
+vgdev->has_edid? '+' : '-',
+vgdev->has_resource_blob ? '+' : '-');
ret = virtio_find_vqs(vgdev->vdev, 2, vqs, callbacks, names, NULL);
if (ret) {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/19] drm/virtgpu api: blob resources
This makes blob resources available to guest userspace. They are needed
for GL4.5, Vulkan and zero-copy virtio-gpu.
For Mesa, blob resources have been tested with Piglit's ARB_buffer_storage
tests and apitraces. Apitraces of GL4.5 games show we're between 70%
to 80% of host performance on Iris, based on a apitrace of a 2013 GL4.5
game:
11.204 FPS (guest)
15.947 FPS (host)
This is still better than the status quo, when said game was unplayable
with Virgl due to an inefficient GL4.3 fallback. But there's still room
for improvement if we want to match HW-assisted virtualization.
For Vulkan, blob resources have been tested with dEQP.vk.memory* and
running Vulkan applications in production with the "Cuttlefish" virtual
Android device. This has been done with Lingfeng Yang's "gfxstream"
Vulkan implementation, which virtualizes Vulkan across many Google
products.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
Acked-by: Chia-I Wu
Acked-by: Lingfeng Yang
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4821
Link:
https://android-review.googlesource.com/c/device/generic/goldfish-opengl/+/1283761
---
include/uapi/drm/virtgpu_drm.h | 37 +-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
index f06a789f34cd9..bb224f604c9e3 100644
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -46,6 +46,7 @@ extern "C" {
#define DRM_VIRTGPU_TRANSFER_TO_HOST 0x07
#define DRM_VIRTGPU_WAIT 0x08
#define DRM_VIRTGPU_GET_CAPS 0x09
+#define DRM_VIRTGPU_RESOURCE_CREATE_BLOB 0x0a
#define VIRTGPU_EXECBUF_FENCE_FD_IN0x01
#define VIRTGPU_EXECBUF_FENCE_FD_OUT 0x02
@@ -71,6 +72,7 @@ struct drm_virtgpu_execbuffer {
#define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
#define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */
+#define VIRTGPU_PARAM_RESOURCE_BLOB 3 /* DRM_VIRTGPU_RESOURCE_CREATE_BLOB */
struct drm_virtgpu_getparam {
__u64 param;
@@ -100,7 +102,7 @@ struct drm_virtgpu_resource_info {
__u32 bo_handle;
__u32 res_handle;
__u32 size;
- __u32 stride;
+ __u32 blob_mem;
};
struct drm_virtgpu_3d_box {
@@ -117,6 +119,8 @@ struct drm_virtgpu_3d_transfer_to_host {
struct drm_virtgpu_3d_box box;
__u32 level;
__u32 offset;
+ __u32 stride;
+ __u32 layer_stride;
};
struct drm_virtgpu_3d_transfer_from_host {
@@ -124,6 +128,8 @@ struct drm_virtgpu_3d_transfer_from_host {
struct drm_virtgpu_3d_box box;
__u32 level;
__u32 offset;
+ __u32 stride;
+ __u32 layer_stride;
};
#define VIRTGPU_WAIT_NOWAIT 1 /* like it */
@@ -140,6 +146,31 @@ struct drm_virtgpu_get_caps {
__u32 pad;
};
+struct drm_virtgpu_resource_create_blob {
+#define VIRTGPU_BLOB_MEM_GUEST 0x0001
+#define VIRTGPU_BLOB_MEM_HOST3D0x0002
+#define VIRTGPU_BLOB_MEM_HOST3D_GUEST 0x0003
+
+#define VIRTGPU_BLOB_FLAG_USE_MAPPABLE 0x0001
+#define VIRTGPU_BLOB_FLAG_USE_SHAREABLE0x0002
+#define VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE 0x0004
+ /* zero is invalid blob_mem */
+ __u32 blob_mem;
+ __u32 blob_flags;
+ __u32 bo_handle;
+ __u32 res_handle;
+ __u64 size;
+
+ /*
+* for 3D contexts with VIRTGPU_BLOB_MEM_HOST3D_GUEST and
+* VIRTGPU_BLOB_MEM_HOST3D otherwise, must be zero.
+*/
+ __u32 pad;
+ __u32 cmd_size;
+ __u64 cmd;
+ __u64 blob_id;
+};
+
#define DRM_IOCTL_VIRTGPU_MAP \
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map)
@@ -175,6 +206,10 @@ struct drm_virtgpu_get_caps {
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_GET_CAPS, \
struct drm_virtgpu_get_caps)
+#define DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB \
+ DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_RESOURCE_CREATE_BLOB, \
+ struct drm_virtgpu_resource_create_blob)
+
#if defined(__cplusplus)
}
#endif
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/19] virtio-gpu api: host visible feature
From: Gerd Hoffmann
This patch adds a new virtgpu feature that allows directly
mapping host allocated resources.
This is based on virtio shared memory regions, which allows
querying for memory regions using PCI transport. Each shared
memory region has an associated "shmid", the meaning of which
is device specific.
For virtio-gpu, we can define the shared memory region with id
VIRTIO_GPU_SHM_ID_HOST_VISIBLE to be the "host visible memory
region".
The presence of the host visible memory region means the following
hypercalls are supported:
1) VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB
This hypercall tells the host to inject the host resource's
mapping in an offset into virtio-gpu's PCI address space.
This is typically done via KVM_SET_USER_MEMORY_REGION on Linux
hosts.
On success, VIRTIO_GPU_RESP_OK_MAP_INFO is returned, which
specifies the host buffer's caching type and possibly in the
future performance hints about the buffer..
2) VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB
This hypercall tells the host to remove the host resource's
mapping from the guest VM.
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
Acked-by: Lingfeng Yang
---
include/uapi/linux/virtio_gpu.h | 35 +
1 file changed, 35 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index 4ddf2fe342ed0..fa2ae4a1da5f9 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux/virtio_gpu.h
@@ -88,6 +88,8 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D,
VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D,
VIRTIO_GPU_CMD_SUBMIT_3D,
+ VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB,
+ VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB,
/* cursor commands */
VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
@@ -100,6 +102,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_RESP_OK_CAPSET,
VIRTIO_GPU_RESP_OK_EDID,
VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
+ VIRTIO_GPU_RESP_OK_MAP_INFO,
/* error responses */
VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
@@ -110,6 +113,11 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER,
};
+enum virtio_gpu_shm_id {
+ VIRTIO_GPU_SHM_ID_UNDEFINED = 0,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE = 1
+};
+
#define VIRTIO_GPU_FLAG_FENCE (1 << 0)
struct virtio_gpu_ctrl_hdr {
@@ -402,4 +410,31 @@ struct virtio_gpu_set_scanout_blob {
__le32 offsets[4];
};
+/* VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB */
+struct virtio_gpu_resource_map_blob {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __le32 resource_id;
+ __le32 padding;
+ __le64 offset;
+};
+
+/* VIRTIO_GPU_RESP_OK_MAP_INFO */
+#define VIRTIO_GPU_MAP_CACHE_MASK 0x0f
+#define VIRTIO_GPU_MAP_CACHE_NONE 0x00
+#define VIRTIO_GPU_MAP_CACHE_CACHED 0x01
+#define VIRTIO_GPU_MAP_CACHE_UNCACHED 0x02
+#define VIRTIO_GPU_MAP_CACHE_WC 0x03
+struct virtio_gpu_resp_map_info {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __u32 map_info;
+ __u32 padding;
+};
+
+/* VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB */
+struct virtio_gpu_resource_unmap_blob {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __le32 resource_id;
+ __le32 padding;
+};
+
#endif
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 17/19] drm/virtio: implement blob resources: report blob mem to userspace
The stride field has never been used, so repurpose it to be "blob_mem". This way, userspace can know the memory properties of the blob if it's passed between userspace processes and no suitable userspace API exists to transmit that knowledge. Signed-off-by: Gurchetan Singh Acked-by: Tomeu Vizoso --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c index 0bf789f2bfdec..b0c9dd171ad8a 100644 --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c @@ -301,6 +301,9 @@ static int virtio_gpu_resource_info_ioctl(struct drm_device *dev, void *data, ri->size = qobj->base.base.size; ri->res_handle = qobj->hw_res_handle; + if (qobj->host3d_blob || qobj->guest_blob) + ri->blob_mem = qobj->blob_mem; + drm_gem_object_put(gobj); return 0; } -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/19] drm/virtio: implement blob resources: hypercall interface
This implements the blob hypercall interface.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 15 +++
drivers/gpu/drm/virtio/virtgpu_vq.c | 65
2 files changed, 80 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 7c9cf6960a92f..e1143a00017c5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -384,6 +385,20 @@ int virtio_gpu_cmd_map(struct virtio_gpu_device *vgdev,
void virtio_gpu_cmd_unmap(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo);
+void
+virtio_gpu_cmd_resource_create_blob(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo,
+ struct virtio_gpu_object_params *params,
+ struct virtio_gpu_mem_entry *ents,
+ uint32_t nents);
+void
+virtio_gpu_cmd_set_scanout_blob(struct virtio_gpu_device *vgdev,
+ uint32_t scanout_id,
+ struct virtio_gpu_object *bo,
+ struct drm_framebuffer *fb,
+ uint32_t width, uint32_t height,
+ uint32_t x, uint32_t y);
+
/* virtgpu_display.c */
int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 41fd253d357ed..e71c8eec0b914 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -1237,3 +1237,68 @@ void virtio_gpu_cmd_unmap(struct virtio_gpu_device
*vgdev,
virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
}
+
+void
+virtio_gpu_cmd_resource_create_blob(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo,
+ struct virtio_gpu_object_params *params,
+ struct virtio_gpu_mem_entry *ents,
+ uint32_t nents)
+{
+ struct virtio_gpu_resource_create_blob *cmd_p;
+ struct virtio_gpu_vbuffer *vbuf;
+
+ cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
+ memset(cmd_p, 0, sizeof(*cmd_p));
+
+ cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB);
+ cmd_p->hdr.ctx_id = cpu_to_le32(params->ctx_id);
+ cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle);
+ cmd_p->blob_mem = cpu_to_le32(params->blob_mem);
+ cmd_p->blob_flags = cpu_to_le32(params->blob_flags);
+ cmd_p->blob_id = cpu_to_le64(params->blob_id);
+ cmd_p->size = cpu_to_le64(params->size);
+ cmd_p->nr_entries = cpu_to_le32(nents);
+
+ vbuf->data_buf = ents;
+ vbuf->data_size = sizeof(*ents) * nents;
+
+ virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
+ bo->created = true;
+}
+
+void virtio_gpu_cmd_set_scanout_blob(struct virtio_gpu_device *vgdev,
+uint32_t scanout_id,
+struct virtio_gpu_object *bo,
+struct drm_framebuffer *fb,
+uint32_t width, uint32_t height,
+uint32_t x, uint32_t y)
+{
+ uint32_t i;
+ struct virtio_gpu_set_scanout_blob *cmd_p;
+ struct virtio_gpu_vbuffer *vbuf;
+ uint32_t format = virtio_gpu_translate_format(fb->format->format);
+
+ cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
+ memset(cmd_p, 0, sizeof(*cmd_p));
+
+ cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_SET_SCANOUT_BLOB);
+ cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle);
+ cmd_p->scanout_id = cpu_to_le32(scanout_id);
+
+ cmd_p->format = cpu_to_le32(format);
+ cmd_p->width = cpu_to_le32(fb->width);
+ cmd_p->height = cpu_to_le32(fb->height);
+
+ for (i = 0; i < 4; i++) {
+ cmd_p->strides[i] = cpu_to_le32(fb->pitches[i]);
+ cmd_p->offsets[i] = cpu_to_le32(fb->offsets[i]);
+ }
+
+ cmd_p->r.width = cpu_to_le32(width);
+ cmd_p->r.height = cpu_to_le32(height);
+ cmd_p->r.x = cpu_to_le32(x);
+ cmd_p->r.y = cpu_to_le32(y);
+
+ virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
+}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] mediatek drm fixes for 5.9
Hi, Dave & Daniel: This includes: 1. Fix scrolling of panel 2. Remove duplicated include 3. Use CPU when fail to get cmdq event 4. Add missing put_device() call Regards, Chun-Kuang. The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-fixes-5.9 for you to fetch changes up to 0680a622318b8d657323b94082f4b9a44038dfee: drm/mediatek: Add missing put_device() call in mtk_hdmi_dt_parse_pdata() (2020-09-17 06:58:01 +0800) Mediatek DRM Fixes for Linux 5.9 1. Fix scrolling of panel 2. Remove duplicated include 3. Use CPU when fail to get cmdq event 4. Add missing put_device() call Chun-Kuang Hu (1): drm/mediatek: Use CPU when fail to get cmdq event Jitao Shi (1): drm/mediatek: dsi: Fix scrolling of panel with small hfp or hbp Wang Hai (1): drm/mediatek: Remove duplicated include Yu Kuai (4): drm/mediatek: Add missing put_device() call in mtk_ddp_comp_init() drm/mediatek: Add exception handing in mtk_drm_probe() if component init fail drm/mediatek: Add missing put_device() call in mtk_drm_kms_init() drm/mediatek: Add missing put_device() call in mtk_hdmi_dt_parse_pdata() drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 20 +--- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 19 +-- drivers/gpu/drm/mediatek/mtk_dsi.c | 9 - drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++ 5 files changed, 49 insertions(+), 26 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote: > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote: > > > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney > > > wrote: > > > > > > > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > > > > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds > > > > > wrote: > > > > > > > > > > > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner > > > > > > wrote: > > > > > > > > > > > > > > OTOH, having a working 'preemptible()' or maybe better named > > > > > > > 'can_schedule()' check makes tons of sense to make decisions about > > > > > > > allocation modes or other things. > > > > > > > > > > > > No. I think that those kinds of decisions about actual behavior are > > > > > > always simply fundamentally wrong. > > > > > > > > > > > > Note that this is very different from having warnings about invalid > > > > > > use. THAT is correct. It may not warn in all configurations, but > > > > > > that > > > > > > doesn't matter: what matters is that it warns in common enough > > > > > > configurations that developers will catch it. > > > > > > > > > > > > So having a warning in "might_sleep()" that doesn't always trigger, > > > > > > because you have a limited configuration that can't even detect the > > > > > > situation, that's fine and dandy and intentional. > > > > > > > > > > > > But having code like > > > > > > > > > > > >if (can_schedule()) > > > > > >.. do something different .. > > > > > > > > > > > > is fundamentally complete and utter garbage. > > > > > > > > > > > > It's one thing if you test for "am I in hardware interrupt context". > > > > > > Those tests aren't great either, but at least they make sense. > > > > > > > > > > > > But a driver - or some library routine - making a difference based > > > > > > on > > > > > > some nebulous "can I schedule" is fundamentally and basically WRONG. > > > > > > > > > > > > If some code changes behavior, it needs to be explicit to the > > > > > > *caller* > > > > > > of that code. > > > > > > > > > > > > So this is why GFP_ATOMIC is fine, but "if (!can_schedule()) > > > > > > do_something_atomic()" is pure shite. > > > > > > > > > > > > And I am not IN THE LEAST interested in trying to help people doing > > > > > > pure shite. We need to fix them. Like the crypto code is getting > > > > > > fixed. > > > > > > > > > > Just figured I'll throw my +1 in from reading too many (gpu) drivers. > > > > > Code that tries to cleverly adjust its behaviour depending upon the > > > > > context it's running in is harder to understand and blows up in more > > > > > interesting ways. We still have drm_can_sleep() and it's mostly just > > > > > used for debug code, and I've largely ended up just deleting > > > > > everything that used it because when you're driver is blowing up the > > > > > last thing you want is to realize your debug code and output can't be > > > > > relied upon. Or worse, that the only Oops you have is the one in the > > > > > debug code, because the real one scrolled away - the original idea > > > > > behind drm_can_sleep was to make all the modeset code work > > > > > automagically both in normal ioctl/kworker context and in the panic > > > > > handlers or kgdb callbacks. Wishful thinking at best. > > > > > > > > > > Also at least for me that extends to everything, e.g. I much prefer > > > > > explicit spin_lock and spin_lock_irq vs magic spin_lock_irqsave for > > > > > locks shared with interrupt handlers, since the former two gives me > > > > > clear information from which contexts such function can be called. > > > > > Other end is the memalloc_no*_save/restore functions, where I recently > > > > > made a real big fool of myself because I didn't realize how much that > > > > > impacts everything that's run within - suddenly "GFP_KERNEL for small > > > > > stuff never fails" is wrong everywhere. > > > > > > > > > > It's all great for debugging and sanity checks (and we run with all > > > > > that stuff enabled in our CI), but really semantic changes depending > > > > > upon magic context checks freak my out :-) > > > > > > > > All fair, but some of us need to write code that must handle being > > > > invoked from a wide variety of contexts. Now perhaps you like the idea > > > > of > > > > call_rcu() for schedulable contexts, call_rcu_nosched() when preemption > > > > is disabled, call_rcu_irqs_are_disabled() when interrupts are disabled, > > > > call_rcu_raw_atomic() from contexts where (for example) raw spinlocks > > > > are held, and so on. However, from what I can see, most people instead > > > > consistently prefer that the RCU API instead be consolidated. > > > > > > > > Some in-flight cache-efficiency work for kvfree_rcu() and call_rcu() > > > > needs to be able to allocate memory occasionally. It can do that when > > > > invoked from some contexts, but not when invoked from oth
Re: [PATCH] Revert "drm/radeon: handle PCIe root ports with addressing limitations"
On Wed, Sep 16, 2020 at 3:04 AM Christoph Hellwig wrote: > > On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote: > > This change breaks tons of systems. > > Did you do at least some basic root causing on why? Do GPUs get > fed address they can't deal with? Any examples? > > Bug 1 doesn't seem to contain any analysis and was reported against > a very old kernel that had all kind of fixes since. > > Bug 2 seems to imply a drm kthread is accessing some structure it > shouldn't, which would imply a mismatch between pools used by radeon > now and those actually provided by the core. Something that should > be pretty to trivial to fix for someone understanding the whole ttm > pool maze. > > Bug 3: same as 1, but an even older kernel. > > Bug 4: looks like 1 and 3, and actually verified to work properly > in 5.9-rc. Did you try to get the other reporters test this as well? It would appear that the change in 5.9 to disable AGP on radeon fixed the issue. I'm following up on the other tickets to see if I can get confirmation. On another thread[1], the user was able to avoid the issue by disabling HIMEM. Looks like some issue with HIMEM and/or AGP. Alex [1] https://lkml.org/lkml/2019/12/14/263 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
On Mon, Feb 24, 2020 at 4:20 AM Thomas Backlund wrote: > > Den 09-01-2020 kl. 17:12, skrev Christian König: > > Hi Christoph, > > > > Am 09.01.20 um 15:14 schrieb Christoph Hellwig: > >> Hi Woody, > >> > >> sorry for the late reply, I've been off to a vacation over the holidays. > >> > >> On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: > >>> Regression in 5.4 kernel on 32-bit Radeon IBM T40 > >>> triggered by > >>> commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 > >>> Author: Christoph Hellwig > >>> Date: Thu Aug 15 09:27:00 2019 +0200 > >>> > >>> Howdy, > >>> The above patch has triggered a display problem on IBM Thinkpad T40, > >>> where > >>> the screen is covered with a lots of random short black horizontal > >>> lines, > >>> or distorted letters in X terms. > >>> > >>> The culprit seems to be that the dma_get_required_mask() is returning a > >>> value 0x3fff > >>> which is smaller than dma_get_mask()0x.That results in > >>> dma_addressing_limited()==0 in ttm_bo_device(), and using 40-bits dma > >>> instead of 32-bits. > >> Which is the intended behavior assuming your system has 1GB of memory. > >> Does it? > > > > Assuming the system doesn't have the 1GB split up somehow crazy over the > > address space that should indeed work as intended. > > > >> > >>> If I hardcode "1" as the last parameter to ttm_bo_device_init() in > >>> place of > >>> a call to dma_addressing_limited(),the problem goes away. > >> I'll need some help from the drm / radeon / TTM maintainers if there are > >> any other side effects from not passing the need_dma32 paramters. > >> Obviously if the device doesn't have more than 32-bits worth of dram and > >> no DMA offset we can't feed unaddressable memory to the device. > >> Unfortunately I have a very hard time following the implementation of > >> the TTM pool if it does anything else in this case. > > > > The only other thing which comes to mind is using huge pages. Can you > > try a kernel with CONFIG_TRANSPARENT_HUGEPAGE disabled? > > > > > Any progress on this ? > > We have a bugreport in Mageia with the hw: > Dell Inspiron 5100, 32-bit P4 processor, 2GB of RAM, Radeon Mobility > 7500 (RV200) graphics > > that gets display issues too and reverting the offending commit restores > normal behaviour. > > and the same issue is still there with 5.5 series kernels. Does disabling HIMEM or setting radeon.agpmode=-1 on the kernel command line in grub fix the issue? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207763] Noisy Screen in Linux with kernel 5
https://bugzilla.kernel.org/show_bug.cgi?id=207763 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- Another thing to try, does setting radeon.agpmode=-1 fix the issue? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/16] drm/exynos: add host_ops callback for platform drivers
W dniu 15.09.2020 o 20:02, Michael Tretter pisze:
> On Tue, 15 Sep 2020 19:07:59 +0200, Andrzej Hajda wrote:
>> W dniu 11.09.2020 o 15:54, Michael Tretter pisze:
>>> Platform drivers need to be aware if a mipi dsi device attaches or
>>> detaches. Add host_ops to the driver_data for attach and detach
>>> callbacks and move the i80 mode selection and the hotplug handling into
>>> the callback, because these depend on the drm driver.
>>>
>>> Signed-off-by: Michael Tretter
>>> ---
>>> v2:
>>> - new patch
>>> ---
>>>drivers/gpu/drm/exynos/exynos_drm_dsi.c | 64 -
>>>1 file changed, 53 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index 1a15ae71205d..684a2fbef08a 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -239,6 +239,12 @@ struct exynos_dsi_transfer {
>>>#define DSIM_STATE_CMD_LPM BIT(2)
>>>#define DSIM_STATE_VIDOUT_AVAILABLE BIT(3)
>>>
>>> +struct exynos_dsi;
>>> +struct exynos_dsi_host_ops {
>>> + int (*attach)(struct device *dev, struct mipi_dsi_device *device);
>>> + int (*detach)(struct device *dev, struct mipi_dsi_device *device);
>>> +};
>>> +
>>>enum exynos_reg_offset {
>>> EXYNOS_REG_OFS,
>>> EXYNOS5433_REG_OFS
>>> @@ -254,6 +260,7 @@ struct exynos_dsi_driver_data {
>>> unsigned int wait_for_reset;
>>> unsigned int num_bits_resol;
>>> const unsigned int *reg_values;
>>> + const struct exynos_dsi_host_ops *host_ops;
>>>};
>>>
>>>struct exynos_dsi {
>>> @@ -467,6 +474,41 @@ static const unsigned int exynos5433_reg_values[] = {
>>> [PHYTIMING_HS_TRAIL] = 0x0c,
>>>};
>>>
>>> +static int __exynos_dsi_host_attach(struct device *dev,
>>> + struct mipi_dsi_device *device)
>>> +{
>>> + struct exynos_dsi *dsi = dev_get_drvdata(dev);
>>> + struct drm_device *drm = dsi->encoder.dev;
>>
>> As I wrote yesterday drm device was guaranteed to be present here only
>> if mipi dsi host registration was performed in component bind. In case
>> it is performed in probe it will be always NULL, and the code does not
>> make sense.
> Correct, but if the driver is used as a drm bridge, there won't be an encoder
> until bridge_attach. Mipi dsi devices defer their probe until the mipi dsi
> host is available. If I move the mipi dsi host registration into
> bridge_attach, the driver does not know if the next device is another bridge
> or a panel during bridge_attach, but the driver cannot successfully return
> from bridge_attach, because then the drm driver expects a connector.
Hmm, I am not sure why do you think driver expects connector on return
of briddge_attach.
>
> I guess that the encoder should be initialized before registering the mipi dsi
> host during probe instead of bind.
But you should have already drm dev on encoder init which in probe is
unavailable.
> The probe won't be rolled back on
> PROBE_DEFER during bind and the encoder will be available in host_attach.
> When splitting the driver into the exynos platform specific code and the more
> generic code, there won't be an encoder during host_attach in the generic
> code, but the host_ops callback could (and will) use the platform specific
> encoder, which is available before bridge_attach.
>
> Does this make sense to you?
Nope :) But maybe I am missing sth.
Generally I see two ways (which I have already described in different
e-mail, in different words):
A. Static - we wait for every part of display stack to be probed, then
create drm_dev - typical approach, but slow (deferred probe causes late
drm creation), and racy - only(?) component framework and DSI bus have
possibility to signal driver unbind, so we can react on it properly.
B. Dynamic - drm framework requires only crtcs and encoders to be
attached to drm on init, connectors, and hidden parts (drm_bridges,
drm_panels) can be created/destroyed and attached/detached at any time
(almost), so lets take advantage of it - create drm_dev ASAP and attach
other parts when they become available, the only issue is that there is
no generic way to be notified when given parts becomes available - in
interesting area only mipi devices have such notifications via attach
callbacks.
So either we convert exynos_dsi to A either we continue B approach. In
second case we should assure mipi_dsi host is created if drm_dev is
available.
Regards
Andrzej
>
> Michael
>
>>
>> Regards
>>
>> Andrzej
>>
>>
>>
>>> + struct exynos_drm_crtc *crtc;
>>> +
>>> + mutex_lock(&drm->mode_config.mutex);
>>> + crtc = exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD);
>>> + crtc->i80_mode = !(device->mode_flags & MIPI_DSI_MODE_VIDEO);
>>> + mutex_unlock(&drm->mode_config.mutex);
>>> +
>>> + if (drm->mode_config.poll_enabled)
>>> + drm_kms_helper_hotplug_event(drm);
>>> +
>>>
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote: > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote: > > > > > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > > > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds > > > > wrote: > > > > > > > > > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner > > > > > wrote: > > > > > > > > > > > > OTOH, having a working 'preemptible()' or maybe better named > > > > > > 'can_schedule()' check makes tons of sense to make decisions about > > > > > > allocation modes or other things. > > > > > > > > > > No. I think that those kinds of decisions about actual behavior are > > > > > always simply fundamentally wrong. > > > > > > > > > > Note that this is very different from having warnings about invalid > > > > > use. THAT is correct. It may not warn in all configurations, but that > > > > > doesn't matter: what matters is that it warns in common enough > > > > > configurations that developers will catch it. > > > > > > > > > > So having a warning in "might_sleep()" that doesn't always trigger, > > > > > because you have a limited configuration that can't even detect the > > > > > situation, that's fine and dandy and intentional. > > > > > > > > > > But having code like > > > > > > > > > >if (can_schedule()) > > > > >.. do something different .. > > > > > > > > > > is fundamentally complete and utter garbage. > > > > > > > > > > It's one thing if you test for "am I in hardware interrupt context". > > > > > Those tests aren't great either, but at least they make sense. > > > > > > > > > > But a driver - or some library routine - making a difference based on > > > > > some nebulous "can I schedule" is fundamentally and basically WRONG. > > > > > > > > > > If some code changes behavior, it needs to be explicit to the *caller* > > > > > of that code. > > > > > > > > > > So this is why GFP_ATOMIC is fine, but "if (!can_schedule()) > > > > > do_something_atomic()" is pure shite. > > > > > > > > > > And I am not IN THE LEAST interested in trying to help people doing > > > > > pure shite. We need to fix them. Like the crypto code is getting > > > > > fixed. > > > > > > > > Just figured I'll throw my +1 in from reading too many (gpu) drivers. > > > > Code that tries to cleverly adjust its behaviour depending upon the > > > > context it's running in is harder to understand and blows up in more > > > > interesting ways. We still have drm_can_sleep() and it's mostly just > > > > used for debug code, and I've largely ended up just deleting > > > > everything that used it because when you're driver is blowing up the > > > > last thing you want is to realize your debug code and output can't be > > > > relied upon. Or worse, that the only Oops you have is the one in the > > > > debug code, because the real one scrolled away - the original idea > > > > behind drm_can_sleep was to make all the modeset code work > > > > automagically both in normal ioctl/kworker context and in the panic > > > > handlers or kgdb callbacks. Wishful thinking at best. > > > > > > > > Also at least for me that extends to everything, e.g. I much prefer > > > > explicit spin_lock and spin_lock_irq vs magic spin_lock_irqsave for > > > > locks shared with interrupt handlers, since the former two gives me > > > > clear information from which contexts such function can be called. > > > > Other end is the memalloc_no*_save/restore functions, where I recently > > > > made a real big fool of myself because I didn't realize how much that > > > > impacts everything that's run within - suddenly "GFP_KERNEL for small > > > > stuff never fails" is wrong everywhere. > > > > > > > > It's all great for debugging and sanity checks (and we run with all > > > > that stuff enabled in our CI), but really semantic changes depending > > > > upon magic context checks freak my out :-) > > > > > > All fair, but some of us need to write code that must handle being > > > invoked from a wide variety of contexts. Now perhaps you like the idea of > > > call_rcu() for schedulable contexts, call_rcu_nosched() when preemption > > > is disabled, call_rcu_irqs_are_disabled() when interrupts are disabled, > > > call_rcu_raw_atomic() from contexts where (for example) raw spinlocks > > > are held, and so on. However, from what I can see, most people instead > > > consistently prefer that the RCU API instead be consolidated. > > > > > > Some in-flight cache-efficiency work for kvfree_rcu() and call_rcu() > > > needs to be able to allocate memory occasionally. It can do that when > > > invoked from some contexts, but not when invoked from others. Right now, > > > in !PREEMPT kernels, it cannot tell, and must either do things to the > > > memory allocators that some of the MM hate or must unnecessarily invoke > > > workqueues. Thomas's patches would allow the code to just allocate in > > > the common case when these primitives ar
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote: > > > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds > > > wrote: > > > > > > > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner > > > > wrote: > > > > > > > > > > OTOH, having a working 'preemptible()' or maybe better named > > > > > 'can_schedule()' check makes tons of sense to make decisions about > > > > > allocation modes or other things. > > > > > > > > No. I think that those kinds of decisions about actual behavior are > > > > always simply fundamentally wrong. > > > > > > > > Note that this is very different from having warnings about invalid > > > > use. THAT is correct. It may not warn in all configurations, but that > > > > doesn't matter: what matters is that it warns in common enough > > > > configurations that developers will catch it. > > > > > > > > So having a warning in "might_sleep()" that doesn't always trigger, > > > > because you have a limited configuration that can't even detect the > > > > situation, that's fine and dandy and intentional. > > > > > > > > But having code like > > > > > > > >if (can_schedule()) > > > >.. do something different .. > > > > > > > > is fundamentally complete and utter garbage. > > > > > > > > It's one thing if you test for "am I in hardware interrupt context". > > > > Those tests aren't great either, but at least they make sense. > > > > > > > > But a driver - or some library routine - making a difference based on > > > > some nebulous "can I schedule" is fundamentally and basically WRONG. > > > > > > > > If some code changes behavior, it needs to be explicit to the *caller* > > > > of that code. > > > > > > > > So this is why GFP_ATOMIC is fine, but "if (!can_schedule()) > > > > do_something_atomic()" is pure shite. > > > > > > > > And I am not IN THE LEAST interested in trying to help people doing > > > > pure shite. We need to fix them. Like the crypto code is getting > > > > fixed. > > > > > > Just figured I'll throw my +1 in from reading too many (gpu) drivers. > > > Code that tries to cleverly adjust its behaviour depending upon the > > > context it's running in is harder to understand and blows up in more > > > interesting ways. We still have drm_can_sleep() and it's mostly just > > > used for debug code, and I've largely ended up just deleting > > > everything that used it because when you're driver is blowing up the > > > last thing you want is to realize your debug code and output can't be > > > relied upon. Or worse, that the only Oops you have is the one in the > > > debug code, because the real one scrolled away - the original idea > > > behind drm_can_sleep was to make all the modeset code work > > > automagically both in normal ioctl/kworker context and in the panic > > > handlers or kgdb callbacks. Wishful thinking at best. > > > > > > Also at least for me that extends to everything, e.g. I much prefer > > > explicit spin_lock and spin_lock_irq vs magic spin_lock_irqsave for > > > locks shared with interrupt handlers, since the former two gives me > > > clear information from which contexts such function can be called. > > > Other end is the memalloc_no*_save/restore functions, where I recently > > > made a real big fool of myself because I didn't realize how much that > > > impacts everything that's run within - suddenly "GFP_KERNEL for small > > > stuff never fails" is wrong everywhere. > > > > > > It's all great for debugging and sanity checks (and we run with all > > > that stuff enabled in our CI), but really semantic changes depending > > > upon magic context checks freak my out :-) > > > > All fair, but some of us need to write code that must handle being > > invoked from a wide variety of contexts. Now perhaps you like the idea of > > call_rcu() for schedulable contexts, call_rcu_nosched() when preemption > > is disabled, call_rcu_irqs_are_disabled() when interrupts are disabled, > > call_rcu_raw_atomic() from contexts where (for example) raw spinlocks > > are held, and so on. However, from what I can see, most people instead > > consistently prefer that the RCU API instead be consolidated. > > > > Some in-flight cache-efficiency work for kvfree_rcu() and call_rcu() > > needs to be able to allocate memory occasionally. It can do that when > > invoked from some contexts, but not when invoked from others. Right now, > > in !PREEMPT kernels, it cannot tell, and must either do things to the > > memory allocators that some of the MM hate or must unnecessarily invoke > > workqueues. Thomas's patches would allow the code to just allocate in > > the common case when these primitives are invoked from contexts where > > allocation is permitted. > > > > If we want to restrict access to the can_schedule() or whatever primitive, > > fine and good. We can add a check to checkpatch.pl, for example. Maybe > > we can go back to
[Bug 207763] Noisy Screen in Linux with kernel 5
https://bugzilla.kernel.org/show_bug.cgi?id=207763 --- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) --- Does it work correctly with 5.9-rc1 or newer? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, Sep 16, 2020 at 08:23:52PM +0100, Matthew Wilcox wrote:
> On Mon, Sep 14, 2020 at 11:55:24PM +0200, Thomas Gleixner wrote:
> > But just look at any check which uses preemptible(), especially those
> > which check !preemptible():
>
> hmm.
>
> +++ b/include/linux/preempt.h
> @@ -180,7 +180,9 @@ do { \
>
> #define preempt_enable_no_resched() sched_preempt_enable_no_resched()
>
> +#ifndef MODULE
> #define preemptible() (preempt_count() == 0 && !irqs_disabled())
> +#endif
>
> #ifdef CONFIG_PREEMPTION
> #define preempt_enable() \
>
>
> $ git grep -w preemptible drivers
> (slightly trimmed by hand to remove, eg, comments)
> drivers/firmware/arm_sdei.c:WARN_ON_ONCE(preemptible());
> drivers/firmware/arm_sdei.c:WARN_ON_ONCE(preemptible());
> drivers/firmware/arm_sdei.c:WARN_ON_ONCE(preemptible());
> drivers/firmware/arm_sdei.c:WARN_ON_ONCE(preemptible());
> drivers/firmware/arm_sdei.c:WARN_ON(preemptible());
> drivers/firmware/efi/efi-pstore.c:preemptible(),
> record->size, record->psi->buf);
> drivers/irqchip/irq-gic-v4.c: WARN_ON(preemptible());
> drivers/irqchip/irq-gic-v4.c: WARN_ON(preemptible());
> drivers/scsi/hisi_sas/hisi_sas_main.c: if (!preemptible())
> drivers/xen/time.c: BUG_ON(preemptible());
>
> That only looks like two drivers that need more than WARNectomies.
I could easily imagine someone thinking that these did something in
CONFIG_PREEMPT_NONE=y kernels. In fact, I could easily imagine myself
making that mistake. :-/
> Although maybe rcu_read_load_sched_held() or rcu_read_lock_any_held()
> might get called from a module ...
But yes, from the rcutorture module for certain and also from any other
RCU-using module that includes the usual RCU debug checks.
Thanx, Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, Sep 16, 2020 at 11:32:00AM -0700, Linus Torvalds wrote: > On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote: > > > > All fair, but some of us need to write code that must handle being > > invoked from a wide variety of contexts. > > Note that I think that core functionality is different from random drivers. > > Of course core code can (and will) look at things like > > if (in_interrupt()) > .. schedule work asynchronously .. > > because core code ends up being called from odd places, and code like > that is expected to have understanding of the rules it plays with. > > But something like RCU is a very different beast from some "walk the > scatter-gather list" code. > > RCU does its work in the background, and works with lots of different > things. And it's so core and used everywhere that it knows about these > things. I mean, we literally have special code explicitly to let RCU > know "we entered kernel context now". > > But something like a driver list walking thing should not be doing > different things behind peoples back depending on whether they hold > spinlocks or not. It should either just work regardless, or there > should be a flag (or special interface) for the "you're being called > in a crtitical region". > > Because dynamically changing behavior really is very confusing. Whew! I feel much better now. ;-) Thanx, Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 13/17] gpu: host1x: Reset max value when freeing a syncpoint
On 9/16/20 10:44 PM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
With job recovery becoming optional, syncpoints may have a mismatch
between their value and max value when freed. As such, when freeing,
set the max value to the current value of the syncpoint so that it
is in a sane state for the next user.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/syncpt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 2fad8b2a55cc..82ecb4ac387e 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -385,6 +385,7 @@ static void syncpt_release(struct kref *ref)
{
struct host1x_syncpt *sp = container_of(ref, struct host1x_syncpt, ref);
+ atomic_set(&sp->max_val, host1x_syncpt_read_min(sp));
sp->locked = false;
mutex_lock(&sp->host->syncpt_mutex);
Please note that the sync point state actually needs to be completely
reset at the sync point request-time because both downstream fastboot
and upstream u-boot [1] are needlessly enabling display VBLANK interrupt
that continuously increments sync point #26 during of kernel boot until
display controller is reset.
[1] https://github.com/u-boot/u-boot/blob/master/drivers/video/tegra.c#L155
Hence once sync point #26 is requested, it will have a dirty state. So
far this doesn't have any visible effect because sync points aren't used
much.
Maybe we can instead reserve syncpoints that might be used by the boot
chain, and only allow allocating them once the display driver has acked
that the syncpoint will no longer be incremented? That way if the
display driver is disabled for some reason we'll still be fine.
Looking at the downstream driver, it (still, on new chips..) reserves
the following syncpoints:
- 10 (AVP)
- 22 (3D)
- 26 (VBLANK0)
- 27 (VBLANK1)
and says that this applies to T20, T30, T114 and T148.
I suppose if you haven't observed this happening to other syncpoints
than 26, then reserving 26 would probably be enough.
Mikko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote: > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds > > wrote: > > > > > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner > > > wrote: > > > > > > > > OTOH, having a working 'preemptible()' or maybe better named > > > > 'can_schedule()' check makes tons of sense to make decisions about > > > > allocation modes or other things. > > > > > > No. I think that those kinds of decisions about actual behavior are > > > always simply fundamentally wrong. > > > > > > Note that this is very different from having warnings about invalid > > > use. THAT is correct. It may not warn in all configurations, but that > > > doesn't matter: what matters is that it warns in common enough > > > configurations that developers will catch it. > > > > > > So having a warning in "might_sleep()" that doesn't always trigger, > > > because you have a limited configuration that can't even detect the > > > situation, that's fine and dandy and intentional. > > > > > > But having code like > > > > > >if (can_schedule()) > > >.. do something different .. > > > > > > is fundamentally complete and utter garbage. > > > > > > It's one thing if you test for "am I in hardware interrupt context". > > > Those tests aren't great either, but at least they make sense. > > > > > > But a driver - or some library routine - making a difference based on > > > some nebulous "can I schedule" is fundamentally and basically WRONG. > > > > > > If some code changes behavior, it needs to be explicit to the *caller* > > > of that code. > > > > > > So this is why GFP_ATOMIC is fine, but "if (!can_schedule()) > > > do_something_atomic()" is pure shite. > > > > > > And I am not IN THE LEAST interested in trying to help people doing > > > pure shite. We need to fix them. Like the crypto code is getting > > > fixed. > > > > Just figured I'll throw my +1 in from reading too many (gpu) drivers. > > Code that tries to cleverly adjust its behaviour depending upon the > > context it's running in is harder to understand and blows up in more > > interesting ways. We still have drm_can_sleep() and it's mostly just > > used for debug code, and I've largely ended up just deleting > > everything that used it because when you're driver is blowing up the > > last thing you want is to realize your debug code and output can't be > > relied upon. Or worse, that the only Oops you have is the one in the > > debug code, because the real one scrolled away - the original idea > > behind drm_can_sleep was to make all the modeset code work > > automagically both in normal ioctl/kworker context and in the panic > > handlers or kgdb callbacks. Wishful thinking at best. > > > > Also at least for me that extends to everything, e.g. I much prefer > > explicit spin_lock and spin_lock_irq vs magic spin_lock_irqsave for > > locks shared with interrupt handlers, since the former two gives me > > clear information from which contexts such function can be called. > > Other end is the memalloc_no*_save/restore functions, where I recently > > made a real big fool of myself because I didn't realize how much that > > impacts everything that's run within - suddenly "GFP_KERNEL for small > > stuff never fails" is wrong everywhere. > > > > It's all great for debugging and sanity checks (and we run with all > > that stuff enabled in our CI), but really semantic changes depending > > upon magic context checks freak my out :-) > > All fair, but some of us need to write code that must handle being > invoked from a wide variety of contexts. Now perhaps you like the idea of > call_rcu() for schedulable contexts, call_rcu_nosched() when preemption > is disabled, call_rcu_irqs_are_disabled() when interrupts are disabled, > call_rcu_raw_atomic() from contexts where (for example) raw spinlocks > are held, and so on. However, from what I can see, most people instead > consistently prefer that the RCU API instead be consolidated. > > Some in-flight cache-efficiency work for kvfree_rcu() and call_rcu() > needs to be able to allocate memory occasionally. It can do that when > invoked from some contexts, but not when invoked from others. Right now, > in !PREEMPT kernels, it cannot tell, and must either do things to the > memory allocators that some of the MM hate or must unnecessarily invoke > workqueues. Thomas's patches would allow the code to just allocate in > the common case when these primitives are invoked from contexts where > allocation is permitted. > > If we want to restrict access to the can_schedule() or whatever primitive, > fine and good. We can add a check to checkpatch.pl, for example. Maybe > we can go back to the old brlock approach of requiring certain people's > review for each addition to the kernel. > > But there really are use cases that it would greatly help. We can deadlock in random fun places if random stuff we're calling suddenly starts allocat
Re: [PATCH v2 1/2] drm/nouveau: return temperatures in temp_get() via parameter
On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst wrote:
>
> On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote:
> >
> > The temp_get() function currently returns negative error numbers or a
> > temperature. However, the thermal sensors can (in theory) measure
> > negative temperatures. Some implementations of temp_get() correctly
> > clamp negative temperature readings to 0 so that users do not mistake
> > them for errors, but some, like gp100_temp_get(), do not.
> >
> > Rather than relying on implementations remembering to clamp values,
> > dedicate the function return value to error codes and accept a pointer
> > to an integer where the temperature reading should be stored.
> >
> > Signed-off-by: Jeremy Cline
> > ---
> > .../drm/nouveau/include/nvkm/subdev/therm.h | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_hwmon.c | 12 ++--
> > .../gpu/drm/nouveau/nvkm/subdev/therm/base.c | 19 ++-
> > .../gpu/drm/nouveau/nvkm/subdev/therm/g84.c | 11 ++-
> > .../gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 11 ++-
> > .../gpu/drm/nouveau/nvkm/subdev/therm/nv40.c | 9 +++--
> > .../gpu/drm/nouveau/nvkm/subdev/therm/nv50.c | 9 +++--
> > .../gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 17 +++--
> > .../gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 12
> > 9 files changed, 62 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> > b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> > index 62c34f98c930..bfe9779216fc 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> > @@ -99,7 +99,7 @@ struct nvkm_therm {
> > bool clkgating_enabled;
> > };
> >
> > -int nvkm_therm_temp_get(struct nvkm_therm *);
> > +int nvkm_therm_temp_get(struct nvkm_therm *therm, int *temp);
> > int nvkm_therm_fan_sense(struct nvkm_therm *);
> > int nvkm_therm_cstate(struct nvkm_therm *, int, int);
> > void nvkm_therm_clkgate_init(struct nvkm_therm *,
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > index 1c3104d20571..aff6aa296678 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > @@ -325,7 +325,7 @@ nouveau_temp_is_visible(const void *data, u32 attr, int
> > channel)
> > struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
> > struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
> >
> > - if (!therm || !therm->attr_get || nvkm_therm_temp_get(therm) < 0)
> > + if (!therm || !therm->attr_get || nvkm_therm_temp_get(therm, NULL)
> > < 0)
> > return 0;
> >
> > switch (attr) {
> > @@ -419,7 +419,7 @@ nouveau_temp_read(struct device *dev, u32 attr, int
> > channel, long *val)
> > struct drm_device *drm_dev = dev_get_drvdata(dev);
> > struct nouveau_drm *drm = nouveau_drm(drm_dev);
> > struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
> > - int ret;
> > + int ret = 0, temp;
> >
> > if (!therm || !therm->attr_get)
> > return -EOPNOTSUPP;
> > @@ -428,8 +428,8 @@ nouveau_temp_read(struct device *dev, u32 attr, int
> > channel, long *val)
> > case hwmon_temp_input:
> > if (drm_dev->switch_power_state != DRM_SWITCH_POWER_ON)
> > return -EINVAL;
> > - ret = nvkm_therm_temp_get(therm);
> > - *val = ret < 0 ? ret : (ret * 1000);
> > + ret = nvkm_therm_temp_get(therm, &temp);
> > + *val = temp * 1000;
> > break;
> > case hwmon_temp_max:
> > *val = therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK)
> > @@ -459,7 +459,7 @@ nouveau_temp_read(struct device *dev, u32 attr, int
> > channel, long *val)
> > return -EOPNOTSUPP;
> > }
> >
> > - return 0;
> > + return ret;
> > }
> >
> > static int
> > @@ -735,7 +735,7 @@ nouveau_hwmon_init(struct drm_device *dev)
> > hwmon->dev = dev;
> >
> > if (therm && therm->attr_get && therm->attr_set) {
> > - if (nvkm_therm_temp_get(therm) >= 0)
> > + if (nvkm_therm_temp_get(therm, NULL) >= 0)
> > special_groups[i++] =
> > &temp1_auto_point_sensor_group;
> > if (therm->fan_get && therm->fan_get(therm) >= 0)
> > special_groups[i++] = &pwm_fan_sensor_group;
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> > index 4a4d1e224126..e7ffea1512e6 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> > @@ -27,10 +27,15 @@
> > #include
> >
> > int
> > -nvkm_therm_temp_get(struct nvkm_therm *therm)
> > +nvkm_therm_temp_g
Re: [PATCH v2 1/2] drm/nouveau: return temperatures in temp_get() via parameter
On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote:
>
> The temp_get() function currently returns negative error numbers or a
> temperature. However, the thermal sensors can (in theory) measure
> negative temperatures. Some implementations of temp_get() correctly
> clamp negative temperature readings to 0 so that users do not mistake
> them for errors, but some, like gp100_temp_get(), do not.
>
> Rather than relying on implementations remembering to clamp values,
> dedicate the function return value to error codes and accept a pointer
> to an integer where the temperature reading should be stored.
>
> Signed-off-by: Jeremy Cline
> ---
> .../drm/nouveau/include/nvkm/subdev/therm.h | 2 +-
> drivers/gpu/drm/nouveau/nouveau_hwmon.c | 12 ++--
> .../gpu/drm/nouveau/nvkm/subdev/therm/base.c | 19 ++-
> .../gpu/drm/nouveau/nvkm/subdev/therm/g84.c | 11 ++-
> .../gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 11 ++-
> .../gpu/drm/nouveau/nvkm/subdev/therm/nv40.c | 9 +++--
> .../gpu/drm/nouveau/nvkm/subdev/therm/nv50.c | 9 +++--
> .../gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 17 +++--
> .../gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 12
> 9 files changed, 62 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> index 62c34f98c930..bfe9779216fc 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -99,7 +99,7 @@ struct nvkm_therm {
> bool clkgating_enabled;
> };
>
> -int nvkm_therm_temp_get(struct nvkm_therm *);
> +int nvkm_therm_temp_get(struct nvkm_therm *therm, int *temp);
> int nvkm_therm_fan_sense(struct nvkm_therm *);
> int nvkm_therm_cstate(struct nvkm_therm *, int, int);
> void nvkm_therm_clkgate_init(struct nvkm_therm *,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index 1c3104d20571..aff6aa296678 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -325,7 +325,7 @@ nouveau_temp_is_visible(const void *data, u32 attr, int
> channel)
> struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
> struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
>
> - if (!therm || !therm->attr_get || nvkm_therm_temp_get(therm) < 0)
> + if (!therm || !therm->attr_get || nvkm_therm_temp_get(therm, NULL) <
> 0)
> return 0;
>
> switch (attr) {
> @@ -419,7 +419,7 @@ nouveau_temp_read(struct device *dev, u32 attr, int
> channel, long *val)
> struct drm_device *drm_dev = dev_get_drvdata(dev);
> struct nouveau_drm *drm = nouveau_drm(drm_dev);
> struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
> - int ret;
> + int ret = 0, temp;
>
> if (!therm || !therm->attr_get)
> return -EOPNOTSUPP;
> @@ -428,8 +428,8 @@ nouveau_temp_read(struct device *dev, u32 attr, int
> channel, long *val)
> case hwmon_temp_input:
> if (drm_dev->switch_power_state != DRM_SWITCH_POWER_ON)
> return -EINVAL;
> - ret = nvkm_therm_temp_get(therm);
> - *val = ret < 0 ? ret : (ret * 1000);
> + ret = nvkm_therm_temp_get(therm, &temp);
> + *val = temp * 1000;
> break;
> case hwmon_temp_max:
> *val = therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK)
> @@ -459,7 +459,7 @@ nouveau_temp_read(struct device *dev, u32 attr, int
> channel, long *val)
> return -EOPNOTSUPP;
> }
>
> - return 0;
> + return ret;
> }
>
> static int
> @@ -735,7 +735,7 @@ nouveau_hwmon_init(struct drm_device *dev)
> hwmon->dev = dev;
>
> if (therm && therm->attr_get && therm->attr_set) {
> - if (nvkm_therm_temp_get(therm) >= 0)
> + if (nvkm_therm_temp_get(therm, NULL) >= 0)
> special_groups[i++] = &temp1_auto_point_sensor_group;
> if (therm->fan_get && therm->fan_get(therm) >= 0)
> special_groups[i++] = &pwm_fan_sensor_group;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> index 4a4d1e224126..e7ffea1512e6 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> @@ -27,10 +27,15 @@
> #include
>
> int
> -nvkm_therm_temp_get(struct nvkm_therm *therm)
> +nvkm_therm_temp_get(struct nvkm_therm *therm, int *temp)
> {
> + int ignored_reading;
> +
> + if (temp == NULL)
> + temp = &ignored_reading;
> +
> if (therm->func->temp_get)
> - return therm->func->temp_get(therm);
> + return the
[PATCH v2 2/2] drm/nouveau: Add fine-grain temperature reporting
Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
new gp1xx temperature sensor") added support for reading finer-grain
temperatures, but continued to report temperatures in 1 degree Celsius
increments via nvkm_therm_temp_get().
This alters the temp_get() API to return millidegrees rather than
degrees, adjusts all implementations, and changes users that need integer
Celsius to use the new nvkm_therm_temp_get_c() helper function. Since
there are now two units of measurement floating around, structs that
store temperature now include documentation to make it clear what the
unit is.
Signed-off-by: Jeremy Cline
---
.../nouveau/include/nvkm/subdev/bios/therm.h | 13 ++
.../drm/nouveau/include/nvkm/subdev/therm.h | 26 +++
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/therm/base.c | 14 --
.../gpu/drm/nouveau/nvkm/subdev/therm/g84.c | 4 +--
.../gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/therm/nv40.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/therm/nv50.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 4 +--
9 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/therm.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/therm.h
index 0fb8a3480871..fdf23214cc69 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/therm.h
@@ -1,6 +1,12 @@
/* SPDX-License-Identifier: MIT */
#ifndef __NVBIOS_THERM_H__
#define __NVBIOS_THERM_H__
+
+/**
+ * struct nvbios_therm_threshold - The threshold of a thermal event.
+ * @temp: The temperature, in degrees Celsius, of the thermal threshold.
+ * @hysteresis: The hysteresis of this threshold, in degrees Celsius.
+ */
struct nvbios_therm_threshold {
u8 temp;
u8 hysteresis;
@@ -29,6 +35,13 @@ enum nvbios_therm_fan_type {
/* no vbios have more than 6 */
#define NVKM_TEMP_FAN_TRIP_MAX 10
+
+/**
+ * struct nvbios_therm_trip_point - Represents a thermal trip point.
+ * @fan_duty: The fan's duty cycle as a percentage. Valid values are 0-100.
+ * @temp: The temperature of this trip point, in degrees Celsius.
+ * @hysteresis: the hysteresis to use at this trip point, in degrees Celsius.
+ */
struct nvbios_therm_trip_point {
int fan_duty;
int temp;
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index bfe9779216fc..e817bb9c9505 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -99,7 +99,33 @@ struct nvkm_therm {
bool clkgating_enabled;
};
+/**
+ * nvkm_therm_temp_get() - get the temperature in millidegrees Celsius
+ * @therm: The thermal device to read from.
+ * @temp: A pointer to write the temperature reading to. Passing NULL is
+ * allowed, useful if you only need to check that it's possible to
+ * read a temperature.
+ *
+ * Note that because some cards are only capable of reporting temperatures in
+ * integer degrees Celsius or, if they support fractional degrees, not support
+ * millidegree accuracy, the accuracy of this interface is hardware dependent.
+ *
+ * Returns: Zero on success, or a negative error code on failure.
+ */
int nvkm_therm_temp_get(struct nvkm_therm *therm, int *temp);
+
+/**
+ * nvkm_therm_temp_get_c() - get the temperature in degrees Celsius
+ * @therm: The thermal device to read from.
+ * @temp: A pointer to write the temperature reading to.
+ *
+ * A convenient wrapper for nvkm_therm_temp_get() that converts to degrees
+ * Celsius.
+ *
+ * Returns: Zero on success, or a negative error code on failure.
+ */
+int nvkm_therm_temp_get_c(struct nvkm_therm *therm, int *temp);
+
int nvkm_therm_fan_sense(struct nvkm_therm *);
int nvkm_therm_cstate(struct nvkm_therm *, int, int);
void nvkm_therm_clkgate_init(struct nvkm_therm *,
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index aff6aa296678..1363068f44c1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -429,7 +429,7 @@ nouveau_temp_read(struct device *dev, u32 attr, int
channel, long *val)
if (drm_dev->switch_power_state != DRM_SWITCH_POWER_ON)
return -EINVAL;
ret = nvkm_therm_temp_get(therm, &temp);
- *val = temp * 1000;
+ *val = temp;
break;
case hwmon_temp_max:
*val = therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index e7ffea1512e6..a7bb1e6b6169 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -39,6 +39,16 @@ nvk
[PATCH v2 1/2] drm/nouveau: return temperatures in temp_get() via parameter
The temp_get() function currently returns negative error numbers or a
temperature. However, the thermal sensors can (in theory) measure
negative temperatures. Some implementations of temp_get() correctly
clamp negative temperature readings to 0 so that users do not mistake
them for errors, but some, like gp100_temp_get(), do not.
Rather than relying on implementations remembering to clamp values,
dedicate the function return value to error codes and accept a pointer
to an integer where the temperature reading should be stored.
Signed-off-by: Jeremy Cline
---
.../drm/nouveau/include/nvkm/subdev/therm.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 12 ++--
.../gpu/drm/nouveau/nvkm/subdev/therm/base.c | 19 ++-
.../gpu/drm/nouveau/nvkm/subdev/therm/g84.c | 11 ++-
.../gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 11 ++-
.../gpu/drm/nouveau/nvkm/subdev/therm/nv40.c | 9 +++--
.../gpu/drm/nouveau/nvkm/subdev/therm/nv50.c | 9 +++--
.../gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 17 +++--
.../gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 12
9 files changed, 62 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index 62c34f98c930..bfe9779216fc 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -99,7 +99,7 @@ struct nvkm_therm {
bool clkgating_enabled;
};
-int nvkm_therm_temp_get(struct nvkm_therm *);
+int nvkm_therm_temp_get(struct nvkm_therm *therm, int *temp);
int nvkm_therm_fan_sense(struct nvkm_therm *);
int nvkm_therm_cstate(struct nvkm_therm *, int, int);
void nvkm_therm_clkgate_init(struct nvkm_therm *,
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 1c3104d20571..aff6aa296678 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -325,7 +325,7 @@ nouveau_temp_is_visible(const void *data, u32 attr, int
channel)
struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- if (!therm || !therm->attr_get || nvkm_therm_temp_get(therm) < 0)
+ if (!therm || !therm->attr_get || nvkm_therm_temp_get(therm, NULL) < 0)
return 0;
switch (attr) {
@@ -419,7 +419,7 @@ nouveau_temp_read(struct device *dev, u32 attr, int
channel, long *val)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct nouveau_drm *drm = nouveau_drm(drm_dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- int ret;
+ int ret = 0, temp;
if (!therm || !therm->attr_get)
return -EOPNOTSUPP;
@@ -428,8 +428,8 @@ nouveau_temp_read(struct device *dev, u32 attr, int
channel, long *val)
case hwmon_temp_input:
if (drm_dev->switch_power_state != DRM_SWITCH_POWER_ON)
return -EINVAL;
- ret = nvkm_therm_temp_get(therm);
- *val = ret < 0 ? ret : (ret * 1000);
+ ret = nvkm_therm_temp_get(therm, &temp);
+ *val = temp * 1000;
break;
case hwmon_temp_max:
*val = therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK)
@@ -459,7 +459,7 @@ nouveau_temp_read(struct device *dev, u32 attr, int
channel, long *val)
return -EOPNOTSUPP;
}
- return 0;
+ return ret;
}
static int
@@ -735,7 +735,7 @@ nouveau_hwmon_init(struct drm_device *dev)
hwmon->dev = dev;
if (therm && therm->attr_get && therm->attr_set) {
- if (nvkm_therm_temp_get(therm) >= 0)
+ if (nvkm_therm_temp_get(therm, NULL) >= 0)
special_groups[i++] = &temp1_auto_point_sensor_group;
if (therm->fan_get && therm->fan_get(therm) >= 0)
special_groups[i++] = &pwm_fan_sensor_group;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index 4a4d1e224126..e7ffea1512e6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -27,10 +27,15 @@
#include
int
-nvkm_therm_temp_get(struct nvkm_therm *therm)
+nvkm_therm_temp_get(struct nvkm_therm *therm, int *temp)
{
+ int ignored_reading;
+
+ if (temp == NULL)
+ temp = &ignored_reading;
+
if (therm->func->temp_get)
- return therm->func->temp_get(therm);
+ return therm->func->temp_get(therm, temp);
return -ENODEV;
}
@@ -40,9 +45,11 @@ nvkm_therm_update_trip(struct nvkm_therm *therm)
struct nvbios_therm_trip_point *trip = therm->fan->bios.trip,
*cur_trip = NULL,
[PATCH v2 0/2] Add fine-grain temperature reporting
Hi folks, This series adjusts the temp_get() interface in the thermal functions to report milli-degrees, and additionally alters the way errors are reported. As I went through all the users and implementations I realized that Pascal's temp_get() implementation didn't include turning negative temperatures to 0 like other implementations, so I separated error reporting from the temperature in the API. Couple of things I'm on the fence about here: * I allowed the nvkm_therm_temp_get() functions to accept NULL as a way to check if temperature reading is available rather than adding a separate helper, but was torn about whether this is clearer than a separate helper function. * I added a WARN_ON in places that previously called nvkm_therm_temp_get() and didn't check the return value for an error. This may not be a reasonable error handling method. Jeremy Cline (2): drm/nouveau: return temperatures in temp_get() via parameter drm/nouveau: Add fine-grain temperature reporting .../nouveau/include/nvkm/subdev/bios/therm.h | 13 + .../drm/nouveau/include/nvkm/subdev/therm.h | 28 ++- drivers/gpu/drm/nouveau/nouveau_hwmon.c | 12 .../gpu/drm/nouveau/nvkm/subdev/therm/base.c | 28 +++ .../gpu/drm/nouveau/nvkm/subdev/therm/g84.c | 11 .../gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 11 .../gpu/drm/nouveau/nvkm/subdev/therm/nv40.c | 9 ++ .../gpu/drm/nouveau/nvkm/subdev/therm/nv50.c | 9 ++ .../gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 17 +-- .../gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 12 +--- 10 files changed, 110 insertions(+), 40 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix incorrect TT->SYSTEM move handling
On Thu, 17 Sep 2020 at 00:24, Christian König
wrote:
>
> When we move from the SYSTEM domain to the TT domain
> we still need to potentially change the caching state.
>
> This is most likely the source of a bunch of problems with
> AGP and USWC together with hibernation and swap.
I'm going to need more commentary, because I've been staring at this
code a lot in the past few days and I'm although I dislike this path,
I'm not sure what this brings.
The current code flow to me is for SYSTEM->TT domain
ttm_tt_create
ttm_tt_set_placement_caching (new placement)
ttm_tt_bind (can cause populate)
move_notify
replace pointers
evicted = false
return
The new flow looks like
ttm_tt_create
ttm_tt_set_placement_caching (new placement)
ttm_tt_bind (can cause populate)
move_notify
(via ttm_bo_move_ttm)
ttm_tt_set_placement_caching (new placement)
ttm_tt_bind
replace pointers
(back to main code)
evicted = false
return
Is the second set placement caching doing something different here? or
is there something that happens in move notify that we need to set
things afterwards?
Dave.
>
> Signed-off-by: Christian König
> CC: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index ffbdc20d8e8d..5f7efc90970e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -264,13 +264,6 @@ static int ttm_bo_handle_move_mem(struct
> ttm_buffer_object *bo,
> if (ret)
> goto out_err;
> }
> -
> - if (bo->mem.mem_type == TTM_PL_SYSTEM) {
> - if (bdev->driver->move_notify)
> - bdev->driver->move_notify(bo, evict, mem);
> - bo->mem = *mem;
> - goto moved;
> - }
> }
>
> if (bdev->driver->move_notify)
> @@ -293,7 +286,6 @@ static int ttm_bo_handle_move_mem(struct
> ttm_buffer_object *bo,
> goto out_err;
> }
>
> -moved:
> bo->evicted = false;
>
> ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: dp-connector: add binding for DisplayPort connector
Add binding for DisplayPort connector. A few notes:
* Similar to hdmi-connector, it has hpd-gpios as an optional property,
as the HPD could also be handled by, e.g., the DP bridge.
* dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it
is not strictly required: standard DP cables do not even have the pin
connected.
* No property for the connector type. Full size and mini connectors are
identical except for the connector size and form, so I believe there
is no need to include the type in the bindings.
* No eDP. There's really no "eDP connector", as it's always a custom
made connection between the DP and the DP panel. So possibly there is
no need for edp-connector binding, but even if there is, I don't want
to guess what it could look like, and could it be part of the
dp-connector binding.
* No DP++. I'm not familiar with DP++, but I think it's all handled by
the DP bridge, and does not need any new properties to the dp-connector.
Signed-off-by: Tomi Valkeinen
---
.../display/connector/dp-connector.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/connector/dp-connector.yaml
diff --git
a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
new file mode 100644
index ..983be1fe43f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/connector/dp-connector.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DisplayPort Connector
+
+maintainers:
+ - Tomi Valkeinen
+
+properties:
+ compatible:
+const: dp-connector
+
+ label: true
+
+ hpd-gpios:
+description: A GPIO line connected to HPD
+maxItems: 1
+
+ dp-pwr-supply:
+description: Power supply for the DP_PWR pin
+maxItems: 1
+
+ port:
+description: Connection to controller providing DP signals
+
+required:
+ - compatible
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+connector {
+compatible = "dp-connector";
+label = "dp0";
+
+port {
+dp_connector_in: endpoint {
+remote-endpoint = <&dp_out>;
+};
+};
+};
+
+...
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Tue, Sep 15, 2020 at 12:57 PM Thomas Gleixner wrote: > > You wish. I just found a 7 year old bug in a 10G network driver which > surely would have been found if people would enable debug configs and > not just run the crap on their PREEMPT_NONE, all debug off kernel. And > that driver is not subject to bitrot, it gets regular bug fixes from > people who seem to care (distro folks). That driver clearly cannot be very well maintained. All the distro kernels have the basic debug checks in place, afaik. Is it some wonderful "enterprise hardware" garbage again that only gets used in special data centers? Becasue the "enterprise" people really are special. Very much in the "short bus" special kind of way. The fact that they have fooled so much of the industry into thinking that they are the competent and serious people is a disgrace. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote: > > All fair, but some of us need to write code that must handle being > invoked from a wide variety of contexts. Note that I think that core functionality is different from random drivers. Of course core code can (and will) look at things like if (in_interrupt()) .. schedule work asynchronously .. because core code ends up being called from odd places, and code like that is expected to have understanding of the rules it plays with. But something like RCU is a very different beast from some "walk the scatter-gather list" code. RCU does its work in the background, and works with lots of different things. And it's so core and used everywhere that it knows about these things. I mean, we literally have special code explicitly to let RCU know "we entered kernel context now". But something like a driver list walking thing should not be doing different things behind peoples back depending on whether they hold spinlocks or not. It should either just work regardless, or there should be a flag (or special interface) for the "you're being called in a crtitical region". Because dynamically changing behavior really is very confusing. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 21/21] drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several drivers.
>
> What is also gone is gem_vm_ops in struct drm_driver. All drivers now
> use struct drm_gem_object_funcs.vm_ops instead.
>
> While at it, the patch also improves error handling around calls
> to .free and .get_sg_table callbacks.
>
> v2:
> * update related TODO item (Sam)
>
> Signed-off-by: Thomas Zimmermann
> ---
> Documentation/gpu/todo.rst | 7 +--
> drivers/gpu/drm/drm_gem.c| 35 +++-
> drivers/gpu/drm/drm_gem_cma_helper.c | 6 +-
> drivers/gpu/drm/drm_prime.c | 17 +++---
> include/drm/drm_drv.h| 85 ++--
> 5 files changed, 25 insertions(+), 125 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index b0ea17da8ff6..0fc6bc222392 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -289,11 +289,8 @@ struct drm_gem_object_funcs
> ---
>
> GEM objects can now have a function table instead of having the callbacks on
> the
> -DRM driver struct. This is now the preferred way and drivers can be moved
> over.
> -
> -We also need a 2nd version of the CMA define that doesn't require the
> -vmapping to be present (different hook for prime importing). Plus this needs
> to
> -be rolled out to all drivers using their own implementations, too.
> +DRM driver struct. This is now the preferred way. Callbacks in drivers have
> been
> +converted, except for struct drm_driver.gem_prime_mmap.
>
> Level: Intermediate
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 19d73868490e..96945bed8291 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -247,12 +247,9 @@ drm_gem_object_release_handle(int id, void *ptr, void
> *data)
> {
> struct drm_file *file_priv = data;
> struct drm_gem_object *obj = ptr;
> - struct drm_device *dev = obj->dev;
>
> if (obj->funcs && obj->funcs->close)
> obj->funcs->close(obj, file_priv);
> - else if (dev->driver->gem_close_object)
> - dev->driver->gem_close_object(obj, file_priv);
>
> drm_gem_remove_prime_handles(obj, file_priv);
> drm_vma_node_revoke(&obj->vma_node, file_priv);
> @@ -407,10 +404,6 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
> ret = obj->funcs->open(obj, file_priv);
> if (ret)
> goto err_revoke;
> - } else if (dev->driver->gem_open_object) {
> - ret = dev->driver->gem_open_object(obj, file_priv);
> - if (ret)
> - goto err_revoke;
> }
>
> *handlep = handle;
> @@ -982,12 +975,11 @@ drm_gem_object_free(struct kref *kref)
> {
> struct drm_gem_object *obj =
> container_of(kref, struct drm_gem_object, refcount);
> - struct drm_device *dev = obj->dev;
>
> - if (obj->funcs)
> - obj->funcs->free(obj);
> - else if (dev->driver->gem_free_object_unlocked)
> - dev->driver->gem_free_object_unlocked(obj);
> + if (drm_WARN_ON_ONCE(obj->dev, !obj->funcs || !obj->funcs->free))
> + return;
> +
> + obj->funcs->free(obj);
> }
> EXPORT_SYMBOL(drm_gem_object_free);
>
> @@ -1049,9 +1041,9 @@ EXPORT_SYMBOL(drm_gem_vm_close);
> * @obj_size: the object size to be mapped, in bytes
> * @vma: VMA for the area to be mapped
> *
> - * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops
> - * provided by the driver. Depending on their requirements, drivers can
> either
> - * provide a fault handler in their gem_vm_ops (in which case any accesses to
> + * Set up the VMA to prepare mapping of the GEM object using the GEM object's
> + * vm_ops. Depending on their requirements, GEM objects can either
> + * provide a fault handler in their vm_ops (in which case any accesses to
> * the object will be trapped, to perform migration, GTT binding, surface
> * register allocation, or performance monitoring), or mmap the buffer memory
> * synchronously after calling drm_gem_mmap_obj.
> @@ -1065,12 +1057,11 @@ EXPORT_SYMBOL(drm_gem_vm_close);
> * callers must verify access restrictions before calling this helper.
> *
> * Return 0 or success or -EINVAL if the object size is smaller than the VMA
> - * size, or if no gem_vm_ops are provided.
> + * size, or if no vm_ops are provided.
> */
> int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
>struct vm_area_struct *vma)
> {
> - struct drm_device *dev = obj->dev;
> int ret;
>
> /* Check for valid size. */
> @@ -1095,8 +1086,6 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj,
>
Re: [PATCH 0/3] drm: panfrost: Coherency support
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig wrote: > > > So I get a performance regression with the dma-coherent approach, even if > > it's > > clearly the cleaner. > > That's bizarre -- this should really be the faster of the two. Coherency may not be free. CortexA9 had something like 4x slower memcpy if SMP was enabled as an example. I don't know if there's anything going on like that specifically here. If there's never any CPU accesses mixed in with kmscube, then there would be no benefit to coherency. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels
Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.
We also take care not to reprogram the source OUI if it already matches
what we expect. This is just to be careful so that we don't accidentally
take the panel out of any backlight control modes we found it in.
v2:
* Add careful parameter to intel_edp_init_source_oui() to avoid
re-writing the source OUI if it's already been set during driver
initialization
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
drivers/gpu/drm/i915/display/intel_dp.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4bd10456ad188..7db2b6a3cd52e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct
intel_dp *intel_dp,
enable ? "enable" : "disable");
}
+static void
+intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 oui[] = { 0x00, 0xaa, 0x01 };
+ u8 buf[3] = { 0 };
+
+ /*
+* During driver init, we want to be careful and avoid changing the
source OUI if it's
+* already set to what we want, so as to avoid clearing any state by
accident
+*/
+ if (careful) {
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_SOURCE_OUI, buf,
sizeof(buf)) < 0)
+ drm_err(&i915->drm, "Failed to read source OUI\n");
+
+ if (memcmp(oui, buf, sizeof(oui)) == 0)
+ return;
+ }
+
+ if (drm_dp_dpcd_write(&intel_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui))
< 0)
+ drm_err(&i915->drm, "Failed to write source OUI\n");
+}
+
/* If the sink supports it, try to set the power state appropriately */
void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
{
@@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
mode)
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+ /* Write the source OUI as early as possible */
+ if (intel_dp_is_edp(intel_dp))
+ intel_edp_init_source_oui(intel_dp, false);
+
/*
* When turning on, we need to retry for 1ms to give the sink
* time to wake up.
@@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
intel_dp_get_dsc_sink_cap(intel_dp);
+ /*
+* If needed, program our source OUI so we can make various
Intel-specific AUX services
+* available (such as HDR backlight controls)
+*/
+ intel_edp_init_source_oui(intel_dp, true);
+
return true;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 8/8] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.
At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.
As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.
v2:
* Fix indenting error picked up by checkpatch in
intel_edp_init_connector()
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
drivers/gpu/drm/drm_dp_helper.c | 82 +--
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +-
.../drm/i915/display/intel_display_types.h| 1 -
drivers/gpu/drm/i915/display/intel_dp.c | 9 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
include/drm/drm_dp_helper.h | 21 +
7 files changed, 9 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c82..7138655bfc9d0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -823,7 +823,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
- !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+ !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
}
EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
@@ -1544,86 +1544,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident,
bool is_branch)
#undef DEVICE_ID_ANY
#undef DEVICE_ID
-struct edid_quirk {
- u8 mfg_id[2];
- u8 prod_id[2];
- u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * Some devices have unreliable OUIDs where they don't set the device ID
- * correctly, and as a result we need to use the EDID for finding additional
- * DP quirks in such cases.
- */
-static const struct edid_quirk edid_quirk_list[] = {
- /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
-* only supports DPCD backlight controls
-*/
- { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- /*
-* Some Dell CML 2020 systems have panels support both AUX and PWM
-* backlight control, and some only support AUX backlight control. All
-* said panels start up in AUX mode by default, and we don't have any
-* support for disabling HDR mode on these panels which would be
-* required to switch to PWM backlight control mode (plus, I'm not
-* even sure we want PWM backlight controls over DPCD backlight
-* controls anyway...). Until we have a better way of detecting these,
-* force DPCD backlight mode on all of them.
-*/
- { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can be used to check the EDID and look
- * up any additional DP quirks. The bits returned by this functi
[RFC v2 0/8] drm/i915: Add support for Intel's eDP backlight controls
A while ago we ran into issues while trying to enable the eDP backlight control interface as defined by VESA, in order to make the DPCD backlight controls on newer laptop panels work. The issue ended up being much more complicated however, as we also apparently needed to add support for an Intel-specific DPCD backlight control interface as the VESA interface is broken on many laptop panels. For lack of a better name, we just call this the Intel HDR backlight interface. While this only adds support for the SDR backlight mode (I think), this will fix a lot of user's laptop panels that we weren't able to properly automatically detect DPCD backlight controls on previously. Lyude Paul (8): drm/i915/dp: Program source OUI on eDP panels drm/i915: Rename pwm_* backlight callbacks to ext_pwm_* drm/i915: Keep track of pwm-related backlight hooks separately drm/i915/dp: Rename eDP VESA backlight interface functions drm/i915/dp: Add register definitions for Intel HDR backlight interface drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight drm/dp: Revert "drm/dp: Introduce EDID-based quirks" drivers/gpu/drm/drm_dp_helper.c | 82 +-- drivers/gpu/drm/drm_dp_mst_topology.c | 3 +- .../drm/i915/display/intel_display_types.h| 24 +- drivers/gpu/drm/i915/display/intel_dp.c | 42 +- .../drm/i915/display/intel_dp_aux_backlight.c | 384 -- drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- drivers/gpu/drm/i915/display/intel_panel.c| 476 ++ drivers/gpu/drm/i915/display/intel_panel.h| 4 + drivers/gpu/drm/i915/display/intel_psr.c | 2 +- drivers/gpu/drm/i915/i915_params.c| 2 +- include/drm/drm_dp_helper.h | 21 +- 11 files changed, 672 insertions(+), 371 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 4/8] drm/i915/dp: Rename eDP VESA backlight interface functions
Since we're about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_dp_aux_backlight.c | 51 ++-
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe3..f601bcbe8ee46 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -25,7 +25,7 @@
#include "intel_display_types.h"
#include "intel_dp_aux_backlight.h"
-static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
@@ -56,7 +56,7 @@ static void set_aux_backlight_enable(struct intel_dp
*intel_dp, bool enable)
* Read the current backlight value from DPCD register(s) based
* on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
*/
-static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
+static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -99,7 +99,8 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector
*connector)
* 8-bit or 16 bit value (MSB and LSB)
*/
static void
-intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32
level)
+intel_dp_aux_vesa_set_backlight(const struct drm_connector_state *conn_state,
+ u32 level)
{
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -129,7 +130,7 @@ intel_dp_aux_set_backlight(const struct drm_connector_state
*conn_state, u32 lev
* - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
* EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
*/
-static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -165,8 +166,8 @@ static bool intel_dp_aux_set_pwm_freq(struct
intel_connector *connector)
return true;
}
-static void intel_dp_aux_enable_backlight(const struct intel_crtc_state
*crtc_state,
- const struct drm_connector_state
*conn_state)
+static void intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state
*crtc_state,
+ const struct drm_connector_state
*conn_state)
{
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -206,7 +207,7 @@ static void intel_dp_aux_enable_backlight(const struct
intel_crtc_state *crtc_st
}
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
- if (intel_dp_aux_set_pwm_freq(connector))
+ if (intel_dp_aux_vesa_set_pwm_freq(connector))
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
if (new_dpcd_buf != dpcd_buf) {
@@ -217,18 +218,18 @@ static void intel_dp_aux_enable_backlight(const struct
intel_crtc_state *crtc_st
}
}
- intel_dp_aux_set_backlight(conn_state,
- connector->panel.backlight.level);
- set_aux_backlight_enable(intel_dp, true);
+ intel_dp_aux_vesa_set_backlight(conn_state,
+ connector->panel.backlight.level);
+ set_vesa_backlight_enable(intel_dp, true);
}
-static void intel_dp_aux_disable_backlight(const struct drm_connector_state
*old_conn_state)
+static void intel_dp_aux_vesa_disable_backlight(const struct
drm_connector_state *old_conn_state)
{
-
set_aux_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
-false);
+
set_vesa_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
+ false);
}
-static u32 intel_dp_aux_calc_max_backlight(struct intel_connector *connector)
+static u32 intel_dp_aux_vesa_calc_max_backlight(struct intel_connector
*connector)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_dp *inte
[RFC v2 7/8] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.
So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
drivers/gpu/drm/i915/i915_params.c| 2 +-
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 376419ea3ae52..aa1429302db70 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -585,15 +585,54 @@ intel_dp_aux_supports_vesa_backlight(struct
intel_connector *connector)
return false;
}
+enum intel_dp_aux_backlight_modparam {
+ INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+ INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+ INTEL_DP_AUX_BACKLIGHT_ON = 1,
+ INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+ INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
{
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ bool try_intel_interface = false, try_vesa_interface = false;
- if (i915->params.enable_dpcd_backlight == 0)
+ /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+ switch (i915->params.enable_dpcd_backlight) {
+ case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+ case INTEL_DP_AUX_BACKLIGHT_AUTO:
+ switch (i915->vbt.backlight.type) {
+ case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+ try_vesa_interface = true;
+ break;
+ case INTEL_BACKLIGHT_DISPLAY_DDI:
+ try_intel_interface = true;
+ try_vesa_interface = true;
+ break;
+ default:
+ return -ENODEV;
+ }
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_ON:
+ if (i915->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+ try_intel_interface = true;
+
+ try_vesa_interface = true;
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+ try_vesa_interface = true;
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+ try_intel_interface = true;
+ break;
+ }
/*
* A lot of eDP panels in the wild will report supporting both the
@@ -602,7 +641,7 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
* and will only work with the Intel interface. So, always probe for
* that first.
*/
- if (intel_dp_aux_supports_hdr_backlight(connector)) {
+ if (try_intel_interface &&
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg(dev, "Using Intel proprietary eDP backlight
controls\n");
panel->backlight.setup = intel_dp_aux_hdr_setup_backlight;
@@ -614,7 +653,7 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
return 0;
}
- if (intel_dp_aux_supports_vesa_backlight(connector)) {
+ if (try_vesa_interface &&
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg(dev, "Using VESA eDP backlight controls\n");
panel->backlight.setup = intel_dp_aux_vesa_setup_backlight;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b2..6939634e56ed6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
- "(-1=use per-VBT LFP backlight type setting [default], 0=disabled,
1=enabled)");
+ "(-1=use per-VBT LFP backlight type setting [default], 0=disabled,
1=enable, 2=force VESA interface, 3=force Intel interface)");
#if
[RFC v2 2/8] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight functions is a bit more obvious.
This introduces no functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 9f23bac0d7924..c0e36244bb07d 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector
*connector)
BXT_BLC_PWM_DUTY(panel->backlight.controller));
}
-static u32 pwm_get_backlight(struct intel_connector *connector)
+static u32 ext_pwm_get_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = &connector->panel;
struct pwm_state state;
@@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct
drm_connector_state *conn_state, u32
BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
}
-static void pwm_set_backlight(const struct drm_connector_state *conn_state,
u32 level)
+static void ext_pwm_set_backlight(const struct drm_connector_state
*conn_state, u32 level)
{
struct intel_panel *panel =
&to_intel_connector(conn_state->connector)->panel;
@@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct
drm_connector_state *old_conn_sta
tmp & ~BXT_BLC_PWM_ENABLE);
}
-static void pwm_disable_backlight(const struct drm_connector_state
*old_conn_state)
+static void ext_pwm_disable_backlight(const struct drm_connector_state
*old_conn_state)
{
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = &connector->panel;
@@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct
intel_crtc_state *crtc_state,
pwm_ctl | BXT_BLC_PWM_ENABLE);
}
-static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state
*conn_state)
{
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct intel_panel *panel = &connector->panel;
@@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector,
enum pipe unused)
return 0;
}
-static int pwm_setup_backlight(struct intel_connector *connector,
- enum pipe pipe)
+static int ext_pwm_setup_backlight(struct intel_connector *connector,
+ enum pipe pipe)
{
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel
*panel)
panel->backlight.hz_to_pwm = pch_hz_to_pwm;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
- panel->backlight.setup = pwm_setup_backlight;
- panel->backlight.enable = pwm_enable_backlight;
- panel->backlight.disable = pwm_disable_backlight;
- panel->backlight.set = pwm_set_backlight;
- panel->backlight.get = pwm_get_backlight;
+ panel->backlight.setup = ext_pwm_setup_backlight;
+ panel->backlight.enable = ext_pwm_enable_backlight;
+ panel->backlight.disable = ext_pwm_disable_backlight;
+ panel->backlight.set = ext_pwm_set_backlight;
+ panel->backlight.get = ext_pwm_get_backlight;
} else {
panel->backlight.setup = vlv_setup_backlight;
panel->backlight.enable = vlv_enable_backlight;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 3/8] drm/i915: Keep track of pwm-related backlight hooks separately
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.
So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:
* We now keep track of two separate backlight level ranges, one for the
high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
enablement separately
* Since the currently set backlight level might not be the same as the
currently programmed PWM backlight level, we stop setting
panel->backlight.level with the currently programmed PWM backlight
level in panel->backlight.pwm_funcs.setup(). Instead, we rely
on the higher level backlight control functions to retrieve the
current PWM backlight level (in this case, intel_pwm_get_backlight()).
Note that there are still a few PWM backlight setup callbacks that
do actually need to retrieve the current PWM backlight level, although
we no longer save this value in panel->backlight.level like before.
* panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
brightness level, unlike their siblings
panel->backlight.enable()/disable(). This is so we can calculate the
actual PWM brightness level we want to set on disable/enable in the
higher level backlight enable()/disable() functions, since this value
might be scaled from a brightness level that doesn't come from PWM.
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_display_types.h| 14 +-
drivers/gpu/drm/i915/display/intel_panel.c| 436 ++
2 files changed, 246 insertions(+), 204 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b2d0edacc58c9..52a6543df842a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -221,6 +221,9 @@ struct intel_panel {
bool alternate_pwm_increment; /* lpt+ */
/* PWM chip */
+ u32 pwm_min;
+ u32 pwm_max;
+ bool pwm_enabled;
bool util_pin_active_low; /* bxt+ */
u8 controller; /* bxt+ only */
struct pwm_device *pwm;
@@ -229,6 +232,16 @@ struct intel_panel {
/* DPCD backlight */
u8 pwmgen_bit_count;
+ struct {
+ int (*setup)(struct intel_connector *connector, enum
pipe pipe);
+ u32 (*get)(struct intel_connector *connector);
+ void (*set)(const struct drm_connector_state
*conn_state, u32 level);
+ void (*disable)(const struct drm_connector_state
*conn_state, u32 level);
+ void (*enable)(const struct intel_crtc_state
*crtc_state,
+ const struct drm_connector_state
*conn_state, u32 level);
+ u32 (*hz_to_pwm)(struct intel_connector *connector, u32
hz);
+ } pwm_funcs;
+
struct backlight_device *device;
/* Connector and platform specific backlight functions */
@@ -238,7 +251,6 @@ struct intel_panel {
void (*disable)(const struct drm_connector_state *conn_state);
void (*enable)(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state);
- u32 (*hz_to_pwm)(struct intel_connector *connector, u32 hz);
void (*power)(struct intel_connector *, bool enable);
} backlight;
};
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index c0e36244bb07d..6d3e9d51d069c 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector
*connector,
0, user_max);
}
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector,
u32 val)
{
struct drm_i915_priv
[RFC v2 6/8] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.
On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.
For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:
* If the panel's VBT reports VESA backlight support, assume it really
does support it
* If the panel's VBT reports DDI backlight controls:
* First probe for Intel's HDR backlight interface
* If that fails, probe for VESA's backlight interface
* If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
doesn't have DPCD backlight controls
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_display_types.h| 9 +-
.../drm/i915/display/intel_dp_aux_backlight.c | 253 --
drivers/gpu/drm/i915/display/intel_panel.c| 34 ++-
drivers/gpu/drm/i915/display/intel_panel.h| 4 +
4 files changed, 268 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 52a6543df842a..9d540368bac89 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -230,7 +230,14 @@ struct intel_panel {
struct pwm_state pwm_state;
/* DPCD backlight */
- u8 pwmgen_bit_count;
+ union {
+ struct {
+ u8 pwmgen_bit_count;
+ } vesa;
+ struct {
+ bool sdr_uses_aux;
+ } intel;
+ } edp;
struct {
int (*setup)(struct intel_connector *connector, enum
pipe pipe);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index c1e8e8b166267..376419ea3ae52 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
*
*/
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
#include "intel_display_types.h"
#include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
/*
* DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,176 @@
#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
+{
+ struct drm_device *dev = connector->base.dev;
+ struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
+ struct drm_dp_aux *aux = &intel_dp->aux;
+ struct intel_panel *panel = &connector->panel;
+ int ret;
+ u8 tcon_cap[4];
+
+ ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_C
[RFC v2 5/8] drm/i915/dp: Add register definitions for Intel HDR backlight interface
No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c
Reviewed-by: Rodrigo Vivi
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_dp_aux_backlight.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index f601bcbe8ee46..c1e8e8b166267 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -25,6 +25,59 @@
#include "intel_display_types.h"
#include "intel_dp_aux_backlight.h"
+/*
+ * DP AUX registers for Intel's proprietary HDR backlight interface. We define
+ * them here since we'll likely be the only driver to ever use these.
+ */
+#define INTEL_EDP_HDR_TCON_CAP00x340
+
+#define INTEL_EDP_HDR_TCON_CAP10x341
+# define INTEL_EDP_HDR_TCON_2084_DECODE_CAP BIT(0)
+# define INTEL_EDP_HDR_TCON_2020_GAMUT_CAPBIT(1)
+# define INTEL_EDP_HDR_TCON_TONE_MAPPING_CAP BIT(2)
+# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_CAP BIT(3)
+# define INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP BIT(4)
+# define INTEL_EDP_HDR_TCON_OPTIMIZATION_CAP BIT(5)
+# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_CAP BIT(6)
+# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_CONVERSION_CAPBIT(7)
+
+#define INTEL_EDP_HDR_TCON_CAP20x342
+# define INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAPBIT(0)
+
+#define INTEL_EDP_HDR_TCON_CAP30x343
+
+#define INTEL_EDP_HDR_GETSET_CTRL_PARAMS 0x344
+# define INTEL_EDP_HDR_TCON_2084_DECODE_ENABLEBIT(0)
+# define INTEL_EDP_HDR_TCON_2020_GAMUT_ENABLE BIT(1)
+# define INTEL_EDP_HDR_TCON_TONE_MAPPING_ENABLE BIT(2)
/* Pre-TGL+ */
+# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_ENABLEBIT(3)
+# define INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE BIT(4)
+# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_ENABLEBIT(5)
+/* Bit 6 is reserved */
+# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_ENABLEBIT(7)
+
+#define INTEL_EDP_HDR_CONTENT_LUMINANCE0x346
/* Pre-TGL+ */
+#define INTEL_EDP_HDR_PANEL_LUMINANCE_OVERRIDE 0x34A
+#define INTEL_EDP_SDR_LUMINANCE_LEVEL 0x352
+#define INTEL_EDP_BRIGHTNESS_NITS_LSB 0x354
+#define INTEL_EDP_BRIGHTNESS_NITS_MSB 0x355
+#define INTEL_EDP_BRIGHTNESS_DELAY_FRAMES 0x356
+#define INTEL_EDP_BRIGHTNESS_PER_FRAME_STEPS 0x357
+
+#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_00x358
+# define INTEL_EDP_TCON_USAGE_MASK GENMASK(0, 3)
+# define INTEL_EDP_TCON_USAGE_UNKNOWN0x0
+# define INTEL_EDP_TCON_USAGE_DESKTOP0x1
+# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_MEDIA 0x2
+# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_GAMING 0x3
+# define INTEL_EDP_TCON_POWER_MASKBIT(4)
+# define INTEL_EDP_TCON_POWER_DC(0 << 4)
+# define INTEL_EDP_TCON_POWER_AC(1 << 4)
+# define INTEL_EDP_TCON_OPTIMIZATION_STRENGTH_MASK GENMASK(5, 7)
+
+#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
+
+/* VESA backlight callbacks */
static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/6] arm64: dts: exynos: Align OPP table name with dt-schema
On Thu, Sep 03, 2020 at 09:14:38PM +0200, Krzysztof Kozlowski wrote: > Device tree nodes should have hyphens instead of underscores. This is > also expected by the bindings. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. New patch > --- > arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +- Applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/6] ARM: dts: exynos: Align OPP table name with dt-schema
On Thu, Sep 03, 2020 at 09:14:37PM +0200, Krzysztof Kozlowski wrote: > Device tree nodes should have hyphens instead of underscores. This is > also expected by the bindings. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. New patch > --- > arch/arm/boot/dts/exynos4412.dtsi | 16 > arch/arm/boot/dts/exynos5250.dtsi | 2 +- > 2 files changed, 9 insertions(+), 9 deletions(-) Applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] Fixes for am65x and j721e dss dt-schema
Hi, This is version three of the series: https://www.spinics.net/lists/arm-kernel/msg836244.html There are no changes to the yaml in this version, but I am resending as I missed cc'ing dri-devel previously. I have also added Rob's reviewed-bys, and sending only the dt-schema changes. Tomi Tomi Valkeinen (2): dt-bindings: display: ti,am65x-dss: add missing properties to dt-schema dt-bindings: display: ti,j721e-dss: add missing properties to dt-schema .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 11 +++ .../devicetree/bindings/display/ti/ti,j721e-dss.yaml | 11 +++ 2 files changed, 22 insertions(+) -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] dt-bindings: display: ti, j721e-dss: add missing properties to dt-schema
Add assigned-clocks, assigned-clock-parents and dma-coherent optional properties. Signed-off-by: Tomi Valkeinen Reviewed-by: Rob Herring --- .../devicetree/bindings/display/ti/ti,j721e-dss.yaml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml index 173730d56334..c9a947d55fa4 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml @@ -77,6 +77,14 @@ properties: - const: vp3 - const: vp4 + assigned-clocks: +minItems: 1 +maxItems: 5 + + assigned-clock-parents: +minItems: 1 +maxItems: 5 + interrupts: items: - description: common_m DSS Master common @@ -95,6 +103,9 @@ properties: maxItems: 1 description: phandle to the associated power domain + dma-coherent: +type: boolean + ports: type: object description: -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] dt-bindings: display: ti, am65x-dss: add missing properties to dt-schema
Add assigned-clocks, assigned-clock-parents and dma-coherent optional properties. Signed-off-by: Tomi Valkeinen Reviewed-by: Rob Herring --- .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 4f9185462ed3..4dc30738ee57 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -55,6 +55,14 @@ properties: - const: vp1 - const: vp2 + assigned-clocks: +minItems: 1 +maxItems: 3 + + assigned-clock-parents: +minItems: 1 +maxItems: 3 + interrupts: maxItems: 1 @@ -62,6 +70,9 @@ properties: maxItems: 1 description: phandle to the associated power domain + dma-coherent: +type: boolean + ports: type: object description: -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
On Mon, Aug 17, 2020 at 9:09 AM Ezequiel Garcia wrote:
>
> This heap is basically a wrapper around DMA-API dma_alloc_attrs,
> which will allocate memory suitable for the given device.
>
> The implementation is mostly a port of the Contiguous Videobuf2
> memory allocator (see videobuf2/videobuf2-dma-contig.c)
> over to the DMA-BUF Heap interface.
>
> The intention of this allocator is to provide applications
> with a more system-agnostic API: the only thing the application
> needs to know is which device to get the buffer for.
>
> Whether the buffer is backed by CMA, IOMMU or a DMA Pool
> is unknown to the application.
>
> I'm not really expecting this patch to be correct or even
> a good idea, but just submitting it to start a discussion on DMA-BUF
> heap discovery and negotiation.
>
> Given Plumbers is just a couple weeks from now, I've submitted
> a BoF proposal to discuss this, as perhaps it would make
> sense to discuss this live?
>
> Not-signed-off-by: Ezequiel Garcia
Adding Simon and James who've done a presentation at XDC just now
about allocation constraint solving and heap ids came up. There's
going to be a discussion tomorrow in the workshop track, might be
worth and try joining if you can make it happen (xdc is virtual and
free).
Cheers, Daniel
> ---
> drivers/dma-buf/heaps/Kconfig | 9 +
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/device_heap.c | 268
> include/linux/device.h | 5 +
> include/linux/dma-heap.h| 6 +
> 5 files changed, 289 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/device_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index a5eef06c4226..2bb3604184bd 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -12,3 +12,12 @@ config DMABUF_HEAPS_CMA
> Choose this option to enable dma-buf CMA heap. This heap is backed
> by the Contiguous Memory Allocator (CMA). If your system has these
> regions, you should say Y here.
> +
> +config DMABUF_HEAPS_DEVICES
> + bool "DMA-BUF Device DMA Heap (Experimental)"
> + depends on DMABUF_HEAPS
> + help
> + Choose this option to enable dma-buf per-device heap. This heap is
> backed
> + by the DMA-API and it's an Experimental feature, meant mostly for
> testing
> + and experimentation.
> + Just say N here.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index 6e54cdec3da0..c691d85b3044 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -2,3 +2,4 @@
> obj-y += heap-helpers.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_DEVICES) += device_heap.o
> diff --git a/drivers/dma-buf/heaps/device_heap.c
> b/drivers/dma-buf/heaps/device_heap.c
> new file mode 100644
> index ..1803dc622dd8
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/device_heap.c
> @@ -0,0 +1,268 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF Device DMA heap exporter
> + *
> + * Copyright (C) 2020, Collabora Ltd.
> + *
> + * Based on:
> + * videobuf2-dma-contig.c - DMA contig memory allocator for videobuf2
> + * Copyright (C) 2010 Samsung Electronics
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct dev_dmabuf_attachment {
> + struct sg_table sgt;
> + enum dma_data_direction dma_dir;
> +};
> +
> +struct dev_dmabuf {
> + struct dma_heap *heap;
> + struct dma_buf *dmabuf;
> + struct device *dev;
> + size_t size;
> + void *vaddr;
> + dma_addr_t dma_addr;
> + unsigned long attrs;
> +
> + struct sg_table sgt;
> +};
> +
> +static struct sg_table *dev_dmabuf_ops_map(struct dma_buf_attachment
> *db_attach,
> + enum dma_data_direction dma_dir)
> +{
> + struct dev_dmabuf_attachment *attach = db_attach->priv;
> + /* stealing dmabuf mutex to serialize map/unmap operations */
> + struct mutex *lock = &db_attach->dmabuf->lock;
> + struct sg_table *sgt;
> +
> + mutex_lock(lock);
> +
> + sgt = &attach->sgt;
> + /* return previously mapped sg table */
> + if (attach->dma_dir == dma_dir) {
> + mutex_unlock(lock);
> + return sgt;
> + }
> +
> + /* release any previous cache */
> + if (attach->dma_dir != DMA_NONE) {
> + dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
> + attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
> + attach->dma_dir = DMA_NONE;
> + }
> +
> + /*
> +* mapping to the client with new direction, no cache sync
> +* required see comment in .dmabuf_o
Re: [PATCH v10 1/3] dt-bindings: drm/bridge: Document Cadence MHDP8546 bridge bindings
Hi Swapnil, Yuti, On 14/09/2020 15:48, Swapnil Jakhade wrote: > From: Yuti Amonkar > > Document the bindings used for the Cadence MHDP8546 DPI/DP bridge in > yaml format. > > Signed-off-by: Yuti Amonkar > Signed-off-by: Swapnil Jakhade > Reviewed-by: Rob Herring > Reviewed-by: Laurent Pinchart > --- > .../display/bridge/cdns,mhdp8546.yaml | 154 ++ > 1 file changed, 154 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml I was testing this on J7 EVM, and looking at the dts files and DT bindings. To get rid of the warnings from dtbs_check, I made the following changes. I think the interrupt one is clear. The driver needs the interrupt, but it was not defined in the yaml file. For phy-names, we had that in the out-of-tree dts file, so I added it here. The driver just looks for the PHY via index, but I guess we should require it. The power-domain is not needed by the driver, but if I'm not mistaken, has to be defined here. diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index a21a4bfe15cf..c5f5781c1ed6 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -46,6 +46,16 @@ properties: description: phandle to the DisplayPort PHY. + phy-names: +items: + - const: dpphy + + power-domains: +maxItems: 1 + + interrupts: +maxItems: 1 + ports: type: object description: @@ -114,6 +124,8 @@ required: - reg - reg-names - phys + - phy-names + - interrupts - ports additionalProperties: false Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 5/8] drm/i915: Add dedicated plane hook for async flip case
On 9/16/2020 6:30 PM, Karthik B S wrote:
On 9/15/2020 8:11 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
and call it from intel_update_plane. (Ville)
v8: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 7 ++
.../drm/i915/display/intel_display_types.h | 3 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 24 +++
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 79032701873a..fdc633020255 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -408,6 +408,13 @@ void intel_update_plane(struct intel_plane *plane,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
trace_intel_update_plane(&plane->base, crtc);
+
+ if (crtc_state->uapi.async_flip) {
Hmm. Now I'm starting to wonder how this is actually going to interact
with legacy cursor updates. The crtc_state we use there I think comes
from the previous update and so will have this flag set it if was an
async flip. Which means the cursor ioctl will oops.
We may want the igt to check this particular combination of ioctls
actually.
I tried this out locally by using the DRM_IOCTL_MODE_CURSOR ioctl after
an async flip. And looks like its working fine. During the cursor commit
it actually takes the 'else' path.
I'll send out the new version of the IGT shortly with this subtest
added. Please let me know if I'm missing something there.
I've pushed the IGT with the cursor subtest added.
https://patchwork.freedesktop.org/series/79701/
Thanks,
Karthik.B.S
Thanks,
Karthik.B.S
+ plane->program_async_surface_address(plane,
+ crtc_state, plane_state);
+ return;
+ }
+
plane->update_plane(plane, crtc_state, plane_state);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b2d0edacc58c..d2ae781e4d81 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1190,6 +1190,9 @@ struct intel_plane {
struct intel_plane_state *plane_state);
int (*min_cdclk)(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state);
+ void (*program_async_surface_address)(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state);
};
struct intel_watermark_params {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index f0c89418d2e1..69407dfcebf6 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -609,6 +609,29 @@ icl_program_input_csc(struct intel_plane *plane,
PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
}
+static void
+skl_program_async_surface_address(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ unsigned long irqflags;
+ enum plane_id plane_id = plane->id;
+ enum pipe pipe = plane->pipe;
+ u32 surf_addr = plane_state->color_plane[0].offset;
+ u32 plane_ctl = plane_state->ctl;
+
+ plane_ctl |= skl_plane_ctl_crtc(crtc_state);
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+
+ intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
+ intel_plane_ggtt_offset(plane_state) + surf_addr);
+
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+}
+
static void
skl_program_plane(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -3096,6 +3119,7 @@ skl_universal_plane_create(struct
drm_i915_private *dev_priv,
plane->get_hw_state = skl_plane_get_hw_state;
plane->check_plane = skl_plane_check;
plane->min_cdclk = skl_plane_min_cdclk;
+ plane->program_async_surface_address =
skl_program_async_surface_address;
if (INTEL_GEN(dev_priv) >= 11)
formats = icl_get_plane_formats(dev_priv, pipe,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/panel: samsung: make vint_table static const
This eliminates the following sparse warning:
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c:217:15: warning: symbol
'vint_table' was not declared. Should it be static?
While at it, make the table const as it is never modified.
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 1d1c79a18613..0ab1b7ec84cd 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -214,7 +214,7 @@ static const u8
gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
0x00, 0x00 }
};
-unsigned char vint_table[S6E3HA2_VINT_STATUS_MAX] = {
+static const unsigned char vint_table[S6E3HA2_VINT_STATUS_MAX] = {
0x18, 0x19, 0x1a, 0x1b, 0x1c,
0x1d, 0x1e, 0x1f, 0x20, 0x21
};
--
2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v15 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
anx7625: MIPI to DP transmitter DT schema
Signed-off-by: Xin Ji
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/analogix,anx7625.yaml | 95 ++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
new file mode 100644
index 000..60585a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ compatible:
+items:
+ - const: analogix,anx7625
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: used for interrupt pin B8.
+maxItems: 1
+
+ enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+ reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description:
+ Video port for MIPI DSI input.
+
+ port@1:
+type: object
+description:
+ Video port for panel or connector.
+
+required:
+- port@0
+- port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi2dp_bridge_in: port@0 {
+reg = <0>;
+anx7625_in: endpoint {
+remote-endpoint = <&mipi_dsi>;
+};
+};
+
+mipi2dp_bridge_out: port@1 {
+reg = <1>;
+anx7625_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v15 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/Kconfig |9 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 1848 +
drivers/gpu/drm/bridge/analogix/anx7625.h | 390 ++
4 files changed, 2248 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e1fa7d8..024ea2a 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_ANX7625
+ tristate "Analogix Anx7625 MIPI to DP interface support"
+ depends on DRM
+ depends on OF
+ help
+ ANX7625 is an ultra-low power 4K mobile HD transmitter
+ designed for portable devices. It converts MIPI/DPI to
+ DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index 97669b3..44da392 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..6e2fe7e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,1848 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "anx7625.h"
+
+/*
+ * There is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+ u8 offset;
+ struct device *dev = &client->dev;
+ int ret;
+
+ if (client == ctx->last_client)
+ return 0;
+
+ ctx->last_client = client;
+
+ if (client == ctx->i2c.tcpc_client)
+ offset = RSVD_00_ADDR;
+ else if (client == ctx->i2c.tx_p0_client)
+ offset = RSVD_D1_ADDR;
+ else if (client == ctx->i2c.tx_p1_client)
+ offset = RSVD_60_ADDR;
+ else if (client == ctx->i2c.rx_p0_client)
+ offset = RSVD_39_ADDR;
+ else if (client == ctx->i2c.rx_p1_client)
+ offset = RSVD_7F_ADDR;
+ else
+ offset = RSVD_00_ADDR;
+
+ ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev,
+ "fail to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+ return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+ struct i2c_client *client, u8 reg_addr)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_byte_data(client, reg_addr);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_i2c_block_data(client, reg_addr, len, buf);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c block fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_write(struct anx7625_data *ctx,
+struct i2c_client *client,
+u8 reg_addr, u8 reg_val)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
[PATCH v15 0/2] Add initial support for slimport anx7625
Hi all, The following series add support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the v15 version, any mistakes, please let me know, I will fix it in the next series. Change history: v15: Fix comments from Sam and Hsin-Yi Wang - Remove connector - Allocate memory for edid at ".get_edid()" v14: Fix comments from Sam and Nicolas - Check flags at drm_bridge_attach - Use panel_bridge instead of drm_panel - Fix not correct return value v13: Fix comments from Launrent Pinchart and Rob Herring - Picked up Rob's Reviewed-By - Add .detect and .get_edid interface in bridge funcs. v12: Fix comments from Hsin-Yi Wang - Rebase the code on kernel 5.7, fix DRM interface not match issue. v11: Fix comments from Rob Herring - Update commit message. - Remove unused label. v10: Fix comments from Rob Herring, Daniel. - Fix dt_binding_check warning. - Update description. v9: Fix comments from Sam, Nicolas, Daniel - Remove extcon interface. - Remove DPI support. - Fix dt_binding_check complains. - Code clean up and update description. v8: Fix comments from Nicolas. - Fix several coding format. - Update description. v7: - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP .../bindings/display/bridge/analogix,anx7625.yaml | 95 + drivers/gpu/drm/bridge/analogix/Kconfig|9 + drivers/gpu/drm/bridge/analogix/Makefile |1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 1848 drivers/gpu/drm/bridge/analogix/anx7625.h | 390 + 5 files changed, 2343 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Remove depends on interconnect
The dependency on interconnect in the Kconfig was introduced to avoid the case of interconnect=m and driver=y, but the interconnect framework has been converted from tristate to bool now. Remove the dependency as the framework can't be a module anymore. Signed-off-by: Georgi Djakov --- drivers/gpu/drm/msm/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 5c55cd0ce9f9..3348969460ab 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -6,7 +6,6 @@ config DRM_MSM depends on ARCH_QCOM || SOC_IMX5 || (ARM && COMPILE_TEST) depends on OF && COMMON_CLK depends on MMU - depends on INTERCONNECT || !INTERCONNECT depends on QCOM_OCMEM || QCOM_OCMEM=n select QCOM_MDT_LOADER if ARCH_QCOM select REGULATOR ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] dss:use devm_platform_ioremap_resource_byname
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately.
Signed-off-by: Zhang Qilong
---
.../video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 10 +
.../video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 10 +
.../video/fbdev/omap2/omapfb/dss/hdmi_phy.c | 10 +
.../video/fbdev/omap2/omapfb/dss/hdmi_pll.c | 9 +---
.../video/fbdev/omap2/omapfb/dss/video-pll.c | 21 +++
5 files changed, 7 insertions(+), 53 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
index 7ca1803bf161..726c190862d4 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
@@ -875,15 +875,7 @@ void hdmi4_audio_stop(struct hdmi_core_data *core, struct
hdmi_wp_data *wp)
int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core)
{
- struct resource *res;
-
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
- if (!res) {
- DSSERR("can't get CORE mem resource\n");
- return -EINVAL;
- }
-
- core->base = devm_ioremap_resource(&pdev->dev, res);
+ core->base = devm_platform_ioremap_resource_byname(pdev, "core");
if (IS_ERR(core->base)) {
DSSERR("can't ioremap CORE\n");
return PTR_ERR(core->base);
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
index 2f6ff14a48d9..eda29d3032e1 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
@@ -887,15 +887,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct
hdmi_wp_data *wp,
int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data *core)
{
- struct resource *res;
-
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
- if (!res) {
- DSSERR("can't get CORE IORESOURCE_MEM HDMI\n");
- return -EINVAL;
- }
-
- core->base = devm_ioremap_resource(&pdev->dev, res);
+ core->base = devm_platform_ioremap_resource_byname(pdev, "core");
if (IS_ERR(core->base)) {
DSSERR("can't ioremap HDMI core\n");
return PTR_ERR(core->base);
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
index 9c645adba9e2..6fbfeb01b315 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
@@ -207,19 +207,11 @@ static const struct hdmi_phy_features
*hdmi_phy_get_features(void)
int hdmi_phy_init(struct platform_device *pdev, struct hdmi_phy_data *phy)
{
- struct resource *res;
-
phy_feat = hdmi_phy_get_features();
if (!phy_feat)
return -ENODEV;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy");
- if (!res) {
- DSSERR("can't get PHY mem resource\n");
- return -EINVAL;
- }
-
- phy->base = devm_ioremap_resource(&pdev->dev, res);
+ phy->base = devm_platform_ioremap_resource_byname(pdev, "phy");
if (IS_ERR(phy->base)) {
DSSERR("can't ioremap TX PHY\n");
return PTR_ERR(phy->base);
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
index 4991be031b0b..eb984dfe 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
@@ -220,17 +220,10 @@ int hdmi_pll_init(struct platform_device *pdev, struct
hdmi_pll_data *pll,
struct hdmi_wp_data *wp)
{
int r;
- struct resource *res;
pll->wp = wp;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pll");
- if (!res) {
- DSSERR("can't get PLL mem resource\n");
- return -EINVAL;
- }
-
- pll->base = devm_ioremap_resource(&pdev->dev, res);
+ pll->base = devm_platform_ioremap_resource_byname(pdev, "pll");
if (IS_ERR(pll->base)) {
DSSERR("can't ioremap PLLCTRL\n");
return PTR_ERR(pll->base);
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/video-pll.c
b/drivers/video/fbdev/omap2/omapfb/dss/video-pll.c
index f45fe60b9e7d..bff03d920722 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/video-pll.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/video-pll.c
@@ -129,7 +129,6 @@ struct dss_pll *dss_video_pll_init(struct platform_device
*pdev, int id,
const char * const clkctrl_name[] = { "pll1_clkctrl", "pll2_clkctrl" };
const char * const clkin_name[] = { "video1_clk", "video2_clk" };
- struct resource *res;
struct dss_video_pll *vpll;
void __iomem *pll_base, *clkctrl_base;
Re: Changing vma->vm_file in dma_buf_mmap()
On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote: > But within the driver, we generally need thousands of these, and that > tends to bring fd exhaustion problems with it. That's why all the private > buffer objects which aren't shared with other process or other drivers are > handles only valid for a specific fd instance of the drm chardev (each > open gets their own namespace), and only for ioctls done on that chardev. > And for mmap we assign fake (but unique across all open fd on it) offsets > within the overall chardev. Hence all the pgoff mangling and re-mangling. Are they still unique struct files? Just without a fdno? > Hence why we'd like to be able to forward aliasing mappings and adjust the > file and pgoff, while hopefully everything keeps working. I thought this > would work, but Christian noticed it doesn't really. It seems reasonable to me that the dma buf should be the owner of the VMA, otherwise like you say, there is a big mess attaching the custom vma ops and what not to the proper dma buf. I don't see anything obviously against this in mmap_region() - why did Chritian notice it doesn't really work? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] virtio-shm region
On Tue, Sep 15, 2020 at 04:38:04PM -0700, Gurchetan Singh wrote: > On Tue, Sep 15, 2020 at 8:27 AM Maxime Ripard wrote: > > > Hi, > > > > On Mon, Sep 14, 2020 at 04:39:41PM -0700, Gurchetan Singh wrote: > > > Hi, > > > > > > This set of changes are required for zero-copy virtio-gpu. > > > > > > The following changes since commit > > 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: > > > > > > Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) > > > > > > are available in the Git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git > > virtio-shm > > > > > > for you to fetch changes up to 38e895487afc2ed42c11045853cbb3fa20b52b6e: > > > > > > virtio: Implement get_shm_region for MMIO transport (2020-09-10 > > 10:05:58 > > > +0200) > > > > > > > > > Sebastien Boeuf (3): > > > virtio: Add get_shm_region method > > > virtio: Implement get_shm_region for PCI transport > > > virtio: Implement get_shm_region for MMIO transport > > > > > > drivers/virtio/virtio_mmio.c | 31 + > > > drivers/virtio/virtio_pci_modern.c | 95 > > > ++ > > > include/linux/virtio_config.h | 17 +++ > > > include/uapi/linux/virtio_mmio.h | 11 + > > > include/uapi/linux/virtio_pci.h| 11 - > > > 5 files changed, 164 insertions(+), 1 deletion(-) > > > > It's not really clear who you expect to pull that PR? > > > > Hmm, Daniel recommended "send[ing] the topic pull request to drm-misc > maintainers (Maarten, Maxime, Thomas)" in the other thread, but I'm not > really sure which one. Maybe whomever is in charge of drm-misc-next pull > requests? That would be me then. I've applied it (but had to hack dim a bit, it doesn't like !text email too much apparently) and pushed it to drm-misc-next. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Fix user font detection test at fbcon_resize().
On 2020/09/16 17:26, Greg KH wrote: > On Wed, Sep 16, 2020 at 09:01:06AM +0900, Tetsuo Handa wrote: >> Greg, will you pick up this patch? >> >> It seems that finding the real cause of [3] and actually fixing [3] will be >> difficult. >> Since I can't reproduce [3] locally, I will have to try flood of "#syz test" >> requests >> for debug printk() patches. > > I agree with Daniel here, can you retest these against Linus's latest > tree please? > syzbot already reproduced these bugs using the latest commit. ;-) You can find ci-upstream-kasan-gce-root2020/09/15 15:18upstream fc4f28bb record for "KASAN: global-out-of-bounds Read in bit_putcs" and ci-upstream-kasan-gce-root2020/09/16 09:54upstreamfc4f28bb record for "KASAN: global-out-of-bounds Read in fbcon_resize". ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dpu: remove unused variables new_cnt and old_cnt in dpu_encoder_phys_vid_vblank_irq()
We found two unused variables new_cnt and old_cnt when build kernel with W=1. So delete it. Signed-off-by: Luo Jiaxing --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c index b5a4905..377ce8d 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c @@ -298,7 +298,6 @@ static void dpu_encoder_phys_vid_vblank_irq(void *arg, int irq_idx) struct dpu_hw_ctl *hw_ctl; unsigned long lock_flags; u32 flush_register = 0; - int new_cnt = -1, old_cnt = -1; hw_ctl = phys_enc->hw_ctl; @@ -308,7 +307,7 @@ static void dpu_encoder_phys_vid_vblank_irq(void *arg, int irq_idx) phys_enc->parent_ops->handle_vblank_virt(phys_enc->parent, phys_enc); - old_cnt = atomic_read(&phys_enc->pending_kickoff_cnt); + atomic_read(&phys_enc->pending_kickoff_cnt); /* * only decrement the pending flush count if we've actually flushed @@ -320,8 +319,7 @@ static void dpu_encoder_phys_vid_vblank_irq(void *arg, int irq_idx) flush_register = hw_ctl->ops.get_flush_register(hw_ctl); if (!(flush_register & hw_ctl->ops.get_pending_flush(hw_ctl))) - new_cnt = atomic_add_unless(&phys_enc->pending_kickoff_cnt, - -1, 0); + atomic_add_unless(&phys_enc->pending_kickoff_cnt, -1, 0); spin_unlock_irqrestore(phys_enc->enc_spinlock, lock_flags); /* Signal any waiting atomic commit thread */ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 8/8] drm/i915: Enable async flips in i915
Enable asynchronous flips in i915 for gen9+ platforms. v2: -Async flip enablement should be a stand alone patch (Paulo) v3: -Move the patch to the end of the series (Paulo) v4: -Rebased. v5: -Rebased. v6: -Rebased. v7: -Rebased. v8: -Rebased. v9: -Rebased. Signed-off-by: Karthik B S Signed-off-by: Vandita Kulkarni --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 6f6edc581e14..e31abf5f1a9d 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -18021,6 +18021,9 @@ static void intel_mode_config_init(struct drm_i915_private *i915) mode_config->funcs = &intel_mode_funcs; + if (INTEL_GEN(i915) >= 9) + mode_config->async_page_flip = true; + /* * Maximum framebuffer dimensions, chosen to match * the maximum render engine surface size on gen4+. -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 6/8] drm/i915: WA for platforms with double buffered address update enable bit
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated before continuing
with the normal commit for sync flip.
v9: -Rename skl_toggle_async_sync() to skl_disable_async_flip_wa(). (Ville)
-Place the declarations appropriately as per need. (Ville)
-Take the lock before the reg read. (Ville)
-Fix comment and formatting. (Ville)
-Use IS_GEN_RANGE() for gen check. (Ville)
-Move skl_disable_async_flip_wa() to intel_pre_plane_update(). (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_display.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0f0bcbb00c7f..6f6edc581e14 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6562,6 +6562,43 @@ static void intel_post_plane_update(struct
intel_atomic_state *state,
icl_wa_scalerclkgating(dev_priv, pipe, false);
}
+static void skl_disable_async_flip_wa(struct intel_atomic_state *state,
+ struct intel_crtc *crtc,
+ const struct intel_crtc_state
*new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_plane *plane;
+ struct intel_plane_state *new_plane_state;
+ int i;
+
+ for_each_new_intel_plane_in_state(state, plane, new_plane_state, i) {
+ u32 update_mask = new_crtc_state->update_planes;
+ u32 plane_ctl, surf_addr;
+ enum plane_id plane_id;
+ unsigned long irqflags;
+ enum pipe pipe;
+
+ if (crtc->pipe != plane->pipe ||
+ !(update_mask & BIT(plane->id)))
+ continue;
+
+ plane_id = plane->id;
+ pipe = plane->pipe;
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+ plane_ctl = intel_de_read_fw(dev_priv, PLANE_CTL(pipe,
plane_id));
+ surf_addr = intel_de_read_fw(dev_priv, PLANE_SURF(pipe,
plane_id));
+
+ plane_ctl &= ~PLANE_CTL_ASYNC_FLIP;
+
+ intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id),
plane_ctl);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
surf_addr);
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+ }
+
+ intel_wait_for_vblank(dev_priv, crtc->pipe);
+}
+
static void intel_pre_plane_update(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
@@ -6647,6 +6684,15 @@ static void intel_pre_plane_update(struct
intel_atomic_state *state,
*/
if (IS_GEN(dev_priv, 2) && planes_disabling(old_crtc_state,
new_crtc_state))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
+
+ /*
+* WA for platforms where async address update enable bit
+* is double buffered and only latched at start of vblank.
+*/
+ if (old_crtc_state->uapi.async_flip &&
+ !new_crtc_state->uapi.async_flip &&
+ IS_GEN_RANGE(dev_priv, 9, 10))
+ skl_disable_async_flip_wa(state, crtc, new_crtc_state);
}
static void intel_crtc_disable_planes(struct intel_atomic_state *state,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/8] drm/i915: Add enable/disable flip done and flip done handler
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
Flip done handler is used to send the page flip event as soon as the
surface address is written as per the requirement of async flips.
The interrupt is disabled after the event is sent.
v2: -Change function name from icl_* to skl_* (Paulo)
-Move flip handler to this patch (Paulo)
-Remove vblank_put() (Paulo)
-Enable flip done interrupt for gen9+ only (Paulo)
-Enable flip done interrupt in power_well_post_enable hook (Paulo)
-Removed the event check in flip done handler to handle async
flips without pageflip events.
v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
-Make the pending vblank event NULL in the beginning of
flip_done_handler to remove sporadic WARN_ON that is seen.
v4: -Calculate timestamps using flip done time stamp and current
timestamp for async flips (Ville)
v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
static.(Reported-by: kernel test robot )
-Fix the typo in commit message.
v6: -Revert back to old time stamping code.
-Remove the break while calling skl_enable_flip_done. (Paulo)
v7: -Rebased.
v8: -Rebased.
v9: -Use struct drm_i915_private *i915 in new code. (Ville)
-Use intel_crtc instead of drm_crtc. (Ville)
-Do not mix the flip done and vblank hooks. (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 8 +++
drivers/gpu/drm/i915/i915_irq.c | 52
drivers/gpu/drm/i915/i915_irq.h | 3 ++
3 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f862403388f6..896f6d3cab44 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15612,6 +15612,11 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_dbuf_pre_plane_update(state);
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip)
+ skl_enable_flip_done(crtc);
+ }
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.commit_modeset_enables(state);
@@ -15633,6 +15638,9 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
drm_atomic_helper_wait_for_flip_done(dev, &state->base);
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip)
+ skl_disable_flip_done(crtc);
+
if (new_crtc_state->hw.active &&
!needs_modeset(new_crtc_state) &&
!new_crtc_state->preload_luts &&
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 759f523c6a6b..9b8796c1a256 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1245,6 +1245,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private
*dev_priv,
u32 crc4) {}
#endif
+static void flip_done_handler(struct drm_i915_private *i915,
+ enum pipe pipe)
+{
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(i915, pipe);
+ struct drm_crtc_state *crtc_state = crtc->base.state;
+ struct drm_pending_vblank_event *e = crtc_state->event;
+ struct drm_device *dev = &i915->drm;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&dev->event_lock, irqflags);
+
+ crtc_state->event = NULL;
+
+ drm_crtc_send_vblank_event(&crtc->base, e);
+
+ spin_unlock_irqrestore(&dev->event_lock, irqflags);
+}
static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
enum pipe pipe)
@@ -2329,6 +2346,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
if (iir & GEN8_PIPE_VBLANK)
intel_handle_vblank(dev_priv, pipe);
+ if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
+ flip_done_handler(dev_priv, pipe);
+
if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
hsw_pipe_crc_irq_handler(dev_priv, pipe);
@@ -2650,6 +2670,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
return 0;
}
+void skl_enable_flip_done(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&i915->irq_lock, irqflags);
+
+ bdw_enable_pip
[PATCH v9 7/8] Documentation/gpu: Add asynchronous flip documentation for i915
Add the details of the implementation of asynchronous flips for i915. v7: -Rebased. v8: -Rebased. v9: -Rebased. Signed-off-by: Karthik B S Signed-off-by: Vandita Kulkarni --- Documentation/gpu/i915.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 33cc6ddf8f64..84ead508f7ad 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -118,6 +118,12 @@ Atomic Plane Helpers .. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c :internal: +Asynchronous Page Flip +-- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c + :doc: asynchronous flip implementation + Output Probing -- -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 0/8] Asynchronous flip implementation for i915
Without async flip support in the kernel, fullscreen apps where game resolution is equal to the screen resolution, must perform an extra blit per frame prior to flipping. Asynchronous page flips will also boost the FPS of Mesa benchmarks. v2: -Few patches have been squashed and patches have been shuffled as per the reviews on the previous version. v3: -Few patches have been squashed and patches have been shuffled as per the reviews on the previous version. v4: -Made changes to fix the sequence and time stamp issue as per the comments received on the previous version. -Timestamps are calculated using the flip done time stamp and current timestamp. Here I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag is used for timestamp calculations. -Event is sent from the interrupt handler immediately using this updated timestamps and sequence. -Added more state checks as async flip should only allow change in plane surface address and nothing else should be allowed to change. -Added a separate plane hook for async flip. -Need to find a way to reject fbc enabling if it comes as part of this flip as bspec states that changes to FBC are not allowed. v5: -Fixed the Checkpatch and sparse warnings. v6: -Reverted back to the old timestamping code as per the feedback received. -Added documentation. v7: -Changes in intel_atomic_check_async() -Add vfunc for skl_program_async_surface_address() v8: -Add WA for older platforms with double buffered async address update enable bit. v9: -Changes as per feedback received on previous version. Test-with: <20200916135044.6903-1-karthik@intel.com> Karthik B S (8): drm/i915: Add enable/disable flip done and flip done handler drm/i915: Add support for async flips in I915 drm/i915: Add checks specific to async flips drm/i915: Do not call drm_crtc_arm_vblank_event in async flips drm/i915: Add dedicated plane hook for async flip case drm/i915: WA for platforms with double buffered address update enable bit Documentation/gpu: Add asynchronous flip documentation for i915 drm/i915: Enable async flips in i915 Documentation/gpu/i915.rst| 6 + .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +- drivers/gpu/drm/i915/display/intel_display.c | 197 ++ .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_sprite.c | 30 +++ drivers/gpu/drm/i915/i915_irq.c | 52 + drivers/gpu/drm/i915/i915_irq.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 1 + 8 files changed, 297 insertions(+), 1 deletion(-) -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 5/8] drm/i915: Add dedicated plane hook for async flip case
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
and call it from intel_update_plane. (Ville)
v8: -Rebased.
v9: -Use if-else instead of return in intel_update_plane(). (Ville)
-Rename 'program_async_surface_address' to 'async_flip'. (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 6 -
.../drm/i915/display/intel_display_types.h| 3 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 24 +++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 79032701873a..1171852dda5a 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -408,7 +408,11 @@ void intel_update_plane(struct intel_plane *plane,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
trace_intel_update_plane(&plane->base, crtc);
- plane->update_plane(plane, crtc_state, plane_state);
+
+ if (crtc_state->uapi.async_flip)
+ plane->async_flip(plane, crtc_state, plane_state);
+ else
+ plane->update_plane(plane, crtc_state, plane_state);
}
void intel_disable_plane(struct intel_plane *plane,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b2d0edacc58c..67e48215d89e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1190,6 +1190,9 @@ struct intel_plane {
struct intel_plane_state *plane_state);
int (*min_cdclk)(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state);
+ void (*async_flip)(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state);
};
struct intel_watermark_params {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 76a3d9bfe0de..3634e98b04c1 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -609,6 +609,29 @@ icl_program_input_csc(struct intel_plane *plane,
PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
}
+static void
+skl_program_async_surface_address(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ unsigned long irqflags;
+ enum plane_id plane_id = plane->id;
+ enum pipe pipe = plane->pipe;
+ u32 surf_addr = plane_state->color_plane[0].offset;
+ u32 plane_ctl = plane_state->ctl;
+
+ plane_ctl |= skl_plane_ctl_crtc(crtc_state);
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+
+ intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
+ intel_plane_ggtt_offset(plane_state) + surf_addr);
+
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+}
+
static void
skl_program_plane(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -3095,6 +3118,7 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
plane->get_hw_state = skl_plane_get_hw_state;
plane->check_plane = skl_plane_check;
plane->min_cdclk = skl_plane_min_cdclk;
+ plane->async_flip = skl_program_async_surface_address;
if (INTEL_GEN(dev_priv) >= 11)
formats = icl_get_plane_formats(dev_priv, pipe,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 3/8] drm/i915: Add checks specific to async flips
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3: -Removed TODO as benchmarking tests have been run now.
v4: -Added more state checks for async flip (Ville)
-Moved intel_atomic_check_async to the end of intel_atomic_check
as the plane checks needs to pass before this. (Ville)
-Removed crtc_state->enable_fbc check. (Ville)
-Set the I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag for async
flip case as scanline counter is not reliable here.
v5: -Fix typo and other check patch errors seen in CI
in 'intel_atomic_check_async' function.
v6: -Don't call intel_atomic_check_async multiple times. (Ville)
-Remove the check for n_planes in intel_atomic_check_async
-Added documentation for async flips. (Paulo)
v7: -Replace 'intel_plane' with 'plane'. (Ville)
-Replace all uapi.foo as hw.foo. (Ville)
-Do not use intel_wm_need_update function. (Ville)
-Add destination coordinate check. (Ville)
-Do not allow async flip with linear buffer
on older hw as it has issues with this. (Ville)
-Remove break after intel_atomic_check_async. (Ville)
v8: -Rebased.
v9: -Replace DRM_DEBUG_KMS with drm_dbg_kms(). (Ville)
-Fix comment formatting. (Ville)
-Remove gen specific checks. (Ville)
-Remove irrelevant FB size check. (Ville)
-Add missing stride check. (Ville)
-Use drm_rect_equals() instead of individual checks. (Ville)
-Call intel_atomic_check_async before state dump. (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_display.c | 137 +++
1 file changed, 137 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 627aeaebf94f..0f0bcbb00c7f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14882,6 +14882,137 @@ static bool intel_cpu_transcoders_need_modeset(struct
intel_atomic_state *state,
return false;
}
+/**
+ * DOC: asynchronous flip implementation
+ *
+ * Asynchronous page flip is the implementation for the
DRM_MODE_PAGE_FLIP_ASYNC
+ * flag. Currently async flip is only supported via the drmModePageFlip IOCTL.
+ * Correspondingly, support is currently added for primary plane only.
+ *
+ * Async flip can only change the plane surface address, so anything else
+ * changing is rejected from the intel_atomic_check_async() function.
+ * Once this check is cleared, flip done interrupt is enabled using
+ * the skl_enable_flip_done() function.
+ *
+ * As soon as the surface address register is written, flip done interrupt is
+ * generated and the requested events are sent to the usersapce in the
interrupt
+ * handler itself. The timestamp and sequence sent during the flip done event
+ * correspond to the last vblank and have no relation to the actual time when
+ * the flip done event was sent.
+ */
+
+static int intel_atomic_check_async(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+ struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_plane_state *new_plane_state, *old_plane_state;
+ struct intel_crtc *crtc;
+ struct intel_plane *plane;
+ int i;
+
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (needs_modeset(new_crtc_state)) {
+ drm_dbg_kms(&i915->drm, "Modeset Required. Async flip
not supported\n");
+ return -EINVAL;
+ }
+
+ if (!new_crtc_state->hw.active) {
+ drm_dbg_kms(&i915->drm, "CRTC inactive\n");
+ return -EINVAL;
+ }
+ if (old_crtc_state->active_planes !=
new_crtc_state->active_planes) {
+ drm_dbg_kms(&i915->drm,
+ "Active planes cannot be changed during
async flip\n");
+ return -EINVAL;
+ }
+ }
+
+ for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
+new_plane_state, i) {
+ /*
+* TODO: Async flip is only supported through the page flip
IOCTL
+* as of now. So support currently added for primary plane only.
+* Support for other planes on platforms on which supports
+* this(vlv/chv and icl+) should be added when async flip is
+* enabled in the atomic IOCTL path.
+*/
+ if (plane->id != PLANE_PRIMARY)
+ return -EINVAL;
+
+
[PATCH v9 4/8] drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
Since the flip done event will be sent in the flip_done_handler, no need to add the event to the list and delay it for later. v2: -Moved the async check above vblank_get as it was causing issues for PSR. v3: -No need to wait for vblank to pass, as this wait was causing a 16ms delay once every few flips. v4: -Rebased. v5: -Rebased. v6: -Rebased. v7: -No need of irq disable if we are not doing vblank evade. (Ville) v8: -Rebased. v9: -Move the return in intel_pipe_update_end before tracepoint. (Ville) Signed-off-by: Karthik B S Signed-off-by: Vandita Kulkarni Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c index 63040cb0d4e1..76a3d9bfe0de 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.c +++ b/drivers/gpu/drm/i915/display/intel_sprite.c @@ -93,6 +93,9 @@ void intel_pipe_update_start(const struct intel_crtc_state *new_crtc_state) DEFINE_WAIT(wait); u32 psr_status; + if (new_crtc_state->uapi.async_flip) + return; + vblank_start = adjusted_mode->crtc_vblank_start; if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) vblank_start = DIV_ROUND_UP(vblank_start, 2); @@ -200,6 +203,9 @@ void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state) ktime_t end_vbl_time = ktime_get(); struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + if (new_crtc_state->uapi.async_flip) + return; + trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end); /* We're still in the vblank-evade critical section, this can't race. -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/8] drm/i915: Add support for async flips in I915
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
v6: -Move the plane hook to separate patch. (Paulo)
-Remove the early return in skl_plane_ctl. (Paulo)
v7: -Move async address update enable to skl_plane_ctl_crtc() (Ville)
v8: -Rebased.
v9: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 896f6d3cab44..627aeaebf94f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4785,6 +4785,9 @@ u32 skl_plane_ctl_crtc(const struct intel_crtc_state
*crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
u32 plane_ctl = 0;
+ if (crtc_state->uapi.async_flip)
+ plane_ctl |= PLANE_CTL_ASYNC_FLIP;
+
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
return plane_ctl;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d805d4da6181..e94ca1f8f6b2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6923,6 +6923,7 @@ enum {
#define PLANE_CTL_TILED_X(1 << 10)
#define PLANE_CTL_TILED_Y(4 << 10)
#define PLANE_CTL_TILED_YF (5 << 10)
+#define PLANE_CTL_ASYNC_FLIP (1 << 9)
#define PLANE_CTL_FLIP_HORIZONTAL(1 << 8)
#define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
#define PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
