Re: [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition
On 10/06/2022 11:53, Matthew Brost wrote:
On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
1 file changed, 490 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See &drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE 0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
+ * Also, on those platforms, it is not allowed to bind an device local-memory
+ * object and a system memory object in a single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @queue_idx: Index of queue for binding */
+ __u32 queue_idx;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to bind */
+ __u64 length;
This probably isn't needed. We are never going to unbind a subset of a
VMA are we? That being said it can't hurt as a sanity check (e.g.
internal vma->le
RE: [PATCH] drm/ttm: fix bulk move handling v2
[AMD Official Use Only - General]
Hi Christian,
I verified the patch, I don’t see the crashes.
Reviewed-by: Arunpravin Paneer Selvam
Thanks,
Arun
-Original Message-
From: Christian König
Sent: Monday, June 13, 2022 1:38 PM
To: Paneer Selvam, Arunpravin ;
m...@fireburn.co.uk; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian ; Tuikov, Luben
Subject: [PATCH] drm/ttm: fix bulk move handling v2
The resource must be on the LRU before ttm_lru_bulk_move_add() is called and we
need to check if the BO is pinned or not before adding it.
Additional to that we missed taking the LRU spinlock in ttm_bo_unpin().
Signed-off-by: Christian König
Acked-by: Luben Tuikov
---
drivers/gpu/drm/ttm/ttm_bo.c | 22 -
drivers/gpu/drm/ttm/ttm_resource.c | 52 +-
include/drm/ttm/ttm_resource.h | 8 ++---
3 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index
296af2b89951..0e210df65c30 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -103,11 +103,11 @@ void ttm_bo_set_bulk_move(struct ttm_buffer_object *bo,
return;
spin_lock(&bo->bdev->lru_lock);
- if (bo->bulk_move && bo->resource)
- ttm_lru_bulk_move_del(bo->bulk_move, bo->resource);
+ if (bo->resource)
+ ttm_resource_del_bulk_move(bo->resource, bo);
bo->bulk_move = bulk;
- if (bo->bulk_move && bo->resource)
- ttm_lru_bulk_move_add(bo->bulk_move, bo->resource);
+ if (bo->resource)
+ ttm_resource_add_bulk_move(bo->resource, bo);
spin_unlock(&bo->bdev->lru_lock);
}
EXPORT_SYMBOL(ttm_bo_set_bulk_move);
@@ -683,8 +683,11 @@ void ttm_bo_pin(struct ttm_buffer_object *bo) {
dma_resv_assert_held(bo->base.resv);
WARN_ON_ONCE(!kref_read(&bo->kref));
- if (!(bo->pin_count++) && bo->bulk_move && bo->resource)
- ttm_lru_bulk_move_del(bo->bulk_move, bo->resource);
+ spin_lock(&bo->bdev->lru_lock);
+ if (bo->resource)
+ ttm_resource_del_bulk_move(bo->resource, bo);
+ ++bo->pin_count;
+ spin_unlock(&bo->bdev->lru_lock);
}
EXPORT_SYMBOL(ttm_bo_pin);
@@ -701,8 +704,11 @@ void ttm_bo_unpin(struct ttm_buffer_object *bo)
if (WARN_ON_ONCE(!bo->pin_count))
return;
- if (!(--bo->pin_count) && bo->bulk_move && bo->resource)
- ttm_lru_bulk_move_add(bo->bulk_move, bo->resource);
+ spin_lock(&bo->bdev->lru_lock);
+ --bo->pin_count;
+ if (bo->resource)
+ ttm_resource_add_bulk_move(bo->resource, bo);
+ spin_unlock(&bo->bdev->lru_lock);
}
EXPORT_SYMBOL(ttm_bo_unpin);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 65889b3caf50..20f9adcc3235 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -91,8 +91,8 @@ static void ttm_lru_bulk_move_pos_tail(struct
ttm_lru_bulk_move_pos *pos, }
/* Add the resource to a bulk_move cursor */ -void
ttm_lru_bulk_move_add(struct ttm_lru_bulk_move *bulk,
- struct ttm_resource *res)
+static void ttm_lru_bulk_move_add(struct ttm_lru_bulk_move *bulk,
+ struct ttm_resource *res)
{
struct ttm_lru_bulk_move_pos *pos = ttm_lru_bulk_move_pos(bulk, res);
@@ -105,8 +105,8 @@ void ttm_lru_bulk_move_add(struct ttm_lru_bulk_move *bulk,
}
/* Remove the resource from a bulk_move range */ -void
ttm_lru_bulk_move_del(struct ttm_lru_bulk_move *bulk,
- struct ttm_resource *res)
+static void ttm_lru_bulk_move_del(struct ttm_lru_bulk_move *bulk,
+ struct ttm_resource *res)
{
struct ttm_lru_bulk_move_pos *pos = ttm_lru_bulk_move_pos(bulk, res);
@@ -122,6 +122,22 @@ void ttm_lru_bulk_move_del(struct ttm_lru_bulk_move *bulk,
}
}
+/* Add the resource to a bulk move if the BO is configured for it */
+void ttm_resource_add_bulk_move(struct ttm_resource *res,
+ struct ttm_buffer_object *bo)
+{
+ if (bo->bulk_move && !bo->pin_count)
+ ttm_lru_bulk_move_add(bo->bulk_move, res); }
+
+/* Remove the resource from a bulk move if the BO is configured for it
+*/ void ttm_resource_del_bulk_move(struct ttm_resource *res,
+ struct ttm_buffer_object *bo)
+{
+ if (bo->bulk_move && !bo->pin_count)
+ ttm_lru_bulk_move_del(bo->bulk_move, res); }
+
/* Move a resource to the LRU or bulk tail */ void
ttm_resource_move_to_lru_tail(struct ttm_resource *res) { @@ -169,15 +185,14
@@ void ttm_resource_init(struct ttm_buffer_object *bo,
res->bus.is_iomem = false;
res->bus.caching = ttm_cached;
res->bo = bo;
- INIT_LIST_HEAD(&res->lru);
man = ttm_manager_
[Bug 216120] [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=216120 --- Comment #3 from mat2003...@gmail.com --- same bad commit: https://gitlab.freedesktop.org/drm/amd/-/issues/2050 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH AUTOSEL 5.15 13/41] drm/amdkfd: add pinned BOs to kfd_bo_list
From: Lang Yu
[ Upstream commit 4fac4fcf4500bce515b0f32195e7bb86aa0246c6 ]
The kfd_bo_list is used to restore process BOs after
evictions. As page tables could be destroyed during
evictions, we should also update pinned BOs' page tables
during restoring to make sure they are valid.
So for pinned BOs,
1, Validate them and update their page tables.
2, Don't add eviction fence for them.
v2:
- Don't handle pinned ones specially in BO validation.(Felix)
Signed-off-by: Lang Yu
Acked-by: Christian König
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index ab36cce59d2e..21c02f817a84 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1828,9 +1828,6 @@ int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct
kgd_dev *kgd,
return -EINVAL;
}
- /* delete kgd_mem from kfd_bo_list to avoid re-validating
-* this BO in BO's restoring after eviction.
-*/
mutex_lock(&mem->process_info->lock);
ret = amdgpu_bo_reserve(bo, true);
@@ -1853,7 +1850,6 @@ int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct
kgd_dev *kgd,
amdgpu_amdkfd_remove_eviction_fence(
bo, mem->process_info->eviction_fence);
- list_del_init(&mem->validate_list.head);
if (size)
*size = amdgpu_bo_size(bo);
@@ -2399,12 +2395,15 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
process_info->eviction_fence = new_fence;
*ef = dma_fence_get(&new_fence->base);
- /* Attach new eviction fence to all BOs */
+ /* Attach new eviction fence to all BOs except pinned ones */
list_for_each_entry(mem, &process_info->kfd_bo_list,
- validate_list.head)
+ validate_list.head) {
+ if (mem->bo->tbo.pin_count)
+ continue;
+
amdgpu_bo_fence(mem->bo,
&process_info->eviction_fence->base, true);
-
+ }
/* Attach eviction fence to PD / PT BOs */
list_for_each_entry(peer_vm, &process_info->vm_list_head,
vm_list_node) {
--
2.35.1
[PATCH AUTOSEL 5.15 05/41] drm/amdkfd: Use mmget_not_zero in MMU notifier
From: Philip Yang [ Upstream commit fa582c6f3684ac0098a9d02ddf0ed52a02b37127 ] MMU notifier callback may pass in mm with mm->mm_users==0 when process is exiting, use mmget_no_zero to avoid accessing invalid mm in deferred list work after mm is gone. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c index 830809b694dd..74e6f613be02 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c @@ -2181,6 +2181,8 @@ svm_range_cpu_invalidate_pagetables(struct mmu_interval_notifier *mni, if (range->event == MMU_NOTIFY_RELEASE) return true; + if (!mmget_not_zero(mni->mm)) + return true; start = mni->interval_tree.start; last = mni->interval_tree.last; @@ -2207,6 +2209,7 @@ svm_range_cpu_invalidate_pagetables(struct mmu_interval_notifier *mni, } svm_range_unlock(prange); + mmput(mni->mm); return true; } -- 2.35.1
[PATCH AUTOSEL 5.15 04/41] drm/amd/display: Fix DMUB outbox trace in S4 (#4465)
From: "Hung, Cruise"
[ Upstream commit 6ecf9773a5030aa4932096754bacff20e1b944b8 ]
[Why]
DMUB Outbox0 read/write pointer not sync after resumed from S4.
And that caused old traces were sent to outbox.
[How]
Disable DMUB Outbox0 interrupt
and clear DMUB Outbox0 read/write pointer when resumes from S4.
And then enable Outbox0 interrupt before starts DMCUB.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Jasdeep Dhillon
Tested-by: Daniel Wheeler
Signed-off-by: Cruise Hung
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c | 61 +--
.../gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 2 +
2 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
index 696c9307715d..f0dc680377be 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
@@ -111,12 +111,10 @@ void dccg31_set_physymclk(
/* Controls the generation of pixel valid for OTG in (OTG -> HPO case) */
void dccg31_set_dtbclk_dto(
struct dccg *dccg,
- int dtbclk_inst,
- int req_dtbclk_khz,
- int num_odm_segments,
- const struct dc_crtc_timing *timing)
+ struct dtbclk_dto_params *params)
{
struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg);
+ int req_dtbclk_khz = params->pixclk_khz;
uint32_t dtbdto_div;
/* Mode DTBDTO Rate DTBCLK_DTO_DIV Register
@@ -127,57 +125,56 @@ void dccg31_set_dtbclk_dto(
* DSC native 4:2:2 pixel rate/2 4
* Other modes pixel rate8
*/
- if (num_odm_segments == 4) {
+ if (params->num_odm_segments == 4) {
dtbdto_div = 2;
- req_dtbclk_khz = req_dtbclk_khz / 4;
- } else if ((num_odm_segments == 2) ||
- (timing->pixel_encoding == PIXEL_ENCODING_YCBCR420) ||
- (timing->flags.DSC && timing->pixel_encoding ==
PIXEL_ENCODING_YCBCR422
- && !timing->dsc_cfg.ycbcr422_simple)) {
+ req_dtbclk_khz = params->pixclk_khz / 4;
+ } else if ((params->num_odm_segments == 2) ||
+ (params->timing->pixel_encoding ==
PIXEL_ENCODING_YCBCR420) ||
+ (params->timing->flags.DSC &&
params->timing->pixel_encoding == PIXEL_ENCODING_YCBCR422
+ &&
!params->timing->dsc_cfg.ycbcr422_simple)) {
dtbdto_div = 4;
- req_dtbclk_khz = req_dtbclk_khz / 2;
+ req_dtbclk_khz = params->pixclk_khz / 2;
} else
dtbdto_div = 8;
- if (dccg->ref_dtbclk_khz && req_dtbclk_khz) {
+ if (params->ref_dtbclk_khz && req_dtbclk_khz) {
uint32_t modulo, phase;
// phase / modulo = dtbclk / dtbclk ref
- modulo = dccg->ref_dtbclk_khz * 1000;
- phase = div_u64unsigned long long)modulo * req_dtbclk_khz)
+ dccg->ref_dtbclk_khz - 1),
- dccg->ref_dtbclk_khz);
+ modulo = params->ref_dtbclk_khz * 1000;
+ phase = div_u64unsigned long long)modulo * req_dtbclk_khz)
+ params->ref_dtbclk_khz - 1),
+ params->ref_dtbclk_khz);
- REG_UPDATE(OTG_PIXEL_RATE_CNTL[dtbclk_inst],
- DTBCLK_DTO_DIV[dtbclk_inst], dtbdto_div);
+ REG_UPDATE(OTG_PIXEL_RATE_CNTL[params->otg_inst],
+ DTBCLK_DTO_DIV[params->otg_inst], dtbdto_div);
- REG_WRITE(DTBCLK_DTO_MODULO[dtbclk_inst], modulo);
- REG_WRITE(DTBCLK_DTO_PHASE[dtbclk_inst], phase);
+ REG_WRITE(DTBCLK_DTO_MODULO[params->otg_inst], modulo);
+ REG_WRITE(DTBCLK_DTO_PHASE[params->otg_inst], phase);
- REG_UPDATE(OTG_PIXEL_RATE_CNTL[dtbclk_inst],
- DTBCLK_DTO_ENABLE[dtbclk_inst], 1);
+ REG_UPDATE(OTG_PIXEL_RATE_CNTL[params->otg_inst],
+ DTBCLK_DTO_ENABLE[params->otg_inst], 1);
- REG_WAIT(OTG_PIXEL_RATE_CNTL[dtbclk_inst],
- DTBCLKDTO_ENABLE_STATUS[dtbclk_inst], 1,
+ REG_WAIT(OTG_PIXEL_RATE_CNTL[params->otg_inst],
+ DTBCLKDTO_ENABLE_STATUS[params->otg_inst], 1,
1, 100);
/* The recommended programming sequence to enable DTBCLK DTO to
generate
* valid pixel HPO DPSTREAM ENCODER, specifies that DTO source
select should
* be set only after DTO is enabled
*/
- REG_UPDATE(OTG_PIXEL_RATE_CNTL[dtbclk_inst],
- PIPE_DTO_SRC_SEL[dtbclk_inst], 1);
-
-
[PATCH AUTOSEL 5.15 03/41] drm/amd/display: Read Golden Settings Table from VBIOS
From: Sherry Wang [ Upstream commit 4b81dd2cc6f4f4e8cea0ed6ee8d5193a8ae14a72 ] [Why] Dmub read AUX_DPHY_RX_CONTROL0 from Golden Setting Table, but driver will set it to default value 0x103d1110, which causes issue in some case [How] Remove the driver code, use the value set by dmub in dp_aux_init Reviewed-by: Nicholas Kazlauskas Acked-by: Jasdeep Dhillon Tested-by: Daniel Wheeler Signed-off-by: Sherry Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c index b0892443fbd5..c7c27a605f15 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c +++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c @@ -168,9 +168,7 @@ void enc31_hw_init(struct link_encoder *enc) AUX_RX_PHASE_DETECT_LEN, [21,20] = 0x3 default is 3 AUX_RX_DETECTION_THRESHOLD [30:28] = 1 */ - AUX_REG_WRITE(AUX_DPHY_RX_CONTROL0, 0x103d1110); - - AUX_REG_WRITE(AUX_DPHY_TX_CONTROL, 0x21c7a); + // dmub will read AUX_DPHY_RX_CONTROL0/AUX_DPHY_TX_CONTROL from vbios table in dp_aux_init //AUX_DPHY_TX_REF_CONTROL'AUX_TX_REF_DIV HW default is 0x32; // Set AUX_TX_REF_DIV Divider to generate 2 MHz reference from refclk -- 2.35.1
[PATCH AUTOSEL 5.17 13/43] drm/amdkfd: add pinned BOs to kfd_bo_list
From: Lang Yu
[ Upstream commit 4fac4fcf4500bce515b0f32195e7bb86aa0246c6 ]
The kfd_bo_list is used to restore process BOs after
evictions. As page tables could be destroyed during
evictions, we should also update pinned BOs' page tables
during restoring to make sure they are valid.
So for pinned BOs,
1, Validate them and update their page tables.
2, Don't add eviction fence for them.
v2:
- Don't handle pinned ones specially in BO validation.(Felix)
Signed-off-by: Lang Yu
Acked-by: Christian König
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 5df387c4d7fb..e6b88642d6c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1912,9 +1912,6 @@ int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct
amdgpu_device *adev,
return -EINVAL;
}
- /* delete kgd_mem from kfd_bo_list to avoid re-validating
-* this BO in BO's restoring after eviction.
-*/
mutex_lock(&mem->process_info->lock);
ret = amdgpu_bo_reserve(bo, true);
@@ -1937,7 +1934,6 @@ int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct
amdgpu_device *adev,
amdgpu_amdkfd_remove_eviction_fence(
bo, mem->process_info->eviction_fence);
- list_del_init(&mem->validate_list.head);
if (size)
*size = amdgpu_bo_size(bo);
@@ -2497,12 +2493,15 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
process_info->eviction_fence = new_fence;
*ef = dma_fence_get(&new_fence->base);
- /* Attach new eviction fence to all BOs */
+ /* Attach new eviction fence to all BOs except pinned ones */
list_for_each_entry(mem, &process_info->kfd_bo_list,
- validate_list.head)
+ validate_list.head) {
+ if (mem->bo->tbo.pin_count)
+ continue;
+
amdgpu_bo_fence(mem->bo,
&process_info->eviction_fence->base, true);
-
+ }
/* Attach eviction fence to PD / PT BOs */
list_for_each_entry(peer_vm, &process_info->vm_list_head,
vm_list_node) {
--
2.35.1
[PATCH AUTOSEL 5.17 04/43] drm/amd/display: Fix DMUB outbox trace in S4 (#4465)
From: "Hung, Cruise"
[ Upstream commit 6ecf9773a5030aa4932096754bacff20e1b944b8 ]
[Why]
DMUB Outbox0 read/write pointer not sync after resumed from S4.
And that caused old traces were sent to outbox.
[How]
Disable DMUB Outbox0 interrupt
and clear DMUB Outbox0 read/write pointer when resumes from S4.
And then enable Outbox0 interrupt before starts DMCUB.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Jasdeep Dhillon
Tested-by: Daniel Wheeler
Signed-off-by: Cruise Hung
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c | 61 +--
.../gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 2 +
2 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
index ea4f8e06b07c..036cf4ebd9c8 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c
@@ -464,12 +464,10 @@ void dccg31_set_physymclk(
/* Controls the generation of pixel valid for OTG in (OTG -> HPO case) */
static void dccg31_set_dtbclk_dto(
struct dccg *dccg,
- int dtbclk_inst,
- int req_dtbclk_khz,
- int num_odm_segments,
- const struct dc_crtc_timing *timing)
+ struct dtbclk_dto_params *params)
{
struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg);
+ int req_dtbclk_khz = params->pixclk_khz;
uint32_t dtbdto_div;
/* Mode DTBDTO Rate DTBCLK_DTO_DIV Register
@@ -480,57 +478,56 @@ static void dccg31_set_dtbclk_dto(
* DSC native 4:2:2 pixel rate/2 4
* Other modes pixel rate8
*/
- if (num_odm_segments == 4) {
+ if (params->num_odm_segments == 4) {
dtbdto_div = 2;
- req_dtbclk_khz = req_dtbclk_khz / 4;
- } else if ((num_odm_segments == 2) ||
- (timing->pixel_encoding == PIXEL_ENCODING_YCBCR420) ||
- (timing->flags.DSC && timing->pixel_encoding ==
PIXEL_ENCODING_YCBCR422
- && !timing->dsc_cfg.ycbcr422_simple)) {
+ req_dtbclk_khz = params->pixclk_khz / 4;
+ } else if ((params->num_odm_segments == 2) ||
+ (params->timing->pixel_encoding ==
PIXEL_ENCODING_YCBCR420) ||
+ (params->timing->flags.DSC &&
params->timing->pixel_encoding == PIXEL_ENCODING_YCBCR422
+ &&
!params->timing->dsc_cfg.ycbcr422_simple)) {
dtbdto_div = 4;
- req_dtbclk_khz = req_dtbclk_khz / 2;
+ req_dtbclk_khz = params->pixclk_khz / 2;
} else
dtbdto_div = 8;
- if (dccg->ref_dtbclk_khz && req_dtbclk_khz) {
+ if (params->ref_dtbclk_khz && req_dtbclk_khz) {
uint32_t modulo, phase;
// phase / modulo = dtbclk / dtbclk ref
- modulo = dccg->ref_dtbclk_khz * 1000;
- phase = div_u64unsigned long long)modulo * req_dtbclk_khz)
+ dccg->ref_dtbclk_khz - 1),
- dccg->ref_dtbclk_khz);
+ modulo = params->ref_dtbclk_khz * 1000;
+ phase = div_u64unsigned long long)modulo * req_dtbclk_khz)
+ params->ref_dtbclk_khz - 1),
+ params->ref_dtbclk_khz);
- REG_UPDATE(OTG_PIXEL_RATE_CNTL[dtbclk_inst],
- DTBCLK_DTO_DIV[dtbclk_inst], dtbdto_div);
+ REG_UPDATE(OTG_PIXEL_RATE_CNTL[params->otg_inst],
+ DTBCLK_DTO_DIV[params->otg_inst], dtbdto_div);
- REG_WRITE(DTBCLK_DTO_MODULO[dtbclk_inst], modulo);
- REG_WRITE(DTBCLK_DTO_PHASE[dtbclk_inst], phase);
+ REG_WRITE(DTBCLK_DTO_MODULO[params->otg_inst], modulo);
+ REG_WRITE(DTBCLK_DTO_PHASE[params->otg_inst], phase);
- REG_UPDATE(OTG_PIXEL_RATE_CNTL[dtbclk_inst],
- DTBCLK_DTO_ENABLE[dtbclk_inst], 1);
+ REG_UPDATE(OTG_PIXEL_RATE_CNTL[params->otg_inst],
+ DTBCLK_DTO_ENABLE[params->otg_inst], 1);
- REG_WAIT(OTG_PIXEL_RATE_CNTL[dtbclk_inst],
- DTBCLKDTO_ENABLE_STATUS[dtbclk_inst], 1,
+ REG_WAIT(OTG_PIXEL_RATE_CNTL[params->otg_inst],
+ DTBCLKDTO_ENABLE_STATUS[params->otg_inst], 1,
1, 100);
/* The recommended programming sequence to enable DTBCLK DTO to
generate
* valid pixel HPO DPSTREAM ENCODER, specifies that DTO source
select should
* be set only after DTO is enabled
*/
- REG_UPDATE(OTG_PIXEL_RATE_CNTL[dtbclk_inst],
- PIPE_DTO_SRC_SEL[dtbclk_i
[PATCH AUTOSEL 5.17 05/43] drm/amdkfd: Use mmget_not_zero in MMU notifier
From: Philip Yang [ Upstream commit fa582c6f3684ac0098a9d02ddf0ed52a02b37127 ] MMU notifier callback may pass in mm with mm->mm_users==0 when process is exiting, use mmget_no_zero to avoid accessing invalid mm in deferred list work after mm is gone. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c index ffec25e642e2..ace8f84918b3 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c @@ -2281,6 +2281,8 @@ svm_range_cpu_invalidate_pagetables(struct mmu_interval_notifier *mni, if (range->event == MMU_NOTIFY_RELEASE) return true; + if (!mmget_not_zero(mni->mm)) + return true; start = mni->interval_tree.start; last = mni->interval_tree.last; @@ -2307,6 +2309,7 @@ svm_range_cpu_invalidate_pagetables(struct mmu_interval_notifier *mni, } svm_range_unlock(prange); + mmput(mni->mm); return true; } -- 2.35.1
[PATCH AUTOSEL 5.17 03/43] drm/amd/display: Read Golden Settings Table from VBIOS
From: Sherry Wang [ Upstream commit 4b81dd2cc6f4f4e8cea0ed6ee8d5193a8ae14a72 ] [Why] Dmub read AUX_DPHY_RX_CONTROL0 from Golden Setting Table, but driver will set it to default value 0x103d1110, which causes issue in some case [How] Remove the driver code, use the value set by dmub in dp_aux_init Reviewed-by: Nicholas Kazlauskas Acked-by: Jasdeep Dhillon Tested-by: Daniel Wheeler Signed-off-by: Sherry Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c index 8b9b1a5309ba..0190a90260e9 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c +++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c @@ -230,9 +230,7 @@ static void enc31_hw_init(struct link_encoder *enc) AUX_RX_PHASE_DETECT_LEN, [21,20] = 0x3 default is 3 AUX_RX_DETECTION_THRESHOLD [30:28] = 1 */ - AUX_REG_WRITE(AUX_DPHY_RX_CONTROL0, 0x103d1110); - - AUX_REG_WRITE(AUX_DPHY_TX_CONTROL, 0x21c7a); + // dmub will read AUX_DPHY_RX_CONTROL0/AUX_DPHY_TX_CONTROL from vbios table in dp_aux_init //AUX_DPHY_TX_REF_CONTROL'AUX_TX_REF_DIV HW default is 0x32; // Set AUX_TX_REF_DIV Divider to generate 2 MHz reference from refclk -- 2.35.1
[PATCH AUTOSEL 5.18 15/47] drm/amdkfd: add pinned BOs to kfd_bo_list
From: Lang Yu
[ Upstream commit 4fac4fcf4500bce515b0f32195e7bb86aa0246c6 ]
The kfd_bo_list is used to restore process BOs after
evictions. As page tables could be destroyed during
evictions, we should also update pinned BOs' page tables
during restoring to make sure they are valid.
So for pinned BOs,
1, Validate them and update their page tables.
2, Don't add eviction fence for them.
v2:
- Don't handle pinned ones specially in BO validation.(Felix)
Signed-off-by: Lang Yu
Acked-by: Christian König
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index cd89d2e46852..f4509656ea8c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1955,9 +1955,6 @@ int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct
amdgpu_device *adev,
return -EINVAL;
}
- /* delete kgd_mem from kfd_bo_list to avoid re-validating
-* this BO in BO's restoring after eviction.
-*/
mutex_lock(&mem->process_info->lock);
ret = amdgpu_bo_reserve(bo, true);
@@ -1980,7 +1977,6 @@ int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct
amdgpu_device *adev,
amdgpu_amdkfd_remove_eviction_fence(
bo, mem->process_info->eviction_fence);
- list_del_init(&mem->validate_list.head);
if (size)
*size = amdgpu_bo_size(bo);
@@ -2544,12 +2540,15 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
process_info->eviction_fence = new_fence;
*ef = dma_fence_get(&new_fence->base);
- /* Attach new eviction fence to all BOs */
+ /* Attach new eviction fence to all BOs except pinned ones */
list_for_each_entry(mem, &process_info->kfd_bo_list,
- validate_list.head)
+ validate_list.head) {
+ if (mem->bo->tbo.pin_count)
+ continue;
+
amdgpu_bo_fence(mem->bo,
&process_info->eviction_fence->base, true);
-
+ }
/* Attach eviction fence to PD / PT BOs */
list_for_each_entry(peer_vm, &process_info->vm_list_head,
vm_list_node) {
--
2.35.1
[PATCH AUTOSEL 5.18 06/47] drm/amdkfd: Use mmget_not_zero in MMU notifier
From: Philip Yang [ Upstream commit fa582c6f3684ac0098a9d02ddf0ed52a02b37127 ] MMU notifier callback may pass in mm with mm->mm_users==0 when process is exiting, use mmget_no_zero to avoid accessing invalid mm in deferred list work after mm is gone. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c index 3b8856b4cece..5979335d7afd 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c @@ -2286,6 +2286,8 @@ svm_range_cpu_invalidate_pagetables(struct mmu_interval_notifier *mni, if (range->event == MMU_NOTIFY_RELEASE) return true; + if (!mmget_not_zero(mni->mm)) + return true; start = mni->interval_tree.start; last = mni->interval_tree.last; @@ -2312,6 +2314,7 @@ svm_range_cpu_invalidate_pagetables(struct mmu_interval_notifier *mni, } svm_range_unlock(prange); + mmput(mni->mm); return true; } -- 2.35.1
[PATCH AUTOSEL 5.18 05/47] drm/amdgpu: Resolve RAS GFX error count issue after cold boot on Arcturus
From: Candice Li
[ Upstream commit 2a460963350ec6b1534d28d7f943b5f84815aff2 ]
Adjust the sequence for ras late init and separate ras reset error status
from query status.
v2: squash in fix from Candice
Signed-off-by: Candice Li
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 9 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 27 -
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 28a736c507bb..bd3b32e5ba9e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -625,17 +625,20 @@ int amdgpu_get_gfx_off_status(struct amdgpu_device *adev,
uint32_t *value)
int amdgpu_gfx_ras_late_init(struct amdgpu_device *adev, struct ras_common_if
*ras_block)
{
int r;
- r = amdgpu_ras_block_late_init(adev, ras_block);
- if (r)
- return r;
if (amdgpu_ras_is_supported(adev, ras_block->block)) {
if (!amdgpu_persistent_edc_harvesting_supported(adev))
amdgpu_ras_reset_error_status(adev,
AMDGPU_RAS_BLOCK__GFX);
+ r = amdgpu_ras_block_late_init(adev, ras_block);
+ if (r)
+ return r;
+
r = amdgpu_irq_get(adev, &adev->gfx.cp_ecc_error_irq, 0);
if (r)
goto late_fini;
+ } else {
+ amdgpu_ras_feature_enable_on_boot(adev, ras_block, 0);
}
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 424c22a841f4..3f96dadf2698 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -195,6 +195,13 @@ static ssize_t amdgpu_ras_debugfs_read(struct file *f,
char __user *buf,
if (amdgpu_ras_query_error_status(obj->adev, &info))
return -EINVAL;
+ /* Hardware counter will be reset automatically after the query on
Vega20 and Arcturus */
+ if (obj->adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 2) &&
+ obj->adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 4)) {
+ if (amdgpu_ras_reset_error_status(obj->adev, info.head.block))
+ dev_warn(obj->adev->dev, "Failed to reset error counter
and error status");
+ }
+
s = snprintf(val, sizeof(val), "%s: %lu\n%s: %lu\n",
"ue", info.ue_count,
"ce", info.ce_count);
@@ -548,9 +555,10 @@ static ssize_t amdgpu_ras_sysfs_read(struct device *dev,
if (amdgpu_ras_query_error_status(obj->adev, &info))
return -EINVAL;
- if (obj->adev->asic_type == CHIP_ALDEBARAN) {
+ if (obj->adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 2) &&
+ obj->adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 4)) {
if (amdgpu_ras_reset_error_status(obj->adev, info.head.block))
- DRM_WARN("Failed to reset error counter and error
status");
+ dev_warn(obj->adev->dev, "Failed to reset error counter
and error status");
}
return sysfs_emit(buf, "%s: %lu\n%s: %lu\n", "ue", info.ue_count,
@@ -1023,9 +1031,6 @@ int amdgpu_ras_query_error_status(struct amdgpu_device
*adev,
}
}
- if (!amdgpu_persistent_edc_harvesting_supported(adev))
- amdgpu_ras_reset_error_status(adev, info->head.block);
-
return 0;
}
@@ -1145,6 +1150,12 @@ int amdgpu_ras_query_error_count(struct amdgpu_device
*adev,
if (res)
return res;
+ if (adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 2) &&
+ adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 4)) {
+ if (amdgpu_ras_reset_error_status(adev,
info.head.block))
+ dev_warn(adev->dev, "Failed to reset error
counter and error status");
+ }
+
ce += info.ce_count;
ue += info.ue_count;
}
@@ -1705,6 +1716,12 @@ static void amdgpu_ras_log_on_err_counter(struct
amdgpu_device *adev)
continue;
amdgpu_ras_query_error_status(adev, &info);
+
+ if (adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 2) &&
+ adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 4)) {
+ if (amdgpu_ras_reset_error_status(adev,
info.head.block))
+ dev_warn(adev->dev, "Failed to reset error
counter and error status");
+ }
}
}
--
2.35.1
[PATCH AUTOSEL 5.18 04/47] drm/amd/display: Read Golden Settings Table from VBIOS
From: Sherry Wang [ Upstream commit 4b81dd2cc6f4f4e8cea0ed6ee8d5193a8ae14a72 ] [Why] Dmub read AUX_DPHY_RX_CONTROL0 from Golden Setting Table, but driver will set it to default value 0x103d1110, which causes issue in some case [How] Remove the driver code, use the value set by dmub in dp_aux_init Reviewed-by: Nicholas Kazlauskas Acked-by: Jasdeep Dhillon Tested-by: Daniel Wheeler Signed-off-by: Sherry Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c index d94fd1010deb..8b12b4111c88 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c +++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c @@ -230,9 +230,7 @@ static void enc31_hw_init(struct link_encoder *enc) AUX_RX_PHASE_DETECT_LEN, [21,20] = 0x3 default is 3 AUX_RX_DETECTION_THRESHOLD [30:28] = 1 */ - AUX_REG_WRITE(AUX_DPHY_RX_CONTROL0, 0x103d1110); - - AUX_REG_WRITE(AUX_DPHY_TX_CONTROL, 0x21c7a); + // dmub will read AUX_DPHY_RX_CONTROL0/AUX_DPHY_TX_CONTROL from vbios table in dp_aux_init //AUX_DPHY_TX_REF_CONTROL'AUX_TX_REF_DIV HW default is 0x32; // Set AUX_TX_REF_DIV Divider to generate 2 MHz reference from refclk -- 2.35.1
Re: [PATCH 7/8] drm: Remove linux/media-bus-format.h from drm_crtc.h
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20220610]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next v5.19-rc2 v5.19-rc1 v5.18 v5.19-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Ville-Syrjala/drm-Clean-up-drm_crtc-h/20220614-040443
base:6d0c806803170f120f8cb97b321de7bd89d3a791
config: arm64-randconfig-r004-20220613
(https://download.01.org/0day-ci/archive/20220614/202206140805.ebeq2f87-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
d378268ead93c85803c270277f0243737b536ae7)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/intel-lab-lkp/linux/commit/a94efb8736c53bd301f57ecaf952c154db64a56f
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ville-Syrjala/drm-Clean-up-drm_crtc-h/20220614-040443
git checkout a94efb8736c53bd301f57ecaf952c154db64a56f
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/gpu/drm/ingenic/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:499:22: error: incomplete
definition of type 'struct drm_framebuffer'
new_plane_state->fb->format->format == DRM_FORMAT_C8;
~~~^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:511:26: error: incomplete
definition of type 'struct drm_framebuffer'
old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
~~~^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:511:65: error: incomplete
definition of type 'struct drm_framebuffer'
old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
~~~^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:677:21: error: incomplete
definition of type 'struct drm_framebuffer'
cpp = newstate->fb->format->cpp[0];
^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:695:24: error: incomplete
definition of type 'struct drm_framebuffer'
switch (newstate->fb->format->format) {
^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:715:25: error: incomplete
definition of type 'struct drm_framebuffer'
fourcc = newstate->fb->format->format;
^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:765:9: error: use of undeclared
>> identifier 'MEDIA_BUS_FMT_RGB565_1X16'
case MEDIA_BUS_FMT_RGB565_1X16:
^
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:768:9: error: use of undeclared
>> identifier 'MEDIA_BUS_FMT_RGB666_1X18'
case MEDIA_BUS_FMT_RGB666_1X1
Re: [PATCH 7/8] drm: Remove linux/media-bus-format.h from drm_crtc.h
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20220610]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next v5.19-rc2 v5.19-rc1 v5.18 v5.19-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Ville-Syrjala/drm-Clean-up-drm_crtc-h/20220614-040443
base:6d0c806803170f120f8cb97b321de7bd89d3a791
config: xtensa-randconfig-r012-20220613
(https://download.01.org/0day-ci/archive/20220614/202206140738.nk4evaxd-...@intel.com/config)
compiler: xtensa-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/a94efb8736c53bd301f57ecaf952c154db64a56f
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ville-Syrjala/drm-Clean-up-drm_crtc-h/20220614-040443
git checkout a94efb8736c53bd301f57ecaf952c154db64a56f
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1
O=build_dir ARCH=xtensa SHELL=/bin/bash drivers/gpu/drm/ingenic/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_plane_atomic_check':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:499:36: error: invalid use of
undefined type 'struct drm_framebuffer'
499 | new_plane_state->fb->format->format == DRM_FORMAT_C8;
|^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:511:33: error: invalid use of
undefined type 'struct drm_framebuffer'
511 | old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:511:72: error: invalid use of
undefined type 'struct drm_framebuffer'
511 | old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
|
^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_plane_atomic_update':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:677:35: error: invalid use of
undefined type 'struct drm_framebuffer'
677 | cpp = newstate->fb->format->cpp[0];
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:695:45: error: invalid use of
undefined type 'struct drm_framebuffer'
695 | switch (newstate->fb->format->format) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:715:46: error: invalid use of
undefined type 'struct drm_framebuffer'
715 | fourcc = newstate->fb->format->format;
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_encoder_atomic_mode_set':
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:765:30: error:
>> 'MEDIA_BUS_FMT_RGB565_1X16' undeclared (first use in this function)
765 | case MEDIA_BUS_FMT_RGB565_1X16:
| ^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:765:30: note: each undeclared
identifier is reported only once for each function it appears in
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:768:30: error:
>> 'MEDIA_BUS_FMT_RGB666_1X18' undeclared (first use in this function)
768 | case MEDIA_BUS_FMT_RGB666_1X18:
| ^
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:771:30: error:
>> 'MEDIA_BUS_FMT_RGB888_1X24' undeclared (first use in this function)
771 | case MEDIA_BUS_FMT_RGB888_1X24:
| ^
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:774:30: error:
>> 'MEDIA_BUS_FMT_RGB888_3X8_DELTA' undeclared (first use in this function)
774 | case MEDIA_BUS_FMT_RGB888_3X8_DELTA:
| ^~
>> drivers/gpu/drm/ingenic/ingenic-drm-
Re: [Intel-gfx] [PATCH 2/8] drm: Drop drm_framebuffer.h from drm_crtc.h
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20220610]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next v5.19-rc2 v5.19-rc1 v5.18 v5.19-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Ville-Syrjala/drm-Clean-up-drm_crtc-h/20220614-040443
base:6d0c806803170f120f8cb97b321de7bd89d3a791
config: arm64-randconfig-r004-20220613
(https://download.01.org/0day-ci/archive/20220614/202206140726.cjoshn1e-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
d378268ead93c85803c270277f0243737b536ae7)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/intel-lab-lkp/linux/commit/be7de5c4289616ee04e75a6fe7df89e80a184da0
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ville-Syrjala/drm-Clean-up-drm_crtc-h/20220614-040443
git checkout be7de5c4289616ee04e75a6fe7df89e80a184da0
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/gpu/drm/ingenic/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:499:22: error: incomplete
>> definition of type 'struct drm_framebuffer'
new_plane_state->fb->format->format == DRM_FORMAT_C8;
~~~^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:511:26: error: incomplete
definition of type 'struct drm_framebuffer'
old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
~~~^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:511:65: error: incomplete
definition of type 'struct drm_framebuffer'
old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
~~~^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:677:21: error: incomplete
definition of type 'struct drm_framebuffer'
cpp = newstate->fb->format->cpp[0];
^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:695:24: error: incomplete
definition of type 'struct drm_framebuffer'
switch (newstate->fb->format->format) {
^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:715:25: error: incomplete
definition of type 'struct drm_framebuffer'
fourcc = newstate->fb->format->format;
^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
^
6 errors generated.
--
>> drivers/gpu/drm/ingenic/ingenic-ipu.c:342:38: error: incomplete definition
>> of type 'struct drm_framebuffer'
finfo = drm_format_info(newstate->fb->format->format);
^
include/drm/drm_mode_config.h:83:9: note: forward declaration of 'struct
drm_framebuffer'
struct drm
[PATCH v6 9/9] drm: vkms: Add support to the RGB565 format
This commit also adds new helper macros to deal with fixed-point
arithmetic.
It was done to improve the precision of the conversion to ARGB16161616
since the "conversion ratio" is not an integer.
V3: Adapt the handlers to the new format introduced in patch 7 V3.
V5: Minor improvements
V6: Minor improvements (Pekka Paalanen)
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_formats.c | 70 +++
drivers/gpu/drm/vkms/vkms_plane.c | 6 ++-
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +-
3 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 587e0e078d82..b646292addec 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -5,6 +5,23 @@
#include "vkms_formats.h"
+/* The following macros help doing fixed point arithmetic. */
+/*
+ * With Fixed-Point scale 15 we have 17 and 15 bits of integer and fractional
+ * parts respectively.
+ * | 0.000 |
+ * 31 0
+ */
+#define SHIFT 15
+
+#define INT_TO_FIXED(a) ((a) << SHIFT)
+#define FIXED_MUL(a, b) ((s32)(((s64)(a) * (b)) >> SHIFT))
+#define FIXED_DIV(a, b) ((s32)(((s64)(a) << SHIFT) / (b)))
+/* This macro converts a fixed point number to int, and round half up it */
+#define FIXED_TO_INT_ROUND(a) (((a) + (1 << (SHIFT - 1))) >> SHIFT)
+#define INT_TO_FIXED_DIV(a, b) (FIXED_DIV(INT_TO_FIXED(a), INT_TO_FIXED(b)))
+#define INT_TO_FIXED_DIV(a, b) (FIXED_DIV(INT_TO_FIXED(a), INT_TO_FIXED(b)))
+
static size_t pixel_offset(const struct vkms_frame_info *frame_info, int x,
int y)
{
return frame_info->offset + (y * frame_info->pitch)
@@ -112,6 +129,30 @@ static void XRGB16161616_to_argb_u16(struct line_buffer
*stage_buffer,
}
}
+static void RGB565_to_argb_u16(struct line_buffer *stage_buffer,
+ const struct vkms_frame_info *frame_info, int y)
+{
+ struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
+ u16 *src_pixels = get_packed_src_addr(frame_info, y);
+ int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
+ stage_buffer->n_pixels);
+
+ s32 fp_rb_ratio = INT_TO_FIXED_DIV(65535, 31);
+ s32 fp_g_ratio = INT_TO_FIXED_DIV(65535, 63);
+
+ for (size_t x = 0; x < x_limit; x++, src_pixels++) {
+ u16 rgb_565 = le16_to_cpu(*src_pixels);
+ s32 fp_r = INT_TO_FIXED((rgb_565 >> 11) & 0x1f);
+ s32 fp_g = INT_TO_FIXED((rgb_565 >> 5) & 0x3f);
+ s32 fp_b = INT_TO_FIXED(rgb_565 & 0x1f);
+
+ out_pixels[x].a = (u16)0x;
+ out_pixels[x].r = FIXED_TO_INT_ROUND(FIXED_MUL(fp_r,
fp_rb_ratio));
+ out_pixels[x].g = FIXED_TO_INT_ROUND(FIXED_MUL(fp_g,
fp_g_ratio));
+ out_pixels[x].b = FIXED_TO_INT_ROUND(FIXED_MUL(fp_b,
fp_rb_ratio));
+ }
+}
+
/*
* The following functions take an line of argb_u16 pixels from the
@@ -197,6 +238,31 @@ static void argb_u16_to_XRGB16161616(struct
vkms_frame_info *frame_info,
}
}
+static void argb_u16_to_RGB565(struct vkms_frame_info *frame_info,
+ const struct line_buffer *src_buffer, int y)
+{
+ int x_dst = frame_info->dst.x1;
+ u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+ struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
+ int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
+ src_buffer->n_pixels);
+
+ s32 fp_rb_ratio = INT_TO_FIXED_DIV(65535, 31);
+ s32 fp_g_ratio = INT_TO_FIXED_DIV(65535, 63);
+
+ for (size_t x = 0; x < x_limit; x++, dst_pixels++) {
+ s32 fp_r = INT_TO_FIXED(in_pixels[x].r);
+ s32 fp_g = INT_TO_FIXED(in_pixels[x].g);
+ s32 fp_b = INT_TO_FIXED(in_pixels[x].b);
+
+ u16 r = FIXED_TO_INT_ROUND(FIXED_DIV(fp_r, fp_rb_ratio));
+ u16 g = FIXED_TO_INT_ROUND(FIXED_DIV(fp_g, fp_g_ratio));
+ u16 b = FIXED_TO_INT_ROUND(FIXED_DIV(fp_b, fp_rb_ratio));
+
+ *dst_pixels = cpu_to_le16(r << 11 | g << 5 | b);
+ }
+}
+
frame_to_line_func get_frame_to_line_function(u32 format)
{
switch (format) {
@@ -208,6 +274,8 @@ frame_to_line_func get_frame_to_line_function(u32 format)
return &ARGB16161616_to_argb_u16;
case DRM_FORMAT_XRGB16161616:
return &XRGB16161616_to_argb_u16;
+ case DRM_FORMAT_RGB565:
+ return &RGB565_to_argb_u16;
default:
return NULL;
}
@@ -224,6 +292,8 @@ line_to_frame_func get_line_to_frame_function(u32 format)
return &argb_u16_to_ARGB16161616;
case DRM_FORMAT_XRGB16161616:
return &argb_u16_to_XRGB16161616;
+ case DRM_FORMAT_RGB565:
+ return &argb_u16_to_RGB565;
[PATCH v6 8/9] drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats
This will be useful to write tests that depends on these formats.
ARGB and XRGB follows the a similar implementation of the former formats.
Just adjusting for 16 bits per channel.
V3: Adapt the handlers to the new format introduced in patch 7 V3.
V5: Minor improvements
Added le16_to_cpu/cpu_to_le16 to the 16 bits color read/writes.
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_formats.c | 77 +++
drivers/gpu/drm/vkms/vkms_plane.c | 5 +-
drivers/gpu/drm/vkms/vkms_writeback.c | 2 +
3 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index ca4bfcac686b..8b651ffcc743 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -78,6 +78,41 @@ static void XRGB_to_argb_u16(struct line_buffer
*stage_buffer,
}
}
+static void ARGB16161616_to_argb_u16(struct line_buffer *stage_buffer,
+const struct vkms_frame_info *frame_info,
+int y)
+{
+ struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
+ u16 *src_pixels = get_packed_src_addr(frame_info, y);
+ int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
+ stage_buffer->n_pixels);
+
+ for (size_t x = 0; x < x_limit; x++, src_pixels += 4) {
+ out_pixels[x].a = le16_to_cpu(src_pixels[3]);
+ out_pixels[x].r = le16_to_cpu(src_pixels[2]);
+ out_pixels[x].g = le16_to_cpu(src_pixels[1]);
+ out_pixels[x].b = le16_to_cpu(src_pixels[0]);
+ }
+}
+
+static void XRGB16161616_to_argb_u16(struct line_buffer *stage_buffer,
+const struct vkms_frame_info *frame_info,
+int y)
+{
+ struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
+ u16 *src_pixels = get_packed_src_addr(frame_info, y);
+ int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
+ stage_buffer->n_pixels);
+
+ for (size_t x = 0; x < x_limit; x++, src_pixels += 4) {
+ out_pixels[x].a = (u16)0x;
+ out_pixels[x].r = le16_to_cpu(src_pixels[2]);
+ out_pixels[x].g = le16_to_cpu(src_pixels[1]);
+ out_pixels[x].b = le16_to_cpu(src_pixels[0]);
+ }
+}
+
+
/*
* The following functions take an line of argb_u16 pixels from the
* src_buffer, convert them to a specific format, and store them in the
@@ -130,6 +165,40 @@ static void argb_u16_to_XRGB(struct vkms_frame_info
*frame_info,
}
}
+static void argb_u16_to_ARGB16161616(struct vkms_frame_info *frame_info,
+const struct line_buffer *src_buffer, int
y)
+{
+ int x_dst = frame_info->dst.x1;
+ u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+ struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
+ int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
+ src_buffer->n_pixels);
+
+ for (size_t x = 0; x < x_limit; x++, dst_pixels += 4) {
+ dst_pixels[3] = cpu_to_le16(in_pixels[x].a);
+ dst_pixels[2] = cpu_to_le16(in_pixels[x].r);
+ dst_pixels[1] = cpu_to_le16(in_pixels[x].g);
+ dst_pixels[0] = cpu_to_le16(in_pixels[x].b);
+ }
+}
+
+static void argb_u16_to_XRGB16161616(struct vkms_frame_info *frame_info,
+const struct line_buffer *src_buffer, int
y)
+{
+ int x_dst = frame_info->dst.x1;
+ u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+ struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
+ int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
+ src_buffer->n_pixels);
+
+ for (size_t x = 0; x < x_limit; x++, dst_pixels += 4) {
+ dst_pixels[3] = 0x;
+ dst_pixels[2] = cpu_to_le16(in_pixels[x].r);
+ dst_pixels[1] = cpu_to_le16(in_pixels[x].g);
+ dst_pixels[0] = cpu_to_le16(in_pixels[x].b);
+ }
+}
+
frame_to_line_func get_frame_to_line_function(u32 format)
{
switch (format) {
@@ -137,6 +206,10 @@ frame_to_line_func get_frame_to_line_function(u32 format)
return &ARGB_to_argb_u16;
case DRM_FORMAT_XRGB:
return &XRGB_to_argb_u16;
+ case DRM_FORMAT_ARGB16161616:
+ return &ARGB16161616_to_argb_u16;
+ case DRM_FORMAT_XRGB16161616:
+ return &XRGB16161616_to_argb_u16;
default:
return NULL;
}
@@ -149,6 +222,10 @@ line_to_frame_func get_line_to_frame_function(u32 format)
return &argb_u16_to_ARGB;
case DRM_FORMAT_XRGB:
return &argb_u16_to_XRGB;
+ case DRM_FORMAT_ARGB1616161
[PATCH v6 7/9] drm: vkms: Supports to the case where primary plane doesn't match the CRTC
We will remove the current assumption that the primary plane has the
same size and position as CRTC and that the primary plane is the
bottom-most in zpos order, or is even enabled. At least as far
as the blending machinery is concerned.
For that we will add CRTC dimension information to `vkms_crtc_state`
and add a opaque black backgound color.
Because now we need to fill the background, we had a loss in
performance with this change. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
| Frametime |
|::|
| Implementation | Previous | This commit |
|:---:|:-:|:--:|
| frametime range | 5~18 ms | 10~22 ms |
| Average | 8.47 ms | 12.32 ms |
[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4
V6: Improve the commit description (Pekka Paalanen).
Update some comments (Pekka Paalanen).
Remove some fields from `vkms_crtc_state` and move where
some variables are set (Pekka Paalanen).
Signed-off-by: Igor Torrente
---
Documentation/gpu/vkms.rst| 3 +-
drivers/gpu/drm/vkms/vkms_composer.c | 59 +--
drivers/gpu/drm/vkms/vkms_writeback.c | 4 ++
3 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index a49e4ae92653..49db221c0f52 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -121,8 +121,7 @@ There's lots of plane features we could add support for:
- ARGB format on primary plane: blend the primary plane into background with
translucent alpha.
-- Support when the primary plane isn't exactly matching the output size: blend
- the primary plane into the black background.
+- Add background color KMS property[Good to get started].
- Full alpha blending on all planes.
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 5b1a8bdd8268..8e53fa80742b 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -61,6 +61,13 @@ static bool check_y_limit(struct vkms_frame_info
*frame_info, int y)
return false;
}
+static void fill_background(const struct pixel_argb_u16 *background_color,
+ struct line_buffer *output_buffer)
+{
+ for (size_t i = 0; i < output_buffer->n_pixels; i++)
+ output_buffer->pixels[i] = *background_color;
+}
+
/**
* @wb_frame_info: The writeback frame buffer metadata
* @crtc_state: The crtc state
@@ -78,21 +85,17 @@ static void blend(struct vkms_writeback_job *wb,
struct line_buffer *output_buffer, size_t row_size)
{
struct vkms_plane_state **plane = crtc_state->active_planes;
- struct vkms_frame_info *primary_plane_info = plane[0]->frame_info;
u32 n_active_planes = crtc_state->num_active_planes;
- int y_dst = primary_plane_info->dst.y1;
- int h_dst = drm_rect_height(&primary_plane_info->dst);
- int y_limit = y_dst + h_dst;
+ const struct pixel_argb_u16 background_color = { .a = 0x };
- for (size_t y = y_dst; y < y_limit; y++) {
- plane[0]->plane_read(output_buffer, primary_plane_info, y);
+ size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay;
- /* If there are other planes besides primary, we consider the
active
-* planes should be in z-order and compose them associatively:
-* ((primary <- overlay) <- cursor)
-*/
- for (size_t i = 1; i < n_active_planes; i++) {
+ for (size_t y = 0; y < crtc_y_limit; y++) {
+ fill_background(&background_color, output_buffer);
+
+ /* The active planes are composed associatively in z-order. */
+ for (size_t i = 0; i < n_active_planes; i++) {
if (!check_y_limit(plane[i]->frame_info, y))
continue;
@@ -124,14 +127,24 @@ static int check_format_funcs(struct vkms_crtc_state
*crtc_state,
return 0;
}
+static int check_iosys_map(struct vkms_crtc_state *crtc_state)
+{
+ struct vkms_plane_state **plane_state = crtc_state->active_planes;
+ u32 n_active_planes = crtc_state->num_active_planes;
+
+ for (size_t i = 0; i < n_active_planes; i++)
+ if (iosys_map_is_null(&plane_state[i]->frame_info->map[0]))
+ return -1;
+
+ return 0;
+}
+
static int compose_active_planes(struct vkms_writeback_job *active_wb,
struct vkms_crtc_state *crtc_state,
u32 *crc32)
{
size_t line_width, pixel_size = sizeof(struct pixel_argb_u16);
- struct vkms_frame_info *primary_plane_info = NULL;
struct line_buffer output_buffer, stage_buffer;
- struct vkms_plane_state *act_plane = NULL
[PATCH v6 6/9] drm: vkms: Refactor the plane composer to accept new formats
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
The pixels blend is done using the new internal format. And new handlers
are being added to convert a specific format to/from this internal format.
So the blend operation depends on these handlers to convert to this common
format. The blended result, if necessary, is converted to the writeback
buffer format.
This patch introduces three major differences to the blend function.
1 - All the planes are blended at once.
2 - The blend calculus is done as per line instead of per pixel.
3 - It is responsible to calculates the CRC and writing the writeback
buffer(if necessary).
These changes allow us to allocate way less memory in the intermediate
buffer to compute these operations. Because now we don't need to
have the entire intermediate image lines at once, just one line is
enough.
| Memory consumption (output dimensions) |
|:--:|
| Current | This patch|
|:--:|:-:|
| Width * Heigth | 2 * Width |
Beyond memory, we also have a minor performance benefit from all
these changes. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
| Frametime |
|:--:|
| Implementation | Current | This commit |
|:---:|:-:|::|
| frametime range | 9~22 ms |5~17 ms |
| Average | 11.4 ms |7.8 ms|
[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4
V2: Improves the performance drastically, by performing the operations
per-line and not per-pixel(Pekka Paalanen).
Minor improvements(Pekka Paalanen).
V3: Changes the code to blend the planes all at once. This improves
performance, memory consumption, and removes much of the weirdness
of the V2(Pekka Paalanen and me).
Minor improvements(Pekka Paalanen and me).
V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant.
V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen).
Several security/robustness improvents(Pekka Paalanen).
Removes check_planes_x_bounds function and allows partial
partly off-screen(Pekka Paalanen).
V6: Fix a mismatch of some variable sizes (Pekka Paalanen).
Several minor improvements (Pekka Paalanen).
Reported-by: kernel test robot
Signed-off-by: Igor Torrente
---
Documentation/gpu/vkms.rst| 4 -
drivers/gpu/drm/vkms/Makefile | 1 +
drivers/gpu/drm/vkms/vkms_composer.c | 320 --
drivers/gpu/drm/vkms/vkms_formats.c | 155 +
drivers/gpu/drm/vkms/vkms_formats.h | 12 +
drivers/gpu/drm/vkms/vkms_plane.c | 3 +
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +
7 files changed, 317 insertions(+), 181 deletions(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 973e2d43108b..a49e4ae92653 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -118,10 +118,6 @@ Add Plane Features
There's lots of plane features we could add support for:
-- Clearing primary plane: clear primary plane before plane composition (at the
- start) for correctness of pixel blend ops. It also guarantees alpha channel
- is cleared in the target buffer for stable crc. [Good to get started]
-
- ARGB format on primary plane: blend the primary plane into background with
translucent alpha.
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 72f779cbfedd..1b28a6a32948 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -3,6 +3,7 @@ vkms-y := \
vkms_drv.o \
vkms_plane.o \
vkms_output.o \
+ vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
vkms_writeback.o
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index b9fb408e8973..5b1a8bdd8268 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -7,204 +7,188 @@
#include
#include
#include
+#include
#include "vkms_drv.h"
-static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
-const struct vkms_frame_info *frame_info)
+static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
{
- u32 pixel;
- int src_offset = frame_info->offset + (y * frame_info->pitch)
- + (x * frame_info->cpp);
+ u32 new_color;
- pixel = *(u32 *)&buffer[src_offset];
+ new_color = (src * 0x + dst * (0x - alpha));
- return pixel;
+ return DIV_ROUND_CLOSEST(new_color, 0x);
}
/**
- *
[PATCH v6 5/9] drm: vkms: Add fb information to `vkms_writeback_job`
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_frame_info`
struct.
Also adds two new function pointers (`line_to_frame_func` and
`frame_to_line_func`) are defined to handle format conversion
from/to internal format.
A new internal format(`struct pixel_argb_u16`) is introduced to deal with
all possible inputs. It consists of 16 bits fields that represent each of
the channels.
These things will allow us, in the future, to have different compositing
and wb format types.
V2: Change the code to get the drm_framebuffer reference and not copy its
contents (Thomas Zimmermann).
V3: Drop the refcount in the wb code (Thomas Zimmermann).
V5: Add {wb,plane}_format_transform_func to vkms_writeback_job
and vkms_plane_state (Pekka Paalanen)
V6: Improvements to some struct/struct members names (Pekka Paalanen).
Splits this patch in two (Pekka Paalanen).
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_drv.h | 29 ++-
drivers/gpu/drm/vkms/vkms_writeback.c | 20 +++---
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 95d71322500b..0d407ec84f94 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -22,11 +22,6 @@
#define NUM_OVERLAY_PLANES 8
-struct vkms_writeback_job {
- struct iosys_map map[DRM_FORMAT_MAX_PLANES];
- struct iosys_map data[DRM_FORMAT_MAX_PLANES];
-};
-
struct vkms_frame_info {
struct drm_framebuffer *fb;
struct drm_rect src, dst;
@@ -36,6 +31,29 @@ struct vkms_frame_info {
unsigned int cpp;
};
+struct pixel_argb_u16 {
+ u16 a, r, g, b;
+};
+
+struct line_buffer {
+ size_t n_pixels;
+ struct pixel_argb_u16 *pixels;
+};
+
+typedef void
+(*line_to_frame_func)(struct vkms_frame_info *frame_info,
+ const struct line_buffer *buffer, int y);
+
+typedef void
+(*frame_to_line_func)(struct line_buffer *buffer,
+ const struct vkms_frame_info *frame_info, int y);
+
+struct vkms_writeback_job {
+ struct iosys_map data[DRM_FORMAT_MAX_PLANES];
+ struct vkms_frame_info wb_frame_info;
+ line_to_frame_func wb_write;
+};
+
/**
* vkms_plane_state - Driver specific plane state
* @base: base plane state
@@ -44,6 +62,7 @@ struct vkms_frame_info {
struct vkms_plane_state {
struct drm_shadow_plane_state base;
struct vkms_frame_info *frame_info;
+ frame_to_line_func plane_read;
};
struct vkms_plane {
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 250e509a298f..c87f6c89e7b4 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -74,12 +74,15 @@ static int vkms_wb_prepare_job(struct
drm_writeback_connector *wb_connector,
if (!vkmsjob)
return -ENOMEM;
- ret = drm_gem_fb_vmap(job->fb, vkmsjob->map, vkmsjob->data);
+ ret = drm_gem_fb_vmap(job->fb, vkmsjob->wb_frame_info.map,
vkmsjob->data);
if (ret) {
DRM_ERROR("vmap failed: %d\n", ret);
goto err_kfree;
}
+ vkmsjob->wb_frame_info.fb = job->fb;
+ drm_framebuffer_get(vkmsjob->wb_frame_info.fb);
+
job->priv = vkmsjob;
return 0;
@@ -98,7 +101,9 @@ static void vkms_wb_cleanup_job(struct
drm_writeback_connector *connector,
if (!job->fb)
return;
- drm_gem_fb_vunmap(job->fb, vkmsjob->map);
+ drm_gem_fb_vunmap(job->fb, vkmsjob->wb_frame_info.map);
+
+ drm_framebuffer_put(vkmsjob->wb_frame_info.fb);
vkmsdev = drm_device_to_vkms_device(job->fb->dev);
vkms_set_composer(&vkmsdev->output, false);
@@ -115,14 +120,23 @@ static void vkms_wb_atomic_commit(struct drm_connector
*conn,
struct drm_writeback_connector *wb_conn = &output->wb_connector;
struct drm_connector_state *conn_state = wb_conn->base.state;
struct vkms_crtc_state *crtc_state = output->composer_state;
+ struct drm_framebuffer *fb = connector_state->writeback_job->fb;
+ struct vkms_writeback_job *active_wb;
+ struct vkms_frame_info *wb_frame_info;
if (!conn_state)
return;
vkms_set_composer(&vkmsdev->output, true);
+ active_wb = conn_state->writeback_job->priv;
+ wb_frame_info = &active_wb->wb_frame_info;
+
spin_lock_irq(&output->composer_lock);
- crtc_state->active_writeback = conn_state->writeback_job->priv;
+ crtc_state->active_writeback = active_wb;
+ wb_frame_info->offset = fb->offsets[0];
+ wb_frame_info->pitch = fb->pitches[0];
+ wb_frame_info->cpp = fb->format->cpp[0];
crtc_state->wb_pending = true;
spin_unlock_irq(&output-
[PATCH v6 4/9] drm: vkms: get the reference to `drm_framebuffer` instead if coping it
Instead of coping `drm_framebuffer` - which can cause problems -
we just get the reference and add the ref count.
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_composer.c | 4 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
drivers/gpu/drm/vkms/vkms_plane.c| 10 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 0aded4e87e60..b9fb408e8973 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -153,7 +153,7 @@ static void compose_plane(struct vkms_frame_info
*primary_plane_info,
struct vkms_frame_info *plane_frame_info,
void *vaddr_out)
{
- struct drm_framebuffer *fb = &plane_frame_info->fb;
+ struct drm_framebuffer *fb = plane_frame_info->fb;
void *vaddr;
void (*pixel_blend)(const u8 *p_src, u8 *p_dst);
@@ -175,7 +175,7 @@ static int compose_active_planes(void **vaddr_out,
struct vkms_frame_info *primary_plane_info,
struct vkms_crtc_state *crtc_state)
{
- struct drm_framebuffer *fb = &primary_plane_info->fb;
+ struct drm_framebuffer *fb = primary_plane_info->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
const void *vaddr;
int i;
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 5199c5f18e17..95d71322500b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -28,7 +28,7 @@ struct vkms_writeback_job {
};
struct vkms_frame_info {
- struct drm_framebuffer fb;
+ struct drm_framebuffer *fb;
struct drm_rect src, dst;
struct iosys_map map[DRM_FORMAT_MAX_PLANES];
unsigned int offset;
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index fcae6c508f4b..8adbfdc05e50 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -50,12 +50,12 @@ static void vkms_plane_destroy_state(struct drm_plane
*plane,
struct vkms_plane_state *vkms_state = to_vkms_plane_state(old_state);
struct drm_crtc *crtc = vkms_state->base.base.crtc;
- if (crtc) {
+ if (crtc && vkms_state->frame_info->fb) {
/* dropping the reference we acquired in
* vkms_primary_plane_update()
*/
- if (drm_framebuffer_read_refcount(&vkms_state->frame_info->fb))
- drm_framebuffer_put(&vkms_state->frame_info->fb);
+ if (drm_framebuffer_read_refcount(vkms_state->frame_info->fb))
+ drm_framebuffer_put(vkms_state->frame_info->fb);
}
kfree(vkms_state->frame_info);
@@ -110,9 +110,9 @@ static void vkms_plane_atomic_update(struct drm_plane
*plane,
frame_info = vkms_plane_state->frame_info;
memcpy(&frame_info->src, &new_state->src, sizeof(struct drm_rect));
memcpy(&frame_info->dst, &new_state->dst, sizeof(struct drm_rect));
- memcpy(&frame_info->fb, fb, sizeof(struct drm_framebuffer));
+ frame_info->fb = fb;
memcpy(&frame_info->map, &shadow_plane_state->data,
sizeof(frame_info->map));
- drm_framebuffer_get(&frame_info->fb);
+ drm_framebuffer_get(frame_info->fb);
frame_info->offset = fb->offsets[0];
frame_info->pitch = fb->pitches[0];
frame_info->cpp = fb->format->cpp[0];
--
2.30.2
[PATCH v6 3/9] drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation
Add a helper function to validate the connector configuration received in
the encoder atomic_check by the drivers.
So the drivers don't need to do these common validations themselves.
V2: Move the format verification to a new helper at the drm_atomic_helper.c
(Thomas Zimmermann).
V3: Format check improvements (Leandro Ribeiro).
Minor improvements(Thomas Zimmermann).
V5: Fix some grammar issues in the commit message (André Almeida).
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/drm_atomic_helper.c | 39 +++
drivers/gpu/drm/vkms/vkms_writeback.c | 9 +++
include/drm/drm_atomic_helper.h | 3 +++
3 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9603193d2fa1..2052e18fa64c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -776,6 +776,45 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
+/**
+ * drm_atomic_helper_check_wb_connector_state() - Check writeback encoder state
+ * @encoder: encoder state to check
+ * @conn_state: connector state to check
+ *
+ * Checks if the writeback connector state is valid, and returns an error if it
+ * isn't.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int
+drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
+struct drm_connector_state *conn_state)
+{
+ struct drm_writeback_job *wb_job = conn_state->writeback_job;
+ struct drm_property_blob *pixel_format_blob;
+ struct drm_framebuffer *fb;
+ size_t i, nformats;
+ u32 *formats;
+
+ if (!wb_job || !wb_job->fb)
+ return 0;
+
+ pixel_format_blob = wb_job->connector->pixel_formats_blob_ptr;
+ nformats = pixel_format_blob->length / sizeof(u32);
+ formats = pixel_format_blob->data;
+ fb = wb_job->fb;
+
+ for (i = 0; i < nformats; i++)
+ if (fb->format->format == formats[i])
+ return 0;
+
+ drm_dbg_kms(encoder->dev, "Invalid pixel format %p4cc\n",
&fb->format->format);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
+
/**
* drm_atomic_helper_check_plane_state() - Check plane state for validity
* @plane_state: plane state to check
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index af1604dfbbaf..250e509a298f 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -30,6 +30,7 @@ static int vkms_wb_encoder_atomic_check(struct drm_encoder
*encoder,
{
struct drm_framebuffer *fb;
const struct drm_display_mode *mode = &crtc_state->mode;
+ int ret;
if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
return 0;
@@ -41,11 +42,9 @@ static int vkms_wb_encoder_atomic_check(struct drm_encoder
*encoder,
return -EINVAL;
}
- if (fb->format->format != vkms_wb_formats[0]) {
- DRM_DEBUG_KMS("Invalid pixel format %p4cc\n",
- &fb->format->format);
- return -EINVAL;
- }
+ ret = drm_atomic_helper_check_wb_encoder_state(encoder, conn_state);
+ if (ret < 0)
+ return ret;
return 0;
}
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 4045e2507e11..3fbf695da60f 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -40,6 +40,9 @@ struct drm_private_state;
int drm_atomic_helper_check_modeset(struct drm_device *dev,
struct drm_atomic_state *state);
+int
+drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
+struct drm_connector_state
*conn_state);
int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
const struct drm_crtc_state *crtc_state,
int min_scale,
--
2.30.2
[PATCH v6 1/9] drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES
The `map` vector at `vkms_composer` uses a hardcoded value to define its
size.
If someday the maximum number of planes increases, this hardcoded value
can be a problem.
This value is being replaced with the DRM_FORMAT_MAX_PLANES macro.
Acked-by: Thomas Zimmermann
Reviewed-by: Melissa Wen
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 91e63b12f60f..36fbab5989d1 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -30,7 +30,7 @@ struct vkms_writeback_job {
struct vkms_composer {
struct drm_framebuffer fb;
struct drm_rect src, dst;
- struct iosys_map map[4];
+ struct iosys_map map[DRM_FORMAT_MAX_PLANES];
unsigned int offset;
unsigned int pitch;
unsigned int cpp;
--
2.30.2
[PATCH v6 2/9] drm: vkms: Rename `vkms_composer` to `vkms_frame_info`
Changes the name of this struct to a more meaningful name.
A name that represents better what this struct is about.
Composer is the code that do the compositing of the planes.
This struct contains information on the frame used in the output
composition. Thus, vkms_frame_info is a better name to represent
this.
V5: Fix a commit message typo(Melissa Wen).
Reviewed-by: Melissa Wen
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_composer.c | 87 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 6 +-
drivers/gpu/drm/vkms/vkms_plane.c| 38 ++--
3 files changed, 66 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 775b97766e08..0aded4e87e60 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -11,11 +11,11 @@
#include "vkms_drv.h"
static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
-const struct vkms_composer *composer)
+const struct vkms_frame_info *frame_info)
{
u32 pixel;
- int src_offset = composer->offset + (y * composer->pitch)
- + (x * composer->cpp);
+ int src_offset = frame_info->offset + (y * frame_info->pitch)
+ + (x * frame_info->cpp);
pixel = *(u32 *)&buffer[src_offset];
@@ -26,24 +26,24 @@ static u32 get_pixel_from_buffer(int x, int y, const u8
*buffer,
* compute_crc - Compute CRC value on output frame
*
* @vaddr: address to final framebuffer
- * @composer: framebuffer's metadata
+ * @frame_info: framebuffer's metadata
*
* returns CRC value computed using crc32 on the visible portion of
* the final framebuffer at vaddr_out
*/
static uint32_t compute_crc(const u8 *vaddr,
- const struct vkms_composer *composer)
+ const struct vkms_frame_info *frame_info)
{
int x, y;
u32 crc = 0, pixel = 0;
- int x_src = composer->src.x1 >> 16;
- int y_src = composer->src.y1 >> 16;
- int h_src = drm_rect_height(&composer->src) >> 16;
- int w_src = drm_rect_width(&composer->src) >> 16;
+ int x_src = frame_info->src.x1 >> 16;
+ int y_src = frame_info->src.y1 >> 16;
+ int h_src = drm_rect_height(&frame_info->src) >> 16;
+ int w_src = drm_rect_width(&frame_info->src) >> 16;
for (y = y_src; y < y_src + h_src; ++y) {
for (x = x_src; x < x_src + w_src; ++x) {
- pixel = get_pixel_from_buffer(x, y, vaddr, composer);
+ pixel = get_pixel_from_buffer(x, y, vaddr, frame_info);
crc = crc32_le(crc, (void *)&pixel, sizeof(u32));
}
}
@@ -98,8 +98,8 @@ static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
* blend - blend value at vaddr_src with value at vaddr_dst
* @vaddr_dst: destination address
* @vaddr_src: source address
- * @dst_composer: destination framebuffer's metadata
- * @src_composer: source framebuffer's metadata
+ * @dst_frame_info: destination framebuffer's metadata
+ * @src_frame_info: source framebuffer's metadata
* @pixel_blend: blending equation based on plane format
*
* Blend the vaddr_src value with the vaddr_dst value using a pixel blend
@@ -111,33 +111,33 @@ static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
* pixel color values
*/
static void blend(void *vaddr_dst, void *vaddr_src,
- struct vkms_composer *dst_composer,
- struct vkms_composer *src_composer,
+ struct vkms_frame_info *dst_frame_info,
+ struct vkms_frame_info *src_frame_info,
void (*pixel_blend)(const u8 *, u8 *))
{
int i, j, j_dst, i_dst;
int offset_src, offset_dst;
u8 *pixel_dst, *pixel_src;
- int x_src = src_composer->src.x1 >> 16;
- int y_src = src_composer->src.y1 >> 16;
+ int x_src = src_frame_info->src.x1 >> 16;
+ int y_src = src_frame_info->src.y1 >> 16;
- int x_dst = src_composer->dst.x1;
- int y_dst = src_composer->dst.y1;
- int h_dst = drm_rect_height(&src_composer->dst);
- int w_dst = drm_rect_width(&src_composer->dst);
+ int x_dst = src_frame_info->dst.x1;
+ int y_dst = src_frame_info->dst.y1;
+ int h_dst = drm_rect_height(&src_frame_info->dst);
+ int w_dst = drm_rect_width(&src_frame_info->dst);
int y_limit = y_src + h_dst;
int x_limit = x_src + w_dst;
for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
- offset_dst = dst_composer->offset
-+ (i_dst * dst_composer->pitch)
-+ (j_dst++ * dst_composer->cpp);
- offset_src = src_compose
[PATCH v6 0/9] Add new formats support to vkms
Summary === This series of patches refactor some vkms components in order to introduce new formats to the planes and writeback connector. Now in the blend function, the plane's pixels are converted to ARGB16161616 and then blended together. The CRC is calculated based on the ARGB1616161616 buffer. And if required, this buffer is copied/converted to the writeback buffer format. And to handle the pixel conversion, new functions were added to convert from a specific format to ARGB16161616 (the reciprocal is also true). Tests = This patch series was tested using the following igt tests: -t ".*kms_plane.*" -t ".*kms_writeback.*" -t ".*kms_cursor_crc*" -t ".*kms_flip.*" New tests passing --- - pipe-A-cursor-size-change - pipe-A-cursor-alpha-transparent Performance --- It's running slightly faster than the current implementation. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times: | Frametime | |::| | Implementation | Current | This commit | |:---:|:-:|:--:| | frametime range | 9~22 ms | 10~22 ms | | Average | 11.4 ms | 12.32 ms | Memory consumption == It consumes less memory than the current implementation in the common case (more detail in the commit message). | Memory consumption (output dimensions) | |:--:| | Current | This patch| |:--:|:-:| | Width * Heigth | 2 * Width | [1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4 XRGB to ARGB behavior = During the development, I decided to always fill the alpha channel of the output pixel whenever the conversion from a format without an alpha channel to ARGB16161616 is necessary. Therefore, I ignore the value received from the XRGB and overwrite the value with 0x. Primary plane and CRTC size === This patch series reworks the blend function to accept a primary plane with a different size and position from CRTC. Because now we need to fill the background, we had a loss in performance with this change Alpha channel output for XRGB formats = There's still an open question about which value the writeback alpha channel should be for XRGB formats. The current igt test implementation is expecting the channel to not be change. But it's not entirely clear if this should be the behavior followed by vkms (or any other driver). Open issue: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/118 --- Igor Torrente (9): drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES drm: vkms: Rename `vkms_composer` to `vkms_frame_info` drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation drm: vkms: get the reference to `drm_framebuffer` instead if coping it drm: vkms: Add fb information to `vkms_writeback_job` drm: vkms: Refactor the plane composer to accept new formats drm: vkms: Supports to the case where primary plane doesn't match the CRTC drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats drm: vkms: Add support to the RGB565 format Documentation/gpu/vkms.rst| 7 +- drivers/gpu/drm/drm_atomic_helper.c | 39 drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_composer.c | 314 -- drivers/gpu/drm/vkms/vkms_drv.h | 39 +++- drivers/gpu/drm/vkms/vkms_formats.c | 300 drivers/gpu/drm/vkms/vkms_formats.h | 12 + drivers/gpu/drm/vkms/vkms_plane.c | 50 ++-- drivers/gpu/drm/vkms/vkms_writeback.c | 39 +++- include/drm/drm_atomic_helper.h | 3 + 10 files changed, 584 insertions(+), 220 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h -- 2.30.2
Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition
On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote: > > On 13/06/2022 18:49, Niranjana Vishwanathapura wrote: > > On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote: > > > > > > On 13/06/2022 16:05, Niranjana Vishwanathapura wrote: > > > > On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote: > > > > > > > > > > On 10/06/2022 17:14, Niranjana Vishwanathapura wrote: > > > > > > On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote: > > > > > > > On 10/06/2022 13:37, Tvrtko Ursulin wrote: > > > > > > > > > > > > > > > > On 10/06/2022 08:07, Niranjana Vishwanathapura wrote: > > > > > > > > > VM_BIND and related uapi definitions > > > > > > > > > > > > > > > > > > Signed-off-by: Niranjana Vishwanathapura > > > > > > > > > > > > > > > > > > --- > > > > > > > > > Documentation/gpu/rfc/i915_vm_bind.h | 490 > > > > > > > > > +++ > > > > > > > > > 1 file changed, 490 insertions(+) > > > > > > > > > create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > a/Documentation/gpu/rfc/i915_vm_bind.h > > > > > > > > > b/Documentation/gpu/rfc/i915_vm_bind.h > > > > > > > > > new file mode 100644 > > > > > > > > > index ..9fc854969cfb > > > > > > > > > --- /dev/null > > > > > > > > > +++ b/Documentation/gpu/rfc/i915_vm_bind.h > > > > > > > > > @@ -0,0 +1,490 @@ > > > > > > > > > +/* SPDX-License-Identifier: MIT */ > > > > > > > > > +/* > > > > > > > > > + * Copyright © 2022 Intel Corporation > > > > > > > > > + */ > > > > > > > > > + > > > > > > > > > +/** > > > > > > > > > + * DOC: I915_PARAM_HAS_VM_BIND > > > > > > > > > + * > > > > > > > > > + * VM_BIND feature availability. > > > > > > > > > + * See typedef drm_i915_getparam_t param. > > > > > > > > > + * bit[0]: If set, VM_BIND is supported, otherwise not. > > > > > > > > > + * bits[8-15]: VM_BIND implementation version. > > > > > > > > > + * version 0 will not have VM_BIND/UNBIND > > > > > > > > > timeline fence array support. > > > > > > > > > + */ > > > > > > > > > +#define I915_PARAM_HAS_VM_BIND 57 > > > > > > > > > + > > > > > > > > > +/** > > > > > > > > > + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND > > > > > > > > > + * > > > > > > > > > + * Flag to opt-in for VM_BIND mode of binding during VM > > > > > > > > > creation. > > > > > > > > > + * See struct drm_i915_gem_vm_control flags. > > > > > > > > > + * > > > > > > > > > + * The older execbuf2 ioctl will not > > > > > > > > > support VM_BIND mode of operation. > > > > > > > > > + * For VM_BIND mode, we have new execbuf3 > > > > > > > > > ioctl which will not accept any > > > > > > > > > + * execlist (See struct > > > > > > > > > drm_i915_gem_execbuffer3 for more details). > > > > > > > > > + * > > > > > > > > > + */ > > > > > > > > > +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0) > > > > > > > > > + > > > > > > > > > +/** > > > > > > > > > + * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING > > > > > > > > > + * > > > > > > > > > + * Flag to declare context as long running. > > > > > > > > > + * See struct drm_i915_gem_context_create_ext flags. > > > > > > > > > + * > > > > > > > > > + * Usage of dma-fence expects that they > > > > > > > > > complete in reasonable amount of time. > > > > > > > > > + * Compute on the other hand can be long > > > > > > > > > running. Hence it is not appropriate > > > > > > > > > + * for compute contexts to export request > > > > > > > > > completion dma-fence to user. > > > > > > > > > + * The dma-fence usage will be limited to > > > > > > > > > in-kernel consumption only. > > > > > > > > > + * Compute contexts need to use user/memory fence. > > > > > > > > > + * > > > > > > > > > + * So, long running contexts do not support output fences. > > > > > > > > > Hence, > > > > > > > > > + * I915_EXEC_FENCE_SIGNAL (See > > > > > > > > > &drm_i915_gem_exec_fence.flags) is expected > > > > > > > > > + * to be not used. DRM_I915_GEM_WAIT ioctl > > > > > > > > > call is also not supported for > > > > > > > > > + * objects mapped to long running contexts. > > > > > > > > > + */ > > > > > > > > > +#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2) > > > > > > > > > + > > > > > > > > > +/* VM_BIND related ioctls */ > > > > > > > > > +#define DRM_I915_GEM_VM_BIND 0x3d > > > > > > > > > +#define DRM_I915_GEM_VM_UNBIND 0x3e > > > > > > > > > +#define DRM_I915_GEM_EXECBUFFER3 0x3f > > > > > > > > > +#define DRM_I915_GEM_WAIT_USER_FENCE 0x40 > > > > > > > > > + > > > > > > > > > +#define DRM_IOCTL_I915_GEM_VM_BIND > > > > > > > > > DRM_IOWR(DRM_COMMAND_BASE + > > > > > > > > > DRM_I915_GEM_VM_BIND, struct > > > > > > > > > drm_i915_gem_vm_bind) > > > > > > > > > +#define DRM_IOCTL_I915_GEM_VM_UNBIND > > > > > > > > > DRM_IOWR(DRM_COMMAND_BASE + > > > > > > > > > DRM_I915_GEM_VM_UNBIND, struct > > > > > > > > > drm_i915_gem_vm_bind) > > > > > > > > > +#define DRM_IOCTL_I915_GEM_EXECBUFFER3 > > > > > > > >
Re: [Intel-gfx] [PATCH 2/8] drm: Drop drm_framebuffer.h from drm_crtc.h
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20220610]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next v5.19-rc2 v5.19-rc1 v5.18 v5.19-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Ville-Syrjala/drm-Clean-up-drm_crtc-h/20220614-040443
base:6d0c806803170f120f8cb97b321de7bd89d3a791
config: xtensa-randconfig-r012-20220613
(https://download.01.org/0day-ci/archive/20220614/202206140730.7korev9k-...@intel.com/config)
compiler: xtensa-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/be7de5c4289616ee04e75a6fe7df89e80a184da0
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ville-Syrjala/drm-Clean-up-drm_crtc-h/20220614-040443
git checkout be7de5c4289616ee04e75a6fe7df89e80a184da0
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1
O=build_dir ARCH=xtensa SHELL=/bin/bash drivers/gpu/drm/ingenic/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_plane_atomic_check':
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:499:36: error: invalid use of
>> undefined type 'struct drm_framebuffer'
499 | new_plane_state->fb->format->format == DRM_FORMAT_C8;
|^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:511:33: error: invalid use of
undefined type 'struct drm_framebuffer'
511 | old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:511:72: error: invalid use of
undefined type 'struct drm_framebuffer'
511 | old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
|
^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_plane_atomic_update':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:677:35: error: invalid use of
undefined type 'struct drm_framebuffer'
677 | cpp = newstate->fb->format->cpp[0];
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:695:45: error: invalid use of
undefined type 'struct drm_framebuffer'
695 | switch (newstate->fb->format->format) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:715:46: error: invalid use of
undefined type 'struct drm_framebuffer'
715 | fourcc = newstate->fb->format->format;
| ^~
--
drivers/gpu/drm/ingenic/ingenic-ipu.c: In function
'ingenic_ipu_plane_atomic_update':
>> drivers/gpu/drm/ingenic/ingenic-ipu.c:342:45: error: invalid use of
>> undefined type 'struct drm_framebuffer'
342 | finfo = drm_format_info(newstate->fb->format->format);
| ^~
vim +499 drivers/gpu/drm/ingenic/ingenic-drm-drv.c
90b86fcc47b4d1 drivers/gpu/drm/ingenic/ingenic-drm.c Paul Cercueil
2019-06-03 451
3c9bea4ef32bdc drivers/gpu/drm/ingenic/ingenic-drm-drv.c Paul Cercueil
2020-07-16 452 static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
7c11b99a8e58c0 drivers/gpu/drm/ingenic/ingenic-drm-drv.c Maxime Ripard
2021-02-19 453struct
drm_atomic_state *state)
3c9bea4ef32bdc drivers/gpu/drm/ingenic/ingenic-drm-drv.c Paul Cercueil
2020-07-16 454 {
0b6aaf9d76f042 drivers/gpu/drm/ingenic/ingenic-drm-drv.c Maxime Ripard
2021-02-19 455 struct drm_plane_state *old_plane_state =
drm_atomic_get_old_plane_state(state,
0b6aaf9d76f042 drivers/gpu/drm/ingenic/ingenic-drm-drv.c Maxime Ripard
2021-02-19 456
plane);
7c11b99a8e58c0 drivers/gpu/drm/ingenic/ingenic-drm-drv.c Maxime Ripard
2021-02-19 457 struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_s
Re: [Freedreno] [PATCH] drm/msm: Make msm_gem_free_object() static
On 6/13/2022 1:49 PM, Rob Clark wrote:
From: Rob Clark
Misc small cleanup I noticed. Not called from another object file since
3c9edd9c85f5 ("drm/msm: Introduce GEM object funcs")
Signed-off-by: Rob Clark
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 35845e273d81..3ef7ada59392 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1004,7 +1004,7 @@ void msm_gem_describe_objects(struct list_head *list,
struct seq_file *m)
#endif
/* don't call directly! Use drm_gem_object_put() */
-void msm_gem_free_object(struct drm_gem_object *obj)
+static void msm_gem_free_object(struct drm_gem_object *obj)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct drm_device *dev = obj->dev;
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 6b7d5bb3b575..d608339c1643 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -175,7 +175,6 @@ void msm_gem_active_get(struct drm_gem_object *obj, struct
msm_gpu *gpu);
void msm_gem_active_put(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
int msm_gem_cpu_fini(struct drm_gem_object *obj);
-void msm_gem_free_object(struct drm_gem_object *obj);
int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
uint32_t size, uint32_t flags, uint32_t *handle, char *name);
struct drm_gem_object *msm_gem_new(struct drm_device *dev,
[PATCH v2] drm/msm: use for_each_sgtable_sg to iterate over scatterlist
The dma_map_sgtable() call (used to invalidate cache) overwrites sgt->nents
with 1, so msm_iommu_pagetable_map maps only the first physical segment.
To fix this problem use for_each_sgtable_sg(), which uses orig_nents.
Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
Signed-off-by: Jonathan Marek
---
v2: use for_each_sgtable_sg and update commit message
drivers/gpu/drm/msm/msm_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index bcaddbba564df..a54ed354578b5 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -58,7 +58,7 @@ static int msm_iommu_pagetable_map(struct msm_mmu *mmu, u64
iova,
u64 addr = iova;
unsigned int i;
- for_each_sg(sgt->sgl, sg, sgt->nents, i) {
+ for_each_sgtable_sg(sgt, sg, i) {
size_t size = sg->length;
phys_addr_t phys = sg_phys(sg);
--
2.26.1
[PATCH v5] drm/msm/dp: force link training for display resolution change
During display resolution changes display have to be disabled first
followed by display enabling with new resolution. Display disable
will turn off both pixel clock and main link clock so that main link
have to be re-trained during display enable to have new video stream
flow again. At current implementation, display enable function manually
kicks up irq_hpd_handle which will read panel link status and start link
training if link status is not in sync state. However, there is rare
case that a particular panel links status keep staying in sync for
some period of time after main link had been shut down previously at
display disabled. Main link retraining will not be executed by
irq_hdp_handle() if the link status read from panel shows it is in
sync state. If this was happen, then video stream of newer display
resolution will fail to be transmitted to panel due to main link is
not in sync between host and panel. This patch force main link always
be retrained during display enable procedure to prevent this rare
failed case from happening. Also this implementation are more
efficient than manual kicking off irq_hpd_handle function.
Changes in v2:
-- set force_link_train flag on DP only (is_edp == false)
Changes in v3:
-- revise commit text
-- add Fixes tag
Changes in v4:
-- revise commit text
Changes in v5:
-- fix spelling at commit text
Fixes: 62671d2ef24b ("drm/msm/dp: fixes wrong connection state caused by
failure of link train")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 6 +++---
drivers/gpu/drm/msm/dp/dp_ctrl.h| 2 +-
drivers/gpu/drm/msm/dp/dp_display.c | 15 ---
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index af7a80c..bea93eb 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1551,7 +1551,7 @@ static int dp_ctrl_process_phy_test_request(struct
dp_ctrl_private *ctrl)
ret = dp_ctrl_on_link(&ctrl->dp_ctrl);
if (!ret)
- ret = dp_ctrl_on_stream(&ctrl->dp_ctrl);
+ ret = dp_ctrl_on_stream(&ctrl->dp_ctrl, false);
else
DRM_ERROR("failed to enable DP link controller\n");
@@ -1807,7 +1807,7 @@ static int dp_ctrl_link_retrain(struct dp_ctrl_private
*ctrl)
return dp_ctrl_setup_main_link(ctrl, &training_step);
}
-int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl)
+int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl, bool force_link_train)
{
int ret = 0;
bool mainlink_ready = false;
@@ -1848,7 +1848,7 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl)
return 0;
}
- if (!dp_ctrl_channel_eq_ok(ctrl))
+ if (force_link_train || !dp_ctrl_channel_eq_ok(ctrl))
dp_ctrl_link_retrain(ctrl);
/* stop txing train pattern to end link training */
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.h b/drivers/gpu/drm/msm/dp/dp_ctrl.h
index 0745fde..b563e2e 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.h
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.h
@@ -21,7 +21,7 @@ struct dp_ctrl {
};
int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl);
-int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl);
+int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl, bool force_link_train);
int dp_ctrl_off_link_stream(struct dp_ctrl *dp_ctrl);
int dp_ctrl_off_link(struct dp_ctrl *dp_ctrl);
int dp_ctrl_off(struct dp_ctrl *dp_ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index c388323..370348d 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -872,7 +872,7 @@ static int dp_display_enable(struct dp_display_private *dp,
u32 data)
return 0;
}
- rc = dp_ctrl_on_stream(dp->ctrl);
+ rc = dp_ctrl_on_stream(dp->ctrl, data);
if (!rc)
dp_display->power_on = true;
@@ -1654,6 +1654,7 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
int rc = 0;
struct dp_display_private *dp_display;
u32 state;
+ bool force_link_train = false;
dp_display = container_of(dp, struct dp_display_private, dp_display);
if (!dp_display->dp_mode.drm_mode.clock) {
@@ -1688,10 +1689,14 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
state = dp_display->hpd_state;
- if (state == ST_DISPLAY_OFF)
+ if (state == ST_DISPLAY_OFF) {
dp_display_host_phy_init(dp_display);
- dp_display_enable(dp_display, 0);
+ if (!dp->is_edp)
+ force_link_train = true;
+ }
+
+ dp_display_enable(dp_display, force_link_train);
rc = dp_display_post_enable(dp);
if (rc) {
@@ -1700,10 +1705,6 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
dp_display_unprepare(dp);
}
- /* manual kick off plug event to train link */
- if (state == ST_DISPLAY_OFF)
-
Re: [PATCH v2 7/7] drm/bridge: anx7625: Add typec_mux_set callback function
Hi Nícolas,
On Mon, Jun 13, 2022 at 1:51 PM Nícolas F. R. A. Prado
wrote:
>
> Hi Prashant,
>
> On Thu, Jun 09, 2022 at 06:09:46PM +, Prashant Malani wrote:
> > From: Pin-Yen Lin
> >
> > Add the callback function when the driver receives state
> > changes of the Type-C port. The callback function configures the
> > crosspoint switch of the anx7625 bridge chip, which can change the
> > output pins of the signals according to the port state.
> >
> > Signed-off-by: Pin-Yen Lin
> > Signed-off-by: Prashant Malani
> > ---
> >
> > Changes since v2:
> > - No changes.
> >
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 58 +++
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 13 +
> > 2 files changed, 71 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index d41a21103bd3..2c308d12fab2 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -2582,9 +2583,66 @@ static void anx7625_runtime_disable(void *data)
> > pm_runtime_disable(data);
> > }
> >
> > +static void anx7625_set_crosspoint_switch(struct anx7625_data *ctx,
> > + enum typec_orientation orientation)
> > +{
> > + if (orientation == TYPEC_ORIENTATION_NORMAL) {
> > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
> > + SW_SEL1_SSRX_RX1 | SW_SEL1_DPTX0_RX2);
> > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
> > + SW_SEL2_SSTX_TX1 | SW_SEL2_DPTX1_TX2);
> > + } else if (orientation == TYPEC_ORIENTATION_REVERSE) {
> > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
> > + SW_SEL1_SSRX_RX2 | SW_SEL1_DPTX0_RX1);
> > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
> > + SW_SEL2_SSTX_TX2 | SW_SEL2_DPTX1_TX1);
> > + }
> > +}
> > +
> > +static void anx7625_typec_two_ports_update(struct anx7625_data *ctx)
> > +{
> > + if (ctx->typec_ports[0].dp_connected &&
> > ctx->typec_ports[1].dp_connected)
> > + /* Both ports available, do nothing to retain the current
> > one. */
> > + return;
> > + else if (ctx->typec_ports[0].dp_connected)
> > + anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_NORMAL);
> > + else if (ctx->typec_ports[1].dp_connected)
> > + anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_REVERSE);
> > +}
> > +
> > static int anx7625_typec_mux_set(struct typec_mux_dev *mux,
> >struct typec_mux_state *state)
> > {
> > + struct anx7625_port_data *data = typec_mux_get_drvdata(mux);
> > + struct anx7625_data *ctx = data->ctx;
> > + struct device *dev = &ctx->client->dev;
> > +
> > + bool old_dp_connected = (ctx->typec_ports[0].dp_connected ||
> > + ctx->typec_ports[1].dp_connected);
>
> Here you're assuming you have 2 switches. Given that this on its own doesn't
> do
> anything, just move it after the
>
> if (ctx->num_typec_switches == 1)
> return 0;
>
> check.
Sure. I will fix this up in v3. Thanks!
>
> Thanks,
> Nícolas
>
> > + bool new_dp_connected;
> > +
> > + if (ctx->num_typec_switches == 1)
> > + return 0;
> > +
> > + dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n",
> > + ctx->typec_ports[0].dp_connected,
> > ctx->typec_ports[1].dp_connected);
> > +
> > + data->dp_connected = (state->alt && state->alt->svid ==
> > USB_TYPEC_DP_SID &&
> > + state->alt->mode == USB_TYPEC_DP_MODE);
> > +
> > + new_dp_connected = (ctx->typec_ports[0].dp_connected ||
> > + ctx->typec_ports[1].dp_connected);
> > +
> > + /* dp on, power on first */
> > + if (!old_dp_connected && new_dp_connected)
> > + pm_runtime_get_sync(dev);
> > +
> > + anx7625_typec_two_ports_update(ctx);
> > +
> > + /* dp off, power off last */
> > + if (old_dp_connected && !new_dp_connected)
> > + pm_runtime_put_sync(dev);
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > index 76cfc64f7574..7d6c6fdf9a3a 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > @@ -55,6 +55,18 @@
> > #define HPD_STATUS_CHANGE 0x80
> > #define HPD_STATUS 0x80
> >
> > +#define TCPC_SWITCH_0 0xB4
> > +#define SW_SEL1_DPTX0_RX2 BIT(0)
> > +#define SW_SEL1_DPTX0_RX1 BIT(1)
> > +#define SW_SEL1_SSRX_RX2 BIT(4)
> > +#define SW_SEL1_SSRX_RX1 BIT(5)
> > +
> > +#define TCPC_SWITCH_1 0xB5
> > +#define SW_SEL2
[PATCH v5 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
completely different from the LCDIFv3 found in i.MX23 in that it has
a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space.
Add a separate driver which is really a fork of MXSFB driver with the
i.MX8MP LCDIF variant handling filled in.
Tested-by: Alexander Stein
Tested-by: Martyn Welch
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
V2: - Drop the pitch check from lcdif_fb_create()
- Drop connector caching
- Wait for shadow load bit to be cleared in IRQ handler
- Make all clock mandatory and grab them all by name
- Wait for EN to be cleared in lcdif_disable_controller
- Rename to imx-lcdif
- Move shadow load to atomic_flush
V3: - Invert DE polarity to match MX8MPRM datasheet
- Enable CSC in RGB to YUV mode for MEDIA_BUS_FMT_UYVY8_1X16
V4: - Drop lcdif_overlay_plane_formats, it is unused
V5: - Add TB from Martyn
- Drop lcdif_fb_create in favor of drm_gem_fb_create
- Pull in mxsfb/ directory from drm top level Makefile
- Drop busy polling of CTRLDESCL0_5_SHADOW_LOAD_EN in irq handler
- Use devm_request_irq
- Drop useless dev.of_node validity check in probe
- Drop lcdif_*_axi_clk() prototypes
- Invert HS/VS polarity
- Drop polling from lcdif_reset_block()
- Add TB from Alexander
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/mxsfb/Kconfig | 16 +
drivers/gpu/drm/mxsfb/Makefile | 2 +
drivers/gpu/drm/mxsfb/lcdif_drv.c | 342
drivers/gpu/drm/mxsfb/lcdif_drv.h | 44 +++
drivers/gpu/drm/mxsfb/lcdif_kms.c | 482 +
drivers/gpu/drm/mxsfb/lcdif_regs.h | 257 +++
7 files changed, 1144 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_drv.c
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_drv.h
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_kms.c
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_regs.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 13ef240b3d2b2..75b5ac7c2663c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -130,7 +130,7 @@ obj-y += bridge/
obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
obj-y += hisilicon/
-obj-$(CONFIG_DRM_MXSFB)+= mxsfb/
+obj-y += mxsfb/
obj-y += tiny/
obj-$(CONFIG_DRM_PL111) += pl111/
obj-$(CONFIG_DRM_TVE200) += tve200/
diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 987170e16ebd6..873551b4552f5 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -19,3 +19,19 @@ config DRM_MXSFB
i.MX28, i.MX6SX, i.MX7 and i.MX8M).
If M is selected the module will be called mxsfb.
+
+config DRM_IMX_LCDIF
+ tristate "i.MX LCDIFv3 LCD controller"
+ depends on DRM && OF
+ depends on COMMON_CLK
+ select DRM_MXS
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_PANEL
+ select DRM_PANEL_BRIDGE
+ help
+ Choose this option if you have an LCDIFv3 LCD controller.
+ Those devices are found in various i.MX SoC (i.MX8MP,
+ i.MXRT).
+
+ If M is selected the module will be called imx-lcdif.
diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
index 26d153896d720..3fa44059b9d85 100644
--- a/drivers/gpu/drm/mxsfb/Makefile
+++ b/drivers/gpu/drm/mxsfb/Makefile
@@ -1,3 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
mxsfb-y := mxsfb_drv.o mxsfb_kms.o
obj-$(CONFIG_DRM_MXSFB)+= mxsfb.o
+imx-lcdif-y := lcdif_drv.o lcdif_kms.o
+obj-$(CONFIG_DRM_IMX_LCDIF) += imx-lcdif.o
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
b/drivers/gpu/drm/mxsfb/lcdif_drv.c
new file mode 100644
index 0..021d5511d4a6c
--- /dev/null
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2022 Marek Vasut
+ *
+ * This code is based on drivers/gpu/drm/mxsfb/mxsfb*
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "lcdif_drv.h"
+#include "lcdif_regs.h"
+
+static const struct drm_mode_config_funcs lcdif_mode_config_funcs = {
+ .fb_create = drm_gem_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static const struct drm_mode_config_helper_funcs lcdif_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
+static int
[PATCH v5 1/2] dt-bindings: lcdif: Add compatible for i.MX8MP
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. However, except for the complete bit reshuffling, this is still LCDIF and it still works like one. Acked-by: Rob Herring Signed-off-by: Marek Vasut Cc: Alexander Stein Cc: Laurent Pinchart Cc: Lucas Stach Cc: Peng Fan Cc: Rob Herring Cc: Robby Cai Cc: Sam Ravnborg Cc: Stefan Agner Cc: devicet...@vger.kernel.org --- V2: No change V3: No change V4: No change V5: Add AB from Rob --- Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index 900a56cae80e6..876015a44a1e6 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -20,6 +20,7 @@ properties: - fsl,imx23-lcdif - fsl,imx28-lcdif - fsl,imx6sx-lcdif + - fsl,imx8mp-lcdif - items: - enum: - fsl,imx6sl-lcdif -- 2.35.1
Re: [PATCH v4 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant
On 5/30/22 11:27, Alexander Stein wrote: Hi Marek, Hi, [...] I got this working, somehow. The root cause was that the LDB clock was not the media_disp2_pix_root_clk clock * 7, which is mandatory for LVDS (single link). excerpt from clk_summary: video_pll1_out 2 2 0 59400 0 0 5 Y media_ldb 1 1 0 59400 0 0 5 Y media_disp2_pix 1 1 06600 0 0 5 Y media_ldb is too high (should be 46200). I wonder why media_ldb is not a child from media_disp2_pix (or vice versa) when there is a hard dependency. Probably that's a matter of imx8mp.dtsi patch ? There are several solutions: 1. Set video_pll1 to 103950 and adjust requested pixel clock of the panel (7425 in this case). Now the dividers match hit the clock rates exactly. But this renders the display list in panel-simple a bit useless. 2. Adjust video_pll1_out only (e.g. 478757145). Now the calculated clocks comply to their mandated ratio. But this might affect other users, e.g. DSI displays 3. Improve fsl_ldb_atomic_check to set adjusted_mode.clock to an achievable clock. This way lcdif will pick the new pixelclock to match their ratio. But there is more work necessary, e.g. ensure the new pixelclock is in the valid range of the display. So far, I'm adjusting the LDB clock to match the panel in DT, but that indeed could use an improvement. To summarize: For both HDMI and LVDS using changes unrelated to this lcdif driver: Tested-by: Alexander Stein Thanks
RE: DRM/KMS PWL API Thoughts and Questions
> -Original Message- > From: Harry Wentland > Sent: Saturday, June 11, 2022 1:59 AM > To: Pekka Paalanen ; sebast...@sebastianwick.net; > Shankar, Uma > Cc: Vitaly Prosyak ; Sharma, Shashank > ; Lakha, Bhawanpreet > ; Deucher, Alexander > ; Alex Hung ; dri-devel de...@lists.freedesktop.org>; amd-gfx list ; > intel- > g...@lists.freedesktop.org; Modem, Bhanuprakash > > Subject: DRM/KMS PWL API Thoughts and Questions > > (I'm sending this as an email as lowest common denominator but feel an issue > on the > color-and-hdr repo would be a better interface for productive discussion. > Please pop > over to https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/10 if you > agree. > Hopefully we can drive the discussion there but if there is a strong > preference for > email that works as well. :) ) > > I've wanted to start a thread to discuss the use of PWL APIs that were > introduced by > Uma a year ago and for which Bhanuprakash provided IGT tests. I have come to > like > the API but as we're getting closer to a real-world use of it I have a few > questions > and comments. As with a lot of complex APIs the devil is in the details. Some > of > those details are currently underspecified, or underdocumented and it's > important > that we all interpret the API the same way. Thanks Harry for starting this thread. Adding Ville to the discussion as well as the original design is his brain child. We can discuss on the issue you created if all others agree. > **The API** > > The original patches posted by Uma: > https://patchwork.freedesktop.org/series/90822/ > https://patchwork.freedesktop.org/series/90826/ > > The IGT tests for PWL API: > https://patchwork.freedesktop.org/series/96895/ > > I've rebased the kernel patches on a slightly more recent kernel, along with > an AMD > implementation: > https://gitlab.freedesktop.org/hwentland/linux/-/tree/color-and-hdr > > I've also rebased them on an IGT tree, but that's not too up-to-date: > https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/color-and-hdr > > > **Why do I like the API?** > > In order to allow HW composition of HDR planes in linear space we need the > ability > to program at least a per-CRTC regamma (inv_EOTF) to go from linear to wire > format post-blending. Since userspace might want to apply corrections on top > of a > simple transfer function (such as PQ, BT.709, etc.) it would like a way to > set a custom > LUT. > > The existing CRTC gamma LUT defines equally spaced entries. As Pekka shows in > [1] > equally-spaced LUTs have unacceptable error for regamma/inv_EOTF. Hence we > need finer granularity of our entries near zero while coarse granularity > works fine > toward the brighter values. > > [1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/merge_requests/9 > > HW (at least AMD and Intel HW) implements this ability as segmented piece-wise > linear LUTs. These define segments of equally spaced entries. These segments > are > constrained by the HW implementation. I like how the PWL API allows different > drivers to specify the constraints imposed by different HW while allowing > userspace > a generic way of parsing the PWL. This also avoids complex calculations in > the kernel > driver, which might be required for other APIs one could envision. If anyone > likes I > can elaborate on some ideas for an alternate API, though all of them will > require > non-trivial transformations by the kernel driver in order to program them to > HW. > I feel the current design fits best to most of the implementations, even legacy API/hardware can be defined using the proposed UAPI's. Its good that we are in agreement and we can surely iron out the UAPI and document the expectations. > **Nitpicks** > > The API defines everything inside the segments, including flags and values > that apply > to the entire PWL, such as DRM_MODE_LUT_GAMMA, > DRM_MODE_LUT_REFLECT_NEGATIVE, input_bpc, and output_bpc. If these don't > stay constant for segments it might complicate the interpretation of > segments. I > suggest we consider these as effectively applying to the entire PWL. We could > encode them in an overall drm_color_lut struct that includes an array of > drm_color_lut_range but that's probably not necessary, hence why I called > this out > as a nitpick. I would just like us to be aware of this ambiguity and document > that > these values applies to the entire PWL. It can be done, no concerns as such. > > **How to read the PWL** > > Let me first give a summary for how this LUT is used in userspace. If you're > familiar > with this please review and comment if I got things wrong. As I mentioned, a > lot of > this is underspecified at the moment so you're reading my interpretation. > > You can see this behavior in plane_degamma_test [2] in the kms_color.c IGT > test > suite. I suggest the plane_degamma_test here here instead of the > test_pipe_gamma > test as the latter still has Intelisms (assu
Re: [PATCH v2 0/7] usb: typec: Introduce typec-switch binding
On Thu, Jun 09, 2022 at 06:09:39PM +, Prashant Malani wrote: > This series introduces a binding for Type-C data lane switches. These > control the routing and operating modes of USB Type-C data lanes based > on the PD messaging from the Type-C port driver regarding connected > peripherals. > > The first patch introduces a change to the Type-C mux class mode-switch > matching code, while the second adds a config guard to a Type-C header. > The next couple of patches introduce the new "typec-switch" binding as > well as one user of it (the ANX7625 drm bridge). > > The remaining patches add functionality to the anx7625 driver to > register the mode-switches, as well as program its crosspoint > switch depending on which Type-C port has a DisplayPort (DP) peripheral > connected to it. > > v1: > https://lore.kernel.org/linux-usb/20220607190131.1647511-1-pmal...@chromium.org/ > > Changes since v1: > - Fixed function signature error in "else case" of typec_mux.h > - typec-switch.yaml: Fixed indentation, compatible, and node names in > examples. > - anx7625.yaml: > + Introduced patternProperties for "switch" children (suggested by > Krzysztof Kozlowski). > + Added unevaluatedProperties descriptor (suggested by Krzysztof > Kozlowski). > + Added "address-cells" and "size-cells" properties to "switches". > > Pin-Yen Lin (1): > drm/bridge: anx7625: Add typec_mux_set callback function > > Prashant Malani (6): > usb: typec: mux: Allow muxes to specify mode-switch > usb: typec: mux: Add CONFIG guards for functions > dt-bindings: usb: Add Type-C switch binding > dt-bindings: drm/bridge: anx7625: Add mode-switch support > drm/bridge: anx7625: Register number of Type C switches > drm/bridge: anx7625: Register Type-C mode switches For the whole series, Reviewed-by: Nícolas F. R. A. Prado Tested-by: Nícolas F. R. A. Prado Tested that external display works on both ports of mt8192-asurada-spherion. Thanks, Nícolas > > .../display/bridge/analogix,anx7625.yaml | 63 > .../devicetree/bindings/usb/typec-switch.yaml | 74 + > drivers/gpu/drm/bridge/analogix/anx7625.c | 151 ++ > drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +++ > drivers/usb/typec/mux.c | 8 +- > include/linux/usb/typec_mux.h | 38 + > 6 files changed, 352 insertions(+), 2 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/typec-switch.yaml > > -- > 2.36.1.476.g0c4daa206d-goog >
Re: [PATCH v2 7/7] drm/bridge: anx7625: Add typec_mux_set callback function
Hi Prashant,
On Thu, Jun 09, 2022 at 06:09:46PM +, Prashant Malani wrote:
> From: Pin-Yen Lin
>
> Add the callback function when the driver receives state
> changes of the Type-C port. The callback function configures the
> crosspoint switch of the anx7625 bridge chip, which can change the
> output pins of the signals according to the port state.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Prashant Malani
> ---
>
> Changes since v2:
> - No changes.
>
> drivers/gpu/drm/bridge/analogix/anx7625.c | 58 +++
> drivers/gpu/drm/bridge/analogix/anx7625.h | 13 +
> 2 files changed, 71 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index d41a21103bd3..2c308d12fab2 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -2582,9 +2583,66 @@ static void anx7625_runtime_disable(void *data)
> pm_runtime_disable(data);
> }
>
> +static void anx7625_set_crosspoint_switch(struct anx7625_data *ctx,
> + enum typec_orientation orientation)
> +{
> + if (orientation == TYPEC_ORIENTATION_NORMAL) {
> + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
> + SW_SEL1_SSRX_RX1 | SW_SEL1_DPTX0_RX2);
> + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
> + SW_SEL2_SSTX_TX1 | SW_SEL2_DPTX1_TX2);
> + } else if (orientation == TYPEC_ORIENTATION_REVERSE) {
> + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
> + SW_SEL1_SSRX_RX2 | SW_SEL1_DPTX0_RX1);
> + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
> + SW_SEL2_SSTX_TX2 | SW_SEL2_DPTX1_TX1);
> + }
> +}
> +
> +static void anx7625_typec_two_ports_update(struct anx7625_data *ctx)
> +{
> + if (ctx->typec_ports[0].dp_connected &&
> ctx->typec_ports[1].dp_connected)
> + /* Both ports available, do nothing to retain the current one.
> */
> + return;
> + else if (ctx->typec_ports[0].dp_connected)
> + anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_NORMAL);
> + else if (ctx->typec_ports[1].dp_connected)
> + anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_REVERSE);
> +}
> +
> static int anx7625_typec_mux_set(struct typec_mux_dev *mux,
>struct typec_mux_state *state)
> {
> + struct anx7625_port_data *data = typec_mux_get_drvdata(mux);
> + struct anx7625_data *ctx = data->ctx;
> + struct device *dev = &ctx->client->dev;
> +
> + bool old_dp_connected = (ctx->typec_ports[0].dp_connected ||
> + ctx->typec_ports[1].dp_connected);
Here you're assuming you have 2 switches. Given that this on its own doesn't do
anything, just move it after the
if (ctx->num_typec_switches == 1)
return 0;
check.
Thanks,
Nícolas
> + bool new_dp_connected;
> +
> + if (ctx->num_typec_switches == 1)
> + return 0;
> +
> + dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n",
> + ctx->typec_ports[0].dp_connected,
> ctx->typec_ports[1].dp_connected);
> +
> + data->dp_connected = (state->alt && state->alt->svid ==
> USB_TYPEC_DP_SID &&
> + state->alt->mode == USB_TYPEC_DP_MODE);
> +
> + new_dp_connected = (ctx->typec_ports[0].dp_connected ||
> + ctx->typec_ports[1].dp_connected);
> +
> + /* dp on, power on first */
> + if (!old_dp_connected && new_dp_connected)
> + pm_runtime_get_sync(dev);
> +
> + anx7625_typec_two_ports_update(ctx);
> +
> + /* dp off, power off last */
> + if (old_dp_connected && !new_dp_connected)
> + pm_runtime_put_sync(dev);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> b/drivers/gpu/drm/bridge/analogix/anx7625.h
> index 76cfc64f7574..7d6c6fdf9a3a 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> @@ -55,6 +55,18 @@
> #define HPD_STATUS_CHANGE 0x80
> #define HPD_STATUS 0x80
>
> +#define TCPC_SWITCH_0 0xB4
> +#define SW_SEL1_DPTX0_RX2 BIT(0)
> +#define SW_SEL1_DPTX0_RX1 BIT(1)
> +#define SW_SEL1_SSRX_RX2 BIT(4)
> +#define SW_SEL1_SSRX_RX1 BIT(5)
> +
> +#define TCPC_SWITCH_1 0xB5
> +#define SW_SEL2_DPTX1_TX2 BIT(0)
> +#define SW_SEL2_DPTX1_TX1 BIT(1)
> +#define SW_SEL2_SSTX_TX2 BIT(4)
> +#define SW_SEL2_SSTX_TX1 BIT(5)
> +
> / END of I2C Address 0x58 /
>
> /***/
> @@ -444,6 +456,7 @@ struct anx7625_i2c_client {
> };
>
> struct anx7625_port_data {
> + bool dp_connected;
>
[PATCH] drm/msm/gem: Drop obj lock in msm_gem_free_object()
From: Rob Clark
The only reason we grabbed the lock was to satisfy a bunch of places
that WARN_ON() if called without the lock held. But this angers lockdep
which doesn't realize no one else can be holding the lock by the time we
end up destroying the object (and sees what would otherwise be a locking
inversion between reservation_ww_class_mutex and fs_reclaim).
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/14
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 8
drivers/gpu/drm/msm/msm_gem.h | 14 +-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 3ef7ada59392..ccc7e6d8cc30 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1020,8 +1020,6 @@ static void msm_gem_free_object(struct drm_gem_object
*obj)
list_del(&msm_obj->mm_list);
mutex_unlock(&priv->mm_lock);
- msm_gem_lock(obj);
-
/* object should not be on active list: */
GEM_WARN_ON(is_active(msm_obj));
@@ -1037,17 +1035,11 @@ static void msm_gem_free_object(struct drm_gem_object
*obj)
put_iova_vmas(obj);
- /* dma_buf_detach() grabs resv lock, so we need to unlock
-* prior to drm_prime_gem_destroy
-*/
- msm_gem_unlock(obj);
-
drm_prime_gem_destroy(obj, msm_obj->sgt);
} else {
msm_gem_vunmap(obj);
put_pages(obj);
put_iova_vmas(obj);
- msm_gem_unlock(obj);
}
drm_gem_object_release(obj);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index d608339c1643..432032ad4aed 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -229,7 +229,19 @@ msm_gem_unlock(struct drm_gem_object *obj)
static inline bool
msm_gem_is_locked(struct drm_gem_object *obj)
{
- return dma_resv_is_locked(obj->resv);
+ /*
+* Destroying the object is a special case.. msm_gem_free_object()
+* calls many things that WARN_ON if the obj lock is not held. But
+* acquiring the obj lock in msm_gem_free_object() can cause a
+* locking order inversion between reservation_ww_class_mutex and
+* fs_reclaim.
+*
+* This deadlock is not actually possible, because no one should
+* be already holding the lock when msm_gem_free_object() is called.
+* Unfortunately lockdep is not aware of this detail. So when the
+* refcount drops to zero, we pretend it is already locked.
+*/
+ return dma_resv_is_locked(obj->resv) || (kref_read(&obj->refcount) ==
0);
}
static inline bool is_active(struct msm_gem_object *msm_obj)
--
2.36.1
[PATCH] drm/msm: Make msm_gem_free_object() static
From: Rob Clark
Misc small cleanup I noticed. Not called from another object file since
3c9edd9c85f5 ("drm/msm: Introduce GEM object funcs")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 35845e273d81..3ef7ada59392 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1004,7 +1004,7 @@ void msm_gem_describe_objects(struct list_head *list,
struct seq_file *m)
#endif
/* don't call directly! Use drm_gem_object_put() */
-void msm_gem_free_object(struct drm_gem_object *obj)
+static void msm_gem_free_object(struct drm_gem_object *obj)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct drm_device *dev = obj->dev;
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 6b7d5bb3b575..d608339c1643 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -175,7 +175,6 @@ void msm_gem_active_get(struct drm_gem_object *obj, struct
msm_gpu *gpu);
void msm_gem_active_put(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
int msm_gem_cpu_fini(struct drm_gem_object *obj);
-void msm_gem_free_object(struct drm_gem_object *obj);
int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
uint32_t size, uint32_t flags, uint32_t *handle, char *name);
struct drm_gem_object *msm_gem_new(struct drm_device *dev,
--
2.36.1
Re: [PATCH v2 5/7] drm/bridge: anx7625: Register number of Type C switches
Hi Nícolas,
On Mon, Jun 13, 2022 at 1:45 PM Nícolas F. R. A. Prado
wrote:
>
> Hi Prashant,
>
> On Thu, Jun 09, 2022 at 06:09:44PM +, Prashant Malani wrote:
> > Parse the "switches" node, if available, and count and store the number
> > of Type-C switches within it. Since we currently don't do anything with
> > this info, no functional changes are expected from this change.
> >
> > This patch sets a foundation for the actual registering of Type-C
> > switches with the Type-C connector class framework.
> >
> > Signed-off-by: Prashant Malani
> > ---
> >
> > Changes since v1:
> > - No changes.
> >
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 20
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index 53a5da6c49dd..07ed44c6b839 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -2581,6 +2581,22 @@ static void anx7625_runtime_disable(void *data)
> > pm_runtime_disable(data);
> > }
> >
> > +static int anx7625_register_typec_switches(struct device *device, struct
> > anx7625_data *ctx)
> > +{
> > + struct device_node *of = NULL;
> > + int ret = 0;
> > +
> > + of = of_get_child_by_name(device->of_node, "switches");
> > + if (!of)
> > + return -ENODEV;
> > +
> > + ctx->num_typec_switches = of_get_child_count(of);
> > + if (ctx->num_typec_switches <= 0)
> > + return -ENODEV;
>
> Since the hardware only allows at most 2 switches (based on the dt-bindings),
> you should have a define for that limit and check that it isn't exceeded here.
This is already enforced by the DT binding (see the
"patternProperties" in patch 4/7, suggested by Krzysztof in the
previous version)
>
> Thanks,
> Nícolas
>
> > +
> > + return ret;
> > +}
> > +
> > static int anx7625_i2c_probe(struct i2c_client *client,
> >const struct i2c_device_id *id)
> > {
> > @@ -2686,6 +2702,10 @@ static int anx7625_i2c_probe(struct i2c_client
> > *client,
> > if (platform->pdata.intp_irq)
> > queue_work(platform->workqueue, &platform->work);
> >
> > + ret = anx7625_register_typec_switches(dev, platform);
> > + if (ret)
> > + dev_info(dev, "Didn't register Type C switches, err: %d\n",
> > ret);
> > +
> > platform->bridge.funcs = &anx7625_bridge_funcs;
> > platform->bridge.of_node = client->dev.of_node;
> > if (!anx7625_of_panel_on_aux_bus(&client->dev))
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > index e257a84db962..d5cbca708842 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > @@ -473,6 +473,7 @@ struct anx7625_data {
> > struct drm_connector *connector;
> > struct mipi_dsi_device *dsi;
> > struct drm_dp_aux aux;
> > + int num_typec_switches;
> > };
> >
> > #endif /* __ANX7625_H__ */
> > --
> > 2.36.1.476.g0c4daa206d-goog
> >
Re: [PATCH v2 5/7] drm/bridge: anx7625: Register number of Type C switches
Hi Prashant,
On Thu, Jun 09, 2022 at 06:09:44PM +, Prashant Malani wrote:
> Parse the "switches" node, if available, and count and store the number
> of Type-C switches within it. Since we currently don't do anything with
> this info, no functional changes are expected from this change.
>
> This patch sets a foundation for the actual registering of Type-C
> switches with the Type-C connector class framework.
>
> Signed-off-by: Prashant Malani
> ---
>
> Changes since v1:
> - No changes.
>
> drivers/gpu/drm/bridge/analogix/anx7625.c | 20
> drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 53a5da6c49dd..07ed44c6b839 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -2581,6 +2581,22 @@ static void anx7625_runtime_disable(void *data)
> pm_runtime_disable(data);
> }
>
> +static int anx7625_register_typec_switches(struct device *device, struct
> anx7625_data *ctx)
> +{
> + struct device_node *of = NULL;
> + int ret = 0;
> +
> + of = of_get_child_by_name(device->of_node, "switches");
> + if (!of)
> + return -ENODEV;
> +
> + ctx->num_typec_switches = of_get_child_count(of);
> + if (ctx->num_typec_switches <= 0)
> + return -ENODEV;
Since the hardware only allows at most 2 switches (based on the dt-bindings),
you should have a define for that limit and check that it isn't exceeded here.
Thanks,
Nícolas
> +
> + return ret;
> +}
> +
> static int anx7625_i2c_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
> {
> @@ -2686,6 +2702,10 @@ static int anx7625_i2c_probe(struct i2c_client *client,
> if (platform->pdata.intp_irq)
> queue_work(platform->workqueue, &platform->work);
>
> + ret = anx7625_register_typec_switches(dev, platform);
> + if (ret)
> + dev_info(dev, "Didn't register Type C switches, err: %d\n",
> ret);
> +
> platform->bridge.funcs = &anx7625_bridge_funcs;
> platform->bridge.of_node = client->dev.of_node;
> if (!anx7625_of_panel_on_aux_bus(&client->dev))
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> b/drivers/gpu/drm/bridge/analogix/anx7625.h
> index e257a84db962..d5cbca708842 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> @@ -473,6 +473,7 @@ struct anx7625_data {
> struct drm_connector *connector;
> struct mipi_dsi_device *dsi;
> struct drm_dp_aux aux;
> + int num_typec_switches;
> };
>
> #endif /* __ANX7625_H__ */
> --
> 2.36.1.476.g0c4daa206d-goog
>
Re: [PATCH v2 3/7] dt-bindings: usb: Add Type-C switch binding
Hi Nícolas,
On Mon, Jun 13, 2022 at 1:38 PM Nícolas F. R. A. Prado
wrote:
>
> Hi Prashant,
>
> thanks for the patch. Please see sugestions below.
>
> On Thu, Jun 09, 2022 at 06:09:42PM +, Prashant Malani wrote:
> > Introduce a binding which represents a component that can control the
> > routing of USB Type-C data lines as well as address data line
> > orientation (based on CC lines' orientation).
> >
> > Signed-off-by: Prashant Malani
> > ---
> >
> > Changes since v1:
> > - Removed "items" from compatible.
> > - Fixed indentation in example.
> >
> > .../devicetree/bindings/usb/typec-switch.yaml | 74 +++
> > 1 file changed, 74 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/typec-switch.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/usb/typec-switch.yaml
> > b/Documentation/devicetree/bindings/usb/typec-switch.yaml
> > new file mode 100644
> > index ..78b0190c8543
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/typec-switch.yaml
> > @@ -0,0 +1,74 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/usb/typec-switch.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: USB Type-C Switch
> > +
> > +maintainers:
> > + - Prashant Malani
> > +
> > +description:
> > + A USB Type-C switch represents a component which routes USB Type-C data
> > + lines to various protocol host controllers (e.g USB, VESA DisplayPort,
> > + Thunderbolt etc.) depending on which mode the Type-C port, port partner
> > + and cable are operating in. It can also modify lane routing based on
> > + the orientation of a connected Type-C peripheral.
> > +
> > +properties:
> > + compatible:
> > +const: typec-switch
> > +
> > + mode-switch:
> > +type: boolean
> > +description: Specify that this switch can handle alternate mode
> > switching.
> > +
> > + orientation-switch:
> > +type: boolean
> > +description: Specify that this switch can handle orientation switching.
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +description: OF graph binding modelling data lines to the Type-C
> > switch.
> > +
> > +properties:
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: Link between the switch and a Type-C connector.
>
> Since you have a single port, you can omit the ports node.
I've kept "ports", since it should be possible to add additional ports
which connect the switch to some other entity (and kept separate from
port@0), if the individual driver desires this.
port@0 should only contain the end-point from the Type-C connector.
>
> > +
> > +required:
> > + - port@0
> > +
> > +required:
> > + - compatible
> > + - ports
> > +
> > +anyOf:
> > + - required:
> > + - mode-switch
> > + - required:
> > + - orientation-switch
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > + - |
> > +drm-bridge {
> > +usb-switch {
> > +compatible = "typec-switch";
> > +mode-switch;
> > +orientation-switch;
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +reg = <0>;
> > +anx_ep: endpoint {
> > +remote-endpoint = <&typec_controller>;
> > +};
> > +};
> > +};
>
> So instead of ports you would have just
>
>port {
>anx_ep: endpoint {
>remote-endpoint = <&typec_controller>;
>};
>};
>
> And the same simplification on patch 4, for the anx7625 dt-binding.
>
> Thanks,
> Nícolas
>
> > +};
> > +};
> > --
> > 2.36.1.476.g0c4daa206d-goog
> >
Re: [PATCH v2 3/7] dt-bindings: usb: Add Type-C switch binding
Hi Prashant,
thanks for the patch. Please see sugestions below.
On Thu, Jun 09, 2022 at 06:09:42PM +, Prashant Malani wrote:
> Introduce a binding which represents a component that can control the
> routing of USB Type-C data lines as well as address data line
> orientation (based on CC lines' orientation).
>
> Signed-off-by: Prashant Malani
> ---
>
> Changes since v1:
> - Removed "items" from compatible.
> - Fixed indentation in example.
>
> .../devicetree/bindings/usb/typec-switch.yaml | 74 +++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/typec-switch.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/typec-switch.yaml
> b/Documentation/devicetree/bindings/usb/typec-switch.yaml
> new file mode 100644
> index ..78b0190c8543
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/typec-switch.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/typec-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: USB Type-C Switch
> +
> +maintainers:
> + - Prashant Malani
> +
> +description:
> + A USB Type-C switch represents a component which routes USB Type-C data
> + lines to various protocol host controllers (e.g USB, VESA DisplayPort,
> + Thunderbolt etc.) depending on which mode the Type-C port, port partner
> + and cable are operating in. It can also modify lane routing based on
> + the orientation of a connected Type-C peripheral.
> +
> +properties:
> + compatible:
> +const: typec-switch
> +
> + mode-switch:
> +type: boolean
> +description: Specify that this switch can handle alternate mode
> switching.
> +
> + orientation-switch:
> +type: boolean
> +description: Specify that this switch can handle orientation switching.
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description: OF graph binding modelling data lines to the Type-C switch.
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Link between the switch and a Type-C connector.
Since you have a single port, you can omit the ports node.
> +
> +required:
> + - port@0
> +
> +required:
> + - compatible
> + - ports
> +
> +anyOf:
> + - required:
> + - mode-switch
> + - required:
> + - orientation-switch
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> +drm-bridge {
> +usb-switch {
> +compatible = "typec-switch";
> +mode-switch;
> +orientation-switch;
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +anx_ep: endpoint {
> +remote-endpoint = <&typec_controller>;
> +};
> +};
> +};
So instead of ports you would have just
port {
anx_ep: endpoint {
remote-endpoint = <&typec_controller>;
};
};
And the same simplification on patch 4, for the anx7625 dt-binding.
Thanks,
Nícolas
> +};
> +};
> --
> 2.36.1.476.g0c4daa206d-goog
>
Re: [PATCH] drm/bridge: tc358767: don't fixup mode polarity
On 6/10/22 20:39, Lucas Stach wrote:
It doesn't always work, as there is just a single adjusted mode, so if
parts of the display pipeline disagree on the required sync polarity
it's possible to end up with a invalid config. However it also isn't
necessary for this bridge chip, as the DPI interface has a configurable
sync polarity, so we can just set it up to match the mode.
The commit message could use a rewrite, it's not easy to figure out what
you're fixing here from the commit message.
[...]
-static bool tc_bridge_mode_fixup(struct drm_bridge *bridge,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adj)
-{
- /* Fixup sync polarities, both hsync and vsync are active low */
- adj->flags = mode->flags;
- adj->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
- adj->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
-
- return true;
-}
This is also called from tc_common_atomic_check() , remove it there too.
Re: [PATCH v5 0/9] Add new formats support to vkms
Hi Melissa, On 6/13/22 06:52, Melissa Wen wrote: On 04/04, Igor Torrente wrote: Summary === This series of patches refactor some vkms components in order to introduce new formats to the planes and writeback connector. Now in the blend function, the plane's pixels are converted to ARGB16161616 and then blended together. The CRC is calculated based on the ARGB1616161616 buffer. And if required, this buffer is copied/converted to the writeback buffer format. And to handle the pixel conversion, new functions were added to convert from a specific format to ARGB16161616 (the reciprocal is also true). Tests = This patch series was tested using the following igt tests: -t ".*kms_plane.*" -t ".*kms_writeback.*" -t ".*kms_cursor_crc*" -t ".*kms_flip.*" New tests passing --- - pipe-A-cursor-size-change - pipe-A-cursor-alpha-transparent Performance --- It's running slightly faster than the current implementation. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times: | Frametime | |::| | Implementation | Current | This commit | |:---:|:-:|:--:| | frametime range | 9~22 ms | 10~22 ms | | Average | 11.4 ms | 12.32 ms | Memory consumption == It consumes less memory than the current implementation in the common case (more detail in the commit message). | Memory consumption (output dimensions) | |:--:| | Current | This patch| |:--:|:-:| | Width * Heigth | 2 * Width | [1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4 XRGB to ARGB behavior = During the development, I decided to always fill the alpha channel of the output pixel whenever the conversion from a format without an alpha channel to ARGB16161616 is necessary. Therefore, I ignore the value received from the XRGB and overwrite the value with 0x. Primary plane and CRTC size === This patch series reworks the blend function to accept a primary plane with a different size and position from CRTC. Because now we need to fill the background, we had a loss in performance with this change --- Hi Igor, Thanks for this effort. Igor Torrente (9): drm: vkms: Alloc the compose frame using vzalloc As this first patch fixes an error on vkms, I cherry-picked it and applied to drm-misc-next. Oh right. I will skip it then! Best Regards, --- Igor Torrente For remaining patches, looking forward the next version addressing feedback and rebasing them too. Best Regards, Melissa drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES drm: vkms: Rename `vkms_composer` to `vkms_frame_info` drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation drm: vkms: Add fb information to `vkms_writeback_job` drm: vkms: Refactor the plane composer to accept new formats drm: vkms: Supports to the case where primary plane doesn't match the CRTC drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats drm: vkms: Add support to the RGB565 format Documentation/gpu/vkms.rst| 13 +- drivers/gpu/drm/drm_atomic_helper.c | 39 drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_composer.c | 325 -- drivers/gpu/drm/vkms/vkms_crtc.c | 4 + drivers/gpu/drm/vkms/vkms_drv.h | 41 +++- drivers/gpu/drm/vkms/vkms_formats.c | 298 +++ drivers/gpu/drm/vkms/vkms_formats.h | 12 + drivers/gpu/drm/vkms/vkms_plane.c | 50 ++-- drivers/gpu/drm/vkms/vkms_writeback.c | 35 ++- include/drm/drm_atomic_helper.h | 3 + 11 files changed, 596 insertions(+), 225 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h -- 2.30.2
Re: [PATCH v2 15/15] video: backlight: mt6370: Add Mediatek MT6370 support
On 6/13/22 04:11, ChiaEn Wu wrote: > diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig > index a003e02e13ce..ec1589ad88bb 100644 > --- a/drivers/video/backlight/Kconfig > +++ b/drivers/video/backlight/Kconfig > @@ -268,6 +268,15 @@ config BACKLIGHT_MAX8925 > If you have a LCD backlight connected to the WLED output of MAX8925 > WLED output, say Y here to enable this driver. > > +config BACKLIGHT_MT6370 > + tristate "Mediatek MT6370 Backlight Driver" > + depends on MFD_MT6370 > + help > + This enables support for Mediatek MT6370 Backlight driver. > + It's commonly used to drive the display WLED. There're 4 channels There are 4 channels > + inisde, and each channel supports up to 30mA of current capability inside, > + with 2048 current steps in exponential or linear mapping curves. -- ~Randy
Re: [PATCH v2 13/15] leds: mt6370: Add Mediatek MT6370 current sink type LED Indicator support
Hi-- On 6/13/22 04:11, ChiaEn Wu wrote: > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > index 6090e647daee..61e6ec416cb0 100644 > --- a/drivers/leds/Kconfig > +++ b/drivers/leds/Kconfig > @@ -244,6 +244,17 @@ config LEDS_MT6323 > This option enables support for on-chip LED drivers found on > Mediatek MT6323 PMIC. > > +config LEDS_MT6370_RGB > + tristate "LED Support for Mediatek MT6370 PMIC" > + depends on LEDS_CLASS > + depends on MFD_MT6370 > + select LINEAR_RANGE > + help > + Say Y here to enable support for MT6370_RGB LED device. > + In MT6370, there're four channel current-sink LED driver that support Please spell out "there are" instead of using an unusual contraction. Also: drivers that support > + hardware pattern for reg, pwm, breath mode. Isink4 channel PWM, What is "reg"? > + can also be used as a CHG_VIN power good indicator. -- ~Randy
Re: [PATCH v2 11/15] iio: adc: mt6370: Add Mediatek MT6370 support
Hi, On 6/13/22 04:11, ChiaEn Wu wrote: > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index 71ab0a06aa82..09576fb478ad 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -737,6 +737,15 @@ config MEDIATEK_MT6360_ADC > is used in smartphones and tablets and supports a 11 channel > general purpose ADC. > > +config MEDIATEK_MT6370_ADC > + tristate "Mediatek MT6370 ADC driver" > + depends on MFD_MT6370 > + help > + Say Y here to enable MT6370 ADC support. > + > + Integrated for System Monitoring includes is used in smartphones Please try again on the help text. I can't decode that. > + and tablets and supports a 9 channel general purpose ADC. -- ~Randy
Re: [PATCH v2 10/15] regulator: mt6370: Add mt6370 DisplayBias and VibLDO support
On 6/13/22 04:11, ChiaEn Wu wrote: > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig > index cbe0f96ca342..dcb6866dab53 100644 > --- a/drivers/regulator/Kconfig > +++ b/drivers/regulator/Kconfig > @@ -804,6 +804,14 @@ config REGULATOR_MT6360 > 2-channel buck with Thermal Shutdown and Overload Protection > 6-channel High PSRR and Low Dropout LDO. > > +config REGULATOR_MT6370 > + tristate "MT6370 SubPMIC Regulator" > + depends on MFD_MT6370 > + help > + Say Y here to enable MT6370 regulator support. > + This driver support the control for DisplayBias voltages and one supports > + general purpose LDO which commonly used to drive the vibrator. which is commonly used to drive the vibrator. -- ~Randy
Re: [PATCH v2 08/15] mfd: mt6370: Add Mediatek MT6370 support
On 6/13/22 04:11, ChiaEn Wu wrote: > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 3b59456f5545..d9a7524a3e0e 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -937,6 +937,19 @@ config MFD_MT6360 > PMIC part includes 2-channel BUCKs and 2-channel LDOs > LDO part includes 4-channel LDOs > > +config MFD_MT6370 > + tristate "Mediatek MT6370 SubPMIC" > + select MFD_CORE > + select REGMAP_I2C > + select REGMAP_IRQ > + depends on I2C > + help > + Say Y here to enable MT6370 SubPMIC functional support. > + It integrate single cell battery charger with adc monitoring, RGB integrates ADC (?) > + LEDs, dual channel flashlight, WLED backlight driver, display bias > + voltage supply, one general purpose LDO, and cc logic CC (?) What is CC? > + controller with USBPD commmunication capable. capability. -- ~Randy
Re: [PATCH v4, 0/3] add h264 decoder driver for mt8186
Le jeudi 12 mai 2022 à 11:46 +0800, Yunfei Dong a écrit : > Firstly, add mt8186 compatible and private data, then add document for > compatible "mediatek,mt8186-vcodec-dec". For mt8186 is single core > architecture, need to add new interface for h264 hardware decoder. Would be nice to take the habit of sharing fluster score for this new HW, I would expect no less then what the numbers you'd get from running over MT8195 or 92, remains nice to demonstrate that this was tested and document any oops along the way. > > Patche 1 add mt8186 compatible and private data. > Patche 2 add mt8186 compatible document. > Patche 3 add h264 single core driver. > --- > This patch depends on "support for MT8192 decoder"[1] > > [1] > https://patchwork.kernel.org/project/linux-mediatek/cover/20220512021950.29087-1-yunfei.d...@mediatek.com/ > --- > changed with v3: > - fix __iomem not reasonable, align share memory to dram. > changed with v2: > - fix sparse and smatch check fail for patch 3 > changed with v1: > - rebase driver to the latest media_stage. > --- > Yunfei Dong (3): > dt-bindings: media: mediatek: vcodec: Adds decoder dt-bindings for > mt8186 > media: mediatek: vcodec: Support MT8186 > media: mediatek: vcodec: add h264 decoder driver for mt8186 > > .../media/mediatek,vcodec-subdev-decoder.yaml | 4 +- > .../platform/mediatek/vcodec/mtk_vcodec_dec.h | 1 + > .../mediatek/vcodec/mtk_vcodec_dec_drv.c | 4 + > .../vcodec/mtk_vcodec_dec_stateless.c | 19 ++ > .../vcodec/vdec/vdec_h264_req_multi_if.c | 177 +- > 5 files changed, 203 insertions(+), 2 deletions(-) >
Re: [PATCH v4, 3/3] media: mediatek: vcodec: add h264 decoder driver for mt8186
Le jeudi 12 mai 2022 à 11:46 +0800, Yunfei Dong a écrit :
> Add h264 decode driver to support mt8186. For the architecture
> is single core, need to add new interface to decode.
>
> Signed-off-by: Yunfei Dong
> ---
> .../vcodec/vdec/vdec_h264_req_multi_if.c | 177 +-
> 1 file changed, 176 insertions(+), 1 deletion(-)
>
> diff --git
> a/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c
> b/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c
> index a96f203b5d54..1d9e753cf894 100644
> --- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c
> @@ -140,6 +140,9 @@ struct vdec_h264_slice_share_info {
> * @vsi: vsi used for lat
> * @vsi_core:vsi used for core
> *
> + * @vsi_ctx: Local VSI data for this decoding context
> + * @h264_slice_param:the parameters that hardware use to decode
> + *
> * @resolution_changed:resolution changed
> * @realloc_mv_buf: reallocate mv buffer
> * @cap_num_planes: number of capture queue plane
> @@ -157,6 +160,9 @@ struct vdec_h264_slice_inst {
> struct vdec_h264_slice_vsi *vsi;
> struct vdec_h264_slice_vsi *vsi_core;
>
> + struct vdec_h264_slice_vsi vsi_ctx;
> + struct vdec_h264_slice_lat_dec_param h264_slice_param;
> +
> unsigned int resolution_changed;
> unsigned int realloc_mv_buf;
> unsigned int cap_num_planes;
> @@ -208,6 +214,61 @@ static int vdec_h264_slice_fill_decode_parameters(struct
> vdec_h264_slice_inst *i
> return 0;
> }
>
> +static int get_vdec_sig_decode_parameters(struct vdec_h264_slice_inst *inst)
> +{
> + const struct v4l2_ctrl_h264_decode_params *dec_params;
> + const struct v4l2_ctrl_h264_sps *sps;
> + const struct v4l2_ctrl_h264_pps *pps;
> + const struct v4l2_ctrl_h264_scaling_matrix *scaling_matrix;
> + struct vdec_h264_slice_lat_dec_param *slice_param =
> &inst->h264_slice_param;
> + struct v4l2_h264_reflist_builder reflist_builder;
> + u8 *p0_reflist = slice_param->decode_params.ref_pic_list_p0;
> + u8 *b0_reflist = slice_param->decode_params.ref_pic_list_b0;
> + u8 *b1_reflist = slice_param->decode_params.ref_pic_list_b1;
> +
> + dec_params =
> + mtk_vdec_h264_get_ctrl_ptr(inst->ctx,
> V4L2_CID_STATELESS_H264_DECODE_PARAMS);
> + if (IS_ERR(dec_params))
> + return PTR_ERR(dec_params);
> +
> + sps = mtk_vdec_h264_get_ctrl_ptr(inst->ctx,
> V4L2_CID_STATELESS_H264_SPS);
> + if (IS_ERR(sps))
> + return PTR_ERR(sps);
> +
> + pps = mtk_vdec_h264_get_ctrl_ptr(inst->ctx,
> V4L2_CID_STATELESS_H264_PPS);
> + if (IS_ERR(pps))
> + return PTR_ERR(pps);
> +
> + scaling_matrix =
> + mtk_vdec_h264_get_ctrl_ptr(inst->ctx,
> V4L2_CID_STATELESS_H264_SCALING_MATRIX);
> + if (IS_ERR(scaling_matrix))
> + return PTR_ERR(scaling_matrix);
> +
> + mtk_vdec_h264_update_dpb(dec_params, inst->dpb);
> +
> + mtk_vdec_h264_copy_sps_params(&slice_param->sps, sps);
> + mtk_vdec_h264_copy_pps_params(&slice_param->pps, pps);
> + mtk_vdec_h264_copy_scaling_matrix(&slice_param->scaling_matrix,
> scaling_matrix);
> +
> + mtk_vdec_h264_copy_decode_params(&slice_param->decode_params,
> dec_params, inst->dpb);
> + mtk_vdec_h264_fill_dpb_info(inst->ctx, &slice_param->decode_params,
> + slice_param->h264_dpb_info);
> +
> + /* Build the reference lists */
> + v4l2_h264_init_reflist_builder(&reflist_builder, dec_params, sps,
> inst->dpb);
> + v4l2_h264_build_p_ref_list(&reflist_builder, p0_reflist);
> +
> + v4l2_h264_build_b_ref_lists(&reflist_builder, b0_reflist, b1_reflist);
> + /* Adapt the built lists to the firmware's expectations */
> + mtk_vdec_h264_fixup_ref_list(p0_reflist, reflist_builder.num_valid);
> + mtk_vdec_h264_fixup_ref_list(b0_reflist, reflist_builder.num_valid);
> + mtk_vdec_h264_fixup_ref_list(b1_reflist, reflist_builder.num_valid);
> + memcpy(&inst->vsi_ctx.h264_slice_params, slice_param,
> +sizeof(inst->vsi_ctx.h264_slice_params));
This function looks very redundant across multiple variants, could you try and
make a helper to reduce the duplication ?
> +
> + return 0;
> +}
> +
> static void vdec_h264_slice_fill_decode_reflist(struct vdec_h264_slice_inst
> *inst,
> struct
> vdec_h264_slice_lat_dec_param *slice_param,
> struct
> vdec_h264_slice_share_info *share_info)
> @@ -596,6 +657,120 @@ static int vdec_h264_slice_lat_decode(void *h_vdec,
> struct mtk_vcodec_mem *bs,
> return err;
> }
>
> +static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem
> *bs,
> + struct vdec_fb *unused, bool *res_chg)
> +{
>
[PATCH 6/8] drm: Remove linux/fb.h from drm_crtc.h
From: Ville Syrjälä drm_crtc.h has no need for linux/fb.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/fb.h. Quite a few placs do currently depend on linux/fb.h or other headers pulled in by it without actually including any of it directly. All of those need to be fixed up. vmwgfx also needs some weird 'TRUE' definition from somewhere. Not even sure where that is coming from tbh. Just replace that with a raw number. Cc: Zack Rusin Cc: VMware Graphics Reviewers Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c | 2 ++ drivers/gpu/drm/armada/armada_510.c | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 1 + drivers/gpu/drm/bridge/tc358764.c| 1 + drivers/gpu/drm/display/drm_dp_helper.c | 1 + drivers/gpu/drm/drm_connector.c | 1 + drivers/gpu/drm/drm_mipi_dbi.c | 1 + drivers/gpu/drm/drm_modes.c | 1 + drivers/gpu/drm/drm_of.c | 1 + drivers/gpu/drm/exynos/exynos_drm_dpi.c | 1 + drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 1 + drivers/gpu/drm/i915/display/intel_backlight.c | 1 + drivers/gpu/drm/imx/dcss/dcss-drv.c | 1 + drivers/gpu/drm/kmb/kmb_dsi.c| 1 + drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_encoder.c| 1 + drivers/gpu/drm/sti/sti_compositor.c | 1 + drivers/gpu/drm/sti/sti_gdp.c| 1 + drivers/gpu/drm/sti/sti_hda.c| 1 + drivers/gpu/drm/sti/sti_hqvdp.c | 1 + drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + drivers/gpu/drm/tilcdc/tilcdc_panel.c| 1 + drivers/gpu/drm/vc4/vc4_drv.h| 1 + drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- include/drm/drm_crtc.h | 1 - include/drm/drm_fb_helper.h | 1 + 27 files changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c index 06c595378dda..4b7d94961527 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c @@ -4,6 +4,8 @@ * Author: James.Qian.Wang * */ +#include + #include #include "komeda_dev.h" diff --git a/drivers/gpu/drm/armada/armada_510.c b/drivers/gpu/drm/armada/armada_510.c index 93d5c0a2d49a..93cd7e1a08ab 100644 --- a/drivers/gpu/drm/armada/armada_510.c +++ b/drivers/gpu/drm/armada/armada_510.c @@ -6,6 +6,7 @@ */ #include #include +#include #include #include "armada_crtc.h" #include "armada_drm.h" diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c index 43bc709e3523..50fee6a93964 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c @@ -9,6 +9,7 @@ */ #include +#include #include #include diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c index dca41ed32f8a..fdfb14aca926 100644 --- a/drivers/gpu/drm/bridge/tc358764.c +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -9,6 +9,7 @@ #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c index 8eb3172b4b36..4c7c489428c3 100644 --- a/drivers/gpu/drm/display/drm_dp_helper.c +++ b/drivers/gpu/drm/display/drm_dp_helper.c @@ -20,6 +20,7 @@ * OF THIS SOFTWARE. */ +#include #include #include #include diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 1c48d162c77e..bf271aebf531 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -32,6 +32,7 @@ #include #include +#include #include "drm_crtc_internal.h" #include "drm_internal.h" diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c index 0eda9dcb0e52..2f61f53d472f 100644 --- a/drivers/gpu/drm/drm_mipi_dbi.c +++ b/drivers/gpu/drm/drm_mipi_dbi.c @@ -5,6 +5,7 @@ * Copyright 2016 Noralf Trønnes */ +#include #include #include #include diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index a2542254233e..304004fb80aa 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -34,6 +34,7 @@ #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c index 2c1ee601f1d8..6d640d2ab4d4 100644 --- a/drivers/gpu/drm/drm_of.c +++ b/drivers/gpu/drm/drm_of.c @@ -2,6 +2,7 @@ #include #include #include +#include #include #include diff
[PATCH 4/8] drm: Drop drm_connector.h from drm_crtc.h
From: Ville Syrjälä drm_crtc.h has no need for drm_connector.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_connector.h. Signed-off-by: Ville Syrjälä --- include/drm/drm_crtc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 7fbccbe8b4c6..c404b6e81220 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -37,7 +37,6 @@ #include #include #include -#include #include #include #include @@ -45,6 +44,7 @@ #include #include +struct drm_connector; struct drm_device; struct drm_framebuffer; struct drm_mode_set; -- 2.35.1
[PATCH 8/8] drm: Remove linux/i2c.h from drm_crtc.h
From: Ville Syrjälä drm_crtc.h has no need for linux/i2c.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/i2c.h. Quite a few placs do currently depend on linux/i2c.h without actually including it directly. All of those need to be fixed up. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/bridge/chrontel-ch7033.c | 1 + drivers/gpu/drm/bridge/lontium-lt9611.c| 1 + drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + drivers/gpu/drm/exynos/exynos_dp.c | 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 1 + drivers/gpu/drm/panel/panel-simple.c | 1 + drivers/gpu/drm/sti/sti_hdmi.c | 1 + drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 1 + include/drm/drm_crtc.h | 1 - include/drm/drm_encoder_slave.h| 2 ++ 11 files changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c b/drivers/gpu/drm/bridge/chrontel-ch7033.c index 486f405c2e16..ba060277c3fd 100644 --- a/drivers/gpu/drm/bridge/chrontel-ch7033.c +++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c @@ -6,6 +6,7 @@ */ #include +#include #include #include diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c b/drivers/gpu/drm/bridge/lontium-lt9611.c index 585506eae10c..8a60e83482a0 100644 --- a/drivers/gpu/drm/bridge/lontium-lt9611.c +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c @@ -5,6 +5,7 @@ */ #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c index 310b3b194491..fdf12d4c6416 100644 --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c @@ -6,6 +6,7 @@ #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 3e1be9894ed1..25a60eb4d67c 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c index 27664f663c5a..4e3d3d5f6866 100644 --- a/drivers/gpu/drm/exynos/exynos_dp.c +++ b/drivers/gpu/drm/exynos/exynos_dp.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index b7ec6c374fbd..7c4455541dbb 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 27a8894ef5c9..7e09b11e4acf 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -23,6 +23,7 @@ #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index b3fbee7eac11..61a034a01764 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c index d8b71710e8f6..c0df5e892fa7 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c @@ -7,6 +7,7 @@ #include #include +#include #include #include #include diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index a583669eb443..ffc1cde331d3 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -25,7 +25,6 @@ #ifndef __DRM_CRTC_H__ #define __DRM_CRTC_H__ -#include #include #include #include diff --git a/include/drm/drm_encoder_slave.h b/include/drm/drm_encoder_slave.h index a09864f6d684..7214101fd731 100644 --- a/include/drm/drm_encoder_slave.h +++ b/include/drm/drm_encoder_slave.h @@ -27,6 +27,8 @@ #ifndef __DRM_ENCODER_SLAVE_H__ #define __DRM_ENCODER_SLAVE_H__ +#include + #include #include -- 2.35.1
[PATCH 7/8] drm: Remove linux/media-bus-format.h from drm_crtc.h
From: Ville Syrjälä drm_crtc.h has no need for linux/media-bus-format.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/media-bus-format.h. Quite a few placs do currently depend on linux/media-bus-format.h without actually including it directly. All of those need to be fixed up. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 1 + drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 + drivers/gpu/drm/bridge/chipone-icn6211.c | 1 + drivers/gpu/drm/bridge/display-connector.c| 1 + drivers/gpu/drm/bridge/fsl-ldb.c | 1 + drivers/gpu/drm/bridge/ite-it66121.c | 1 + drivers/gpu/drm/bridge/lontium-lt8912b.c | 1 + drivers/gpu/drm/bridge/lontium-lt9211.c | 1 + drivers/gpu/drm/bridge/lontium-lt9611.c | 1 + drivers/gpu/drm/bridge/nwl-dsi.c | 1 + drivers/gpu/drm/bridge/sii902x.c | 1 + drivers/gpu/drm/bridge/tc358767.c | 1 + drivers/gpu/drm/bridge/tc358775.c | 1 + drivers/gpu/drm/bridge/ti-dlpc3433.c | 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 + drivers/gpu/drm/bridge/ti-tfp410.c| 1 + drivers/gpu/drm/drm_bridge.c | 1 + drivers/gpu/drm/drm_of.c | 1 + drivers/gpu/drm/imx/imx-ldb.c | 1 + drivers/gpu/drm/imx/parallel-display.c| 1 + drivers/gpu/drm/mediatek/mtk_dpi.c| 1 + drivers/gpu/drm/mxsfb/mxsfb_kms.c | 1 + drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 + drivers/gpu/drm/panel/panel-raydium-rm67191.c | 1 + drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 1 + drivers/gpu/drm/panel/panel-simple.c | 1 + drivers/gpu/drm/pl111/pl111_display.c | 1 + drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 1 + drivers/gpu/drm/rockchip/rockchip_rgb.c | 1 + drivers/gpu/drm/stm/ltdc.c| 1 + drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 + drivers/gpu/drm/tidss/tidss_dispc.c | 1 + drivers/gpu/drm/vc4/vc4_dpi.c | 1 + include/drm/drm_crtc.h| 1 - 35 files changed, 34 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c index cfe4fc69277e..58184cd6ab0b 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c @@ -8,6 +8,7 @@ */ #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c index ba5f695703dc..ab63e7b11944 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c b/drivers/gpu/drm/bridge/chipone-icn6211.c index d25bc62bfebd..481c86b2406e 100644 --- a/drivers/gpu/drm/bridge/chipone-icn6211.c +++ b/drivers/gpu/drm/bridge/chipone-icn6211.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm/bridge/display-connector.c index e4d52a7e31b7..9a12449ad7b8 100644 --- a/drivers/gpu/drm/bridge/display-connector.c +++ b/drivers/gpu/drm/bridge/display-connector.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c index b2675c769a55..8d091521ccba 100644 --- a/drivers/gpu/drm/bridge/fsl-ldb.c +++ b/drivers/gpu/drm/bridge/fsl-ldb.c @@ -4,6 +4,7 @@ */ #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c index 448c58e60c11..44278d54d35d 100644 --- a/drivers/gpu/drm/bridge/ite-it66121.c +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -7,6 +7,7 @@ * */ +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c b/drivers/gpu/drm/bridge/lontium-lt8912b.c index 6a7a6983e796..28bad30dc4e5 100644 --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/bridge/lontium-lt9211.c b/drivers/gpu/drm/bridge/lontium-lt9211.c index 84d764b4139b..9a3e90427d12 100644 --- a/drivers/gpu/drm/bridge/lontium-lt9211.c +++ b/drivers/gpu/drm/brid
[PATCH 5/8] drm: Remove unnecessary junk from drm_crtc.h
From: Ville Syrjälä drm_crtc.h is including several entirely unnecessary headers, and also contains unused forward declarations. Remove it all. Signed-off-by: Ville Syrjälä --- include/drm/drm_crtc.h | 8 1 file changed, 8 deletions(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index c404b6e81220..1cbd95689f33 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -29,18 +29,12 @@ #include #include #include -#include #include -#include -#include #include -#include #include #include #include -#include #include -#include #include #include @@ -49,11 +43,9 @@ struct drm_device; struct drm_framebuffer; struct drm_mode_set; struct drm_file; -struct drm_clip_rect; struct drm_printer; struct drm_self_refresh_data; struct device_node; -struct dma_fence; struct edid; static inline int64_t U642I64(uint64_t val) -- 2.35.1
[PATCH 3/8] drm: Drop drm_blend.h from drm_crtc.h
From: Ville Syrjälä drm_crtc.h has no need for drm_blend.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_blend.h. Quite a few placs do currently depend on drm_blend.h without actually including it directly. All of those need to be fixed up. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 1 + drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 1 + drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 1 + drivers/gpu/drm/arm/malidp_planes.c| 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 1 + drivers/gpu/drm/drm_atomic.c | 1 + drivers/gpu/drm/drm_atomic_helper.c| 1 + drivers/gpu/drm/drm_atomic_state_helper.c | 1 + drivers/gpu/drm/drm_crtc.c | 1 + drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 + drivers/gpu/drm/exynos/exynos_drm_ipp.c| 1 + drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 + drivers/gpu/drm/exynos/exynos_drm_scaler.c | 1 + drivers/gpu/drm/exynos/exynos_mixer.c | 1 + drivers/gpu/drm/gud/gud_drv.c | 1 + drivers/gpu/drm/i915/display/i9xx_plane.c | 1 + drivers/gpu/drm/i915/display/intel_cursor.c| 1 + drivers/gpu/drm/i915/display/intel_fb.c| 1 + drivers/gpu/drm/i915/display/intel_fbc.c | 1 + drivers/gpu/drm/i915/display/intel_sprite.c| 1 + drivers/gpu/drm/i915/display/skl_universal_plane.c | 1 + drivers/gpu/drm/i915/intel_pm.c| 1 + drivers/gpu/drm/imx/dcss/dcss-plane.c | 1 + drivers/gpu/drm/imx/ipuv3-plane.c | 1 + drivers/gpu/drm/kmb/kmb_plane.c| 1 + drivers/gpu/drm/logicvc/logicvc_layer.c| 1 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 1 + drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 + drivers/gpu/drm/meson/meson_overlay.c | 1 + drivers/gpu/drm/meson/meson_plane.c| 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 1 + drivers/gpu/drm/nouveau/dispnv50/wndw.c| 1 + drivers/gpu/drm/omapdrm/omap_fb.c | 1 + drivers/gpu/drm/omapdrm/omap_plane.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_plane.c| 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 1 + drivers/gpu/drm/sprd/sprd_dpu.c| 1 + drivers/gpu/drm/sti/sti_plane.c| 1 + drivers/gpu/drm/stm/ltdc.c | 1 + drivers/gpu/drm/sun4i/sun4i_backend.c | 1 + drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 1 + drivers/gpu/drm/sun4i/sun4i_layer.c| 1 + drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 1 + drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 1 + drivers/gpu/drm/tegra/dc.c | 1 + drivers/gpu/drm/tegra/hub.c| 1 + drivers/gpu/drm/tidss/tidss_dispc.c| 1 + drivers/gpu/drm/tidss/tidss_plane.c| 1 + drivers/gpu/drm/vc4/vc4_plane.c| 1 + include/drm/drm_crtc.h | 1 - 57 files changed, 56 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index ad4571190a90..1228c69c32c4 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -78,6 +78,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c index 00fa56c29b3e..daa1faccd3e7 100644 --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c @@ -5,6 +5,7 @@ * */ +#include #include #include "d71_dev.h" #include "malidp_io.h" diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h index 456f3c435719..7889e380ab23 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c index e0b9f7063b20..dff22dec54b5 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c +++ b/drivers/gpu/drm/arm/displa
[PATCH 2/8] drm: Drop drm_framebuffer.h from drm_crtc.h
From: Ville Syrjälä drm_crtc.h has no need for drm_frambuffer.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_framebuffer.h. Quite a few placs do currently depend on drm_framebuffer.h without actually including it directly. All of those need to be fixed up. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h | 1 + drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 1 + drivers/gpu/drm/arm/hdlcd_crtc.c | 1 + drivers/gpu/drm/arm/malidp_crtc.c| 1 + drivers/gpu/drm/arm/malidp_mw.c | 1 + drivers/gpu/drm/arm/malidp_planes.c | 1 + drivers/gpu/drm/armada/armada_fb.h | 2 ++ drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 1 + drivers/gpu/drm/drm_atomic.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 1 + drivers/gpu/drm/drm_atomic_state_helper.c| 1 + drivers/gpu/drm/drm_atomic_uapi.c| 1 + drivers/gpu/drm/drm_crtc.c | 1 + drivers/gpu/drm/drm_crtc_helper.c| 1 + drivers/gpu/drm/drm_damage_helper.c | 1 + drivers/gpu/drm/drm_fb_helper.c | 1 + drivers/gpu/drm/drm_gem_atomic_helper.c | 1 + drivers/gpu/drm/drm_mipi_dbi.c | 1 + drivers/gpu/drm/drm_mode_config.c| 1 + drivers/gpu/drm/drm_modeset_helper.c | 1 + drivers/gpu/drm/drm_writeback.c | 1 + drivers/gpu/drm/exynos/exynos5433_drm_decon.c| 1 + drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fb.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c| 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 + drivers/gpu/drm/exynos/exynos_drm_plane.c| 1 + drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 + drivers/gpu/drm/exynos/exynos_mixer.c| 1 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 1 + drivers/gpu/drm/gma500/framebuffer.c | 1 + drivers/gpu/drm/gma500/gma_display.c | 1 + drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 + drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 + drivers/gpu/drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/imx/dcss/dcss-plane.c| 1 + drivers/gpu/drm/imx/ipuv3-plane.c| 1 + drivers/gpu/drm/kmb/kmb_plane.c | 1 + drivers/gpu/drm/logicvc/logicvc_layer.c | 1 + drivers/gpu/drm/mcde/mcde_display.c | 1 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 + drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 ++ drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 + drivers/gpu/drm/meson/meson_overlay.c| 1 + drivers/gpu/drm/meson/meson_plane.c | 1 + drivers/gpu/drm/mgag200/mgag200_mode.c | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 1 + drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 1 + drivers/gpu/drm/msm/disp/mdp_format.c| 2 ++ drivers/gpu/drm/msm/msm_debugfs.c| 1 + drivers/gpu/drm/msm/msm_fb.c | 1 + drivers/gpu/drm/msm/msm_fbdev.c | 1 + drivers/gpu/drm/mxsfb/mxsfb_kms.c| 1 + drivers/gpu/drm/omapdrm/omap_debugfs.c | 1 + drivers/gpu/drm/omapdrm/omap_fb.c| 1 + drivers/gpu/drm/omapdrm/omap_fbdev.c | 1 + drivers/gpu/drm/omapdrm/omap_plane.c | 1 + drivers/gpu/drm/pl111/pl111_display.c| 1 + drivers/gpu/drm/pl111/pl111_drv.c| 1 + drivers/gpu/drm/pl111/pl111_versatile.c | 2 ++ drivers/gpu/drm/qxl/qxl_display.c| 1 + drivers/gpu/drm/qxl/qxl_draw.c | 1 + drivers/gpu/drm/radeon/atombios_crtc.c | 1 + drivers/gpu/drm/radeon/evergreen.c | 1 + drivers/gpu/drm/radeon/r100.c| 1 + drivers/gpu/drm/radeon/radeon_device.c | 1 + drivers/gpu/drm/radeon/radeon_display.c
[PATCH 1/8] drm: Drop drm_edid.h from drm_crtc.h
From: Ville Syrjälä drm_crtc.h has no need for drm_edid.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_edid.h. Quite a few placs do currently depend on drm_edid.h without actually including it directly. All of those need to be fixed up. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/arm/malidp_mw.c | 1 + drivers/gpu/drm/aspeed/aspeed_gfx_out.c | 1 + drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 + drivers/gpu/drm/bridge/lontium-lt8912b.c| 1 + drivers/gpu/drm/bridge/parade-ps8640.c | 1 + drivers/gpu/drm/bridge/simple-bridge.c | 1 + drivers/gpu/drm/bridge/ti-tfp410.c | 1 + drivers/gpu/drm/display/drm_dp_helper.c | 1 + drivers/gpu/drm/display/drm_dp_mst_topology.c | 1 + drivers/gpu/drm/drm_client_modeset.c| 1 + drivers/gpu/drm/drm_kms_helper_common.c | 1 + drivers/gpu/drm/drm_modes.c | 1 + drivers/gpu/drm/exynos/exynos_mixer.c | 1 + drivers/gpu/drm/gma500/cdv_intel_dp.c | 1 + drivers/gpu/drm/gma500/oaktrail_hdmi.c | 1 + drivers/gpu/drm/gma500/oaktrail_lvds.c | 1 + drivers/gpu/drm/gma500/psb_intel_modes.c| 2 ++ drivers/gpu/drm/gud/gud_connector.c | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 1 + drivers/gpu/drm/i915/display/intel_lspcon.c | 1 + drivers/gpu/drm/i915/display/intel_opregion.c | 2 ++ drivers/gpu/drm/imx/imx-ldb.c | 1 + drivers/gpu/drm/imx/imx-tve.c | 1 + drivers/gpu/drm/imx/parallel-display.c | 1 + drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 + drivers/gpu/drm/omapdrm/dss/hdmi4.c | 1 + drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 + drivers/gpu/drm/panel/panel-edp.c | 1 + drivers/gpu/drm/panel/panel-simple.c| 1 + drivers/gpu/drm/qxl/qxl_display.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 1 + drivers/gpu/drm/rockchip/rk3066_hdmi.c | 1 + drivers/gpu/drm/solomon/ssd130x.c | 1 + drivers/gpu/drm/stm/ltdc.c | 1 + drivers/gpu/drm/tiny/arcpgu.c | 1 + drivers/gpu/drm/tiny/bochs.c| 1 + drivers/gpu/drm/tiny/cirrus.c | 1 + drivers/gpu/drm/tiny/gm12u320.c | 1 + drivers/gpu/drm/udl/udl_connector.c | 1 + drivers/gpu/drm/vboxvideo/vbox_mode.c | 1 + drivers/gpu/drm/virtio/virtgpu_display.c| 1 + drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++ drivers/gpu/drm/vkms/vkms_output.c | 1 + drivers/gpu/drm/vkms/vkms_writeback.c | 1 + include/drm/drm_crtc.h | 1 - 47 files changed, 49 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c index 204c869d9fe2..43de2ac8f27e 100644 --- a/drivers/gpu/drm/arm/malidp_mw.c +++ b/drivers/gpu/drm/arm/malidp_mw.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c index 6759cb88415a..4f2187025a21 100644 --- a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include "aspeed_gfx.h" diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index db2010a55674..3eb9afecd9d4 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -36,6 +36,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 01c8b80e34ec..8aadcc0aa90b 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c index 67f0f444b4e8..ba5f695703dc 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c @@ -43,6 +43,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c b/drivers/gpu/drm/bridge/lontium-lt8912b.c index c92515834ff2..6a7a6983e796 100644 --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c +++ b/drivers/gpu/drm/bridge/
[PATCH 0/8] drm: Clean up drm_crtc.h
From: Ville Syrjälä Eliminate unnecessary includes from drm_crtc.h to avoid pointless rebuilds of the entire universe when touching some random header. I didn't really feel like splitting this up per-driver since that would have ended up being metric ton of one liners. I'm thinking the conflicts (if any) should be trivial enough to deal with even with bigger patches. Also the cc list would have been massive so didn't do it. Hopefully enough people actually read dri-devel... Ville Syrjälä (8): drm: Drop drm_edid.h from drm_crtc.h drm: Drop drm_framebuffer.h from drm_crtc.h drm: Drop drm_blend.h from drm_crtc.h drm: Drop drm_connector.h from drm_crtc.h drm: Remove unnecessary junk from drm_crtc.h drm: Remove linux/fb.h from drm_crtc.h drm: Remove linux/media-bus-format.h from drm_crtc.h drm: Remove linux/i2c.h from drm_crtc.h drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 + .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + .../drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h | 1 + .../gpu/drm/arm/display/komeda/d71/d71_dev.c| 1 + drivers/gpu/drm/arm/display/komeda/komeda_kms.h | 1 + .../drm/arm/display/komeda/komeda_pipeline.c| 2 ++ .../gpu/drm/arm/display/komeda/komeda_plane.c | 1 + .../arm/display/komeda/komeda_wb_connector.c| 1 + drivers/gpu/drm/arm/hdlcd_crtc.c| 1 + drivers/gpu/drm/arm/malidp_crtc.c | 1 + drivers/gpu/drm/arm/malidp_mw.c | 2 ++ drivers/gpu/drm/arm/malidp_planes.c | 2 ++ drivers/gpu/drm/armada/armada_510.c | 1 + drivers/gpu/drm/armada/armada_fb.h | 2 ++ drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c| 1 + drivers/gpu/drm/aspeed/aspeed_gfx_out.c | 1 + drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c| 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 ++ .../gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + .../gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 2 ++ drivers/gpu/drm/bridge/chipone-icn6211.c| 1 + drivers/gpu/drm/bridge/chrontel-ch7033.c| 1 + drivers/gpu/drm/bridge/display-connector.c | 1 + drivers/gpu/drm/bridge/fsl-ldb.c| 1 + drivers/gpu/drm/bridge/ite-it66121.c| 1 + drivers/gpu/drm/bridge/lontium-lt8912b.c| 2 ++ drivers/gpu/drm/bridge/lontium-lt9211.c | 1 + drivers/gpu/drm/bridge/lontium-lt9611.c | 2 ++ drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 + drivers/gpu/drm/bridge/nwl-dsi.c| 1 + drivers/gpu/drm/bridge/parade-ps8640.c | 1 + drivers/gpu/drm/bridge/sii902x.c| 1 + drivers/gpu/drm/bridge/simple-bridge.c | 1 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + drivers/gpu/drm/bridge/tc358764.c | 1 + drivers/gpu/drm/bridge/tc358767.c | 1 + drivers/gpu/drm/bridge/tc358775.c | 1 + drivers/gpu/drm/bridge/ti-dlpc3433.c| 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 + drivers/gpu/drm/bridge/ti-tfp410.c | 2 ++ drivers/gpu/drm/display/drm_dp_helper.c | 2 ++ drivers/gpu/drm/display/drm_dp_mst_topology.c | 1 + drivers/gpu/drm/drm_atomic.c| 2 ++ drivers/gpu/drm/drm_atomic_helper.c | 2 ++ drivers/gpu/drm/drm_atomic_state_helper.c | 2 ++ drivers/gpu/drm/drm_atomic_uapi.c | 1 + drivers/gpu/drm/drm_bridge.c| 1 + drivers/gpu/drm/drm_client_modeset.c| 1 + drivers/gpu/drm/drm_connector.c | 1 + drivers/gpu/drm/drm_crtc.c | 2 ++ drivers/gpu/drm/drm_crtc_helper.c | 1 + drivers/gpu/drm/drm_damage_helper.c | 1 + drivers/gpu/drm/drm_fb_helper.c | 1 + drivers/gpu/drm/drm_gem_atomic_helper.c | 1 + drivers/gpu/drm/drm_kms_helper_common.c | 1 + drivers/gpu/drm/drm_mipi_dbi.c | 2 ++ drivers/gpu/drm/drm_mode_config.c | 1 + drivers/gpu/drm/drm_modes.c | 2 ++ drivers/gpu/drm/drm_modeset_helper.c| 1 + drivers/gpu/drm/drm_of.c| 2 ++ drivers/gpu/drm/drm_writeback.c | 1 + drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 ++ drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1 + drivers/gpu/drm/exynos/exynos_dp.c | 1 + drivers/gpu/drm/exynos/exynos_drm_dpi.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fb.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c| 2 ++ drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1 + drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 ++ drivers/gpu/drm/exynos/exynos_drm_scaler.c | 1 + drivers/gpu/drm/exynos/exynos_dr
[PATCH] drm/msm: Deprecate MSM_BO_UNCACHED harder
From: Rob Clark
Handle the demotion to MSM_BO_WC at the userspace ABI level, and fix
the remaining internal MSM_BO_UNCACHED user.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 13 +
drivers/gpu/drm/msm/msm_gem.c | 7 +++
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 57a66093e671..acc940d32ab4 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -633,12 +633,25 @@ static int msm_ioctl_gem_new(struct drm_device *dev, void
*data,
struct drm_file *file)
{
struct drm_msm_gem_new *args = data;
+ uint32_t flags = args->flags;
if (args->flags & ~MSM_BO_FLAGS) {
DRM_ERROR("invalid flags: %08x\n", args->flags);
return -EINVAL;
}
+ /*
+* Uncached CPU mappings are deprecated, as of:
+*
+* 9ef364432db4 ("drm/msm: deprecate MSM_BO_UNCACHED (map as
writecombine instead)")
+*
+* So promote them to WC.
+*/
+ if (flags & MSM_BO_UNCACHED) {
+ flags &= ~MSM_BO_CACHED;
+ flags |= MSM_BO_WC;
+ }
+
return msm_gem_new_handle(dev, file, args->size,
args->flags, &args->handle, NULL);
}
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 9a73e48a3049..35845e273d81 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -129,7 +129,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
/* For non-cached buffers, ensure the new pages are clean
* because display controller, GPU, etc. are not coherent:
*/
- if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
+ if (msm_obj->flags & MSM_BO_WC)
sync_for_device(msm_obj);
update_inactive(msm_obj);
@@ -160,7 +160,7 @@ static void put_pages(struct drm_gem_object *obj)
* pages are clean because display controller,
* GPU, etc. are not coherent:
*/
- if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
+ if (msm_obj->flags & MSM_BO_WC)
sync_for_cpu(msm_obj);
sg_free_table(msm_obj->sgt);
@@ -213,7 +213,7 @@ void msm_gem_put_pages(struct drm_gem_object *obj)
static pgprot_t msm_gem_pgprot(struct msm_gem_object *msm_obj, pgprot_t prot)
{
- if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
+ if (msm_obj->flags & MSM_BO_WC)
return pgprot_writecombine(prot);
return prot;
}
@@ -1122,7 +1122,6 @@ static int msm_gem_new_impl(struct drm_device *dev,
struct msm_gem_object *msm_obj;
switch (flags & MSM_BO_CACHE_MASK) {
- case MSM_BO_UNCACHED:
case MSM_BO_CACHED:
case MSM_BO_WC:
break;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index f99292eaf529..e59a757578df 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -952,7 +952,7 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
memptrs = msm_gem_kernel_new(drm,
sizeof(struct msm_rbmemptrs) * nr_rings,
- check_apriv(gpu, MSM_BO_UNCACHED), gpu->aspace,
&gpu->memptrs_bo,
+ check_apriv(gpu, MSM_BO_WC), gpu->aspace, &gpu->memptrs_bo,
&memptrs_iova);
if (IS_ERR(memptrs)) {
--
2.36.1
Re: [PATCH] iosys-map: Add word-sized reads
On Mon, Jun 13, 2022 at 12:58:52PM +0200, Thomas Zimmermann wrote:
Hi Lucas
Am 10.06.22 um 01:20 schrieb Lucas De Marchi:
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.
Employ a similar trick as __seqprop() by using _Generic() to generate
only the specific call based on a type-compatible variable.
For a pariticular i915 workload producing GPU context switches,
__get_engine_usage_record() is particularly hot since the engine usage
is read from device local memory with dgfx, possibly multiple times
since it's racy. Test execution time for this test shows a ~12.5%
improvement with DG2:
Before:
nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07;
median = 9.52548e+06; var = 526149;
After:
nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06;
median = 8.33955e+06; var = 333113;
Other things attempted that didn't prove very useful:
1) Change the _Generic() on x86 to just dereference the memory address
2) Change __get_engine_usage_record() to do just 1 read per loop,
comparing with the previous value read
3) Change __get_engine_usage_record() to access the fields directly as it
was before the conversion to iosys-map
(3) did gave a small improvement (~3%), but doesn't seem to scale well
to other similar cases in the driver.
Additional test by Chris Wilson using gem_create from igt with some
changes to track object creation time. This happens to accidentaly
stress this code path:
Pre iosys_map conversion of engine busyness:
lmem0: Creating262144 4KiB objects took 59274.2ms
Unpatched:
lmem0: Creating262144 4KiB objects took 108830.2ms
With readl (this patch):
lmem0: Creating262144 4KiB objects took 61348.6ms
s/readl/READ_ONCE/
lmem0: Creating262144 4KiB objects took 61333.2ms
So we do take a little bit more time than before the conversion, but
that is due to other factors: bringing the READ_ONCE back would be as
good as just doing this conversion.
Signed-off-by: Lucas De Marchi
---
If this is acceptable we should probably add the write counterpart, too.
Sending here only the read for now since this fixes the issue we are
seeing and to gather feedback.
That would not be a problem, but please only add functions that you use.
I sent v2 that includes the write as the second patch. We do use it,
it's just not in the critical path.
$ git grep iosys_map_wr drivers/
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c:
iosys_map_wr_field(&(guc_)->ads_map, 0, struct __guc_ads_blob, \
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c: iosys_map_wr_field(map_, 0,
struct guc_gt_system_info, field_, val_)
include/linux/iosys-map.h | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index e69a002d5aa4..4ae3e459419e 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -333,6 +333,20 @@ static inline void iosys_map_memset(struct iosys_map *dst,
size_t offset,
memset(dst->vaddr + offset, value, len);
}
+#ifdef CONFIG_64BIT
+#define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) \
+ u64: val_ = readq(vaddr_iomem_),
+#else
+#define __iosys_map_u64_case(val_, vaddr_iomem_)
+#endif
+
+#define __iosys_map_rd_io(val__, vaddr_iomem__, type__) _Generic(val__,
\
+ u8: val__ = readb(vaddr_iomem__), \
+ u16: val__ = readw(vaddr_iomem__), \
+ u32: val__ = readl(vaddr_iomem__), \
+ __iosys_map_rd_io_u64_case(val__, vaddr_iomem__)\
+ default: memcpy_fromio(&(val__), vaddr_iomem__, sizeof(val__)))
+
/**
* iosys_map_rd - Read a C-type value from the iosys_map
*
@@ -346,10 +360,14 @@ static inline void iosys_map_memset(struct iosys_map
*dst, size_t offset,
* Returns:
* The value read from the mapping.
*/
-#define iosys_map_rd(map__, offset__, type__) ({ \
- type__ val; \
- iosys_map_memcpy_from(&val, map__, offset__, sizeof(val)); \
- val;\
+#define iosys_map_rd(map__, offset__, type__) ({
\
+ type__ val;
\
+ if ((map__)->is_iomem) { \
+ __iosys_map_rd_io(val, (map__)->vaddr_iomem + offset__,
type__);\
+ } else {
\
+ memcpy(&val, (map__)->vaddr + offset__, sizeof(val));
\
+ }
Re: [PATCH v3 1/3] drm/rect: Add DRM_RECT_INIT() macro
On Mon, 13 Jun 2022, José Expósito wrote:
> Add a helper macro to initialize a rectangle from x, y, width and
> height information.
>
> Signed-off-by: José Expósito
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_rect.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> index 6f6e19bd4dac..e8d94fca2703 100644
> --- a/include/drm/drm_rect.h
> +++ b/include/drm/drm_rect.h
> @@ -47,6 +47,22 @@ struct drm_rect {
> int x1, y1, x2, y2;
> };
>
> +/**
> + * DRM_RECT_INIT - initialize a rectangle from x/y/w/h
> + * @x: x coordinate
> + * @y: y coordinate
> + * @w: width
> + * @h: height
> + *
> + * RETURNS:
> + * A new rectangle of the specified size.
> + */
> +#define DRM_RECT_INIT(x, y, w, h) ((struct drm_rect){ \
> + .x1 = (x), \
> + .y1 = (y), \
> + .x2 = (x) + (w), \
> + .y2 = (y) + (h) })
> +
> /**
> * DRM_RECT_FMT - printf string for &struct drm_rect
> */
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 01/19] drm/gma500: Unify *_lvds_get_max_backlight()
On Mon, Jun 13, 2022 at 7:08 PM Sam Ravnborg wrote:
>
> Hi Patrick.
>
> On Mon, Jun 13, 2022 at 02:34:18PM +0200, Patrik Jakobsson wrote:
> > These functions mostly do the same thing so unify them into one. All
> > unified lvds code will live in gma_lvds.c.
> >
> > Signed-off-by: Patrik Jakobsson
> > ---
> > +/*
> > + * Returns the maximum level of the backlight duty cycle field.
> > + */
>
> I find this function quite un-readable.
>
> > +u32 gma_lvds_get_max_backlight(struct drm_device *dev)
> > +{
> > + struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
> > + u32 retval;
> > +
> > + if (gma_power_begin(dev, false)) {
> > + retval = ((REG_READ(BLC_PWM_CTL) &
> > + BACKLIGHT_MODULATION_FREQ_MASK) >>
> > + BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> > +
> > + gma_power_end(dev);
> > + } else
> > + retval = ((dev_priv->regs.saveBLC_PWM_CTL &
> > + BACKLIGHT_MODULATION_FREQ_MASK) >>
> > + BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> > +
> > + return retval;
> > +}
>
> Maybe like this - which should be the same functionality:
>
> u32 gma_lvds_get_max_backlight(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
> u32 pwmctl;
>
> if (gma_power_begin(dev, false)) {
> pwmctl = REG_READ(BLC_PWM_CTL);
> gma_power_end(dev);
> } else {
> pwmctl = dev_priv->regs.saveBLC_PWM_CTL;
> }
>
> pwmctl = pwmctl & BACKLIGHT_MODULATION_FREQ_MASK;
> return (pwmctl >> BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> }
>
> this is more or less the same as in psb_intel_lvds_get_max_backlight().
>
> With or without this change the patch is:
> Reviewed-by: Sam Ravnborg
Hi Sam,
Thanks for having a look.
I've intentionally tried to change as little as possible from the
version I copied so that any functional change is easy to spot and the
series becomes easy to review. Would it be ok if I do cleanups as a
followup series?
-Patrik
>
> >> +
> > +
> > diff --git a/drivers/gpu/drm/gma500/gma_lvds.h
> > b/drivers/gpu/drm/gma500/gma_lvds.h
> > new file mode 100644
> > index ..2a9ce8ee3fa7
> > --- /dev/null
> > +++ b/drivers/gpu/drm/gma500/gma_lvds.h
> > @@ -0,0 +1,12 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +/*
> > + * Copyright © 2006-2011 Intel Corporation
> > + */
> > +
> > +#ifndef _GMA_LVDS_H
> > +#define _GMA_LVDS_H
> > +
> > +u32 gma_lvds_get_max_backlight(struct drm_device *dev);
> > +
> > +#endif
> > diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> > b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> > index 9c9ebf8e29c4..4913baca7ae2 100644
> > --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> > +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> > @@ -20,6 +20,7 @@
> > #include "psb_drv.h"
> > #include "psb_intel_drv.h"
> > #include "psb_intel_reg.h"
> > +#include "gma_lvds.h"
> >
> > /* The max/min PWM frequency in BPCR[31:17] - */
> > /* The smallest number is 1 (not 0) that can fit in the
> > @@ -170,25 +171,6 @@ static void oaktrail_lvds_prepare(struct drm_encoder
> > *encoder)
> > gma_power_end(dev);
> > }
> >
> > -static u32 oaktrail_lvds_get_max_backlight(struct drm_device *dev)
> > -{
> > - struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
> > - u32 ret;
> > -
> > - if (gma_power_begin(dev, false)) {
> > - ret = ((REG_READ(BLC_PWM_CTL) &
> > - BACKLIGHT_MODULATION_FREQ_MASK) >>
> > - BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> > -
> > - gma_power_end(dev);
> > - } else
> > - ret = ((dev_priv->regs.saveBLC_PWM_CTL &
> > - BACKLIGHT_MODULATION_FREQ_MASK) >>
> > - BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> > -
> > - return ret;
> > -}
> > -
> > static void oaktrail_lvds_commit(struct drm_encoder *encoder)
> > {
> > struct drm_device *dev = encoder->dev;
> > @@ -197,8 +179,7 @@ static void oaktrail_lvds_commit(struct drm_encoder
> > *encoder)
> > struct psb_intel_mode_device *mode_dev = &dev_priv->mode_dev;
> >
> > if (mode_dev->backlight_duty_cycle == 0)
> > - mode_dev->backlight_duty_cycle =
> > - oaktrail_lvds_get_max_backlight(dev);
> > + mode_dev->backlight_duty_cycle =
> > gma_lvds_get_max_backlight(dev);
> > oaktrail_lvds_set_power(dev, gma_encoder, true);
> > }
> >
> > diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
> > b/drivers/gpu/drm/gma500/psb_intel_lvds.c
> > index 7ee6c8ce103b..371c202a15ce 100644
> > --- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
> > +++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
> > @@ -18,6 +18,7 @@
> > #include "psb_drv.h"
> > #include "psb_intel_drv.h"
> > #include "psb_intel_reg.h"
> > +#include "gma_lvds.h"
> >
> > /*
> > * LVDS I2C
[PATCH] drm/msm/adreno: Defer enabling runpm until hw_init()
From: Rob Clark To avoid preventing the display from coming up before the rootfs is mounted, without resorting to packing fw in the initrd, the GPU has this limbo state where the device is probed, but we aren't ready to start sending commands to it. This is particularly problematic for a6xx, since the GMU (which requires fw to be loaded) is the one that is controlling the power/clk/icc votes. So defer enabling runpm until we are ready to call gpu->hw_init(), as that is a point where we know we have all the needed fw and are ready to start sending commands to the coproc's. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.c| 1 - 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index 8706bcdd1472..7cef8ae73c71 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_device.c +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c @@ -415,6 +415,12 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev) if (ret) return NULL; + /* +* Now that we have firmware loaded, and are ready to begin +* booting the gpu, go ahead and enable runpm: +*/ + pm_runtime_enable(&pdev->dev); + /* Make sure pm runtime is active and reset any previous errors */ pm_runtime_set_active(&pdev->dev); diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c index 4e665c806a14..e1aef4875e2f 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c @@ -1042,7 +1042,6 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, pm_runtime_set_autosuspend_delay(dev, adreno_gpu->info->inactive_period); pm_runtime_use_autosuspend(dev); - pm_runtime_enable(dev); return msm_gpu_init(drm, pdev, &adreno_gpu->base, &funcs->base, gpu_name, &adreno_gpu_config); -- 2.36.1
Re: [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays
Hello Dominik, On 6/13/22 13:39, Dominik Kierner wrote: Removed the regmap part since Andy already commented and I agree with him. >>> Splitting in VCC/VBAT and VDD and enforcing their presence is of >>> course compatibility breaking. >>> >>> https://github.com/dh-electronics/panel-solomon-ssd130x-draft/blob/drm >>> -ssd130x/drivers/gpu/drm/panel/panel-solomon-ssd130x.h#L85 >>> https://github.com/dh-electronics/panel-solomon-ssd130x-draft/blob/drm >>> -ssd130x/drivers/gpu/drm/panel/panel-solomon-ssd130x.c#L80 >>> >> >> It is a break in the DT binding indeed but on the other hand it seems that >> the >> regulator story is lacking in the current solomon,ssd1307fb.yaml anyways. >> >> That is, the binding schema only mentions a "vbat-supply" but the DRM driver >> is not >> looking for that but instead for "vcc-supply" (I think that was changed due >> some >> feedback I got on some revisions, but didn't update the DT binding). The >> fbdev >> drivers/video/fbdev/ssd1307fb.c driver does lookup "vbat-supply" but all the >> DTS and >> DTS overlays I find don't set one. >> >> Also the "vbat-supply" is not a required property in the current binding. >> One thing to >> notice is that regulator_get() and regulator_get_optional() semantics are >> confusing >> (at least for me). Since doesn't mean whether the regulator must be present >> or not >> but rather if a dummy regulator must be provided if a supply is not found. > > I always understood regulator_get_optional() as a way of not having to rely > on a dummy, > when a regulator is not present, but please correct me, if I am wrong on this. > The dummies would only be necessary for the mandatory supplies VCC and VDD. > Yes, that's what I tried to say. That's regulator_get() and not _optional() the function that will provide a dummy regulator if isn't physically present: https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L2067 > You mean this part of the documentation of regulator_get_optional(), correct?: > >> * This is intended for use by consumers for devices which can have >> * some supplies unconnected in normal use, such as some MMC devices. >> * It can allow the regulator core to provide stub supplies for other >> * supplies requested using normal regulator_get() calls without >> * disrupting the operation of drivers that can handle absent >> * supplies. > > >> In other words, I don't think that any of these supplies should be made >> required in >> the DT binding but just leave the current "vbat-supply" and add properties >> for "vcc- >> supply" and explain the relationship between these and just make the logic >> in the >> driver to override struct ssd130x_deviceinfo .need_chargepump if are present. > > My idea was to require these supplies, so that the binding correctly > reflects the manuals. Driving supply VCC and logic supply VDD, are > present throughout the SSD130x family. Only the VBAT supply is an > optional SSD1306 specific and would therefore use an optional > regulator. > > The only other device specific supply is the SSD1305's VDDIO supply, > which is mandatory and seems to be commonly connected to VDD, > so including that is likely unnecessary. > I Just wanted to mention it for completeness. > > If the device isn't controllable by Linux, a dummy would be connected > instead, just like the dummy regulator documentation states: > >> * This is useful for systems with mixed controllable and >> * non-controllable regulators, as well as for allowing testing on >> * systems with no controllable regulators. > > Which would be the case, with the SSD130x controllers. > Sometimes they are connected to external, non-controllable regulators. > > I figured that the kernel developers might be more open to a compatibility > breaking change, under the circumstance, that this is more or less a new > driver for DRM, that it provides atomic charge pump configuration for the > SSD1306 and that some (embedded) user space software might need to be > rewritten to accommodate for the transition from fbdev to DRM anyway. > But I might be wrong on this. > So for example when you just use a voltage rail in let's say a board pin header then you will need to define supply nodes with compatible = "regulator-fixed" ? That is indeed more accurate from a hardware description point of view but I'm not convinced that this is something worth to break DT backward compatibility. You also mentioned (IIUC) that the regulators could be made optional and their presence be used as an indication that an atomic charge pump configuration can be made instead of using the current ssd130x->display_settings.use_charge_pump. I think that would prefer that the latter option, but will let others to chime in since maybe I'm not correct on the preferred approach. > >>> # Static or Dynamic Configuration for SPI-Modes 3-Wire and 4-Wire >>> >>> For the SPI-protocol drivers I see two possible approaches: >>> * Dynamic configuration by determining the
Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition
On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:
On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:
On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:
On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:
On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:
On 10/06/2022 13:37, Tvrtko Ursulin wrote:
On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
1 file changed, 490 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND timeline fence array
support.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of
operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not
accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more
details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable
amount of time.
+ * Compute on the other hand can be long running. Hence it is
not appropriate
+ * for compute contexts to export request completion dma-fence
to user.
+ * The dma-fence usage will be limited to in-kernel consumption
only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See &drm_i915_gem_exec_fence.flags)
is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl call is also not
supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE 0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE
+ DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the
mapping of GPU
+ * virtual address (VA) range to the section of an object that
should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently
bound) and can
+ * be mapped to whole object or a section of the object
(partial binding).
+ * Multiple VA mappings can be created to the same section of
the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to use for binding. Same
queue can be
+ * used for both VM_BIND and VM_UNBIND calls. All submitted
bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should be 4K page aligned.
However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and
has compact page
+ * table. On those platforms, for binding device local-memory
objects, the
+ * @start should be 2M aligned, @offset and @length should be
64K aligned.
+ * Also, on those platforms, it is not allowed to bind an
device local-memory
+ * object and a system memory object in a single 2M section of
VA range.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @queue_idx: Index of queue for binding */
+ __u32 queue_idx;
I have a question here to which I did not find an answer by
browsing the old threads.
Queue index appears to be an implicit synchronisation mechanism,
right? Op
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Mon, Jun 13, 2022 at 06:33:07AM -0700, Zeng, Oak wrote: Regards, Oak -Original Message- From: Intel-gfx On Behalf Of Niranjana Vishwanathapura Sent: June 10, 2022 1:43 PM To: Landwerlin, Lionel G Cc: Intel GFX ; Maling list - DRI developers ; Hellstrom, Thomas ; Wilson, Chris P ; Vetter, Daniel ; Christian König Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document On Fri, Jun 10, 2022 at 11:18:14AM +0300, Lionel Landwerlin wrote: >On 10/06/2022 10:54, Niranjana Vishwanathapura wrote: >>On Fri, Jun 10, 2022 at 09:53:24AM +0300, Lionel Landwerlin wrote: >>>On 09/06/2022 22:31, Niranjana Vishwanathapura wrote: On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote: > On 09/06/2022 00:55, Jason Ekstrand wrote: > >On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura > wrote: > > On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko Ursulin wrote: > > > > > >On 07/06/2022 22:32, Niranjana Vishwanathapura wrote: > >>On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana >Vishwanathapura > wrote: > >>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason >Ekstrand wrote: > On Fri, Jun 3, 2022 at 6:52 PM Niranjana Vishwanathapura > wrote: > > On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel >Landwerlin > wrote: > > On 02/06/2022 23:35, Jason Ekstrand wrote: > > > > On Thu, Jun 2, 2022 at 3:11 PM Niranjana >Vishwanathapura > > wrote: > > > > On Wed, Jun 01, 2022 at 01:28:36PM -0700, Matthew > Brost wrote: > > >On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel > Landwerlin > wrote: > > >> On 17/05/2022 21:32, Niranjana Vishwanathapura > wrote: > > >> > +VM_BIND/UNBIND ioctl will immediately start > binding/unbinding > > the mapping in an > > >> > +async worker. The binding and >unbinding will > work like a > special > > GPU engine. > > >> > +The binding and unbinding operations are > serialized and > will > > wait on specified > > >> > +input fences before the operation >and will signal > the > output > > fences upon the > > >> > +completion of the operation. Due to > serialization, > completion of > > an operation > > >> > +will also indicate that all >previous operations > are also > > complete. > > >> > > >> I guess we should avoid saying "will >immediately > start > > binding/unbinding" if > > >> there are fences involved. > > >> > > >> And the fact that it's happening in an async > worker seem to > imply > > it's not > > >> immediate. > > >> > > > > Ok, will fix. > > This was added because in earlier design >binding was > deferred > until > > next execbuff. > > But now it is non-deferred (immediate in >that sense). > But yah, > this is > > confusing > > and will fix it. > > > > >> > > >> I have a question on the behavior of the bind > operation when > no > > input fence > > >> is provided. Let say I do : > > >> > > >> VM_BIND (out_fence=fence1) > > >> > > >> VM_BIND (out_fence=fence2) > > >> > > >> VM_BIND (out_fence=fence3) > > >> > > >> > > >> In what order are the fences going to >be signaled? > > >> > > >> In the order of VM_BIND ioctls? Or out >of order? > > >> > > >> Because you wrote "serialized I assume >it's : in > order > > >> > > > > Yes, in the order of VM_BIND/UNBIND >ioctls. Note that > bind and > unbind >
Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition
On Fri, Jun 10, 2022 at 09:35:14AM -0700, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 01:56:58AM -0700, Matthew Brost wrote:
On Fri, Jun 10, 2022 at 01:53:40AM -0700, Matthew Brost wrote:
On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
1 file changed, 490 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See &drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE 0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
+ * Also, on those platforms, it is not allowed to bind an device local-memory
+ * object and a system memory object in a single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @queue_idx: Index of queue for binding */
+ __u32 queue_idx;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to bind */
+ __u64 leng
Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition
On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:
On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:
On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:
On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:
On 10/06/2022 13:37, Tvrtko Ursulin wrote:
On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
1 file changed, 490 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND timeline fence
array support.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode
of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which
will not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in
reasonable amount of time.
+ * Compute on the other hand can be long running. Hence
it is not appropriate
+ * for compute contexts to export request completion
dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel
consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See
&drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl call is also
not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE 0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3,
struct drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT_USER_FENCE,
struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and
specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object
that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not
currently bound) and can
+ * be mapped to whole object or a section of the object
(partial binding).
+ * Multiple VA mappings can be created to the same
section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to use for binding.
Same queue can be
+ * used for both VM_BIND and VM_UNBIND calls. All
submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should be 4K page
aligned. However the DG2
+ * and XEHPSDV has 64K page size for device local-memory
and has compact page
+ * table. On those platforms, for binding device
local-memory objects, the
+ * @start should be 2M aligned, @offset and @length
should be 64K aligned.
+ * Also, on those platforms, it is not allowed to bind an
device local-memory
+ * object and a system memory object in a single 2M
section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @queue_idx: Index of queue for binding */
+ __u32 queue_idx;
I have a question here to which I did not find an answer by
browsing the old threads.
Queue index appears to be an implicit synchronisation
mechanism, right? Operations on the same index are
executed/complete in ord
Re: [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays
On 6/13/22 17:35, andriy.shevche...@linux.intel.com wrote: > On Mon, Jun 13, 2022 at 11:39:30AM +, Dominik Kierner wrote: >> On 5/25/2022 21:46, Javier Martinez Canillas wrote: > > ... > >>> Thanks, I looked at the code briefly and think that there are things there >>> that we >>> could use. I.e the 3-wire SPI support that's in >>> panel-solomon-ssd130x-spi-3wire.c. >> >> When writing my driver code, I wasn't even considering using regmaps, >> like You did in Your I2C-Code. If that's applicable for 3-wire-SPI, >> it would likely be the better, more generic option. Your SPI-code >> reuses these parts to some extent. For that case, >> ssd130x_spi_regmap_config.reg_bits would need be changed to 1, >> as the "register address" has a length of 1 bit and we are sending >> 9 bits over the line and not 16. >> Since we still have 2 bytes of host memory, >> it should still be compatible with the 4-wire write, right? >> Or would 3-wire SPI require a second regmap? > > I believe the cleanest solution is to have different regmap configurations. > I agree with this. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH] drm/bridge: anx7625: Zero error variable when panel bridge not present
On Mon, Jun 13, 2022 at 12:37:05PM -0400, Nícolas F. R. A. Prado wrote:
> While parsing the DT, the anx7625 driver checks for the presence of a
> panel bridge on endpoint 1. If it is missing, pdata->panel_bridge stores
> the error pointer and the function returns successfully without first
> cleaning that variable. This is an issue since other functions later
> check for the presence of a panel bridge by testing the trueness of that
> variable.
>
> In order to ensure proper behavior, zero out pdata->panel_bridge before
> returning when no panel bridge is found.
>
> Fixes: 9e82ea0fb1df ("drm/bridge: anx7625: switch to devm_drm_of_get_bridge")
> Signed-off-by: Nícolas F. R. A. Prado
>
> ---
>
> drivers/gpu/drm/bridge/analogix/anx7625.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 53a5da6c49dd..3aed4de16690 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -1657,8 +1657,10 @@ static int anx7625_parse_dt(struct device *dev,
>
> pdata->panel_bridge = devm_drm_of_get_bridge(dev, np, 1, 0);
> if (IS_ERR(pdata->panel_bridge)) {
> - if (PTR_ERR(pdata->panel_bridge) == -ENODEV)
> + if (PTR_ERR(pdata->panel_bridge) == -ENODEV) {
> + pdata->panel_bridge = NULL;
> return 0;
> + }
>
> return PTR_ERR(pdata->panel_bridge);
> }
> --
> 2.36.1
>
Thanks for spotting this error Nícolas. As you mentioned, prior to
9e82ea0fb1df the "pdata->panel_bridge" pointer was not modified
(i.e. left to NULL) on the ENODEV error branch.
I missed it during the refactor, sorry about that.
Re: [PATCH] Revert "fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled"
On 6/10/22 11:47, Daniel Vetter wrote:
> On Fri, Jun 10, 2022 at 10:54:50AM +0200, Javier Martinez Canillas wrote:
>> This reverts commit fa0e256450f27a7d85f65c63f05e6897954a1d53. The kernel
>> test robot reported that attempting to build the vesafb driver fails on
>> some architectures, because these don't define a `struct screen_info`.
>>
>> This leads to linking errors, for example on parisc with allyesconfig:
>>
>> hppa-linux-ld: drivers/video/fbdev/vesafb.o: in function `vesafb_probe':
(.text+0x738): undefined reference to `screen_info'
hppa-linux-ld: (.text+0x73c): undefined reference to `screen_info'
>>hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init':
(.init.text+0x28): undefined reference to `screen_info'
hppa-linux-ld: (.init.text+0x30): undefined reference to `screen_info'
>>hppa-linux-ld: (.init.text+0x78): undefined reference to `screen_info'
>>
>> The goal of commit fa0e256450f2 ("fbdev: vesafb: Allow to be built if
>> COMPILE_TEST is enabled") was to have more build coverage for the driver
>> but it wrongly assumed that all architectures would define a screen_info.
>>
>> Reported-by: kernel test robot
>> Signed-off-by: Javier Martinez Canillas
>
> Acked-by: Daniel Vetter
Pushed to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH v2 1/3] drm/rect: Add DRM_RECT_INIT() macro
On Mon, Jun 13, 2022 at 10:53:57AM +0300, Jani Nikula wrote:
> On Sun, 12 Jun 2022, José Expósito wrote:
> > Add a helper macro to initialize a rectangle from x, y, width and
> > height information.
> >
> > Signed-off-by: José Expósito
> > ---
> > include/drm/drm_rect.h | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> > index 6f6e19bd4dac..945696323c69 100644
> > --- a/include/drm/drm_rect.h
> > +++ b/include/drm/drm_rect.h
> > @@ -47,6 +47,18 @@ struct drm_rect {
> > int x1, y1, x2, y2;
> > };
> >
> > +/**
> > + * DRM_RECT_INIT - initialize a rectangle from x/y/w/h
> > + * @x: x coordinate
> > + * @y: y coordinate
> > + * @w: width
> > + * @h: height
> > + *
> > + * RETURNS:
> > + * A new rectangle of the specified size.
> > + */
> > +#define DRM_RECT_INIT(x, y, w, h) { (x), (y), (x) + (w), (y) + (h) }
>
> Please use designated initializers.
>
> It might help type safety if it also contained a (struct drm_rect) cast.
Thanks a lot for your review Jani, just emailed v3 with your suggested
changes.
Jose
> BR,
> Jani.
>
>
> > +
> > /**
> > * DRM_RECT_FMT - printf string for &struct drm_rect
> > */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
[PATCH v3 2/3] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()
Test the conversion from XRGB to RGB332.
What is tested?
- Different values for the X in XRGB to make sure it is ignored
- Different clip values: Single pixel and full and partial buffer
- Well known colors: White, black, red, green, blue, magenta, yellow
and cyan
- Other colors: Randomly picked
- Destination pitch
How to run the tests?
$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/kunit \
--kconfig_add CONFIG_VIRTIO_UML=y \
--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
Suggested-by: Javier Martinez Canillas
Reviewed-by: Javier Martinez Canillas
Signed-off-by: José Expósito
---
drivers/gpu/drm/Kconfig | 16 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/kunit/.kunitconfig| 3 +
drivers/gpu/drm/kunit/Makefile| 3 +
.../gpu/drm/kunit/drm_format_helper_test.c| 160 ++
5 files changed, 183 insertions(+)
create mode 100644 drivers/gpu/drm/kunit/.kunitconfig
create mode 100644 drivers/gpu/drm/kunit/Makefile
create mode 100644 drivers/gpu/drm/kunit/drm_format_helper_test.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 22e7fa48d693..6c2256e8474b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -70,6 +70,22 @@ config DRM_DEBUG_SELFTEST
If in doubt, say "N".
+config DRM_KUNIT_TEST
+ tristate "KUnit tests for DRM" if !KUNIT_ALL_TESTS
+ depends on DRM && KUNIT=y
+ select DRM_KMS_HELPER
+ default KUNIT_ALL_TESTS
+ help
+ This builds unit tests for DRM. This option is not useful for
+ distributions or general kernels, but only for kernel
+ developers working on DRM and associated drivers.
+
+ For more information on KUnit and unit tests in general,
+ please refer to the KUnit documentation in
+ Documentation/dev-tools/kunit/.
+
+ If in doubt, say "N".
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 13ef240b3d2b..3171437d74f8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
#
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
+obj-$(CONFIG_DRM_KUNIT_TEST) += kunit/
obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
diff --git a/drivers/gpu/drm/kunit/.kunitconfig
b/drivers/gpu/drm/kunit/.kunitconfig
new file mode 100644
index ..6ec04b4c979d
--- /dev/null
+++ b/drivers/gpu/drm/kunit/.kunitconfig
@@ -0,0 +1,3 @@
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_KUNIT_TEST=y
diff --git a/drivers/gpu/drm/kunit/Makefile b/drivers/gpu/drm/kunit/Makefile
new file mode 100644
index ..2c8273796d9d
--- /dev/null
+++ b/drivers/gpu/drm/kunit/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o
diff --git a/drivers/gpu/drm/kunit/drm_format_helper_test.c
b/drivers/gpu/drm/kunit/drm_format_helper_test.c
new file mode 100644
index ..f8f2351f3449
--- /dev/null
+++ b/drivers/gpu/drm/kunit/drm_format_helper_test.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../drm_crtc_internal.h"
+
+#define TEST_BUF_SIZE 50
+
+struct xrgb_to_rgb332_case {
+ const char *name;
+ unsigned int pitch;
+ unsigned int dst_pitch;
+ struct drm_rect clip;
+ const u32 xrgb[TEST_BUF_SIZE];
+ const u8 expected[4 * TEST_BUF_SIZE];
+};
+
+static struct xrgb_to_rgb332_case xrgb_to_rgb332_cases[] = {
+ {
+ .name = "Single pixel source buffer",
+ .pitch = 1 * 4,
+ .dst_pitch = 0,
+ .clip = DRM_RECT_INIT(0, 0, 1, 1),
+ .xrgb = { 0x01FF },
+ .expected = { 0xE0 },
+ },
+ {
+ .name = "Single pixel clip rectangle",
+ .pitch = 2 * 4,
+ .dst_pitch = 0,
+ .clip = DRM_RECT_INIT(1, 1, 1, 1),
+ .xrgb = {
+ 0x, 0x,
+ 0x, 0x10FF,
+ },
+ .expected = { 0xE0 },
+ },
+ {
+ /* Well known colors, different values for the X in XRGB to
+* make sure it is ignored. Partial clip area.
+*/
+ .name = "White, black, red, green, blue, magenta, yellow, cyan",
+ .pitch = 4 * 4,
+ .dst_pitch = 0,
+ .clip = DRM_RECT_INIT(1, 1, 2, 4),
+ .xrgb = {
+ 0x, 0x, 0x, 0x,
+ 0x, 0x11FF, 0x2200, 0x,
+
[PATCH v3 1/3] drm/rect: Add DRM_RECT_INIT() macro
Add a helper macro to initialize a rectangle from x, y, width and
height information.
Signed-off-by: José Expósito
---
include/drm/drm_rect.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 6f6e19bd4dac..e8d94fca2703 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -47,6 +47,22 @@ struct drm_rect {
int x1, y1, x2, y2;
};
+/**
+ * DRM_RECT_INIT - initialize a rectangle from x/y/w/h
+ * @x: x coordinate
+ * @y: y coordinate
+ * @w: width
+ * @h: height
+ *
+ * RETURNS:
+ * A new rectangle of the specified size.
+ */
+#define DRM_RECT_INIT(x, y, w, h) ((struct drm_rect){ \
+ .x1 = (x), \
+ .y1 = (y), \
+ .x2 = (x) + (w), \
+ .y2 = (y) + (h) })
+
/**
* DRM_RECT_FMT - printf string for &struct drm_rect
*/
--
2.25.1
[PATCH v3 3/3] drm/doc: Add KUnit documentation
Explain how to run the KUnit tests present in the DRM subsystem and clarify why the UML-only options were not added to the configuration file present in drivers/gpu/drm/.kunitconfig [1] [2]. [1] https://lore.kernel.org/dri-devel/CABVgOSn8i=lo5p7830h2xu1jgg0krn0qtnxkomhf1otgxja...@mail.gmail.com/ [2] https://lore.kernel.org/dri-devel/CAGS_qxqpiCim_sy1LDK7PLwVgWf-LKW+uNFTGM=t7ydk-dy...@mail.gmail.com/ Reviewed-by: Maxime Ripard Signed-off-by: José Expósito --- Documentation/gpu/drm-internals.rst | 32 + 1 file changed, 32 insertions(+) diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 38afed24a75c..f1d97e80ca29 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -207,6 +207,38 @@ Utilities :internal: +Unit testing + + +KUnit +- + +KUnit (Kernel unit testing framework) provides a common framework for unit tests +within the Linux kernel. + +This section covers the specifics for the DRM subsystem. For general information +about KUnit, please refer to Documentation/dev-tools/kunit/start.rst. + +How to run the tests? +~ + +In order to facilitate running the test suite, a configuration file is present +in ``drivers/gpu/drm/kunit/.kunitconfig``. It can be used by ``kunit.py`` as +follows: + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/kunit \ + --kconfig_add CONFIG_VIRTIO_UML=y \ + --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y + +.. note:: + The configuration included in ``.kunitconfig`` should be as generic as + possible. + ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not + included in it because they are only required for User Mode Linux. + + Legacy Support Code === -- 2.25.1
[PATCH v3 0/3] KUnit tests for drm_format_helper
Hello everyone, Here is the v3 of the series, including the documentation, previously sent as a standalone patch [1], and changes suggested during review. Thanks a lot, José Expósito RFC -> v1: https://lore.kernel.org/dri-devel/20220530102017.471865-1-jose.exposit...@gmail.com/T/ - Add .kunitconfig (Maxime Ripard) - Fix memory leak (Daniel Latypov) - Make config option generic (Javier Martinez Canillas): DRM_FORMAR_HELPER_TEST -> DRM_KUNIT_TEST - Remove DISABLE_STRUCTLEAK_PLUGIN (Daniel Latypov) v1 -> v2: https://lore.kernel.org/dri-devel/20220606095516.938934-1-jose.exposit...@gmail.com/T/ Thomas Zimmermann: - Add DRM_RECT_INIT() macro - Move tests to drivers/gpu/drm/kunit - Improve test documentation v2 -> v3: https://lore.kernel.org/dri-devel/20220612161248.271590-1-jose.exposit...@gmail.com/T/ - Use designated initializer in DRM_RECT_INIT (Jani Nikula) - Simplify the "conversion_buf_size" helper [1] https://lore.kernel.org/dri-devel/20220606180940.43371-1-jose.exposit...@gmail.com/T/ José Expósito (3): drm/rect: Add DRM_RECT_INIT() macro drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_rgb332() drm/doc: Add KUnit documentation Documentation/gpu/drm-internals.rst | 32 drivers/gpu/drm/Kconfig | 16 ++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/kunit/.kunitconfig| 3 + drivers/gpu/drm/kunit/Makefile| 3 + .../gpu/drm/kunit/drm_format_helper_test.c| 160 ++ include/drm/drm_rect.h| 16 ++ 7 files changed, 231 insertions(+) create mode 100644 drivers/gpu/drm/kunit/.kunitconfig create mode 100644 drivers/gpu/drm/kunit/Makefile create mode 100644 drivers/gpu/drm/kunit/drm_format_helper_test.c -- 2.25.1
Re: [PATCH v2] dt-bindings: display: Add Arm virtual platforms display
Hi Rob, thanks!
On Mon, Jun 13, 2022 at 08:57:09AM -0600, Rob Herring wrote:
> 'arm,rtsm-display' is a panel for Arm, Ltd. virtual platforms (e.g. FVP).
> The binding has been in use for a long time, but was never documented.
>
> Some users and an example have a 'panel-dpi' compatible, but that's not
> needed without a 'panel-timing' node which none of the users have since
> commit 928faf5e3e8d ("arm64: dts: fvp: Remove panel timings"). The
> example does have a 'panel-timing' node, but it should not for the
> same reasons the node was removed in the dts files. So update the
> example in arm,pl11x.yaml to match the schema.
>
> Cc: Linus Walleij
> Cc: Robin Murphy
> Cc: Andre Przywara
> Signed-off-by: Rob Herring
Acked-by: Sam Ravnborg
Re: [PATCH v2 15/15] video: backlight: mt6370: Add Mediatek MT6370 support
On Mon, Jun 13, 2022 at 07:11:46PM +0800, ChiaEn Wu wrote:
> +static int mt6370_init_backlight_properties(struct mt6370_priv *priv,
> + struct backlight_properties *props)
Most of the changes in this version looks good... but it looks the new
code in this function has a number of problems. See below...
> +{
> + struct device *dev = priv->dev;
> + u8 prop_val;
> + u32 brightness;
> + unsigned int mask, val;
> + int ret;
> +
> + /* Vendor optional properties
> + * if property not exist, keep value in default.
> + */
That's not the right strategy for booleans. Not existing means false
(e.g. flags should actively be unset).
> + if (device_property_read_bool(dev, "mediatek,bled-pwm-enable")) {
> + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_PWM,
> + MT6370_BL_PWM_EN_MASK,
> + MT6370_BL_PWM_EN_MASK);
> + if (ret)
> + return ret;
> + }
As above comment... all of the boolean properties are now being read
incorrectly.
> +
> + if (device_property_read_bool(dev, "mediatek,bled-pwm-hys-enable")) {
> + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_PWM,
> + MT6370_BL_PWM_HYS_EN_MASK,
> + MT6370_BL_PWM_HYS_EN_MASK);
> + if (ret)
> + return ret;
> + }
> +
> + ret = device_property_read_u8(dev, "mediatek,bled-pwm-hys-input-bit",
> + &prop_val);
> + if (!ret) {
> + val = min_t(u8, prop_val, 3)
> + << (ffs(MT6370_BL_PWM_HYS_SEL_MASK) - 1);
> + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_PWM,
> + MT6370_BL_PWM_HYS_SEL_MASK, val);
> + if (ret)
> + return ret;
> + }
> +
> + ret = device_property_read_u8(dev, "mediatek,bled-ovp-microvolt",
> + &prop_val);
> + if (!ret) {
> + val = min_t(u8, prop_val, 3)
> + << (ffs(MT6370_BL_OVP_SEL_MASK) - 1);
This has been renamed but still seems to the using 0, 1, 2, 3 rather
than an actual value in microvolts.
> + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_BSTCTRL,
> + MT6370_BL_OVP_SEL_MASK, val);
> + if (ret)
> + return ret;
> + }
> +
> + if (device_property_read_bool(dev, "mediatek,bled-ovp-shutdown")) {
> + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_BSTCTRL,
> + MT6370_BL_OVP_EN_MASK,
> + MT6370_BL_OVP_EN_MASK);
> + if (ret)
> + return ret;
> + }
> +
> + ret = device_property_read_u8(dev, "mediatek,bled-ocp-microamp",
> + &prop_val);
> + if (!ret) {
> + val = min_t(u8, prop_val, 3)
> + << (ffs(MT6370_BL_OC_SEL_MASK) - 1);
Likewise, should this be accepting a value in microamps?
> + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_BSTCTRL,
> + MT6370_BL_OC_SEL_MASK, val);
> + if (ret)
> + return ret;
> + }
> +
> + if (device_property_read_bool(dev, "mediatek,bled-ocp-shutdown")) {
> + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_BSTCTRL,
> + MT6370_BL_OC_EN_MASK,
> + MT6370_BL_OC_EN_MASK);
> + if (ret)
> + return ret;
> + }
> +
> + /* Common properties */
> + ret = device_property_read_u32(dev, "max-brightness", &brightness);
> + if (ret)
> + brightness = MT6370_BL_MAX_BRIGHTNESS;
> +
> + props->max_brightness = min_t(u32, brightness,
> + MT6370_BL_MAX_BRIGHTNESS);
> +
> + ret = device_property_read_u32(dev, "default-brightness", &brightness);
> + if (ret)
> + brightness = props->max_brightness;
> +
> + props->brightness = min_t(u32, brightness, props->max_brightness);
> +
> +
> + ret = device_property_read_u8(dev, "mediatek,bled-channel-use",
> + &prop_val);
> + if (ret) {
> + dev_err(dev, "mediatek,bled-channel-use DT property missing\n");
> + return ret;
> + }
> +
> + if (!prop_val || prop_val > MT6370_BL_MAX_CH) {
> + dev_err(dev, "No channel specified (ch_val:%d)\n", prop_val);
Error string has not been updated to match condition that triggers it.
> + return -EINVAL;
> + }
Daniel.
Re: [PATCH v6 6/6] arm64: config: Enable DRM_V3D
On Fri, 3 Jun 2022 10:26:10 +0100, Peter Robinson wrote: > From: Nicolas Saenz Julienne > > BCM2711, the SoC used on the Raspberry Pi 4 has a different GPU than its > predecessors. Enable it. > > Signed-off-by: Nicolas Saenz Julienne > Signed-off-by: Peter Robinson > Reviewed-by: Stefan Wahren > Reviewed-by: Javier Martinez Canillas > --- Applied to https://github.com/Broadcom/stblinux/commits/devicetree-arm64/next, thanks! -- Florian
Re: [PATCH 01/19] drm/gma500: Unify *_lvds_get_max_backlight()
Hi Patrick.
On Mon, Jun 13, 2022 at 02:34:18PM +0200, Patrik Jakobsson wrote:
> These functions mostly do the same thing so unify them into one. All
> unified lvds code will live in gma_lvds.c.
>
> Signed-off-by: Patrik Jakobsson
> ---
> +/*
> + * Returns the maximum level of the backlight duty cycle field.
> + */
I find this function quite un-readable.
> +u32 gma_lvds_get_max_backlight(struct drm_device *dev)
> +{
> + struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
> + u32 retval;
> +
> + if (gma_power_begin(dev, false)) {
> + retval = ((REG_READ(BLC_PWM_CTL) &
> + BACKLIGHT_MODULATION_FREQ_MASK) >>
> + BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> +
> + gma_power_end(dev);
> + } else
> + retval = ((dev_priv->regs.saveBLC_PWM_CTL &
> + BACKLIGHT_MODULATION_FREQ_MASK) >>
> + BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> +
> + return retval;
> +}
Maybe like this - which should be the same functionality:
u32 gma_lvds_get_max_backlight(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
u32 pwmctl;
if (gma_power_begin(dev, false)) {
pwmctl = REG_READ(BLC_PWM_CTL);
gma_power_end(dev);
} else {
pwmctl = dev_priv->regs.saveBLC_PWM_CTL;
}
pwmctl = pwmctl & BACKLIGHT_MODULATION_FREQ_MASK;
return (pwmctl >> BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
}
this is more or less the same as in psb_intel_lvds_get_max_backlight().
With or without this change the patch is:
Reviewed-by: Sam Ravnborg
>> +
> +
> diff --git a/drivers/gpu/drm/gma500/gma_lvds.h
> b/drivers/gpu/drm/gma500/gma_lvds.h
> new file mode 100644
> index ..2a9ce8ee3fa7
> --- /dev/null
> +++ b/drivers/gpu/drm/gma500/gma_lvds.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +/*
> + * Copyright © 2006-2011 Intel Corporation
> + */
> +
> +#ifndef _GMA_LVDS_H
> +#define _GMA_LVDS_H
> +
> +u32 gma_lvds_get_max_backlight(struct drm_device *dev);
> +
> +#endif
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index 9c9ebf8e29c4..4913baca7ae2 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -20,6 +20,7 @@
> #include "psb_drv.h"
> #include "psb_intel_drv.h"
> #include "psb_intel_reg.h"
> +#include "gma_lvds.h"
>
> /* The max/min PWM frequency in BPCR[31:17] - */
> /* The smallest number is 1 (not 0) that can fit in the
> @@ -170,25 +171,6 @@ static void oaktrail_lvds_prepare(struct drm_encoder
> *encoder)
> gma_power_end(dev);
> }
>
> -static u32 oaktrail_lvds_get_max_backlight(struct drm_device *dev)
> -{
> - struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
> - u32 ret;
> -
> - if (gma_power_begin(dev, false)) {
> - ret = ((REG_READ(BLC_PWM_CTL) &
> - BACKLIGHT_MODULATION_FREQ_MASK) >>
> - BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> -
> - gma_power_end(dev);
> - } else
> - ret = ((dev_priv->regs.saveBLC_PWM_CTL &
> - BACKLIGHT_MODULATION_FREQ_MASK) >>
> - BACKLIGHT_MODULATION_FREQ_SHIFT) * 2;
> -
> - return ret;
> -}
> -
> static void oaktrail_lvds_commit(struct drm_encoder *encoder)
> {
> struct drm_device *dev = encoder->dev;
> @@ -197,8 +179,7 @@ static void oaktrail_lvds_commit(struct drm_encoder
> *encoder)
> struct psb_intel_mode_device *mode_dev = &dev_priv->mode_dev;
>
> if (mode_dev->backlight_duty_cycle == 0)
> - mode_dev->backlight_duty_cycle =
> - oaktrail_lvds_get_max_backlight(dev);
> + mode_dev->backlight_duty_cycle =
> gma_lvds_get_max_backlight(dev);
> oaktrail_lvds_set_power(dev, gma_encoder, true);
> }
>
> diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
> b/drivers/gpu/drm/gma500/psb_intel_lvds.c
> index 7ee6c8ce103b..371c202a15ce 100644
> --- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
> @@ -18,6 +18,7 @@
> #include "psb_drv.h"
> #include "psb_intel_drv.h"
> #include "psb_intel_reg.h"
> +#include "gma_lvds.h"
>
> /*
> * LVDS I2C backlight control macros
> @@ -52,32 +53,6 @@ struct psb_intel_lvds_priv {
> struct gma_i2c_chan *i2c_bus;
> };
>
> -
> -/*
> - * Returns the maximum level of the backlight duty cycle field.
> - */
> -static u32 psb_intel_lvds_get_max_backlight(struct drm_device *dev)
> -{
> - struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
> - u32 ret;
> -
> - if (gma_power_begin(dev, false)) {
> - ret = REG_READ(BLC_PWM_CTL);
> - gma_power_end(dev);
> - } else /* Powered off, use the saved value */
> - ret = dev_p
Re: [PATCH v6 5/6] ARM: configs: Enable DRM_V3D
On Fri, 3 Jun 2022 10:26:09 +0100, Peter Robinson wrote: > BCM2711, the SoC used on the Raspberry Pi 4 has a different 3D > render GPU IP than its predecessors. Enable it it on multi v7 > and bcm2835 configs. > > Signed-off-by: Nicolas Saenz Julienne > Signed-off-by: Peter Robinson > Reviewed-by: Stefan Wahren > Reviewed-by: Javier Martinez Canillas > --- Applied to https://github.com/Broadcom/stblinux/commits/defconfig/next, thanks! -- Florian
Re: [PATCH v6 4/6] ARM: dts: bcm2711: Enable V3D
On Fri, 3 Jun 2022 10:26:08 +0100, Peter Robinson wrote: > This adds the entry for V3D for bcm2711 (used in the Raspberry Pi 4) > and the associated firmware clock entry. > > Signed-off-by: Nicolas Saenz Julienne > Signed-off-by: Peter Robinson > Reviewed-by: Javier Martinez Canillas > --- Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks! -- Florian
Re: [PATCH] ASoC: hdmi-codec: Update to modern DAI terminology
On Thu, 2 Jun 2022 12:30:29 +0200, Mark Brown wrote: > As part of retiring the old defines used to specify DAI formats update the > hdmi_codec driver to use the modern names, including the variables in the > struct hdmi_codec_daifmt exported to the DRM drivers. > > In updating this I did note that the only use of this information in DRM > drivers is to reject clock provider settings, thinking about what this > hardware is doing I rather suspect that there might not be any hardware > out there which needs the configuration so it may be worth considering > just having hdmi-codec support only clock consumer. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: hdmi-codec: Update to modern DAI terminology commit: 9f1c8677724a0e6a6ac7a74d2b0192a584df859d All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
[PATCH] drm/i915/pvc: Add recommended MMIO setting
As with past platforms, the bspec's performance tuning guide provides
recommended MMIO settings. Although not technically "workarounds" we
apply these through the workaround framework to ensure that they're
re-applied at the proper times (e.g., on engine resets) and that any
conflicts with real workarounds are flagged.
Bspec: 72161
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 226557018037..07ef111947b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -981,6 +981,11 @@
#define XEHP_L3SCQREG7 _MMIO(0xb188)
#define BLEND_FILL_CACHING_OPT_DIS REG_BIT(3)
+#define XEHPC_L3SCRUB _MMIO(0xb18c)
+#define SCRUB_CL_DWNGRADE_SHARED REG_BIT(12)
+#define SCRUB_RATE_PER_BANK_MASK REG_GENMASK(2, 0)
+#define SCRUB_RATE_4B_PER_CLK
REG_FIELD_PREP(SCRUB_RATE_PER_BANK_MASK, 0x6)
+
#define L3SQCREG1_CCS0 _MMIO(0xb200)
#define FLUSHALLNONCOH REG_BIT(5)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 1e982ac931dc..c4af51144216 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2679,6 +2679,15 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
{
struct drm_i915_private *i915 = engine->i915;
+ if (IS_PONTEVECCHIO(i915)) {
+ /*
+* The following is not actually a "workaround" but rather
+* a recommended tuning setting documented in the bspec's
+* performance guide section.
+*/
+ wa_write(wal, XEHPC_L3SCRUB, SCRUB_CL_DWNGRADE_SHARED |
SCRUB_RATE_4B_PER_CLK);
+ }
+
if (IS_XEHPSDV(i915)) {
/* Wa_1409954639 */
wa_masked_en(wal,
--
2.35.3
Re: [PATCH] drm/msm: Fix convert to drm_of_get_data_lanes_count
On 6/12/2022 7:33 AM, Marek Vasut wrote:
Add missing header file into dsi_host.c and encode data-lanes string
directly into the warning message in the driver to avoid build issues
detected by lkp.
Fixes: 185443efa26a ("drm/msm: Convert to drm_of_get_data_lanes_count")
Reported-by: kernel test robot
Signed-off-by: Marek Vasut
Cc: Abhinav Kumar
Cc: Andrzej Hajda
Cc: Dmitry Baryshkov
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Rob Clark
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Sean Paul
To: dri-devel@lists.freedesktop.org
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_parser.c | 4 ++--
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index 346556c5706d7..57ae14a0e1814 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -106,8 +106,8 @@ static int dp_parser_misc(struct dp_parser *parser)
len = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
if (len < 0) {
- DRM_WARN("Invalid property %s, default max DP lanes = %d\n",
- data_lane_property, DP_MAX_NUM_DP_LANES);
+ DRM_WARN("Invalid property \"data-lanes\", default max DP lanes =
%d\n",
+DP_MAX_NUM_DP_LANES);
len = DP_MAX_NUM_DP_LANES;
}
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
index db5871b9c5d88..7e21916d1511a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -21,6 +21,8 @@
#include
+#include
+
#include "dsi.h"
#include "dsi.xml.h"
#include "sfpb.xml.h"
[Bug 216120] [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=216120 mat2003...@gmail.com changed: What|Removed |Added Regression|No |Yes -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/bridge: anx7625: Zero error variable when panel bridge not present
While parsing the DT, the anx7625 driver checks for the presence of a
panel bridge on endpoint 1. If it is missing, pdata->panel_bridge stores
the error pointer and the function returns successfully without first
cleaning that variable. This is an issue since other functions later
check for the presence of a panel bridge by testing the trueness of that
variable.
In order to ensure proper behavior, zero out pdata->panel_bridge before
returning when no panel bridge is found.
Fixes: 9e82ea0fb1df ("drm/bridge: anx7625: switch to devm_drm_of_get_bridge")
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 53a5da6c49dd..3aed4de16690 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1657,8 +1657,10 @@ static int anx7625_parse_dt(struct device *dev,
pdata->panel_bridge = devm_drm_of_get_bridge(dev, np, 1, 0);
if (IS_ERR(pdata->panel_bridge)) {
- if (PTR_ERR(pdata->panel_bridge) == -ENODEV)
+ if (PTR_ERR(pdata->panel_bridge) == -ENODEV) {
+ pdata->panel_bridge = NULL;
return 0;
+ }
return PTR_ERR(pdata->panel_bridge);
}
--
2.36.1
[Bug 216120] [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=216120 --- Comment #2 from mat2003...@gmail.com --- Created attachment 301165 --> https://bugzilla.kernel.org/attachment.cgi?id=301165&action=edit BISECT_LOG -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216120] [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=216120 --- Comment #1 from mat2003...@gmail.com --- Created attachment 301164 --> https://bugzilla.kernel.org/attachment.cgi?id=301164&action=edit BISECT_LOG -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216120] New: [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=216120 Bug ID: 216120 Summary: [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu Product: Drivers Version: 2.5 Kernel Version: 5.19-rc1 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: mat2003...@gmail.com Regression: No KDE plasma panel at the bottom of the desktop is empty. If I revert the patch drm/amdgpu: add drm buddy support to amdgpu c9cad937c0c58618fe5b0310fd539a854dc1ae95 the panel shows widgets and running programs again. Fortunately the patch seems to revert cleanly. BISECT_LOG and lspci attached -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition
On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:
On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:
On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:
On 10/06/2022 13:37, Tvrtko Ursulin wrote:
On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
1 file changed, 490 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND timeline fence array
support.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of
operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not
accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable
amount of time.
+ * Compute on the other hand can be long running. Hence it is not
appropriate
+ * for compute contexts to export request completion dma-fence to
user.
+ * The dma-fence usage will be limited to in-kernel consumption
only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See &drm_i915_gem_exec_fence.flags) is
expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl call is also not
supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE 0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE
+ DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the
mapping of GPU
+ * virtual address (VA) range to the section of an object that
should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently
bound) and can
+ * be mapped to whole object or a section of the object (partial
binding).
+ * Multiple VA mappings can be created to the same section of the
object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to use for binding. Same
queue can be
+ * used for both VM_BIND and VM_UNBIND calls. All submitted bind
and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should be 4K page aligned.
However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has
compact page
+ * table. On those platforms, for binding device local-memory
objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K
aligned.
+ * Also, on those platforms, it is not allowed to bind an device
local-memory
+ * object and a system memory object in a single 2M section of VA
range.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @queue_idx: Index of queue for binding */
+ __u32 queue_idx;
I have a question here to which I did not find an answer by
browsing the old threads.
Queue index appears to be an implicit synchronisation mechanism,
right? Operations on the same index are executed/complete in order
of ioctl submission?
Do we _have_ to implement this on the ker
Re: [PATCH v4] drm/msm/dp: force link training for display resolution change
On 6/10/2022 2:04 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-05-27 14:32:13)
During display resolution changes display have to be disabled first
followed by display enabling with new resolution. Display disable
will turn off both pixel clock and main link clock so that main link
have to be re trained during display enable to have new video stream
s/re/re-/
flow again. At current implementation, display enable function manually
kicks up irq_hpd_handle which will read panel link status and start link
training if link status is not in sync state. However, there is rare
case that a particular panel links status keep staying in sync for
some period of time after main link had been shut down previously at
display disabled. Main link retraining will not be executed by
irq_hdp_handle() if the link status read from pane shows it is in
s/pane/panel/
sync state. If this was happen, then video stream of newer display
resolution will fail to be transmitted to panel due to main link is
not in sync between host and panel. This patch force main link always
be retrained during display enable procedure to prevent this rare
failed case from happening. Also this implementation are more
efficient than manual kicking off irq_hpd_handle function.
The description makes it sound like the link status is not updated,
sometimes. Isn't that the real issue here? Not that link training needs
to be done again (which it always does apparently), but that disabling
the display doesn't wait for the link to go down. Or disabling the link
is causing some sort of glitch on the sink causing it to report the
status as OK when it really isn't.
As soon as mainlink teared down, sink has to reflect the mainlink at out
of synch state in real time.
link re-training always required for display resolution changes since
resolution changes will involve link configuration changes, such as 2
lanes change to 1 changes or 5.7G link rate changes to 2.7G or vise
versa. Therefore there is no need to check sinker's main link status to
decide re training is required or not.
Changes in v2:
-- set force_link_train flag on DP only (is_edp == false)
Changes in v3:
-- revise commit text
-- add Fixes tag
Changes in v4:
-- revise commit text
Fixes: 62671d2ef24b ("drm/msm/dp: fixes wrong connection state caused by failure of
link train")
Signed-off-by: Kuogee Hsieh
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index c388323..370348d 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1688,10 +1689,14 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
state = dp_display->hpd_state;
- if (state == ST_DISPLAY_OFF)
+ if (state == ST_DISPLAY_OFF) {
dp_display_host_phy_init(dp_display);
- dp_display_enable(dp_display, 0);
+ if (!dp->is_edp)
Does this assume eDP has one resolution? I don't understand why eDP is
special here, especially if eDP has more than one resolution available
it seems like we would want to retrain the link regardless.
+ force_link_train = true;
+ }
+
+ dp_display_enable(dp_display, force_link_train);
rc = dp_display_post_enable(dp);
if (rc) {
Re: [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays
On Mon, Jun 13, 2022 at 11:39:30AM +, Dominik Kierner wrote: > On 5/25/2022 21:46, Javier Martinez Canillas wrote: ... > > Thanks, I looked at the code briefly and think that there are things there > > that we > > could use. I.e the 3-wire SPI support that's in > > panel-solomon-ssd130x-spi-3wire.c. > > When writing my driver code, I wasn't even considering using regmaps, > like You did in Your I2C-Code. If that's applicable for 3-wire-SPI, > it would likely be the better, more generic option. Your SPI-code > reuses these parts to some extent. For that case, > ssd130x_spi_regmap_config.reg_bits would need be changed to 1, > as the "register address" has a length of 1 bit and we are sending > 9 bits over the line and not 16. > Since we still have 2 bytes of host memory, > it should still be compatible with the 4-wire write, right? > Or would 3-wire SPI require a second regmap? I believe the cleanest solution is to have different regmap configurations. -- With Best Regards, Andy Shevchenko
[PATCH libdrm] tests/util: Add simpledrm driver
From: Eric Curtin
Add an entry for the "simpledrm" driver, so that the test utilities
work with the simpledrm driver without passing the -M argument.
Signed-off-by: Eric Curtin
---
- It's also here, was unsure whether to use MR or email submission
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/243
---
tests/util/kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/util/kms.c b/tests/util/kms.c
index 39a93866..21a61a77 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -150,6 +150,7 @@ static const char * const modules[] = {
"komeda",
"imx-dcss",
"mxsfb-drm",
+ "simpledrm",
};
int util_open(const char *device, const char *module)
--
2.35.3
