[PATCH v2] drm/amdkfd: fixes for HMM mem allocation
Fix err return value and reset pgmap->type after checking it.
Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
Reviewed-by: Felix Kuehling
Signed-off-by: Dafna Hirschfeld
---
v2: remove unrelated DOC fix and add 'Fixes' tag.
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 6c25dab051d5..b8680e0753ca 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -1021,7 +1021,7 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
} else {
res = devm_request_free_mem_region(adev->dev, &iomem_resource,
size);
if (IS_ERR(res))
- return -ENOMEM;
+ return PTR_ERR(res);
pgmap->range.start = res->start;
pgmap->range.end = res->end;
pgmap->type = MEMORY_DEVICE_PRIVATE;
@@ -1037,10 +1037,10 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
- /* Disable SVM support capability */
- pgmap->type = 0;
if (pgmap->type == MEMORY_DEVICE_PRIVATE)
devm_release_mem_region(adev->dev, res->start,
resource_size(res));
+ /* Disable SVM support capability */
+ pgmap->type = 0;
return PTR_ERR(r);
}
--
2.34.1
[PATCH] drm/amdkfd: fixes for HMM mem allocation
Few fixes to amdkfd and the doc of
devm_request_free_mem_region.
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
kernel/resource.c| 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 6c25dab051d5..b8680e0753ca 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -1021,7 +1021,7 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
} else {
res = devm_request_free_mem_region(adev->dev, &iomem_resource,
size);
if (IS_ERR(res))
- return -ENOMEM;
+ return PTR_ERR(res);
pgmap->range.start = res->start;
pgmap->range.end = res->end;
pgmap->type = MEMORY_DEVICE_PRIVATE;
@@ -1037,10 +1037,10 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
- /* Disable SVM support capability */
- pgmap->type = 0;
if (pgmap->type == MEMORY_DEVICE_PRIVATE)
devm_release_mem_region(adev->dev, res->start,
resource_size(res));
+ /* Disable SVM support capability */
+ pgmap->type = 0;
return PTR_ERR(r);
}
diff --git a/kernel/resource.c b/kernel/resource.c
index 866ef3663a0b..fe890b874606 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1905,8 +1905,8 @@ get_free_mem_region(struct device *dev, struct resource
*base,
* devm_request_free_mem_region - find free region for device private memory
*
* @dev: device struct to bind the resource to
- * @size: size in bytes of the device memory to add
* @base: resource tree to look in
+ * @size: size in bytes of the device memory to add
*
* This function tries to find an empty range of physical address big enough to
* contain the new resource, so that it can later be hotplugged as ZONE_DEVICE
--
2.34.1
Re: [PULL] drm-xe-next v2
On 19.12.2023 19:22, Rodrigo Vivi wrote: Hi Dave and Sima, Here goes a v2 of our first pull request. First PR: https://lore.kernel.org/all/zxzta75g5vhcr...@intel.com/ The lack of committer signature blocked Dave's tools on getting that. I'm sorry for that. As you know we were maintaining this branch with rebases through this past year, so I did the last rebase to fix the tags but ended up not signing off the patches. Fixing this now and hopefully we are getting in and this rebases will stop. Besides that, I also included two more commits in this PR: - One fix that would break the builds without CONFIG_FAULT_INJECTION - One commit that removes the FW loading for blobs that are not in linux-firmware.git yet. Thanks, Rodrigo. Hi, I reviewed the usage of the gpuvm API, all issues I found were fixed. Acked-by: Dafna Hirschfeld Dafna, The following changes since commit a60501d7c2d3e70b3545b9b96576628e369d8e85: Merge tag 'drm-misc-next-2023-12-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-12-08 16:27:00 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-next-2023-12-19-pr1 for you to fetch changes up to ba43af4e32ca80b2b977281d53636a75a93ca530: drm/xe: Remove ci-only GuC FW definitions (2023-12-19 18:52:21 -0500) Introduce a new DRM driver for Intel GPUs Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms. The experimental support starts with Tiger Lake. i915 will continue be the main production driver for the platforms up to Meteor Lake and Alchemist. Then the goal is to make this Intel Xe driver the primary driver for Lunar Lake and newer platforms. It uses most, if not all, of the key drm concepts, in special: TTM, drm-scheduler, drm-exec, drm-gpuvm/gpuva and others. Alan Previn (1): drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN Alexander Usyskin (1): drm/xe/gsc: enable pvc support Andrzej Hajda (1): drm/xe: implement driver initiated function-reset Animesh Manna (1): drm/xe/dsb: DSB implementation for xe Anshuman Gupta (7): drm/xe/pm: Disable PM on unbounded pcie parent bridge drm/xe/pm: Add pci d3cold_capable support drm/xe/pm: Refactor xe_pm_runtime_init drm/xe/pm: Add vram_d3cold_threshold Sysfs drm/xe/pm: Toggle d3cold_allowed using vram_usages drm/xe/pm: Init pcode and restore vram on power lost drm/xe/pm: Add vram_d3cold_threshold for d3cold capable device Anusha Srivatsa (10): drm/xe/huc: Support for loading unversiond HuC drm/xe: Load HuC on Alderlake S drm/xe: GuC and HuC loading support for RKL drm/xe: Add Rocketlake device info drm/xe/kunit: Handle fake device creation for all platform/subplatform cases drm/xe: Add missing ADL entries to xe_test_wa drm/xe/rplu: s/ADLP/ALDERLAKE_P drm/xe/rpls: Add RPLS Support drm/xe/rpls: Add Stepping info for RPLS drm/xe: Add missing ADL entries to xe_test_wa Aravind Iddamsetty (5): drm/xe: Get GT clock to nanosecs drm/xe: Use spinlock in forcewake instead of mutex drm/xe/pmu: Enable PMU interface drm/xe/pmu: Drop interrupt pmu event drm/xe: Fix lockdep warning in xe_force_wake calls Ashutosh Dixit (2): drm/xe/uapi: Use common drm_xe_ext_set_property extension drm/xe/pmu: Remove PMU from Xe till uapi is finalized Badal Nilawar (11): drm/xe: Donot apply forcewake while reading actual frequency drm/xe/mtl: Add support to get C6 residency/status of MTL drm/xe/hwmon: Expose power attributes drm/xe/hwmon: Expose card reactive critical power drm/xe/hwmon: Expose input voltage attribute drm/xe/hwmon: Expose hwmon energy attribute drm/xe: Extend rpX values extraction for future platforms drm/xe/hwmon: Add kernel doc and refactor xe hwmon drm/xe/hwmon: Protect hwmon rw attributes with hwmon_lock drm/xe/hwmon: Expose power1_max_interval drm/xe/mtl: Use 16.67 Mhz freq scale factor to get rpX Balasubramani Vivekanandan (9): drm/xe/gt: Enable interrupt while initializing root gt drm/xe: Use max wopcm size when validating the preset GuC wopcm size drm/xe: Stop accepting value in xe_migrate_clear drm/xe: Keep all resize bar related prints inside xe_resize_vram_bar drm/xe/xe2: Add MOCS table drm/xe/lnl: Hook up MOCS table drm/xe: Leverage ComputeCS read L3 caching drm/xe: Add event tracing for CTB drm/xe/trace: Optimize trace definition Bommithi Sakeena (3): drm/xe: Ensure mutex are destroyed drm/xe: Add a missing mutex_destroy to xe_ttm_vram_mgr drm/xe: Encapsulate all the module parameters Bommu Krishnaiah (2): drm/xe/uapi: add exec_queue_id member to drm_xe_wait_user_fence structure drm/xe/uapi: Retur
Re: [PATCH 5/5 v3] accel/qaic: Fix a leak in map_user_pages()
On 11.07.2023 09:13, Dan Carpenter wrote:
If get_user_pages_fast() allocates some pages but not as many as we
wanted, then the current code leaks those pages. Call put_page() on
the pages before returning.
Fixes: 129776ac2e38 ("accel/qaic: Add control path")
Signed-off-by: Dan Carpenter
Reviewed-by: Dafna Hirschfeld
---
no change
drivers/accel/qaic/qaic_control.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/qaic/qaic_control.c
b/drivers/accel/qaic/qaic_control.c
index d5ce36cb351f..9a6f80f31c65 100644
--- a/drivers/accel/qaic/qaic_control.c
+++ b/drivers/accel/qaic/qaic_control.c
@@ -425,9 +425,12 @@ static int find_and_map_user_pages(struct qaic_device
*qdev,
}
ret = get_user_pages_fast(xfer_start_addr, nr_pages, 0, page_list);
- if (ret < 0 || ret != nr_pages) {
- ret = -EFAULT;
+ if (ret < 0)
goto free_page_list;
+ if (ret != nr_pages) {
+ nr_pages = ret;
+ ret = -EFAULT;
+ goto put_pages;
}
sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
--
2.39.2
Re: [Intel-xe] [PATCH 2/4] drm/xe/ras: Log the GT hw errors.
On 06.04.2023 14:52, Himal Prasad Ghimiray wrote:
From: Aravind Iddamsetty
Count the CORRECTABLE and FATAL GT hardware errors as
signaled by relevant interrupt and respective registers.
For non relevant interrupts count them as driver interrupt error.
For platform supporting error vector registers count and report
the respective vector errors.
Co-authored-by: Himal Prasad Ghimiray
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Himal Prasad Ghimiray
---
drivers/gpu/drm/xe/regs/xe_regs.h| 77 ++-
drivers/gpu/drm/xe/xe_device_types.h | 2 +
drivers/gpu/drm/xe/xe_gt.c | 29 +++
drivers/gpu/drm/xe/xe_gt_types.h | 43
drivers/gpu/drm/xe/xe_irq.c | 332 ---
drivers/gpu/drm/xe/xe_pci.c | 3 +
6 files changed, 453 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/xe/regs/xe_regs.h
b/drivers/gpu/drm/xe/regs/xe_regs.h
index dff74b093d4e..b3d35d0c5a77 100644
--- a/drivers/gpu/drm/xe/regs/xe_regs.h
+++ b/drivers/gpu/drm/xe/regs/xe_regs.h
@@ -122,14 +122,50 @@ enum hardware_error {
HARDWARE_ERROR_MAX,
};
+#define DEV_PCIEERR_STATUS _MMIO(0x100180)
+#define DEV_PCIEERR_IS_FATAL(x) (REG_BIT(2) << (x * 4))
#define _DEV_ERR_STAT_FATAL 0x100174
#define _DEV_ERR_STAT_NONFATAL 0x100178
#define _DEV_ERR_STAT_CORRECTABLE 0x10017c
#define DEV_ERR_STAT_REG(x) _MMIO(_PICK_EVEN((x), \
_DEV_ERR_STAT_CORRECTABLE, \
_DEV_ERR_STAT_NONFATAL))
+
#define DEV_ERR_STAT_GT_ERROR REG_BIT(0)
+enum gt_vctr_registers {
+ ERR_STAT_GT_VCTR0 = 0,
+ ERR_STAT_GT_VCTR1,
+ ERR_STAT_GT_VCTR2,
+ ERR_STAT_GT_VCTR3,
+ ERR_STAT_GT_VCTR4,
+ ERR_STAT_GT_VCTR5,
+ ERR_STAT_GT_VCTR6,
+ ERR_STAT_GT_VCTR7,
+};
+
+#define ERR_STAT_GT_COR_VCTR_LEN(4)
+#define _ERR_STAT_GT_COR_VCTR_0 0x1002a0
+#define _ERR_STAT_GT_COR_VCTR_1 0x1002a4
+#define _ERR_STAT_GT_COR_VCTR_2 0x1002a8
+#define _ERR_STAT_GT_COR_VCTR_3 0x1002ac
+#define ERR_STAT_GT_COR_VCTR_REG(x) _MMIO(_PICK_EVEN((x), \
+ _ERR_STAT_GT_COR_VCTR_0, \
+ _ERR_STAT_GT_COR_VCTR_1))
+
+#define ERR_STAT_GT_FATAL_VCTR_LEN (8)
+#define _ERR_STAT_GT_FATAL_VCTR_0 0x100260
+#define _ERR_STAT_GT_FATAL_VCTR_1 0x100264
+#define _ERR_STAT_GT_FATAL_VCTR_2 0x100268
+#define _ERR_STAT_GT_FATAL_VCTR_3 0x10026c
+#define _ERR_STAT_GT_FATAL_VCTR_4 0x100270
+#define _ERR_STAT_GT_FATAL_VCTR_5 0x100274
+#define _ERR_STAT_GT_FATAL_VCTR_6 0x100278
+#define _ERR_STAT_GT_FATAL_VCTR_7 0x10027c
+#define ERR_STAT_GT_FATAL_VCTR_REG(x) _MMIO(_PICK_EVEN((x), \
+ _ERR_STAT_GT_FATAL_VCTR_0, \
+ _ERR_STAT_GT_FATAL_VCTR_1))
+
#define _ERR_STAT_GT_COR0x100160
#define _ERR_STAT_GT_NONFATAL 0x100164
#define _ERR_STAT_GT_FATAL 0x100168
@@ -137,7 +173,42 @@ enum hardware_error {
_ERR_STAT_GT_COR, \
_ERR_STAT_GT_NONFATAL))
-#define EU_GRF_ERROR REG_BIT(15)
-#define EU_IC_ERRORREG_BIT(14)
-
+#define EU_GRF_COR_ERR (15)
+#define EU_IC_COR_ERR (14)
+#define SLM_COR_ERR(13)
+#define SAMPLER_COR_ERR(12)
+#define GUC_COR_ERR(1)
+#define L3_SNG_COR_ERR (0)
+
+#define PVC_COR_ERR_MASK \
+ (REG_BIT(GUC_COR_ERR) | \
+REG_BIT(SLM_COR_ERR) | \
+REG_BIT(EU_IC_COR_ERR) | \
+REG_BIT(EU_GRF_COR_ERR))
+
+#define EU_GRF_FAT_ERR (15)
+#define EU_IC_FAT_ERR (14)
+#define SLM_FAT_ERR (13)
+#define SAMPLER_FAT_ERR (12)
+#define SQIDI_FAT_ERR (9)
+#define IDI_PAR_FAT_ERR (8)
+#define GUC_FAT_ERR (6)
+#define L3_ECC_CHK_FAT_ERR (5)
+#define L3_DOUBLE_FAT_ERR (4)
+#define FPU_UNCORR_FAT_ERR (3)
+#define ARRAY_BIST_FAT_ERR (1)
+
+#define PVC_FAT_ERR_MASK \
+ (REG_BIT(FPU_UNCORR_FAT_ERR) | \
+REG_BIT(GUC_FAT_ERR) | \
+REG_BIT(SLM_FAT_ERR) | \
+REG_BIT(EU_GRF_FAT_ERR))
+
+#define GT_HW_ERROR_MAX_ERR_BITS16
+
+#define _SLM_ECC_ERROR_CNT 0xe7f4
+#define _SLM_UNCORR_ECC_ERROR_CNT 0xe7c0
+#define SLM_ECC_ERROR_CNTR(x) _MMIO((x) ==
HARDWARE_ERROR_CORRECTABLE ? \
+ _SLM_ECC_ERROR_CNT : \
+ _SLM_UNCORR_ECC_ERROR
Re: [PATCH v2 2/8] accel/qaic: Add uapi and core driver file
On 17.02.2023 11:15, Jeffrey Hugo wrote:
On 2/16/2023 7:13 AM, Jacek Lawrynowicz wrote:
Hi,
On 06.02.2023 16:41, Jeffrey Hugo wrote:
Add the QAIC driver uapi file and core driver file that binds to the PCIe
device. The core driver file also creates the accel device and manages
all the interconnections between the different parts of the driver.
The driver can be built as a module. If so, it will be called "qaic.ko".
Signed-off-by: Jeffrey Hugo
Reviewed-by: Carl Vanderlip
---
drivers/accel/qaic/qaic.h | 321 ++
drivers/accel/qaic/qaic_drv.c | 771 ++
include/uapi/drm/qaic_accel.h | 283
3 files changed, 1375 insertions(+)
create mode 100644 drivers/accel/qaic/qaic.h
create mode 100644 drivers/accel/qaic/qaic_drv.c
create mode 100644 include/uapi/drm/qaic_accel.h
diff --git a/drivers/accel/qaic/qaic.h b/drivers/accel/qaic/qaic.h
new file mode 100644
index 000..3f7ea76
--- /dev/null
+++ b/drivers/accel/qaic/qaic.h
@@ -0,0 +1,321 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Copyright (c) 2019-2021, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2021-2023 Qualcomm Innovation Center, Inc. All rights
reserved.
+ */
+
+#ifndef QAICINTERNAL_H_
Please use guard macro that matches the file name: _QAIC_H_
Before moving to DRM/ACCEL, this conflicted with the uapi file.
However, that is no longer the case, so yes, this should be changed.
Will do.
+#define QAICINTERNAL_H_
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define QAIC_DBC_BASE 0x2
+#define QAIC_DBC_SIZE 0x1000
+
+#define QAIC_NO_PARTITION -1
+
+#define QAIC_DBC_OFF(i)((i) * QAIC_DBC_SIZE + QAIC_DBC_BASE)
+
+#define to_qaic_bo(obj) container_of(obj, struct qaic_bo, base)
+
+extern bool poll_datapath;
+
+struct qaic_user {
+ /* Uniquely identifies this user for the device */
+ int handle;
+ struct kref ref_count;
+ /* Char device opened by this user */
+ struct qaic_drm_device *qddev;
+ /* Node in list of users that opened this drm device */
+ struct list_headnode;
+ /* SRCU used to synchronize this user during cleanup */
+ struct srcu_struct qddev_lock;
+ atomic_tchunk_id;
+};
+
+struct dma_bridge_chan {
+ /* Pointer to device strcut maintained by driver */
+ struct qaic_device *qdev;
+ /* ID of this DMA bridge channel(DBC) */
+ unsigned intid;
+ /* Synchronizes access to xfer_list */
+ spinlock_t xfer_lock;
+ /* Base address of request queue */
+ void*req_q_base;
+ /* Base address of response queue */
+ void*rsp_q_base;
+ /*
+* Base bus address of request queue. Response queue bus address can be
+* calculated by adding request queue size to this variable
+*/
+ dma_addr_t dma_addr;
+ /* Total size of request and response queue in byte */
+ u32 total_size;
+ /* Capacity of request/response queue */
+ u32 nelem;
+ /* The user that opened this DBC */
+ struct qaic_user*usr;
+ /*
+* Request ID of next memory handle that goes in request queue. One
+* memory handle can enqueue more than one request elements, all
+* this requests that belong to same memory handle have same request ID
+*/
+ u16 next_req_id;
+ /* TRUE: DBC is in use; FALSE: DBC not in use */
Use standard "true"/"false" instead of custom "TRUE"/"FALSE" macros.
This applies here and in multiple other places in the driver.
I think you are getting at that the documentation could be confusing.
I don't appear to see custom macro use in the code. Will try to
clarify that here.
+ boolin_use;
+ /*
+* Base address of device registers. Used to read/write request and
+* response queue's head and tail pointer of this DBC.
+*/
+ void __iomem*dbc_base;
+ /* Head of list where each node is a memory handle queued in request
queue */
+ struct list_headxfer_list;
+ /* Synchronizes DBC readers during cleanup */
+ struct srcu_struct ch_lock;
+ /*
+* When this DBC is released, any thread waiting on this wait queue is
+* woken up
+*/
+ wait_queue_head_t dbc_release;
+ /* Head of list where each node is a bo associated with this DBC */
+ struct list_headbo_lists;
+ /* The irq line for this DBC. Used for polling */
+ unsigned intirq;
+ /* Polling work item to simulate interrupts */
+ struct work_struct poll_wo
Re: [PATCH v3] media: mtk-vcodec: Align width and height to 64 bytes
On 04.11.21 14:24, Yunfei Dong wrote:
Width and height need to 64 bytes aligned when setting the format.
Need to make sure all is 64 bytes align when use width and height to
calculate buffer size.
Signed-off-by: Yunfei Dong
Acked-by: Nicolas Dufresne
Tested-by: Steve Cho
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h| 1 +
drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
index e30806c1faea..66cd6d2242c3 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
@@ -11,6 +11,7 @@
#include
#include
+#define VCODEC_DEC_ALIGNED_64 64
This define is a bit useless, it doesn't improve readability,
if you do ALIGN(x, 64) it is already clear enough.
Thank,
Dafna
#define VCODEC_CAPABILITY_4K_DISABLED 0x10
#define VCODEC_DEC_4K_CODED_WIDTH 4096U
#define VCODEC_DEC_4K_CODED_HEIGHT2304U
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
index d402fc4bda69..e1a3011772a9 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
@@ -562,8 +562,8 @@ static void get_pic_info(struct vdec_h264_slice_inst *inst,
{
struct mtk_vcodec_ctx *ctx = inst->ctx;
- ctx->picinfo.buf_w = (ctx->picinfo.pic_w + 15) & 0xFFF0;
- ctx->picinfo.buf_h = (ctx->picinfo.pic_h + 31) & 0xFFE0;
+ ctx->picinfo.buf_w = ALIGN(ctx->picinfo.pic_w, VCODEC_DEC_ALIGNED_64);
+ ctx->picinfo.buf_h = ALIGN(ctx->picinfo.pic_h, VCODEC_DEC_ALIGNED_64);
ctx->picinfo.fb_sz[0] = ctx->picinfo.buf_w * ctx->picinfo.buf_h;
ctx->picinfo.fb_sz[1] = ctx->picinfo.fb_sz[0] >> 1;
inst->vsi_ctx.dec.cap_num_planes =
Re: [PATCH] drm/bridge: parade-ps8640: Assign drm_device to dp aux channel
On 04.11.21 12:20, AngeloGioacchino Del Regno wrote:
As it was done with other bridge drivers and to solve a warning coming
from drm_dp_aux_register(), add a backpointer to drm_device in the
drm_dp_aux that we're registering.
it is common to dump the exact warning in the commit log so people can locate
it later.
Maybe also add 'Fixes' tag?
apart of that
Reviewed-by: Dafna Hirschfeld
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/bridge/parade-ps8640.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 191cc196c9d1..20d8e606d543 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -455,6 +455,7 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
goto err_dsi_attach;
}
+ ps_bridge->aux.drm_dev = bridge->dev;
ret = drm_dp_aux_register(&ps_bridge->aux);
if (ret) {
dev_err(dev, "failed to register DP AUX channel: %d\n", ret);
Re: [PATCH v2 3/3] drm/bridge: parade-ps8640: Perform full poweroff if poweron fails
On 02.11.21 11:36, AngeloGioacchino Del Regno wrote:
In function ps8640_bridge_poweron(), in case of a failure not relative
to the regulators enablement, the code was disabling the regulators but
the gpio changes that happened during the poweron sequence were not
being reverted back to a clean poweroff state.
Since it is expected that, when we enter ps8640_bridge_poweron(), the
powerdown and reset GPIOs are both in active state exactly as they were
left in the poweroff function before, we can simply call function
__ps8640_bridge_poweroff() in the failure case, reverting every change
that was done during the power on sequence.
Of course it was chosen to call the poweroff function instead of adding
code to revert the GPIO changes to the poweron one to avoid duplicating
code, as we would be doing exactly what the poweroff function does.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Dafna Hirschfeld
---
drivers/gpu/drm/bridge/parade-ps8640.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 41f5d511d516..ef1b51d8b676 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -344,7 +344,7 @@ static int ps8640_bridge_poweron(struct ps8640 *ps_bridge)
if (ret < 0) {
DRM_ERROR("failed read PAGE2_GPIO_H: %d\n", ret);
- goto err_regulators_disable;
+ goto err_poweroff;
}
msleep(50);
@@ -360,23 +360,22 @@ static int ps8640_bridge_poweron(struct ps8640 *ps_bridge)
ret = regmap_update_bits(map, PAGE2_MCS_EN, MCS_EN, 0);
if (ret < 0) {
DRM_ERROR("failed write PAGE2_MCS_EN: %d\n", ret);
- goto err_regulators_disable;
+ goto err_poweroff;
}
/* Switch access edp panel's edid through i2c */
ret = regmap_write(map, PAGE2_I2C_BYPASS, I2C_BYPASS_EN);
if (ret < 0) {
DRM_ERROR("failed write PAGE2_I2C_BYPASS: %d\n", ret);
- goto err_regulators_disable;
+ goto err_poweroff;
}
ps_bridge->powered = true;
return 0;
-err_regulators_disable:
- regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
- ps_bridge->supplies);
+err_poweroff:
+ __ps8640_bridge_poweroff(ps_bridge);
return ret;
}
Re: [PATCH v2 2/3] drm/bridge: parade-ps8640: Move real poweroff action to new function
On 02.11.21 11:36, AngeloGioacchino Del Regno wrote:
In preparation for varying the poweron error handling in function
ps8640_bridge_poweron(), move function ps8640_bridge_poweroff() up
and also move the actual logic to power off the chip to a new
__ps8640_bridge_poweroff() function.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/bridge/parade-ps8640.c | 37 ++
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 8c5402947b3c..41f5d511d516 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -293,6 +293,26 @@ static int ps8640_bridge_vdo_control(struct ps8640
*ps_bridge,
return 0;
}
+static void __ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
+{
+ gpiod_set_value(ps_bridge->gpio_reset, 1);
+ gpiod_set_value(ps_bridge->gpio_powerdown, 1);
+ if (regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
+ ps_bridge->supplies)) {
+ DRM_ERROR("cannot disable regulators\n");
+ }
That '{' is redundant
Thanks,
Danfa
+}
+
+static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
+{
+ if (!ps_bridge->powered)
+ return;
+
+ __ps8640_bridge_poweroff(ps_bridge);
+
+ ps_bridge->powered = false;
+}
+
static int ps8640_bridge_poweron(struct ps8640 *ps_bridge)
{
struct regmap *map = ps_bridge->regmap[PAGE2_TOP_CNTL];
@@ -361,23 +381,6 @@ static int ps8640_bridge_poweron(struct ps8640 *ps_bridge)
return ret;
}
-static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
-{
- int ret;
-
- if (!ps_bridge->powered)
- return;
-
- gpiod_set_value(ps_bridge->gpio_reset, 1);
- gpiod_set_value(ps_bridge->gpio_powerdown, 1);
- ret = regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
-ps_bridge->supplies);
- if (ret < 0)
- DRM_ERROR("cannot disable regulators %d\n", ret);
-
- ps_bridge->powered = false;
-}
-
static void ps8640_pre_enable(struct drm_bridge *bridge)
{
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
Re: [PATCH v2 1/3] drm/bridge: parade-ps8640: Don't try to enable VDO if poweron fails
On 02.11.21 11:36, AngeloGioacchino Del Regno wrote:
If the bridge cannot get powered on, there's no reason to try to
communicate with it: change the ps8640_bridge_poweron function to
return an error value to the caller, so that we can avoid calling
ps8640_bridge_vdo_control() in ps8640_pre_enable() if the poweron
sequence fails.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Dafna Hirschfeld
---
drivers/gpu/drm/bridge/parade-ps8640.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b36e4dc78f1..8c5402947b3c 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -293,19 +293,19 @@ static int ps8640_bridge_vdo_control(struct ps8640
*ps_bridge,
return 0;
}
-static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
+static int ps8640_bridge_poweron(struct ps8640 *ps_bridge)
{
struct regmap *map = ps_bridge->regmap[PAGE2_TOP_CNTL];
int ret, status;
if (ps_bridge->powered)
- return;
+ return 0;
ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
if (ret < 0) {
DRM_ERROR("cannot enable regulators %d\n", ret);
- return;
+ return ret;
}
gpiod_set_value(ps_bridge->gpio_powerdown, 0);
@@ -352,11 +352,13 @@ static void ps8640_bridge_poweron(struct ps8640
*ps_bridge)
ps_bridge->powered = true;
- return;
+ return 0;
err_regulators_disable:
regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
+
+ return ret;
}
static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
@@ -381,7 +383,9 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
- ps8640_bridge_poweron(ps_bridge);
+ ret = ps8640_bridge_poweron(ps_bridge);
+ if (ret)
+ return;
ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
if (ret < 0)
Re: [PATCH v8, 07/17] dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings
On 29.10.21 05:55, Yunfei Dong wrote:
Decoder will use component framework to manage hardware, it is big
difference with encoder.
Reviewed-by: Rob Herring
Signed-off-by: Yunfei Dong
---
.../media/mediatek,vcodec-decoder.yaml| 176 +
.../media/mediatek,vcodec-encoder.yaml| 187 ++
.../bindings/media/mediatek-vcodec.txt| 131
3 files changed, 363 insertions(+), 131 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
create mode 100644
Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
delete mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
diff --git
a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
new file mode 100644
index ..5de37065fbce
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,vcodec-decoder.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Video Decode Accelerator With Component
+
+maintainers:
+ - Yunfei Dong
+
+description: |+
+ Mediatek Video Decode is the video decode hardware present in Mediatek
+ SoCs which supports high resolution decoding functionalities.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8173-vcodec-dec
+ - mediatek,mt8183-vcodec-dec
+
+ reg:
+maxItems: 12
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 8
+
+ clock-names:
+items:
+ - const: vcodecpll
+ - const: univpll_d2
+ - const: clk_cci400_sel
+ - const: vdec_sel
+ - const: vdecpll
+ - const: vencpll
+ - const: venc_lt_sel
+ - const: vdec_bus_clk_src
+
+ assigned-clocks: true
+
+ assigned-clock-parents: true
+
+ assigned-clock-rates: true
+
+ power-domains:
+maxItems: 1
+
+ iommus:
+minItems: 1
+maxItems: 32
+description: |
+ List of the hardware port in respective IOMMU block for current Socs.
+ Refer to bindings/iommu/mediatek,iommu.yaml.
+
+ dma-ranges:
+maxItems: 1
+description: |
+ Describes the physical address space of IOMMU maps to memory.
+
+ mediatek,larb:
+$ref: /schemas/types.yaml#/definitions/phandle
+maxItems: 1
+description: |
+ Must contain the local arbiters in the current Socs.
+
+ mediatek,vpu:
+$ref: /schemas/types.yaml#/definitions/phandle
+maxItems: 1
+description:
+ Describes point to vpu.
+
+ mediatek,scp:
+$ref: /schemas/types.yaml#/definitions/phandle
+maxItems: 1
+description:
+ Describes point to scp.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - iommus
+ - assigned-clocks
+ - assigned-clock-parents
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - mediatek,mt8183-vcodec-dec
+
+then:
+ required:
+- mediatek,scp
+
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - mediatek,mt8173-vcodec-dec
+
+then:
+ required:
+- mediatek,vpu
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+vcodec_dec: vcodec@1600 {
+ compatible = "mediatek,mt8173-vcodec-dec";
+ reg = <0x1600 0x100>, /*VDEC_SYS*/
+ <0x1602 0x1000>, /*VDEC_MISC*/
+ <0x16021000 0x800>, /*VDEC_LD*/
+ <0x16021800 0x800>, /*VDEC_TOP*/
+ <0x16022000 0x1000>, /*VDEC_CM*/
+ <0x16023000 0x1000>, /*VDEC_AD*/
+ <0x16024000 0x1000>, /*VDEC_AV*/
+ <0x16025000 0x1000>, /*VDEC_PP*/
+ <0x16026800 0x800>, /*VP8_VD*/
+ <0x16027000 0x800>, /*VP6_VD*/
+ <0x16027800 0x800>, /*VP8_VL*/
+ <0x16028400 0x400>; /*VP9_VD*/
+ interrupts = ;
+ mediatek,larb = <&larb1>;
+ iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_PP_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_PRED_RD_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_PRED_WR_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_UFO_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_VLD_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_VLD2_EXT>;
+ mediatek,vpu = <&vpu>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+ clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>,
+ <&topckgen CLK_TOP_UNIVPLL_D2>,
+ <&topckgen CLK_TOP_CCI400_SEL>,
+ <&topckgen CLK_TOP_VDEC_SEL>,
+ <&topckgen CLK_TOP_VCODECPLL>,
+ <&apmixedsys CLK_APMIXED_VENCPLL>,
+ <&topckgen CLK_TOP_VENC_LT_
Re: [PATCH v8, 04/17] media: mtk-vcodec: Build decoder pm file as module
On 29.10.21 05:55, Yunfei Dong wrote:
Need to build decoder pm file as module for master and comp
use the same pm interface.
Do you still use the component framework in this patchset?
In the cover letter you write: "- Use of_platform_populate to manage multi hardware,
not component framework for patch 4/15"
If that frameworks is not used anymore you should also change the commit log,
and maybe this patch is not needed anymore?
Thanks,
Dafna
Signed-off-by: Yunfei Dong
---
v8: add new patch to build pm file as module
---
drivers/media/platform/mtk-vcodec/Makefile| 6 --
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 9 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index ca8e9e7a9c4e..5d36e05535d7 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -2,7 +2,8 @@
obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
mtk-vcodec-enc.o \
- mtk-vcodec-common.o
+ mtk-vcodec-common.o \
+ mtk-vcodec-dec-common.o
mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec/vdec_vp8_if.o \
@@ -14,7 +15,8 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
mtk_vcodec_dec.o \
mtk_vcodec_dec_stateful.o \
mtk_vcodec_dec_stateless.o \
- mtk_vcodec_dec_pm.o \
+
+mtk-vcodec-dec-common-y := mtk_vcodec_dec_pm.o
mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc/venc_h264_if.o \
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 20bd157a855c..09a281e3065a 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -77,12 +77,14 @@ int mtk_vcodec_init_dec_pm(struct platform_device *pdev,
put_device(pm->larbvdec);
return ret;
}
+EXPORT_SYMBOL_GPL(mtk_vcodec_init_dec_pm);
void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm)
{
pm_runtime_disable(pm->dev);
put_device(pm->larbvdec);
}
+EXPORT_SYMBOL_GPL(mtk_vcodec_release_dec_pm);
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
{
@@ -94,6 +96,7 @@ int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
return ret;
}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_pw_on);
void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
{
@@ -103,6 +106,7 @@ void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
if (ret)
mtk_v4l2_err("pm_runtime_put_sync fail %d", ret);
}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_pw_off);
void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
{
@@ -129,6 +133,7 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
for (i -= 1; i >= 0; i--)
clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_clock_on);
void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
{
@@ -139,3 +144,7 @@ void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
for (i = dec_clk->clk_num - 1; i >= 0; i--)
clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_clock_off);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek video decoder driver");
Re: [PATCH v8, 03/17] media: mtk-vcodec: Refactor vcodec pm interface
On 29.10.21 05:55, Yunfei Dong wrote:
Using the needed param for pm init/release function and remove unused
param mtkdev in 'struct mtk_vcodec_pm'.
Reviewed-by: Tzung-Bi Shih
Reviewed-By: AngeloGioacchino Del Regno
Signed-off-by: Yunfei Dong
Hi,
I already commented on v7 that since the pm implementation for dec and enc is
identical,
you should better do the same refactor to enc and dec or better remove the code
duplication.
Thanks,
Dafna
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 ++---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 22 ---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 5 +++--
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 1 -
5 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 055d50e52720..3ac4c3935e4e 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -249,7 +249,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
if (IS_ERR(dev->fw_handler))
return PTR_ERR(dev->fw_handler);
- ret = mtk_vcodec_init_dec_pm(dev);
+ ret = mtk_vcodec_init_dec_pm(dev->plat_dev, &dev->pm);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to get mt vcodec clock source");
goto err_dec_pm;
@@ -378,7 +378,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
err_dec_alloc:
v4l2_device_unregister(&dev->v4l2_dev);
err_res:
- mtk_vcodec_release_dec_pm(dev);
+ mtk_vcodec_release_dec_pm(&dev->pm);
err_dec_pm:
mtk_vcodec_fw_release(dev->fw_handler);
return ret;
@@ -418,7 +418,7 @@ static int mtk_vcodec_dec_remove(struct platform_device
*pdev)
video_unregister_device(dev->vfd_dec);
v4l2_device_unregister(&dev->v4l2_dev);
- mtk_vcodec_release_dec_pm(dev);
+ mtk_vcodec_release_dec_pm(&dev->pm);
mtk_vcodec_fw_release(dev->fw_handler);
return 0;
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..20bd157a855c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -13,18 +13,15 @@
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
-int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
+int mtk_vcodec_init_dec_pm(struct platform_device *pdev,
+ struct mtk_vcodec_pm *pm)
{
struct device_node *node;
- struct platform_device *pdev;
- struct mtk_vcodec_pm *pm;
+ struct platform_device *larb_pdev;
struct mtk_vcodec_clk *dec_clk;
struct mtk_vcodec_clk_info *clk_info;
int i = 0, ret = 0;
- pdev = mtkdev->plat_dev;
- pm = &mtkdev->pm;
- pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
if (!node) {
@@ -32,13 +29,12 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
return -1;
}
- pdev = of_find_device_by_node(node);
+ larb_pdev = of_find_device_by_node(node);
of_node_put(node);
- if (WARN_ON(!pdev)) {
+ if (WARN_ON(!larb_pdev)) {
return -1;
}
- pm->larbvdec = &pdev->dev;
- pdev = mtkdev->plat_dev;
+ pm->larbvdec = &larb_pdev->dev;
pm->dev = &pdev->dev;
dec_clk->clk_num =
@@ -82,10 +78,10 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
return ret;
}
-void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
+void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm)
{
- pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
+ pm_runtime_disable(pm->dev);
+ put_device(pm->larbvdec);
}
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
index 280aeaefdb65..a3df6aef6cb9 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
@@ -9,8 +9,9 @@
#include "mtk_vcodec_drv.h"
-int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *dev);
-void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev);
+int mtk_vcodec_init_dec_pm(struct platform_device *pdev,
+ struct mtk_vcodec_pm *pm);
+void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm);
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm);
void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 1d2370608d0d..0fa9d85114b9 100644
--- a/dri
Re: [PATCH v8 04/12] iommu/mediatek: Add device_link between the consumer and the larb devices
On 16.10.21 04:23, Yong Wu wrote:
On Mon, 2021-10-11 at 14:36 +0200, Dafna Hirschfeld wrote:
On 29.09.21 03:37, Yong Wu wrote:
MediaTek IOMMU-SMI diagram is like below. all the consumer connect
with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enable the smi-larb's power
which
also need enable the smi-common's power firstly.
Thus, First of all, use the device link connect the consumer and
the
smi-larbs. then add device link between the smi-larb and smi-
common.
This patch adds device_link between the consumer and the larbs.
When device_link_add, I add the flag DL_FLAG_STATELESS to avoid
calling
pm_runtime_xx to keep the original status of clocks. It can avoid
two
issues:
1) Display HW show fastlogo abnormally reported in [1]. At the
beggining,
all the clocks are enabled before entering kernel, but the clocks
for
display HW(always in larb0) will be gated after clk_enable and
clk_disable
called from device_link_add(->pm_runtime_resume) and rpm_idle. The
clock
operation happened before display driver probe. At that time, the
display
HW will be abnormal.
2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip
pm_runtime_xx to avoid the deadlock.
Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then
device_link_removed should be added explicitly.
[1]
https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/
[2] https://lore.kernel.org/patchwork/patch/1086569/
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-
R2/MT7623
---
drivers/iommu/mtk_iommu.c| 22 ++
drivers/iommu/mtk_iommu_v1.c | 20 +++-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d5848f78a677..a2fa55899434 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -560,22 +560,44 @@ static struct iommu_device
*mtk_iommu_probe_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct mtk_iommu_data *data;
+ struct device_link *link;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return ERR_PTR(-ENODEV); /* Not a iommu client device
*/
data = dev_iommu_priv_get(dev);
+ /*
+* Link the consumer device with the smi-larb device(supplier)
+* The device in each a larb is a independent HW. thus only
link
+* one larb here.
+*/
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
so larbid is always the same for all the ids of a device?
Yes. For me, each a dtsi node should represent a HW unit which can only
connect one larb.
If so maybe it worth testing it and return error if this is not the
case.
Thanks for the suggestion. This is very helpful. I did see someone put
the different larbs in one node. I will check this, and add return
I am working on bugs found on media drivers, could you please point me to
that wrong node?
Will you send a fix to that node in the dtsi?
Thanks,
Dafna
EINVAL for this case.
Thanks,
Dafna
Re: [PATCH v7, 03/15] media: mtk-vcodec: Refactor vcodec pm interface
On 11.10.21 09:02, Yunfei Dong wrote:
Using the needed param for pm init/release function and remove unused
param mtkdev in 'struct mtk_vcodec_pm'.
I see that there is a lot of code duplication between
mtk_vcodec_release_dec_pm.c and mtk_vcodec_release_enc_pm.c
I think if you bother to factor the decoder you should do the same factor to
the encoder, but actually the much better thing to do
is to unify all code duplication between these two files, just for example of
identical functions:
mtk_vcodec_enc/dec_clock_on/off
mtk_vcodec_release_enc_pm
mtk_vcodec_init_dec_pm
In addition, the function mtk_vcodec_dec_pw_on can be remove since it only
calls pm_runtime_resume_and_get.
It would be much better to call pm_runtime_resume_and_get directly and not hide
it in a different function
Thanks,
Dafna
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 ++---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 22 ---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 5 +++--
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 1 -
5 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 8db9cdc66043..dd749d41c75a 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -249,7 +249,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
if (IS_ERR(dev->fw_handler))
return PTR_ERR(dev->fw_handler);
- ret = mtk_vcodec_init_dec_pm(dev);
+ ret = mtk_vcodec_init_dec_pm(dev->plat_dev, &dev->pm);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to get mt vcodec clock source");
goto err_dec_pm;
@@ -379,7 +379,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
err_dec_alloc:
v4l2_device_unregister(&dev->v4l2_dev);
err_res:
- mtk_vcodec_release_dec_pm(dev);
+ mtk_vcodec_release_dec_pm(&dev->pm);
err_dec_pm:
mtk_vcodec_fw_release(dev->fw_handler);
return ret;
@@ -422,7 +422,7 @@ static int mtk_vcodec_dec_remove(struct platform_device
*pdev)
video_unregister_device(dev->vfd_dec);
v4l2_device_unregister(&dev->v4l2_dev);
- mtk_vcodec_release_dec_pm(dev);
+ mtk_vcodec_release_dec_pm(&dev->pm);
mtk_vcodec_fw_release(dev->fw_handler);
return 0;
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..20bd157a855c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -13,18 +13,15 @@
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
-int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
+int mtk_vcodec_init_dec_pm(struct platform_device *pdev,
+ struct mtk_vcodec_pm *pm)
{
struct device_node *node;
- struct platform_device *pdev;
- struct mtk_vcodec_pm *pm;
+ struct platform_device *larb_pdev;
struct mtk_vcodec_clk *dec_clk;
struct mtk_vcodec_clk_info *clk_info;
int i = 0, ret = 0;
- pdev = mtkdev->plat_dev;
- pm = &mtkdev->pm;
- pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
if (!node) {
@@ -32,13 +29,12 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
return -1;
}
- pdev = of_find_device_by_node(node);
+ larb_pdev = of_find_device_by_node(node);
of_node_put(node);
- if (WARN_ON(!pdev)) {
+ if (WARN_ON(!larb_pdev)) {
return -1;
}
- pm->larbvdec = &pdev->dev;
- pdev = mtkdev->plat_dev;
+ pm->larbvdec = &larb_pdev->dev;
pm->dev = &pdev->dev;
dec_clk->clk_num =
@@ -82,10 +78,10 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
return ret;
}
-void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
+void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm)
{
- pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
+ pm_runtime_disable(pm->dev);
+ put_device(pm->larbvdec);
}
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
index 280aeaefdb65..a3df6aef6cb9 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
@@ -9,8 +9,9 @@
#include "mtk_vcodec_drv.h"
-int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *dev);
-void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev);
+int mtk_vcodec_
Re: [PATCH v8 04/12] iommu/mediatek: Add device_link between the consumer and the larb devices
On 29.09.21 03:37, Yong Wu wrote:
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enable the smi-larb's power which
also need enable the smi-common's power firstly.
Thus, First of all, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.
This patch adds device_link between the consumer and the larbs.
When device_link_add, I add the flag DL_FLAG_STATELESS to avoid calling
pm_runtime_xx to keep the original status of clocks. It can avoid two
issues:
1) Display HW show fastlogo abnormally reported in [1]. At the beggining,
all the clocks are enabled before entering kernel, but the clocks for
display HW(always in larb0) will be gated after clk_enable and clk_disable
called from device_link_add(->pm_runtime_resume) and rpm_idle. The clock
operation happened before display driver probe. At that time, the display
HW will be abnormal.
2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip
pm_runtime_xx to avoid the deadlock.
Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then
device_link_removed should be added explicitly.
[1] https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/
[2] https://lore.kernel.org/patchwork/patch/1086569/
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 22 ++
drivers/iommu/mtk_iommu_v1.c | 20 +++-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d5848f78a677..a2fa55899434 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -560,22 +560,44 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct mtk_iommu_data *data;
+ struct device_link *link;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return ERR_PTR(-ENODEV); /* Not a iommu client device */
data = dev_iommu_priv_get(dev);
+ /*
+* Link the consumer device with the smi-larb device(supplier)
+* The device in each a larb is a independent HW. thus only link
+* one larb here.
+*/
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
so larbid is always the same for all the ids of a device? If so
maybe it worth testing it and return error if this is not the case.
Thanks,
Dafna
+ larbdev = data->larb_imu[larbid].dev;
+ link = device_link_add(dev, larbdev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
return &data->iommu;
}
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct mtk_iommu_data *data;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return;
+ data = dev_iommu_priv_get(dev);
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ device_link_remove(dev, larbdev);
+
iommu_fwspec_free(dev);
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 4d7809432239..e6f13459470e 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -423,7 +423,9 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct of_phandle_args iommu_spec;
struct mtk_iommu_data *data;
- int err, idx = 0;
+ int err, idx = 0, larbid;
+ struct device_link *link;
+ struct device *larbdev;
/*
* In the deferred case, free the existed fwspec.
@@ -453,6 +455,14 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
data = dev_iommu_priv_get(dev);
+ /* Link the consumer device with the smi-larb device(supplier) */
+ larbid = mt2701_m4u_to_larb(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ link = device_link_add(dev, larbdev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
+
return &data->iommu;
}
@@ -473,10 +483,18 @@ static void mtk_iommu_probe_finalize(struct device *dev)
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
Re: [PATCH v10, 2/5] drm/mediatek: add component POSTMASK
On 30.09.21 17:52, Yongqiang Niu wrote:
This patch add component POSTMASK.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 102 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 73 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4a2abcf3e5f9..89170ad825fd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -62,6 +62,12 @@
#define DITHER_ADD_LSHIFT_G(x)(((x) & 0x7) << 4)
#define DITHER_ADD_RSHIFT_G(x)(((x) & 0x7) << 0)
+#define DISP_POSTMASK_EN 0x
+#define POSTMASK_ENBIT(0)
+#define DISP_POSTMASK_CFG 0x0020
+#define POSTMASK_RELAY_MODEBIT(0)
+#define DISP_POSTMASK_SIZE 0x0030
+
struct mtk_ddp_comp_dev {
struct clk *clk;
void __iomem *regs;
@@ -214,6 +220,32 @@ static void mtk_dither_stop(struct device *dev)
writel_relaxed(0x0, priv->regs + DISP_DITHER_EN);
}
+static void mtk_postmask_config(struct device *dev, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, &priv->cmdq_reg, priv->regs,
+ DISP_POSTMASK_SIZE);
+ mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, &priv->cmdq_reg,
+ priv->regs, DISP_POSTMASK_CFG);
+}
+
+static void mtk_postmask_start(struct device *dev)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ writel(POSTMASK_EN, priv->regs + DISP_POSTMASK_EN);
+}
+
+static void mtk_postmask_stop(struct device *dev)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ writel_relaxed(0x0, priv->regs + DISP_POSTMASK_EN);
+}
+
static const struct mtk_ddp_comp_funcs ddp_aal = {
.clk_enable = mtk_aal_clk_enable,
.clk_disable = mtk_aal_clk_disable,
@@ -289,6 +321,14 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
.bgclr_in_off = mtk_ovl_bgclr_in_off,
};
+static const struct mtk_ddp_comp_funcs ddp_postmask = {
+ .clk_enable = mtk_ddp_clk_enable,
+ .clk_disable = mtk_ddp_clk_disable,
+ .config = mtk_postmask_config,
+ .start = mtk_postmask_start,
+ .stop = mtk_postmask_stop,
+};
+
static const struct mtk_ddp_comp_funcs ddp_rdma = {
.clk_enable = mtk_rdma_clk_enable,
.clk_disable = mtk_rdma_clk_disable,
@@ -324,6 +364,7 @@ static const char * const
mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
[MTK_DISP_BLS] = "bls",
+ [MTK_DISP_POSTMASK] = "postmask",
};
struct mtk_ddp_comp_match {
@@ -333,36 +374,37 @@ struct mtk_ddp_comp_match {
};
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL0]= { MTK_DISP_AAL, 0, &ddp_aal },
- [DDP_COMPONENT_AAL1]= { MTK_DISP_AAL, 1, &ddp_aal },
- [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
- [DDP_COMPONENT_CCORR] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
- [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
- [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
- [DDP_COMPONENT_DITHER] = { MTK_DISP_DITHER,0, &ddp_dither },
- [DDP_COMPONENT_DPI0]= { MTK_DPI,0, &ddp_dpi },
- [DDP_COMPONENT_DPI1]= { MTK_DPI,1, &ddp_dpi },
- [DDP_COMPONENT_DSI0]= { MTK_DSI,0, &ddp_dsi },
- [DDP_COMPONENT_DSI1]= { MTK_DSI,1, &ddp_dsi },
- [DDP_COMPONENT_DSI2]= { MTK_DSI,2, &ddp_dsi },
- [DDP_COMPONENT_DSI3]= { MTK_DSI,3, &ddp_dsi },
- [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
- [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, &ddp_od },
- [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, &ddp_od },
- [DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, &ddp_ovl },
- [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, &ddp_ovl },
- [DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, &ddp_ovl },
- [DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, &ddp_ovl },
- [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, &ddp_ovl },
- [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
- [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
- [DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
- [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, &ddp_rdma },
-
Re: [PATCH v8 09/12] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
On 30.09.21 05:28, Yong Wu wrote:
Hi Dafna,
Thanks very much for the review.
On Wed, 2021-09-29 at 14:13 +0200, Dafna Hirschfeld wrote:
On 29.09.21 03:37, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the
consumer
and smi-larb device. If the vcodec device call the
pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Tiffany Lin
Reviewed-by: Dafna Hirschfeld
---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 +++---
--
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 44 +++---
-
4 files changed, 10 insertions(+), 75 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..d0bf9aa3b29d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -8,14 +8,12 @@
#include
#include
#include
-#include
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
@@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev
*mtkdev)
pm = &mtkdev->pm;
pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
- node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (WARN_ON(!pdev)) {
- return -1;
- }
- pm->larbvdec = &pdev->dev;
pdev = mtkdev->plat_dev;
pm->dev = &pdev->dev;
@@ -47,14 +34,11 @@ int mtk_vcodec_init_dec_pm(struct
mtk_vcodec_dev *mtkdev)
dec_clk->clk_info = devm_kcalloc(&pdev->dev,
dec_clk->clk_num, sizeof(*clk_info),
GFP_KERNEL);
- if (!dec_clk->clk_info) {
- ret = -ENOMEM;
- goto put_device;
- }
+ if (!dec_clk->clk_info)
+ return -ENOMEM;
} else {
mtk_v4l2_err("Failed to get vdec clock count");
- ret = -EINVAL;
- goto put_device;
+ return -EINVAL;
}
for (i = 0; i < dec_clk->clk_num; i++) {
@@ -63,29 +47,24 @@ int mtk_vcodec_init_dec_pm(struct
mtk_vcodec_dev *mtkdev)
"clock-names", i, &clk_info->clk_name);
if (ret) {
mtk_v4l2_err("Failed to get clock name id =
%d", i);
- goto put_device;
+ return ret;
}
clk_info->vcodec_clk = devm_clk_get(&pdev->dev,
clk_info->clk_name);
if (IS_ERR(clk_info->vcodec_clk)) {
mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
clk_info->clk_name);
- ret = PTR_ERR(clk_info->vcodec_clk);
- goto put_device;
+ return PTR_ERR(clk_info->vcodec_clk);
}
}
pm_runtime_enable(&pdev->dev);
return 0;
-put_device:
- put_device(pm->larbvdec);
- return ret;
}
void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
{
pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
}
Now that functions only do 'pm_runtime_disable(dev->pm.dev);' so it
will be more
readable to remove the function mtk_vcodec_release_dec_pm
and replace with pm_runtime_disable(dev->pm.dev);
Same for the 'enc' equivalent.
Make sense. But It may be not proper if using pm_runtime_disable
as the symmetry with mtk_vcodec_init_dec_pm in the mtk_vcodec_probe.
Maybe we should move pm_runtime_enable out from mtk_vcodec_init_dec_pm
into mtk_vcodec_probe. I could do a new patch for this. Is this ok for
you?
yes, there is also asymettry when calling pm_runtime* in general,
I see in the decoder it is called from mtk_vcodec_dec_pm.c
but in the encoder it is called from mtk_vcodec_enc.c,
I think all calls to pm_runtime* should be out of the *_pm.c files
since for example 'mtk_vcodec_dec_pw_on' also do just one call to
pm_runtime_resume_and_get so this function can also be removed.
thanks,
Dafna
Thanks,
Dafna
[snip]
___
Linux-mediatek mailing list
linux-media...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v8 03/12] iommu/mediatek: Add probe_defer for smi-larb
On 29.09.21 03:37, Yong Wu wrote:
Prepare for adding device_link.
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is ready,
then all the iommu consumers always are after the smi driver.
When there is no this patch, if some consumer drivers run before
smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the
device_link_add, then device_links_driver_bound will use WARN_ON
to complain that the link_status of supplier is not right.
device_is_bound may be more elegant here. but it is not allowed to
EXPORT from https://lore.kernel.org/patchwork/patch/1334670/.
Signed-off-by: Yong Wu
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
drivers/iommu/mtk_iommu.c| 2 +-
drivers/iommu/mtk_iommu_v1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d837adfd1da5..d5848f78a677 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -844,7 +844,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
id = i;
plarbdev = of_find_device_by_node(larbnode);
- if (!plarbdev) {
+ if (!plarbdev || !plarbdev->dev.driver) {
of_node_put(larbnode);
return -EPROBE_DEFER;
if plarbdev is null doesn't that mean that the device does not exist?
so we should return -ENODEV in that case?
thanks,
Dafna
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 1467ba1e4417..4d7809432239 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -602,7 +602,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
}
plarbdev = of_find_device_by_node(larbnode);
- if (!plarbdev) {
+ if (!plarbdev || !plarbdev->dev.driver) {
of_node_put(larbnode);
return -EPROBE_DEFER;
}
Re: [PATCH v8 09/12] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
On 29.09.21 03:37, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Tiffany Lin
Reviewed-by: Dafna Hirschfeld
---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 +++-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 44 +++
4 files changed, 10 insertions(+), 75 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..d0bf9aa3b29d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -8,14 +8,12 @@
#include
#include
#include
-#include
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
@@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
pm = &mtkdev->pm;
pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
- node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (WARN_ON(!pdev)) {
- return -1;
- }
- pm->larbvdec = &pdev->dev;
pdev = mtkdev->plat_dev;
pm->dev = &pdev->dev;
@@ -47,14 +34,11 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
dec_clk->clk_info = devm_kcalloc(&pdev->dev,
dec_clk->clk_num, sizeof(*clk_info),
GFP_KERNEL);
- if (!dec_clk->clk_info) {
- ret = -ENOMEM;
- goto put_device;
- }
+ if (!dec_clk->clk_info)
+ return -ENOMEM;
} else {
mtk_v4l2_err("Failed to get vdec clock count");
- ret = -EINVAL;
- goto put_device;
+ return -EINVAL;
}
for (i = 0; i < dec_clk->clk_num; i++) {
@@ -63,29 +47,24 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
"clock-names", i, &clk_info->clk_name);
if (ret) {
mtk_v4l2_err("Failed to get clock name id = %d", i);
- goto put_device;
+ return ret;
}
clk_info->vcodec_clk = devm_clk_get(&pdev->dev,
clk_info->clk_name);
if (IS_ERR(clk_info->vcodec_clk)) {
mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
clk_info->clk_name);
- ret = PTR_ERR(clk_info->vcodec_clk);
- goto put_device;
+ return PTR_ERR(clk_info->vcodec_clk);
}
}
pm_runtime_enable(&pdev->dev);
return 0;
-put_device:
- put_device(pm->larbvdec);
- return ret;
}
void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
{
pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
}
Now that functions only do 'pm_runtime_disable(dev->pm.dev);' so it will be
more
readable to remove the function mtk_vcodec_release_dec_pm
and replace with pm_runtime_disable(dev->pm.dev);
Same for the 'enc' equivalent.
Thanks,
Dafna
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
@@ -122,11 +101,6 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
}
}
- ret = mtk_smi_larb_get(pm->larbvdec);
- if (ret) {
- mtk_v4l2_err("mtk_smi_larb_get larbvdec fail %d", ret);
- goto error;
- }> return;
error:
@@ -139,7 +113,6 @@ void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
struct mtk_vcodec_clk *dec_clk = &pm->vdec_clk;
int i = 0;
- mtk_smi_larb_put(pm->larbvdec);
for (i = dec_clk->clk_num - 1; i >= 0; i--)
clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/pl
Re: [PATCH v6, 15/15] media: mtk-vcodec: Use codec type to separate different hardware
On 02.09.21 08:05, yunfei.d...@mediatek.com wrote:
On Wed, 2021-09-01 at 14:17 +0200, Dafna Hirschfeld wrote:
Hi Dafna,
Thanks for your suggestion.
Hi
On 01.09.21 10:32, Yunfei Dong wrote:
There are just one core thread, in order to separeate different
hardware, using codec type to separeate it in scp driver.
this code seems to relate to the vpu driver not the scp driver.
Is there a corresponding code added to the vpu driver that test the
codec_type?
Vpu is video processor unit, used to connect with micro processor.
In mt8173: vdec_vpu_if.c -> mtk_vpu.c -> micro processor
In mt8192/mt8183: vdec_vpu_if.c -> mtk_scp.c ->micro processor
This init/dec start/dec_end interfaces are the same for vpu and scp.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ---
.../media/platform/mtk-vcodec/vdec_vpu_if.c | 34
---
.../media/platform/mtk-vcodec/vdec_vpu_if.h | 4 +++
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
index 9d8079c4f976..c488f0c40190 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
@@ -35,6 +35,8 @@ enum vdec_ipi_msgid {
* @msg_id : vdec_ipi_msgid
* @vpu_inst_addr : VPU decoder instance address. Used if ABI
version < 2.
* @inst_id : instance ID. Used if the ABI version >= 2.
+ * @codec_type : Codec fourcc
+ * @reserved : reserved param
*/
struct vdec_ap_ipi_cmd {
uint32_t msg_id;
@@ -42,6 +44,8 @@ struct vdec_ap_ipi_cmd {
uint32_t vpu_inst_addr;
uint32_t inst_id;
};
+ uint32_t codec_type;
+ uint32_t reserved;
};
/**
@@ -59,12 +63,12 @@ struct vdec_vpu_ipi_ack {
/**
* struct vdec_ap_ipi_init - for AP_IPIMSG_DEC_INIT
* @msg_id : AP_IPIMSG_DEC_INIT
- * @reserved : Reserved field
+ * @codec_type : Codec fourcc
* @ap_inst_addr : AP video decoder instance address
*/
struct vdec_ap_ipi_init {
uint32_t msg_id;
- uint32_t reserved;
+ uint32_t codec_type;
uint64_t ap_inst_addr;
};
@@ -77,7 +81,7 @@ struct vdec_ap_ipi_init {
* H264 decoder [0]:buf_sz [1]:nal_start
* VP8 decoder [0]:width/height
* VP9 decoder [0]:profile, [1][2] width/height
- * @reserved : Reserved field
+ * @codec_type : Codec fourcc
*/
struct vdec_ap_ipi_dec_start {
uint32_t msg_id;
@@ -86,7 +90,7 @@ struct vdec_ap_ipi_dec_start {
uint32_t inst_id;
};
uint32_t data[3];
- uint32_t reserved;
+ uint32_t codec_type;
};
/**
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index bfd8e87dceff..c84fac52fe26 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -100,18 +100,29 @@ static void vpu_dec_ipi_handler(void *data,
unsigned int len, void *priv)
static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void
*msg, int len)
{
- int err;
+ int err, id, msgid;
- mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg);
+ msgid = *(uint32_t *)msg;
+ mtk_vcodec_debug(vpu, "id=%X", msgid);
vpu->failure = 0;
vpu->signaled = 0;
- err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, vpu-
id, msg,
+ if (vpu->ctx->dev->vdec_pdata->hw_arch ==
MTK_VDEC_LAT_SINGLE_CORE) {
+ if (msgid == AP_IPIMSG_DEC_CORE ||
+ msgid == AP_IPIMSG_DEC_CORE_END)
+ id = vpu->core_id;
+ else
+ id = vpu->id;
+ } else {
+ id = vpu->id;
+ }
+
+ err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id,
msg,
len, 2000);
so
if (err) {
mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X
status=%d",
- vpu->id, *(uint32_t *)msg, err);
+ id, msgid, err);
return err;
}
@@ -131,6 +142,7 @@ static int vcodec_send_ap_ipi(struct
vdec_vpu_inst *vpu, unsigned int msg_id)
msg.vpu_inst_addr = vpu->inst_addr;
else
msg.inst_id = vpu->inst_id;
+ msg.codec_type = vpu->codec_type;
err = vcodec_vpu_send_msg(vpu, &msg, sizeof(msg));
mtk_vcodec_debug(vpu, "- id=%X ret=%d", msg_id, err);
@@ -149,14 +161,25 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
vpu->id,
vpu->handler, "vdec", NULL);
- if (err != 0) {
+
Re: [PATCH v6, 15/15] media: mtk-vcodec: Use codec type to separate different hardware
Hi
On 01.09.21 10:32, Yunfei Dong wrote:
There are just one core thread, in order to separeate different
hardware, using codec type to separeate it in scp driver.
this code seems to relate to the vpu driver not the scp driver.
Is there a corresponding code added to the vpu driver that test the codec_type?
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ---
.../media/platform/mtk-vcodec/vdec_vpu_if.c | 34 ---
.../media/platform/mtk-vcodec/vdec_vpu_if.h | 4 +++
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
index 9d8079c4f976..c488f0c40190 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
@@ -35,6 +35,8 @@ enum vdec_ipi_msgid {
* @msg_id: vdec_ipi_msgid
* @vpu_inst_addr : VPU decoder instance address. Used if ABI version < 2.
* @inst_id : instance ID. Used if the ABI version >= 2.
+ * @codec_type : Codec fourcc
+ * @reserved : reserved param
*/
struct vdec_ap_ipi_cmd {
uint32_t msg_id;
@@ -42,6 +44,8 @@ struct vdec_ap_ipi_cmd {
uint32_t vpu_inst_addr;
uint32_t inst_id;
};
+ uint32_t codec_type;
+ uint32_t reserved;
};
/**
@@ -59,12 +63,12 @@ struct vdec_vpu_ipi_ack {
/**
* struct vdec_ap_ipi_init - for AP_IPIMSG_DEC_INIT
* @msg_id: AP_IPIMSG_DEC_INIT
- * @reserved : Reserved field
+ * @codec_type : Codec fourcc
* @ap_inst_addr : AP video decoder instance address
*/
struct vdec_ap_ipi_init {
uint32_t msg_id;
- uint32_t reserved;
+ uint32_t codec_type;
uint64_t ap_inst_addr;
};
@@ -77,7 +81,7 @@ struct vdec_ap_ipi_init {
*H264 decoder [0]:buf_sz [1]:nal_start
*VP8 decoder [0]:width/height
*VP9 decoder [0]:profile, [1][2] width/height
- * @reserved : Reserved field
+ * @codec_type : Codec fourcc
*/
struct vdec_ap_ipi_dec_start {
uint32_t msg_id;
@@ -86,7 +90,7 @@ struct vdec_ap_ipi_dec_start {
uint32_t inst_id;
};
uint32_t data[3];
- uint32_t reserved;
+ uint32_t codec_type;
};
/**
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index bfd8e87dceff..c84fac52fe26 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -100,18 +100,29 @@ static void vpu_dec_ipi_handler(void *data, unsigned int
len, void *priv)
static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
{
- int err;
+ int err, id, msgid;
- mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg);
+ msgid = *(uint32_t *)msg;
+ mtk_vcodec_debug(vpu, "id=%X", msgid);
vpu->failure = 0;
vpu->signaled = 0;
- err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, vpu->id, msg,
+ if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
+ if (msgid == AP_IPIMSG_DEC_CORE ||
+ msgid == AP_IPIMSG_DEC_CORE_END)
+ id = vpu->core_id;
+ else
+ id = vpu->id;
+ } else {
+ id = vpu->id;
+ }
+
+ err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg,
len, 2000);
so
if (err) {
mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X status=%d",
- vpu->id, *(uint32_t *)msg, err);
+ id, msgid, err);
return err;
}
@@ -131,6 +142,7 @@ static int vcodec_send_ap_ipi(struct vdec_vpu_inst *vpu, unsigned int msg_id)
msg.vpu_inst_addr = vpu->inst_addr;
else
msg.inst_id = vpu->inst_id;
+ msg.codec_type = vpu->codec_type;
err = vcodec_vpu_send_msg(vpu, &msg, sizeof(msg));
mtk_vcodec_debug(vpu, "- id=%X ret=%d", msg_id, err);
@@ -149,14 +161,25 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler, vpu->id,
vpu->handler, "vdec", NULL);
- if (err != 0) {
+ if (err) {
could be nice to send a patch with other such fixes,
anyway it is better to send unrelated fixes in a separate patch
mtk_vcodec_err(vpu, "vpu_ipi_register fail status=%d", err);
return err;
}
+ if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
+ err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
+vpu->core_id, vpu->handler,
+"vdec", NULL);
+ if (err) {
+ mtk_vcodec_err(vp
Re: [PATCH v7 04/12] iommu/mediatek: Add device_link between the consumer and the larb devices
On 30.07.21 04:52, Yong Wu wrote:
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enable the smi-larb's power which
also need enable the smi-common's power firstly.
Thus, First of all, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.
This patch adds device_link between the consumer and the larbs.
When device_link_add, I add the flag DL_FLAG_STATELESS to avoid calling
pm_runtime_xx to keep the original status of clocks. It can avoid two
issues:
1) Display HW show fastlogo abnormally reported in [1]. At the beggining,
all the clocks are enabled before entering kernel, but the clocks for
display HW(always in larb0) will be gated after clk_enable and clk_disable
called from device_link_add(->pm_runtime_resume) and rpm_idle. The clock
operation happened before display driver probe. At that time, the display
HW will be abnormal.
2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip
pm_runtime_xx to avoid the deadlock.
Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then
device_link_removed should be added explicitly.
[1] https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/
[2] https://lore.kernel.org/patchwork/patch/1086569/
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
Tested-by: Dafna Hirschfeld # on mt8173
Hi, unfortunately, I have to take back the Tested-by tag.
I am now testing the mtk-vcodec with latest kernel + patches sent from the
mailing list:
https://gitlab.collabora.com/eballetbo/linux/-/commits/topic/chromeos/chromeos-5.14
which includes this patchset.
On chromeos I open a video conference with googl-meet which cause the
mtk-vcodec vp8 encoder to run.
If I kill it with `killall -9 chrome` I get some page fault messages from the
iommu:
[ 837.255952] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.265696] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.282367] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.299028] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.315683] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.332345] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.349004] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.365665] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.382329] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
[ 837.42] mtk-iommu 10205000.iommu: fault type=0x5 iova=0xfcff0001 pa=0x0
larb=0 port=0 layer=1 read
In addition, running the encoder tests from the shell:
sudo --user=#1000
/usr/local/libexec/chrome-binary-tests/video_encode_accelerator_tests
--gtest_filter=VideoEncoderTest.FlushAtEndOfStream_Multiple* --codec=vp8
/usr/local/share/tast/data/chromiumos/tast/local/bundles/cros/video/data/tulip2-320x180.yuv
--disable_validator
At some point it fails with the error
[ 5472.161821] [MTK_V4L2][ERROR] mtk_vcodec_wait_for_done_ctx:32: [290]
ctx->type=1, cmd=1, wait_event_interruptible_timeout time=1000ms out 0 0!
[ 5472.174678] [MTK_VCODEC][ERROR][290]: vp8_enc_encode_frame() irq_status=0
failed
[ 5472.182687] [MTK_V4L2][ERROR] mtk_venc_worker:1239: venc_if_encode failed=-5
If you have any idea of what might be the problem or how to debug?
Thanks,
Dafna
---
drivers/iommu/mtk_iommu.c| 22 ++
drivers/iommu/mtk_iommu_v1.c | 20 +++-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index a02dde094788..ee742900cf4b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -571,22 +571,44 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct mtk_iommu_data *data;
+ struct device_link *link;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return ERR_PTR(-ENODEV); /* Not a iommu client device */
data = dev_iommu_priv_get(dev);
+ /*
+* Link the consumer device with the smi-larb device(supplier)
+* The device in each a larb is a independent HW. thus only link
+* one larb here.
+*/
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ larbd
Re: [PATCH v6 00/11] Clean up "mediatek,larb"
Hi Thanks for the patchset. I tested it on mt8173 (elm) with chromeos userspace. Before that patchset, the test: tast -verbose run -build=false 10.42.0.175 video.DecodeAccel.h264 sometimes passed and sometimes failed with 'context deadline exceeded'. With this patchset it seems that the test always passes so I added tested-by: Tested-by: Dafna Hirschfeld Thanks, Dafna On 14.07.21 04:56, Yong Wu wrote: MediaTek IOMMU block diagram always like below: M4U | smi-common | - | | ... | | larb1 larb2 | | vdec venc All the consumer connect with smi-larb, then connect with smi-common. When the consumer works, it should enable the smi-larb's power which also need enable the smi-common's power firstly. Thus, Firstly, use the device link connect the consumer and the smi-larbs. then add device link between the smi-larb and smi-common. After adding the device_link, then "mediatek,larb" property can be removed. the iommu consumer don't need call the mtk_smi_larb_get/put to enable the power and clock of smi-larb and smi-common. About the MM dt-binding/dtsi patches, I guess they should go together, thus I don't split them for each a MM module and each a SoC. Base on v5.14-rc1, and a jpeg[1] and mdp[2] patchset. [1] https://lore.kernel.org/linux-mediatek/20210702102304.3346429-1-hsi...@chromium.org/ [2] https://lore.kernel.org/linux-mediatek/20210709022324.1607884-1-ei...@chromium.org/ Change notes: v6: 1) rebase on v5.14-rc1. 2) Fix the issue commented in v5 from Dafna and Hsin-Yi. 3) Remove the patches about using pm_runtime_resume_and_get since they have already been merged by other patches. v5: https://lore.kernel.org/linux-mediatek/20210410091128.31823-1-yong...@mediatek.com/ 1) Base v5.12-rc2. 2) Remove changing the mtk-iommu to module_platform_driver patch, It have already been a independent patch. v4: https://lore.kernel.org/linux-mediatek/1590826218-23653-1-git-send-email-yong...@mediatek.com/ base on v5.7-rc1. 1) Move drm PM patch before smi patchs. 2) Change builtin_platform_driver to module_platform_driver since we may need build as module. 3) Rebase many patchset as above. v3: https://lore.kernel.org/linux-iommu/1567503456-24725-1-git-send-email-yong...@mediatek.com/ 1) rebase on v5.3-rc1 and the latest mt8183 patchset. 2) Use device_is_bound to check whether the driver is ready from Matthias. 3) Add DL_FLAG_STATELESS flag when calling device_link_add and explain the reason in the commit message[3/14]. 4) Add a display patch[12/14] into this series. otherwise it may affect display HW fastlogo even though it don't happen in mt8183. v2: https://lore.kernel.org/linux-iommu/1560171313-28299-1-git-send-email-yong...@mediatek.com/ 1) rebase on v5.2-rc1. 2) Move adding device_link between the consumer and smi-larb into iommu_add_device from Robin. 3) add DL_FLAG_AUTOREMOVE_CONSUMER even though the smi is built-in from Evan. 4) Remove the shutdown callback in iommu. v1: https://lore.kernel.org/linux-iommu/1546318276-18993-1-git-send-email-yong...@mediatek.com/ Yong Wu (10): dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW iommu/mediatek: Add probe_defer for smi-larb iommu/mediatek: Add device_link between the consumer and the larb devices media: mtk-jpeg: Get rid of mtk_smi_larb_get/put media: mtk-mdp: Get rid of mtk_smi_larb_get/put drm/mediatek: Get rid of mtk_smi_larb_get/put media: mtk-vcodec: Get rid of mtk_smi_larb_get/put memory: mtk-smi: Get rid of mtk_smi_larb_get/put arm: dts: mediatek: Get rid of mediatek,larb for MM nodes arm64: dts: mediatek: Get rid of mediatek,larb for MM nodes Yongqiang Niu (1): drm/mediatek: Add pm runtime support for ovl and rdma .../display/mediatek/mediatek,disp.txt| 9 .../bindings/media/mediatek-jpeg-decoder.yaml | 9 .../bindings/media/mediatek-jpeg-encoder.yaml | 9 .../bindings/media/mediatek-mdp.txt | 8 .../bindings/media/mediatek-vcodec.txt| 4 -- arch/arm/boot/dts/mt2701.dtsi | 2 - arch/arm/boot/dts/mt7623n.dtsi| 5 -- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16 --- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 9 +++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 9 +++- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 36 +-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 - drivers/gpu/drm/mediatek/mtk_drm_drv.c| 5 +- drivers/iommu/mtk_iommu.c | 24 +- drivers/iommu/mtk_iommu_v1.c | 22 - .../media/platform/mtk-jpeg/mtk_jpeg_core.c
Re: [PATCH v6 01/11] dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW
On 14.07.21 10:13, Dafna Hirschfeld wrote:
Hi,
thanks for the patch
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connects with from
iommu id in the "iommus=" property.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
Reviewed-by: Evan Green
---
.../bindings/display/mediatek/mediatek,disp.txt | 9 -
.../devicetree/bindings/media/mediatek-jpeg-decoder.yaml | 9 -
.../devicetree/bindings/media/mediatek-jpeg-encoder.yaml | 9 -
On which repo are these patches based on ?
In linux-next the file mediatek-jpeg-encoder.yaml don't exist
Thanks,
Dafna
sorry, I see you reference the patch that convert to yaml in the cover letter.
Thanks,
Dafna
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 8
.../devicetree/bindings/media/mediatek-vcodec.txt | 4
5 files changed, 39 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index fbb59c9ddda6..867bd82e2f03 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -61,8 +61,6 @@ Required properties (DMA function blocks):
"mediatek,-disp-rdma"
"mediatek,-disp-wdma"
the supported chips are mt2701, mt8167 and mt8173.
-- larb: Should contain a phandle pointing to the local arbiter device as
defined
- in
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- iommus: Should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
@@ -91,7 +89,6 @@ ovl0: ovl@1400c000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OVL0>;
iommus = <&iommu M4U_PORT_DISP_OVL0>;
- mediatek,larb = <&larb0>;
};
ovl1: ovl@1400d000 {
@@ -101,7 +98,6 @@ ovl1: ovl@1400d000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OVL1>;
iommus = <&iommu M4U_PORT_DISP_OVL1>;
- mediatek,larb = <&larb4>;
};
rdma0: rdma@1400e000 {
@@ -111,7 +107,6 @@ rdma0: rdma@1400e000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA0>;
iommus = <&iommu M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <&larb0>;
mediatek,rdma-fifosize = <8192>;
};
@@ -122,7 +117,6 @@ rdma1: rdma@1400f000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA1>;
iommus = <&iommu M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <&larb4>;
};
rdma2: rdma@1401 {
@@ -132,7 +126,6 @@ rdma2: rdma@1401 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA2>;
iommus = <&iommu M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <&larb4>;
};
wdma0: wdma@14011000 {
@@ -142,7 +135,6 @@ wdma0: wdma@14011000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_WDMA0>;
iommus = <&iommu M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <&larb0>;
};
wdma1: wdma@14012000 {
@@ -152,7 +144,6 @@ wdma1: wdma@14012000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_WDMA1>;
iommus = <&iommu M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <&larb4>;
};
color0: color@14013000 {
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index 9b87f036f178..052e752157b4 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -42,13 +42,6 @@ properties:
power-domains:
maxItems: 1
- mediatek,larb:
- $ref: '/schemas/types.yaml#/definitions/phandle'
- description: |
- Must contain the local arbiters in the current Socs, see
-
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- for details.
-
iommus:
maxItems: 2
description: |
@@ -63,7 +56,6 @@ required:
- clocks
- clock-names
- power-domains
- - mediatek,larb
- iommus
additionalProperties: false
@@ -83,7 +75,6 @@ examples:
clock-names = &quo
Re: [PATCH v6 06/11] drm/mediatek: Add pm runtime support for ovl and rdma
On 14.07.21 04:56, Yong Wu wrote:
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.
CC: CK Hu
Signed-off-by: Yongqiang Niu
Signed-off-by: Yong Wu
(Yong: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync)
Acked-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 9 -
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 9 -
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 12 +++-
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index fa9d79963cd3..ea5760f856ec 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "mtk_disp_drv.h"
@@ -414,15 +415,21 @@ static int mtk_disp_ovl_probe(struct platform_device
*pdev)
return ret;
}
+ pm_runtime_enable(dev);
+
ret = component_add(dev, &mtk_disp_ovl_component_ops);
- if (ret)
+ if (ret) {
+ pm_runtime_disable(dev);
dev_err(dev, "Failed to add component: %d\n", ret);
+ }
return ret;
}
static int mtk_disp_ovl_remove(struct platform_device *pdev)
{
+ pm_runtime_disable(&pdev->dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 705f28ceb4dd..0f31d1c8e37c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include "mtk_disp_drv.h"
@@ -327,9 +328,13 @@ static int mtk_disp_rdma_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, priv);
+ pm_runtime_enable(dev);
+
ret = component_add(dev, &mtk_disp_rdma_component_ops);
- if (ret)
+ if (ret) {
+ pm_runtime_disable(dev);
dev_err(dev, "Failed to add component: %d\n", ret);
+ }
return ret;
}
@@ -338,6 +343,8 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
{
component_del(&pdev->dev, &mtk_disp_rdma_component_ops);
+ pm_runtime_disable(&pdev->dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 474efb844249..08e3f352377d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -557,9 +557,15 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
return;
}
+ ret = pm_runtime_resume_and_get(comp->dev);
+ if (ret < 0)
+ DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
+ ret);
shouldn't the code return in case of failure here?
Thanks,
Dafna
+
ret = mtk_crtc_ddp_hw_init(mtk_crtc);
if (ret) {
mtk_smi_larb_put(comp->larb_dev);
+ pm_runtime_put(comp->dev);
return;
}
@@ -572,7 +578,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
- int i;
+ int i, ret;
DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
if (!mtk_crtc->enabled)
@@ -596,6 +602,10 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
drm_crtc_vblank_off(crtc);
mtk_crtc_ddp_hw_fini(mtk_crtc);
mtk_smi_larb_put(comp->larb_dev);
+ ret = pm_runtime_put(comp->dev);
+ if (ret < 0)
+ DRM_DEV_ERROR(comp->dev, "Failed to disable power domain: %d\n",
+ ret);
mtk_crtc->enabled = false;
}
Re: [PATCH v6 09/11] memory: mtk-smi: Get rid of mtk_smi_larb_get/put
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked-by: Matthias Brugger
Reviewed-by: Dafna Hirschfeld
---
drivers/memory/mtk-smi.c | 14 --
include/soc/mediatek/smi.h | 20
2 files changed, 34 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index c5fb51f73b34..7c61c924e220 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -134,20 +134,6 @@ static void mtk_smi_clk_disable(const struct mtk_smi *smi)
clk_disable_unprepare(smi->clk_apb);
}
-int mtk_smi_larb_get(struct device *larbdev)
-{
- int ret = pm_runtime_resume_and_get(larbdev);
-
- return (ret < 0) ? ret : 0;
-}
-EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
-
-void mtk_smi_larb_put(struct device *larbdev)
-{
- pm_runtime_put_sync(larbdev);
-}
-EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
-
static int
mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
{
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 15e3397cec58..11f7d6b59642 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -19,26 +19,6 @@ struct mtk_smi_larb_iommu {
unsigned char bank[32];
};
-/*
- * mtk_smi_larb_get: Enable the power domain and clocks for this local arbiter.
- * It also initialize some basic setting(like iommu).
- * mtk_smi_larb_put: Disable the power domain and clocks for this local
arbiter.
- * Both should be called in non-atomic context.
- *
- * Returns 0 if successful, negative on failure.
- */
-int mtk_smi_larb_get(struct device *larbdev);
-void mtk_smi_larb_put(struct device *larbdev);
-
-#else
-
-static inline int mtk_smi_larb_get(struct device *larbdev)
-{
- return 0;
-}
-
-static inline void mtk_smi_larb_put(struct device *larbdev) { }
-
#endif
#endif
Re: [PATCH v6 08/11] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Tiffany Lin
Reviewed-by: Dafna Hirschfeld
---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 +++-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 44 +++
4 files changed, 10 insertions(+), 75 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..d0bf9aa3b29d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -8,14 +8,12 @@
#include
#include
#include
-#include
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
@@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
pm = &mtkdev->pm;
pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
- node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (WARN_ON(!pdev)) {
- return -1;
- }
- pm->larbvdec = &pdev->dev;
pdev = mtkdev->plat_dev;
pm->dev = &pdev->dev;
@@ -47,14 +34,11 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
dec_clk->clk_info = devm_kcalloc(&pdev->dev,
dec_clk->clk_num, sizeof(*clk_info),
GFP_KERNEL);
- if (!dec_clk->clk_info) {
- ret = -ENOMEM;
- goto put_device;
- }
+ if (!dec_clk->clk_info)
+ return -ENOMEM;
} else {
mtk_v4l2_err("Failed to get vdec clock count");
- ret = -EINVAL;
- goto put_device;
+ return -EINVAL;
}
for (i = 0; i < dec_clk->clk_num; i++) {
@@ -63,29 +47,24 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
"clock-names", i, &clk_info->clk_name);
if (ret) {
mtk_v4l2_err("Failed to get clock name id = %d", i);
- goto put_device;
+ return ret;
}
clk_info->vcodec_clk = devm_clk_get(&pdev->dev,
clk_info->clk_name);
if (IS_ERR(clk_info->vcodec_clk)) {
mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
clk_info->clk_name);
- ret = PTR_ERR(clk_info->vcodec_clk);
- goto put_device;
+ return PTR_ERR(clk_info->vcodec_clk);
}
}
pm_runtime_enable(&pdev->dev);
return 0;
-put_device:
- put_device(pm->larbvdec);
- return ret;
}
void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
{
pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
}
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
@@ -122,11 +101,6 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
}
}
- ret = mtk_smi_larb_get(pm->larbvdec);
- if (ret) {
- mtk_v4l2_err("mtk_smi_larb_get larbvdec fail %d", ret);
- goto error;
- }
return;
error:
@@ -139,7 +113,6 @@ void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
struct mtk_vcodec_clk *dec_clk = &pm->vdec_clk;
int i = 0;
- mtk_smi_larb_put(pm->larbvdec);
for (i = dec_clk->clk_num - 1; i >= 0; i--)
clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index c6c7672fecfb..64b73dd880ce 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -189,10 +189,7 @@ struct mtk_vcodec_clk {
*/
struct mtk_vcodec_pm {
str
Re: [PATCH v6 07/11] drm/mediatek: Get rid of mtk_smi_larb_get/put
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Chun-Kuang Hu
Reviewed-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 9 --
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 36 ++---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 -
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +--
4 files changed, 3 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 08e3f352377d..d046abcf66ce 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -10,7 +10,6 @@
#include
#include
-#include
#include
#include
@@ -551,12 +550,6 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
- ret = mtk_smi_larb_get(comp->larb_dev);
- if (ret) {
- DRM_ERROR("Failed to get larb: %d\n", ret);
- return;
- }
-
ret = pm_runtime_resume_and_get(comp->dev);
if (ret < 0)
DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
@@ -564,7 +557,6 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
ret = mtk_crtc_ddp_hw_init(mtk_crtc);
if (ret) {
- mtk_smi_larb_put(comp->larb_dev);
pm_runtime_put(comp->dev);
return;
}
@@ -601,7 +593,6 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
drm_crtc_vblank_off(crtc);
mtk_crtc_ddp_hw_fini(mtk_crtc);
- mtk_smi_larb_put(comp->larb_dev);
ret = pm_runtime_put(comp->dev);
if (ret < 0)
DRM_DEV_ERROR(comp->dev, "Failed to disable power domain: %d\n",
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 75bc00e17fc4..7d240218d4c7 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -449,37 +449,15 @@ unsigned int mtk_drm_find_possible_crtc_by_comp(struct
drm_device *drm,
return ret;
}
-static int mtk_ddp_get_larb_dev(struct device_node *node, struct mtk_ddp_comp *comp,
- struct device *dev)
-{
- struct device_node *larb_node;
- struct platform_device *larb_pdev;
-
- larb_node = of_parse_phandle(node, "mediatek,larb", 0);
- if (!larb_node) {
- dev_err(dev, "Missing mediadek,larb phandle in %pOF node\n",
node);
- return -EINVAL;
- }
-
- larb_pdev = of_find_device_by_node(larb_node);
- if (!larb_pdev) {
- dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
- of_node_put(larb_node);
- return -EPROBE_DEFER;
- }
- of_node_put(larb_node);
- comp->larb_dev = &larb_pdev->dev;
-
- return 0;
-}
-
int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
enum mtk_ddp_comp_id comp_id)
{
struct platform_device *comp_pdev;
enum mtk_ddp_comp_type type;
struct mtk_ddp_comp_dev *priv;
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
int ret;
+#endif
if (comp_id < 0 || comp_id >= DDP_COMPONENT_ID_MAX)
return -EINVAL;
@@ -495,16 +473,6 @@ int mtk_ddp_comp_init(struct device_node *node, struct
mtk_ddp_comp *comp,
}
comp->dev = &comp_pdev->dev;
- /* Only DMA capable components need the LARB property */
- if (type == MTK_DISP_OVL ||
- type == MTK_DISP_OVL_2L ||
- type == MTK_DISP_RDMA ||
- type == MTK_DISP_WDMA) {
- ret = mtk_ddp_get_larb_dev(node, comp, comp->dev);
- if (ret)
- return ret;
- }
-
if (type == MTK_DISP_BLS ||
type == MTK_DISP_CCORR ||
type == MTK_DISP_COLOR ||
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index bb914d976cf5..1b582262b682 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -70,7 +70,6 @@ struct mtk_ddp_comp_funcs {
struct mtk_ddp_comp {
struct device *dev;
int irq;
- struct device *larb_dev;
enum mtk_ddp_comp_id id;
const struct mtk_ddp_comp_funcs *funcs;
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b46bdb8985da..0d5ef3d8d081 100644
--- a
Re: [PATCH v6 05/11] media: mtk-mdp: Get rid of mtk_smi_larb_get/put
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed-by: Houlong Wei
Reviewed-by: Dafna Hirschfeld
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 46 +--
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 -
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 1 -
3 files changed, 1 insertion(+), 48 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index de2d425efdd1..5e0ea83a9f7f 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include "mtk_mdp_comp.h"
@@ -57,13 +56,6 @@ int mtk_mdp_comp_power_on(struct mtk_mdp_comp *comp)
{
int status, err;
- if (comp->larb_dev) {
- err = mtk_smi_larb_get(comp->larb_dev);
- if (err)
- dev_err(comp->dev,
- "failed to get larb, err %d.\n", err);
- }
-
err = pm_runtime_get_sync(comp->dev);
if (err < 0) {
dev_err(comp->dev, "failed to runtime get, err %d.\n", err);
@@ -146,9 +138,6 @@ void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp)
continue;
clk_disable_unprepare(comp->clk[i]);
}
-
- if (comp->larb_dev)
- mtk_smi_larb_put(comp->larb_dev);
}
/*
@@ -236,9 +225,6 @@ static const struct component_ops mtk_mdp_component_ops = {
int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
{
- struct device_node *larb_node;
- struct platform_device *larb_pdev;
- int ret;
int i;
struct device_node *node = dev->of_node;
enum mtk_mdp_comp_type comp_type =
@@ -252,8 +238,7 @@ int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct
device *dev)
if (IS_ERR(comp->clk[i])) {
if (PTR_ERR(comp->clk[i]) != -EPROBE_DEFER)
dev_err(dev, "Failed to get clock\n");
- ret = PTR_ERR(comp->clk[i]);
- goto err;
+ return PTR_ERR(comp->clk[i]);
}
/* Only RDMA needs two clocks */
@@ -261,36 +246,7 @@ int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct
device *dev)
break;
}
- /* Only DMA capable components need the LARB property */
- comp->larb_dev = NULL;
- if (comp_type != MTK_MDP_RDMA &&
- comp_type != MTK_MDP_WDMA &&
- comp_type != MTK_MDP_WROT)
- return 0;
-
- larb_node = of_parse_phandle(node, "mediatek,larb", 0);
- if (!larb_node) {
- dev_err(dev,
- "Missing mediadek,larb phandle in %pOF node\n", node);
- ret = -EINVAL;
- goto err;
- }
-
- larb_pdev = of_find_device_by_node(larb_node);
- if (!larb_pdev) {
- dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
- of_node_put(larb_node);
- ret = -EPROBE_DEFER;
- goto err;
- }
- of_node_put(larb_node);
-
- comp->larb_dev = &larb_pdev->dev;
-
return 0;
-
-err:
- return ret;
}
static int mtk_mdp_comp_probe(struct platform_device *pdev)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 5201c47f7baa..2bd229cc7eae 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -11,13 +11,11 @@
* struct mtk_mdp_comp - the MDP's function component data
* @node: list node to track sibing MDP components
* @clk: clocks required for component
- * @larb_dev: SMI device required for component
* @dev: component's device
*/
struct mtk_mdp_comp {
struct list_headnode;
struct clk *clk[2];
- struct device *larb_dev;
struct device *dev;
};
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index e1fb39231248..be7d35b3e3ff 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include "mtk_mdp_comp.h"
#include "mtk_mdp_core.h"
Re: [PATCH v6 04/11] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_init is
also unnecessary. Remove it too.
CC: Rick Chang
CC: Xia Jiang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Rick Chang
Reviewed-by: Dafna Hirschfeld
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 45 +--
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 -
2 files changed, 2 insertions(+), 45 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index a89c7b206eef..4fea2c512434 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -22,7 +22,6 @@
#include
#include
#include
-#include
#include "mtk_jpeg_enc_hw.h"
#include "mtk_jpeg_dec_hw.h"
@@ -1055,10 +1054,6 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
{
int ret;
- ret = mtk_smi_larb_get(jpeg->larb);
- if (ret)
- dev_err(jpeg->dev, "mtk_smi_larb_get larbvdec fail %d\n", ret);
-
ret = clk_bulk_prepare_enable(jpeg->variant->num_clks,
jpeg->variant->clks);
if (ret)
@@ -1069,7 +1064,6 @@ static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
{
clk_bulk_disable_unprepare(jpeg->variant->num_clks,
jpeg->variant->clks);
- mtk_smi_larb_put(jpeg->larb);
}
static irqreturn_t mtk_jpeg_enc_done(struct mtk_jpeg_dev *jpeg)
@@ -1284,35 +1278,6 @@ static struct clk_bulk_data mtk_jpeg_clocks[] = {
{ .id = "jpgenc" },
};
-static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
-{
- struct device_node *node;
- struct platform_device *pdev;
- int ret;
-
- node = of_parse_phandle(jpeg->dev->of_node, "mediatek,larb", 0);
- if (!node)
- return -EINVAL;
- pdev = of_find_device_by_node(node);
- if (WARN_ON(!pdev)) {
- of_node_put(node);
- return -EINVAL;
- }
- of_node_put(node);
-
- jpeg->larb = &pdev->dev;
-
- ret = devm_clk_bulk_get(jpeg->dev, jpeg->variant->num_clks,
- jpeg->variant->clks);
- if (ret) {
- dev_err(&pdev->dev, "failed to get jpeg clock:%d\n", ret);
- put_device(&pdev->dev);
- return ret;
- }
-
- return 0;
-}
-
static void mtk_jpeg_job_timeout_work(struct work_struct *work)
{
struct mtk_jpeg_dev *jpeg = container_of(work, struct mtk_jpeg_dev,
@@ -1333,11 +1298,6 @@ static void mtk_jpeg_job_timeout_work(struct work_struct
*work)
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
}
-static inline void mtk_jpeg_clk_release(struct mtk_jpeg_dev *jpeg)
-{
- put_device(jpeg->larb);
-}
-
static int mtk_jpeg_probe(struct platform_device *pdev)
{
struct mtk_jpeg_dev *jpeg;
@@ -1376,7 +1336,8 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
goto err_req_irq;
}
- ret = mtk_jpeg_clk_init(jpeg);
+ ret = devm_clk_bulk_get(jpeg->dev, jpeg->variant->num_clks,
+ jpeg->variant->clks);
if (ret) {
dev_err(&pdev->dev, "Failed to init clk, err %d\n", ret);
goto err_clk_init;
@@ -1442,7 +1403,6 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
v4l2_device_unregister(&jpeg->v4l2_dev);
err_dev_register:
- mtk_jpeg_clk_release(jpeg);
err_clk_init:
@@ -1460,7 +1420,6 @@ static int mtk_jpeg_remove(struct platform_device *pdev)
video_device_release(jpeg->vdev);
v4l2_m2m_release(jpeg->m2m_dev);
v4l2_device_unregister(&jpeg->v4l2_dev);
- mtk_jpeg_clk_release(jpeg);
return 0;
}
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 595f7f10c9fd..3e4811a41ba2 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -85,7 +85,6 @@ struct mtk_jpeg_variant {
* @alloc_ctx:videobuf2 memory allocator's context
* @vdev: video device node for jpeg mem2mem mode
* @reg_base: JPEG registers mapping
- * @larb: SMI device
* @job_timeout_work: IRQ timeout structure
* @variant: driver variant to be used
*/
@@ -99,7 +98,6 @@ struct mtk_jpeg_dev {
void*alloc_ctx;
struct video_device *vdev;
void __iomem*reg_base;
- struct device *larb;
struct delayed_work job_timeout_work;
const struct mtk_jpeg_variant *variant;
};
Re: [PATCH v6 03/11] iommu/mediatek: Add device_link between the consumer and the larb devices
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enable the smi-larb's power which
also need enable the smi-common's power firstly.
Thus, First of all, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.
This patch adds device_link between the consumer and the larbs.
When device_link_add, I add the flag DL_FLAG_STATELESS to avoid calling
pm_runtime_xx to keep the original status of clocks. It can avoid two
issues:
1) Display HW show fastlogo abnormally reported in [1]. At the beggining,
all the clocks are enabled before entering kernel, but the clocks for
display HW(always in larb0) will be gated after clk_enable and clk_disable
called from device_link_add(->pm_runtime_resume) and rpm_idle. The clock
operation happened before display driver probe. At that time, the display
HW will be abnormal.
2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip
pm_runtime_xx to avoid the deadlock.
Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then
device_link_removed should be added explicitly.
[1] https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/
[2] https://lore.kernel.org/patchwork/patch/1086569/
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 22 ++
drivers/iommu/mtk_iommu_v1.c | 20 +++-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index a02dde094788..ee742900cf4b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -571,22 +571,44 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct mtk_iommu_data *data;
+ struct device_link *link;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return ERR_PTR(-ENODEV); /* Not a iommu client device */
data = dev_iommu_priv_get(dev);
+ /*
+* Link the consumer device with the smi-larb device(supplier)
+* The device in each a larb is a independent HW. thus only link
+* one larb here.
+*/
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ link = device_link_add(dev, larbdev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
shoudn't ERR_PTR be returned in case of failure?
Thanks,
Dafna
return &data->iommu;
}
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct mtk_iommu_data *data;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return;
+ data = dev_iommu_priv_get(dev);
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ device_link_remove(dev, larbdev);
+
iommu_fwspec_free(dev);
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index d9365a3d8dc9..d2a7c66b8239 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -424,7 +424,9 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct of_phandle_args iommu_spec;
struct mtk_iommu_data *data;
- int err, idx = 0;
+ int err, idx = 0, larbid;
+ struct device_link *link;
+ struct device *larbdev;
while (!of_parse_phandle_with_args(dev->of_node, "iommus",
"#iommu-cells",
@@ -445,6 +447,14 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
data = dev_iommu_priv_get(dev);
+ /* Link the consumer device with the smi-larb device(supplier) */
+ larbid = mt2701_m4u_to_larb(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ link = device_link_add(dev, larbdev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
+
return &data->iommu;
}
@@ -465,10 +475,18 @@ static void mtk_iommu_probe_finalize(struct device *dev)
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct mtk_iommu_data *data;
+ struct device *larbdev;
+ un
Re: [PATCH v6 01/11] dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW
Hi,
thanks for the patch
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connects with from
iommu id in the "iommus=" property.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
Reviewed-by: Evan Green
---
.../bindings/display/mediatek/mediatek,disp.txt | 9 -
.../devicetree/bindings/media/mediatek-jpeg-decoder.yaml | 9 -
.../devicetree/bindings/media/mediatek-jpeg-encoder.yaml | 9 -
On which repo are these patches based on ?
In linux-next the file mediatek-jpeg-encoder.yaml don't exist
Thanks,
Dafna
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 8
.../devicetree/bindings/media/mediatek-vcodec.txt| 4
5 files changed, 39 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index fbb59c9ddda6..867bd82e2f03 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -61,8 +61,6 @@ Required properties (DMA function blocks):
"mediatek,-disp-rdma"
"mediatek,-disp-wdma"
the supported chips are mt2701, mt8167 and mt8173.
-- larb: Should contain a phandle pointing to the local arbiter device as
defined
- in
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- iommus: Should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
@@ -91,7 +89,6 @@ ovl0: ovl@1400c000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OVL0>;
iommus = <&iommu M4U_PORT_DISP_OVL0>;
- mediatek,larb = <&larb0>;
};
ovl1: ovl@1400d000 {
@@ -101,7 +98,6 @@ ovl1: ovl@1400d000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OVL1>;
iommus = <&iommu M4U_PORT_DISP_OVL1>;
- mediatek,larb = <&larb4>;
};
rdma0: rdma@1400e000 {
@@ -111,7 +107,6 @@ rdma0: rdma@1400e000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA0>;
iommus = <&iommu M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <&larb0>;
mediatek,rdma-fifosize = <8192>;
};
@@ -122,7 +117,6 @@ rdma1: rdma@1400f000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA1>;
iommus = <&iommu M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <&larb4>;
};
rdma2: rdma@1401 {
@@ -132,7 +126,6 @@ rdma2: rdma@1401 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA2>;
iommus = <&iommu M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <&larb4>;
};
wdma0: wdma@14011000 {
@@ -142,7 +135,6 @@ wdma0: wdma@14011000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_WDMA0>;
iommus = <&iommu M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <&larb0>;
};
wdma1: wdma@14012000 {
@@ -152,7 +144,6 @@ wdma1: wdma@14012000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_WDMA1>;
iommus = <&iommu M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <&larb4>;
};
color0: color@14013000 {
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index 9b87f036f178..052e752157b4 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -42,13 +42,6 @@ properties:
power-domains:
maxItems: 1
- mediatek,larb:
-$ref: '/schemas/types.yaml#/definitions/phandle'
-description: |
- Must contain the local arbiters in the current Socs, see
-
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- for details.
-
iommus:
maxItems: 2
description: |
@@ -63,7 +56,6 @@ required:
- clocks
- clock-names
- power-domains
- - mediatek,larb
- iommus
additionalProperties: false
@@ -83,7 +75,6 @@ examples:
clock-names = "jpgdec-smi",
"jpgdec";
power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <&larb2>;
iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
<&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
b/Documentation/devicetree/bindings/media/medi
[PATCH] drm/mediatek: Test component initialization earlier in the function mtk_drm_crtc_create
The initialization is currently tested in a later stage in
the function for no reason.
In addition, the test '!comp' will never fail since comp is
set with the '&' operator. Instead, test if a comp was not
initialized by testing "!comp->dev".
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 474efb844249..06f40e589922 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -755,14 +755,22 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
for (i = 0; i < path_len; i++) {
enum mtk_ddp_comp_id comp_id = path[i];
struct device_node *node;
+ struct mtk_ddp_comp *comp;
node = priv->comp_node[comp_id];
+ comp = &priv->ddp_comp[comp_id];
+
if (!node) {
dev_info(dev,
"Not creating crtc %d because component %d is
disabled or missing\n",
pipe, comp_id);
return 0;
}
+
+ if (!comp->dev) {
+ dev_err(dev, "Component %pOF not initialized\n", node);
+ return -ENODEV;
+ }
}
mtk_crtc = devm_kzalloc(dev, sizeof(*mtk_crtc), GFP_KERNEL);
@@ -787,16 +795,8 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
enum mtk_ddp_comp_id comp_id = path[i];
struct mtk_ddp_comp *comp;
- struct device_node *node;
- node = priv->comp_node[comp_id];
comp = &priv->ddp_comp[comp_id];
- if (!comp) {
- dev_err(dev, "Component %pOF not initialized\n", node);
- ret = -ENODEV;
- return ret;
- }
-
mtk_crtc->ddp_comp[i] = comp;
if (comp->funcs) {
--
2.17.1
Re: Aw: Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on mt7623/bananapi-r2
Hi, On 12.07.21 19:16, Frank Wunderlich wrote: Hi, it turns out that problem is the read+or of the new value i reverted my patch and changed reg = readl_relaxed(mmsys->regs + routes[i].addr) | routes[i].val; writel_relaxed(reg, mmsys->regs + routes[i].addr); to writel_relaxed(routes[i].val, mmsys->regs + routes[i].addr); and it works too, but maybe it breaks other platforms Interesting, I can test if it fix that similar bug on mt8173 when resume from suspend. Thanks, Dafna regards Frank
Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on mt7623/bananapi-r2
Hi
On 10.07.21 15:24, Frank Wunderlich wrote:
From: Frank Wunderlich
HDMI output was broken on mt7623/BPI-R2 in 5.13 because function for
special output selection (mtk_mmsys_ddp_sout_sel) was dropped.
This function wrote 3 registers at one time and so it is not compatible
with the array-approach.
I re-added the old function and call this after the default routing table
was applied. This default routing table can still be used as the only
connection handled by mmsys on BPI-R2 is OVL0->RDMA0 and this is already
present in the default routing table
Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing
registers")
Signed-off-by: Frank Wunderlich
---
drivers/soc/mediatek/mtk-mmsys.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 080660ef11bf..f91b7fdd417a 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -57,6 +57,25 @@ struct mtk_mmsys {
const struct mtk_mmsys_driver_data *data;
};
+static void mtk_mmsys_ddp_sout_sel(struct device *dev,
+ enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next)
+{
+ struct mtk_mmsys *mmsys = dev_get_drvdata(dev);
+
+ if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
+ writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
+ mmsys->regs + DISP_REG_CONFIG_OUT_SEL);
+ } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
+ writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
+ mmsys->regs + DISP_REG_CONFIG_OUT_SEL);
+ writel_relaxed(DSI_SEL_IN_RDMA,
+ mmsys->regs + DISP_REG_CONFIG_DSI_SEL);
+ writel_relaxed(DPI_SEL_IN_BLS,
+ mmsys->regs + DISP_REG_CONFIG_DPI_SEL);
you can still use the array approach for this like that:
{
DDP_COMPONENT_BLS, DDP_COMPONENT_DSI0,
DISP_REG_CONFIG_OUT_SEL, BLS_TO_DSI_RDMA1_TO_DPI1
}, {
{
DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
DISP_REG_CONFIG_OUT_SEL, BLS_TO_DPI_RDMA1_TO_DSI
}, {
{
DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
DISP_REG_CONFIG_DSI_SEL, DSI_SEL_IN_RDMA
}, {
{
DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
DISP_REG_CONFIG_DPI_SEL, DPI_SEL_IN_BLS
}, {
Thanks,
Dafna
+ }
+}
+
void mtk_mmsys_ddp_connect(struct device *dev,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
@@ -71,6 +90,8 @@ void mtk_mmsys_ddp_connect(struct device *dev,
reg = readl_relaxed(mmsys->regs + routes[i].addr) |
routes[i].val;
writel_relaxed(reg, mmsys->regs + routes[i].addr);
}
+
+ mtk_mmsys_ddp_sout_sel(dev, cur, next);
}
EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_connect);
Re: Aw: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)
Hi
On 08.07.21 11:35, Frank Wunderlich wrote:
Hi
just a small update, added debug in the vendor-specific functions for page_flip
and vblank and it seems they never get called
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -87,21 +87,25 @@ static void mtk_drm_crtc_finish_page_flip(struct
mtk_drm_crtc *mtk_crtc)
{
struct drm_crtc *crtc = &mtk_crtc->base;
unsigned long flags;
-
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
spin_lock_irqsave(&crtc->dev->event_lock, flags);
drm_crtc_send_vblank_event(crtc, mtk_crtc->event);
drm_crtc_vblank_put(crtc);
mtk_crtc->event = NULL;
spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
}
static void mtk_drm_finish_page_flip(struct mtk_drm_crtc *mtk_crtc)
{
+printk(KERN_ALERT "DEBUG: Passed %s %d
update:%d,needsvblank:%d\n",__FUNCTION__,__LINE__,mtk_crtc->config_updating,mtk_crtc->pending_needs_vblank);
drm_crtc_handle_vblank(&mtk_crtc->base);
if (!mtk_crtc->config_updating && mtk_crtc->pending_needs_vblank) {
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
mtk_drm_crtc_finish_page_flip(mtk_crtc);
mtk_crtc->pending_needs_vblank = false;
}
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
}
static void mtk_drm_crtc_destroy(struct drm_crtc *crtc)
finish_page_flip is called by mtk_crtc_ddp_irq. this seems to be set in
mtk_drm_crtc_enable_vblank with mtk_ddp_comp_enable_vblank. this is called
correctly
113 static inline void mtk_ddp_comp_enable_vblank(struct mtk_ddp_comp *comp,
114 void (*vblank_cb)(void *),
115 void *vblank_cb_data)
116 {
117 printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
118 if (comp->funcs && comp->funcs->enable_vblank)
119 {
120 comp->funcs->enable_vblank(comp->dev, vblank_cb, vblank_cb_data);
121 printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
122 }
123 }
i see both messages, but mtk_crtc_ddp_irq is never called and so the other 2
not.
Yes, In my case the irq isr is also not called after resume which cause the
warning
even though "enable_vblank" do get called. Don't know why is that.
root@bpi-r2:~# dmesg | grep -i DEBUG
[6.433509] DEBUG: Passed mtk_drm_crtc_enable_vblank 510
[6.433530] DEBUG: Passed mtk_ddp_comp_enable_vblank 117
[6.433537] DEBUG: Passed mtk_ddp_comp_enable_vblank 121 <<<
comp->funcs->enable_vblank should be mtk_drm_crtc_enable_vblank, right?
No, this is a bit confusing , there are also the funcs of the components, see
in file mtk_drm_ddp_comp.c
so for mt7623 it is mtk_ovl_enable_vblank.
Thanks,
Dafna
641 static const struct drm_crtc_funcs mtk_crtc_funcs = {
642 .set_config = drm_atomic_helper_set_config,
643 .page_flip = drm_atomic_helper_page_flip,
644 .destroy= mtk_drm_crtc_destroy,
645 .reset = mtk_drm_crtc_reset,
646 .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
647 .atomic_destroy_state = mtk_drm_crtc_destroy_state,
648 .enable_vblank = mtk_drm_crtc_enable_vblank, <<<<<<<
649 .disable_vblank = mtk_drm_crtc_disable_vblank,
650 };
but it looks like a recursion:
mtk_drm_crtc_enable_vblank calls mtk_ddp_comp_enable_vblank => enable_vblank
(=mtk_drm_crtc_enable_vblank), but i see the messages not repeating
mtk_drm_crtc_enable_vblank(struct drm_crtc *crtc)
511 mtk_ddp_comp_enable_vblank(comp, mtk_crtc_ddp_irq, &mtk_crtc->base);
113 static inline void mtk_ddp_comp_enable_vblank(struct mtk_ddp_comp *comp,
114 void (*vblank_cb)(void *),
115 void *vblank_cb_data)
116 {
118 if (comp->funcs && comp->funcs->enable_vblank)
120 comp->funcs->enable_vblank(comp->dev, vblank_cb, vblank_cb_data);
but params do not match...comp->funcs->enable_vblank takes 3 arguments but
comp->funcs->enable_vblank has only one.something i miss here...
i guess not, but is watchdog somehow involved? i ask because i see this on
reboot/poweroff:
"watchdog: watchdog0: watchdog did not stop!"
i see this with my 5.13, 5.12-drm (5.12.0+mtk/core drm-patches) and 5.12.14 too
(hdmi is working there), but not 5.12.0!
that means something in drm-patches (mtk/core) breaks watchdog. maybe the
recursion mentioned above?
regards Frank
Gesendet: Donnerstag, 08. Juli 2021 um 09:22 Uhr
Von: "Dafna Hirschfeld"
Hi Frank,
On 06.07.21 11:54, Frank Wunderlich wrote:
Hi,
i've notice
Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)
Hi Frank,
On 06.07.21 11:54, Frank Wunderlich wrote:
Hi,
i've noticed that HDMI is broken at least on my board (Bananapi-r2,mt7623) on
5.13.
after some research i noticed that it is working till
commit 2e477391522354e763aa62ee3e281c1ad9e8eb1b
Author: Dafna Hirschfeld
Date: Tue Mar 30 13:09:02 2021 +0200
drm/mediatek: Don't support hdmi connector creation
which is the last of mtk-drm-next-5.13 [1] so i guess a problem with
core-patches
dmesg shows the following:
[7.071342] mediatek-drm mediatek-drm.1.auto: bound 14007000.ovl (ops mtk_dis
p_ovl_component_ops)
[7.080330] mediatek-drm mediatek-drm.1.auto: bound 14008000.rdma (ops mtk_di
sp_rdma_component_ops)
[7.089429] mediatek-drm mediatek-drm.1.auto: bound 1400b000.color (ops mtk_d
isp_color_component_ops)
[7.098689] mediatek-drm mediatek-drm.1.auto: bound 14012000.rdma (ops mtk_di
sp_rdma_component_ops)
[7.107814] mediatek-drm mediatek-drm.1.auto: bound 14014000.dpi (ops mtk_dpi
_component_ops)
[7.116338] mediatek-drm mediatek-drm.1.auto: Not creating crtc 1 because com
ponent 9 is disabled or missing
[ 38.403957] Console: switching to colour frame buffer device 160x64
[ 48.516398] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[ 48.516422] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:cr
tc-0] commit wait timed out
[ 58.756384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[ 58.756399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:
32:HDMI-A-1] commit wait timed out
[ 68.996384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[ 68.996399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:33:p
lane-0] commit wait timed out
[ 68.996423] [drm:mtk_drm_crtc_atomic_begin] *ERROR* new event while there is
still a pending event
[ 69.106385] [ cut here ]
[ 69.106392] WARNING: CPU: 2 PID: 7 at drivers/gpu/drm/drm_atomic_helper.c:151
1 drm_atomic_helper_wait_for_vblanks.part.0+0x2a0/0x2a8
[ 69.106414] [CRTC:41:crtc-0] vblank wait timed out
We also encountered that warning on mt8173 device - Acer Chromebook R13. It
happen after resuming from suspend to ram.
We could not find a version that works and we were not able to find the fix of
the bug.
It seems like the irq isr is not called after resuming from suspend.
Please share if you have new findings regarding that bug.
Thanks,
Dafna
so i guess the breaking commit may be this:
$ git logone -S"drm_crtc_commit_wait" -- drivers/gpu/drm/
b99c2c95412c 2021-01-11 drm: Introduce a drm_crtc_commit_wait helper
in drivers/gpu/drm/drm_atomic{,_helper}.c
but i cannot confirm it because my git bisect does strange things (after
defining 5.13 as bad and the 2e4773915223 as good, second step is before the
good commit till the end, last steps are 5.11...). sorry, i'm still new to
bisect.
the fix is targeting to 5.12-rc2, is guess because CK Hu's tree is based on
this...but the fix was not included in 5.12-rc2 (only after 5.12.0...got it by
merging 5.12.14)
maybe you can help me?
regards Frank
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next-5.13
___
Linux-mediatek mailing list
linux-media...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
Hi, On 24.06.21 21:26, Ezequiel Garcia wrote: From: Paul Kocialkowski The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2) and an encoder (VEPU2). Signed-off-by: Paul Kocialkowski Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index b88172a59de7..3b9c5aa91fcc 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -28,6 +28,9 @@ properties: - items: - const: rockchip,rk3228-vpu - const: rockchip,rk3399-vpu + - items: + - const: rockchip,px30-vpu + - const: rockchip,rk3399-vpu This rk3399 compatible is already mentioned in the last 'items' list, should we add it again? Thanks, Dafna reg: maxItems: 1
[PATCH v6 RESEND 0/2] Add support for ANX7688
(resending patchset with Rb tags) ANX7688 is a typec port controller that also converts HDMI to DP. It is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone. On Acer Chromebook R13 (elm), the device is powered-up and controller by the Embedded Controller. Therefore its operation is transparent to the SoC. It is used in elm only as a display bridge driver. The bridge driver only reads some values using i2c and use them to implement the mode_fixup cb. On v5 we added the full dt-binding of the generic Analogix anx7688 device. The problem is that for elm, most of the fields are not needed since the anx7688 sits behind the EC. After a discussion on v5 (see [1]) we decided to go back to the original approach and send the dt binding as specific to the elm. So in this version we rename the device to cros_ec_anx7688 and use the compatible 'google,cros-ec-anx7688'. [1] https://patchwork.kernel.org/project/dri-devel/patch/20210305124351.15079-3-dafna.hirschf...@collabora.com/ Changes since v5: * treat the device as a specific combination of an ANX7688 behind the EC and call it 'cros-ec-anx7688' Changes since v4: In v4 of this set, the device was added as an 'mfd' device and an additional 'bridge' device for the HDMI-DP conversion, see [2]. [2] https://lkml.org/lkml/2020/3/18/64 Dafna Hirschfeld (1): dt-bindings: display: add google,cros-ec-anx7688.yaml Enric Balletbo i Serra (1): drm/bridge: Add ChromeOS EC ANX7688 bridge driver support .../bridge/google,cros-ec-anx7688.yaml| 82 drivers/gpu/drm/bridge/Kconfig| 12 ++ drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/cros-ec-anx7688.c | 191 ++ 4 files changed, 286 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml create mode 100644 drivers/gpu/drm/bridge/cros-ec-anx7688.c -- 2.17.1
[PATCH v6 RESEND 1/2] dt-bindings: display: add google, cros-ec-anx7688.yaml
ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip
which is connected to and operated by the ChromeOS Embedded Controller
(See google,cros-ec.yaml). It is accessed using I2C tunneling through
the EC and therefore its node should be a child of an EC I2C tunnel node
(See google,cros-ec-i2c-tunnel.yaml).
ChromOS EC ANX7688 is found on Acer Chromebook R13 (elm)
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Rob Herring
---
.../bridge/google,cros-ec-anx7688.yaml| 82 +++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
new file mode 100644
index ..9f7cc6b757cb
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/google,cros-ec-anx7688.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChromeOS EC ANX7688 HDMI to DP Converter through Type-C Port
+
+maintainers:
+ - Nicolas Boichat
+ - Enric Balletbo i Serra
+
+description: |
+ ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
+ DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip
+ which is connected to and operated by the ChromeOS Embedded Controller
+ (See google,cros-ec.yaml). It is accessed using I2C tunneling through
+ the EC and therefore its node should be a child of an EC I2C tunnel node
+ (See google,cros-ec-i2c-tunnel.yaml).
+
+properties:
+ compatible:
+const: google,cros-ec-anx7688
+
+ reg:
+maxItems: 1
+description: I2C address of the device.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for HDMI input.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: USB Type-c connector.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+i2c_tunnel_b: i2c-tunnel1 {
+compatible = "google,cros-ec-i2c-tunnel";
+google,remote-bus = <1>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+anx7688: anx7688@2c {
+compatible = "google,cros-ec-anx7688";
+reg = <0x2c>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+anx7688_in: endpoint {
+remote-endpoint = <&hdmi0_out>;
+};
+};
+port@1 {
+reg = <1>;
+anx7688_out: endpoint {
+remote-endpoint = <&typec_connector>;
+};
+};
+};
+};
+};
+
--
2.17.1
[PATCH v6 RESEND 2/2] drm/bridge: Add ChromeOS EC ANX7688 bridge driver support
From: Enric Balletbo i Serra
This driver adds support for the ChromeOS EC ANX7688 HDMI to DP converter
For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP bandwidth and lane count are reported by the bridge via
2 registers and, as far as we know, only chips that have a firmware
version greater than 0.85 support these two registers.
Signed-off-by: Nicolas Boichat
Signed-off-by: Hsin-Yi Wang
[The driver is OF only so should depends on CONFIG_OF]
Reported-by: kbuild test robot
Signed-off-by: Enric Balletbo i Serra
[convert to i2c driver, rename to cros_ec_anx7688, add err checks]
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kconfig | 12 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/cros-ec-anx7688.c | 191 +++
3 files changed, 204 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cros-ec-anx7688.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 630072f3ab59..7e9df06bae19 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -50,6 +50,18 @@ config DRM_CHRONTEL_CH7033
If in doubt, say "N".
+config DRM_CROS_EC_ANX7688
+ tristate "ChromeOS EC ANX7688 bridge"
+ depends on OF
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ChromeOS EC ANX7688 is an ultra-low power
+ 4K Ultra-HD (4096x2160p60) mobile HD transmitter
+ designed for ChromeOS devices. It converts HDMI
+ 2.0 to DisplayPort 1.3 Ultra-HD. It is connected
+ to the ChromeOS Embedded Controller.
+
config DRM_DISPLAY_CONNECTOR
tristate "Display connector support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b017ec182b8f..ae27ef374ef3 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
+obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
diff --git a/drivers/gpu/drm/bridge/cros-ec-anx7688.c
b/drivers/gpu/drm/bridge/cros-ec-anx7688.c
new file mode 100644
index ..0f6d907432e3
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cros-ec-anx7688.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * CrOS EC ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright 2020 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register addresses */
+#define ANX7688_VENDOR_ID_REG 0x00
+#define ANX7688_DEVICE_ID_REG 0x02
+
+#define ANX7688_FW_VERSION_REG 0x80
+
+#define ANX7688_DP_BANDWIDTH_REG 0x85
+#define ANX7688_DP_LANE_COUNT_REG 0x86
+
+#define ANX7688_VENDOR_ID 0x1f29
+#define ANX7688_DEVICE_ID 0x7688
+
+/* First supported firmware version (0.85) */
+#define ANX7688_MINIMUM_FW_VERSION 0x0085
+
+static const struct regmap_config cros_ec_anx7688_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+struct cros_ec_anx7688 {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct drm_bridge bridge;
+ bool filter;
+};
+
+static inline struct cros_ec_anx7688 *
+bridge_to_cros_ec_anx7688(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct cros_ec_anx7688, bridge);
+}
+
+static bool cros_ec_anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode
*mode,
+ struct drm_display_mode
*adjusted_mode)
+{
+ struct cros_ec_anx7688 *anx = bridge_to_cros_ec_anx7688(bridge);
+ int totalbw, requiredbw;
+ u8 dpbw, lanecount;
+ u8 regs[2];
+ int ret;
+
+ if (!anx->filter)
+ return true;
+
+ /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+ ret = regmap_bulk_read(anx->regmap, ANX7688_DP_BANDWIDTH_REG, regs, 2);
+ if (ret < 0) {
+ DRM_ERROR("Failed to read bandwidth/lane count\n");
+ return false;
+ }
+ dpbw = regs[0];
+ lanecount = regs[1];
+
+ /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+ if (dpbw > 0x19 || lanecount > 2) {
+ DRM_ERROR("Invalid bandwidth/lane count (%02x/%d)\n", dpbw,
+ lanecount);
+ return false;
+ }
+
+ /* Compute available bandwidth (kHz) */
+ totalbw = dpbw * lane
Re: [PATCH v6 0/2] Add support for ANX7688
Hi, pinging here, can one of the kernel bridge maintainers review this patchset? Thanks, Dafna On 09.04.21 18:19, Dafna Hirschfeld wrote: ANX7688 is a typec port controller that also converts HDMI to DP. ANX7688 is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone. On Acer Chromebook R13 (elm), the device is powered-up and controller by the Embedded Controller. Therefore its operation is transparent to the SoC. It is used in elm only as a display bridge driver. The bridge driver only reads some values using i2c and use them to implement the mode_fixup cb. On v5 we added the full dt-binding of the generic Analogix anx7688 device. The problem is that for elm, most of the fields are not needed since the anx7688 sits behind the EC. After a discussion on v5 (see [1]) we decided to go back to the original approach and send the dt binding as specific to the elm. So in this version we rename the device to cros_ec_anx7688 and use the compatible 'google,cros-ec-anx7688'. [1] https://patchwork.kernel.org/project/dri-devel/patch/20210305124351.15079-3-dafna.hirschf...@collabora.com/ Changes since v5: * treat the device as a specific combination of an ANX7688 behind the EC and call it 'cros-ec-anx7688' Changes since v4: In v4 of this set, the device was added as an 'mfd' device and an additional 'bridge' device for the HDMI-DP conversion, see [2]. [2] https://lkml.org/lkml/2020/3/18/64 Dafna Hirschfeld (1): dt-bindings: display: add google,cros-ec-anx7688.yaml Enric Balletbo i Serra (1): drm/bridge: Add ChromeOS EC ANX7688 bridge driver support .../bridge/google,cros-ec-anx7688.yaml| 82 drivers/gpu/drm/bridge/Kconfig| 12 ++ drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/cros-ec-anx7688.c | 191 ++ 4 files changed, 286 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml create mode 100644 drivers/gpu/drm/bridge/cros-ec-anx7688.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/2] drm/bridge: Add ChromeOS EC ANX7688 bridge driver support
From: Enric Balletbo i Serra
This driver adds support for the ChromeOS EC ANX7688 HDMI to DP converter
For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP bandwidth and lane count are reported by the bridge via
2 registers and, as far as we know, only chips that have a firmware
version greater than 0.85 support these two registers.
Signed-off-by: Nicolas Boichat
Signed-off-by: Hsin-Yi Wang
[The driver is OF only so should depends on CONFIG_OF]
Reported-by: kbuild test robot
Signed-off-by: Enric Balletbo i Serra
[convert to i2c driver, rename to cros_ec_anx7688, add err checks]
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kconfig | 12 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/cros-ec-anx7688.c | 191 +++
3 files changed, 204 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cros-ec-anx7688.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 998dcda44f70..9f991f0551ce 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -37,6 +37,18 @@ config DRM_CHRONTEL_CH7033
If in doubt, say "N".
+config DRM_CROS_EC_ANX7688
+ tristate "ChromeOS EC ANX7688 bridge"
+ depends on OF
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ChromeOS EC ANX7688 is an ultra-low power
+ 4K Ultra-HD (4096x2160p60) mobile HD transmitter
+ designed for ChromeOS devices. It converts HDMI
+ 2.0 to DisplayPort 1.3 Ultra-HD. It is connected
+ to the ChromeOS Embedded Controller.
+
config DRM_DISPLAY_CONNECTOR
tristate "Display connector support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 0fc37a8e38d0..a6261b89087c 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
+obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
diff --git a/drivers/gpu/drm/bridge/cros-ec-anx7688.c
b/drivers/gpu/drm/bridge/cros-ec-anx7688.c
new file mode 100644
index ..0f6d907432e3
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cros-ec-anx7688.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * CrOS EC ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright 2020 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register addresses */
+#define ANX7688_VENDOR_ID_REG 0x00
+#define ANX7688_DEVICE_ID_REG 0x02
+
+#define ANX7688_FW_VERSION_REG 0x80
+
+#define ANX7688_DP_BANDWIDTH_REG 0x85
+#define ANX7688_DP_LANE_COUNT_REG 0x86
+
+#define ANX7688_VENDOR_ID 0x1f29
+#define ANX7688_DEVICE_ID 0x7688
+
+/* First supported firmware version (0.85) */
+#define ANX7688_MINIMUM_FW_VERSION 0x0085
+
+static const struct regmap_config cros_ec_anx7688_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+struct cros_ec_anx7688 {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct drm_bridge bridge;
+ bool filter;
+};
+
+static inline struct cros_ec_anx7688 *
+bridge_to_cros_ec_anx7688(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct cros_ec_anx7688, bridge);
+}
+
+static bool cros_ec_anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode
*mode,
+ struct drm_display_mode
*adjusted_mode)
+{
+ struct cros_ec_anx7688 *anx = bridge_to_cros_ec_anx7688(bridge);
+ int totalbw, requiredbw;
+ u8 dpbw, lanecount;
+ u8 regs[2];
+ int ret;
+
+ if (!anx->filter)
+ return true;
+
+ /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+ ret = regmap_bulk_read(anx->regmap, ANX7688_DP_BANDWIDTH_REG, regs, 2);
+ if (ret < 0) {
+ DRM_ERROR("Failed to read bandwidth/lane count\n");
+ return false;
+ }
+ dpbw = regs[0];
+ lanecount = regs[1];
+
+ /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+ if (dpbw > 0x19 || lanecount > 2) {
+ DRM_ERROR("Invalid bandwidth/lane count (%02x/%d)\n", dpbw,
+ lanecount);
+ return false;
+ }
+
+ /* Compute available bandwidth (kHz) */
+ totalbw = dpbw * lane
[PATCH v6 0/2] Add support for ANX7688
ANX7688 is a typec port controller that also converts HDMI to DP. ANX7688 is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone. On Acer Chromebook R13 (elm), the device is powered-up and controller by the Embedded Controller. Therefore its operation is transparent to the SoC. It is used in elm only as a display bridge driver. The bridge driver only reads some values using i2c and use them to implement the mode_fixup cb. On v5 we added the full dt-binding of the generic Analogix anx7688 device. The problem is that for elm, most of the fields are not needed since the anx7688 sits behind the EC. After a discussion on v5 (see [1]) we decided to go back to the original approach and send the dt binding as specific to the elm. So in this version we rename the device to cros_ec_anx7688 and use the compatible 'google,cros-ec-anx7688'. [1] https://patchwork.kernel.org/project/dri-devel/patch/20210305124351.15079-3-dafna.hirschf...@collabora.com/ Changes since v5: * treat the device as a specific combination of an ANX7688 behind the EC and call it 'cros-ec-anx7688' Changes since v4: In v4 of this set, the device was added as an 'mfd' device and an additional 'bridge' device for the HDMI-DP conversion, see [2]. [2] https://lkml.org/lkml/2020/3/18/64 Dafna Hirschfeld (1): dt-bindings: display: add google,cros-ec-anx7688.yaml Enric Balletbo i Serra (1): drm/bridge: Add ChromeOS EC ANX7688 bridge driver support .../bridge/google,cros-ec-anx7688.yaml| 82 drivers/gpu/drm/bridge/Kconfig| 12 ++ drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/cros-ec-anx7688.c | 191 ++ 4 files changed, 286 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml create mode 100644 drivers/gpu/drm/bridge/cros-ec-anx7688.c -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/2] dt-bindings: display: add google,cros-ec-anx7688.yaml
ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip
which is connected to and operated by the ChromeOS Embedded Controller
(See google,cros-ec.yaml). It is accessed using I2C tunneling through
the EC and therefore its node should be a child of an EC I2C tunnel node
(See google,cros-ec-i2c-tunnel.yaml).
ChromOS EC ANX7688 is found on Acer Chromebook R13 (elm)
Signed-off-by: Dafna Hirschfeld
---
.../bridge/google,cros-ec-anx7688.yaml| 82 +++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
new file mode 100644
index ..9f7cc6b757cb
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/google,cros-ec-anx7688.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChromeOS EC ANX7688 HDMI to DP Converter through Type-C Port
+
+maintainers:
+ - Nicolas Boichat
+ - Enric Balletbo i Serra
+
+description: |
+ ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
+ DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip
+ which is connected to and operated by the ChromeOS Embedded Controller
+ (See google,cros-ec.yaml). It is accessed using I2C tunneling through
+ the EC and therefore its node should be a child of an EC I2C tunnel node
+ (See google,cros-ec-i2c-tunnel.yaml).
+
+properties:
+ compatible:
+const: google,cros-ec-anx7688
+
+ reg:
+maxItems: 1
+description: I2C address of the device.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for HDMI input.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: USB Type-c connector.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+i2c_tunnel_b: i2c-tunnel1 {
+compatible = "google,cros-ec-i2c-tunnel";
+google,remote-bus = <1>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+anx7688: anx7688@2c {
+compatible = "google,cros-ec-anx7688";
+reg = <0x2c>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+anx7688_in: endpoint {
+remote-endpoint = <&hdmi0_out>;
+};
+};
+port@1 {
+reg = <1>;
+anx7688_out: endpoint {
+remote-endpoint = <&typec_connector>;
+};
+};
+};
+};
+};
+
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: rename the function drm_bridge_hpd_notify to drm_bridge_hpd_cb
Hi
On 06.04.21 14:40, Laurent Pinchart wrote:
Hi Dafna,
Thank you for the patch.
On Tue, Mar 30, 2021 at 01:52:00PM +0200, Dafna Hirschfeld wrote:
drm_bridge_funcs has a function called 'hpd_notify'.
The function drm_bridge_hpd_notify does not call
'hpd_notify' but it calls 'hpd_cb'. This is rather
confusing. Rename the function to fix this confusion.
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c| 2 +-
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 ++--
drivers/gpu/drm/bridge/display-connector.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 8
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
drivers/gpu/drm/drm_bridge.c| 8
include/drm/drm_bridge.h| 8
8 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 76555ae64e9c..748f82910f4f 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -449,7 +449,7 @@ static void adv7511_hpd_work(struct work_struct *work)
cec_phys_addr_invalidate(adv7511->cec_adap);
drm_kms_helper_hotplug_event(adv7511->connector.dev);
} else {
- drm_bridge_hpd_notify(&adv7511->bridge, status);
+ drm_bridge_hpd_cb(&adv7511->bridge, status);
}
}
}
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d0c65610ebb5..682da288ff6d 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -794,7 +794,7 @@ static void cdns_mhdp_fw_cb(const struct firmware *fw, void
*context)
if (mhdp->connector.dev)
drm_kms_helper_hotplug_event(mhdp->bridge.dev);
else
- drm_bridge_hpd_notify(&mhdp->bridge,
cdns_mhdp_detect(mhdp));
+ drm_bridge_hpd_cb(&mhdp->bridge,
cdns_mhdp_detect(mhdp));
}
}
@@ -2314,7 +2314,7 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq, void *data)
else
drm_kms_helper_hotplug_event(mhdp->bridge.dev);
} else {
- drm_bridge_hpd_notify(&mhdp->bridge,
cdns_mhdp_detect(mhdp));
+ drm_bridge_hpd_cb(&mhdp->bridge,
cdns_mhdp_detect(mhdp));
}
}
diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm/bridge/display-connector.c
index 05eb759da6fc..8ccd69d7fe34 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -98,7 +98,7 @@ static irqreturn_t display_connector_hpd_irq(int irq, void
*arg)
struct display_connector *conn = arg;
struct drm_bridge *bridge = &conn->bridge;
- drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
+ drm_bridge_hpd_cb(bridge, display_connector_detect(bridge));
return IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index fee27952ec6d..58f61b5da605 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -175,10 +175,10 @@ static void lt9611uxc_hpd_work(struct work_struct *work)
connected = lt9611uxc->hdmi_connected;
mutex_unlock(<9611uxc->ocm_lock);
- drm_bridge_hpd_notify(<9611uxc->bridge,
- connected ?
- connector_status_connected :
- connector_status_disconnected);
+ drm_bridge_hpd_cb(<9611uxc->bridge,
+ connected ?
+ connector_status_connected :
+ connector_status_disconnected);
}
}
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..984ab5c4bc71 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3026,7 +3026,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (hdmi->bridge.dev) {
drm_helper_hpd_irq_event(hdmi->bridge.dev);
- drm_bridge_hpd_notify(&hdmi->bridge, status);
+ drm_bridge_hpd_cb(&hdmi->bridge, status);
}
}
diff --git a/drivers/gpu/drm/bridge/ti-t
Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml
Hi, On 05.03.21 18:24, Ondřej Jirman wrote: Hello Dafna, On Fri, Mar 05, 2021 at 04:14:03PM +0100, Dafna Hirschfeld wrote: Hi On 05.03.21 15:34, Laurent Pinchart wrote: Hi Dafna, Thank you for the patch. On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote: ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to DisplayPort 1.3 Ultra-HDi (4096x2160p60). The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer along with the DisplayPort Alternate Mode signaling over USB Type-C. Additionally, an on-chip microcontroller (OCM) is available to manage the signal switching, Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other functions as defined in the USB TypeC and USB Power Delivery specifications. ANX7688 is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone. Thanks for your work on the bindings. :) It would be great to find something acceptable for mainlining. A few comments based on my experience implementing the USB-PD part for PinePhone are bellow. +properties: + compatible: +const: analogix,anx7688 + + reg: +maxItems: 1 + + avdd33-supply: +description: 3.3V Analog core supply voltage. + + dvdd18-supply: +description: 1.8V Digital I/O supply voltage. + + avdd18-supply: +description: 1.8V Analog core power supply voltage. + + avdd10-supply: +description: 1.0V Analog core power supply voltage. + + dvdd10-supply: +description: 1.0V Digital core supply voltage. + That's lots of supplies. If there's a reasonable chance that some of them will always be driven by the same regulator (especially if the ANX7688 documentation requires that), then they could be grouped. For instance dvdd18-supply and avdd18-supply could be grouped into vdd18-supply. It would still allow us to extend the bindings in a backward compatible way later if a system uses different regulators. You have more information about the hardware than I do, so it's your call. On PinePhone, AVDD and DVDD for 1.0V are just separately fitlered outputs from the same regulator. So it would work there to just use vdd18 and vdd10. The same is true for reference design, so it's probably safe to assume this can be simplified. + hdmi5v-supply: +description: 5V power supply for the HDMI. + + hdmi_vt-supply: +description: Termination voltage for HDMI input. Maybe hdmi-vt-supply ? + + clocks: +description: The input clock specifier. +maxItems: 1 How about items: - description: The input clock specifier. + + clock-names: +items: + - const: xtal + + hpd-gpios: +description: | + In USB Type-C applications, DP_HPD has no use. In standard DisplayPort + applications, DP_HPD is used as DP hot-plug. +maxItems: 1 On PinePhone this is wired to a HDMI port on the SoC, and HPD is handled by the sun4i HDMI DRM driver. Seems like HPD will be handled by HDMI controller on many/all? other platforms too. Why have it here? Right, I didn't have the full picture when listing all the pins of the anx7688. I was not sure what should be listed. I will remove that. + enable-gpios: +description: Chip power down control. No internal pull-down or pull-up resistor. +maxItems: 1 + + reset-gpios: +description: Reset input signal. Active low. +maxItems: 1 + + vbus-det-gpios: +description: | + An input gpio for VBUS detection and high voltage detection, + external resistance divide VBUS voltage to 1/8. +maxItems: 1 Why have this in the bindings? It seems that this is handled internally by the ANX7688 via OCM firmware. And it's not really gpio either, it's an analog input with AD converter hooked to it internally. I will remove that. + interrupts: +description: | + The interrupt notifies 4 possible events - TCPC ALERT int, PD int, DP int, HDMI int. +maxItems: 1 + + cabledet-gpios: +description: An output gpio, indicates by the device that a cable is plugged. +maxItems: 1 + + vbus-ctrl-gpios: +description: + External VBUS power path. Enable VBUS source and disable VBUS sink or vice versa. +maxItems: 1 VBUS control seems to be already modelled by the usb-connector bindings. Why have this here? dito + vconn-en1-gpios: +description: Controls the VCONN switch on the CC1 pin. +maxItems: 1 + + vconn-en2-gpios: +description: Controls the VCONN switch on the CC2 pin. +maxItems: 1 VCONN is a voltage regulator that can be enabled either on CC1 or CC2 pin, or disabled completely. This control is *partially* performed in reference design directly by the OCM. OCM only decides which CC pin to switch the VCONN regulator to, and informs the SoC when the base VCONN regulator for the switches needs to be enabled. So vconn-en1/2 gpios are irrelevant to the driver, but the driver needs to control VCONN power su
Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml
Hi, On 05.03.21 16:19, Laurent Pinchart wrote: Hi Dafna, On Fri, Mar 05, 2021 at 04:14:03PM +0100, Dafna Hirschfeld wrote: On 05.03.21 15:34, Laurent Pinchart wrote: On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote: ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to DisplayPort 1.3 Ultra-HDi (4096x2160p60). The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer along with the DisplayPort Alternate Mode signaling over USB Type-C. Additionally, an on-chip microcontroller (OCM) is available to manage the signal switching, Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other functions as defined in the USB TypeC and USB Power Delivery specifications. ANX7688 is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone. Signed-off-by: Dafna Hirschfeld --- .../bindings/usb/analogix,anx7688.yaml| 177 ++ 1 file changed, 177 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/analogix,anx7688.yaml diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml new file mode 100644 index ..6c4dd6b4b28b --- /dev/null +++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml @@ -0,0 +1,177 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analogix ANX7688 Type-C Port Controller with HDMI to DP conversion + +maintainers: + - Nicolas Boichat + - Enric Balletbo i Serra + +description: | + ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to + DisplayPort 1.3 Ultra-HDi (4096x2160p60). + The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer along with + the DisplayPort Alternate Mode signaling over USB Type-C. Additionally, + an on-chip microcontroller (OCM) is available to manage the signal switching, + Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor + Defined Message (VDM) protocol support and other functions as defined in the + USB TypeC and USB Power Delivery specifications. + + Extra blank line ? +properties: + compatible: +const: analogix,anx7688 + + reg: +maxItems: 1 + + avdd33-supply: +description: 3.3V Analog core supply voltage. + + dvdd18-supply: +description: 1.8V Digital I/O supply voltage. + + avdd18-supply: +description: 1.8V Analog core power supply voltage. + + avdd10-supply: +description: 1.0V Analog core power supply voltage. + + dvdd10-supply: +description: 1.0V Digital core supply voltage. + That's lots of supplies. If there's a reasonable chance that some of them will always be driven by the same regulator (especially if the ANX7688 documentation requires that), then they could be grouped. For instance dvdd18-supply and avdd18-supply could be grouped into vdd18-supply. It would still allow us to extend the bindings in a backward compatible way later if a system uses different regulators. You have more information about the hardware than I do, so it's your call. Can you explain what do you mean by 'grouped' ? Do you mean that instead of having two properties dvdd18-supply and avdd18-supply I have only one property vdd18-supply? + hdmi5v-supply: +description: 5V power supply for the HDMI. + + hdmi_vt-supply: +description: Termination voltage for HDMI input. Maybe hdmi-vt-supply ? + + clocks: +description: The input clock specifier. +maxItems: 1 How about items: - description: The input clock specifier. + + clock-names: +items: + - const: xtal + + hpd-gpios: +description: | + In USB Type-C applications, DP_HPD has no use. In standard DisplayPort + applications, DP_HPD is used as DP hot-plug. +maxItems: 1 + + enable-gpios: +description: Chip power down control. No internal pull-down or pull-up resistor. +maxItems: 1 + + reset-gpios: +description: Reset input signal. Active low. +maxItems: 1 + + vbus-det-gpios: +description: | + An input gpio for VBUS detection and high voltage detection, + external resistance divide VBUS voltage to 1/8. +maxItems: 1 + + interrupts: +description: | + The interrupt notifies 4 possible events - TCPC ALERT int, PD int, DP int, HDMI int. +maxItems: 1 + + cabledet-gpios: +description: An output gpio, indicates by the device that a cable is plugged. +maxItems: 1 + + vbus-ctrl-gpios: +description: + External VBUS power path. Enable VBUS source and disable VBUS sink or vice versa. +maxItems: 1 + + vconn-en1-gpios: +description: Controls the VCONN switch on the CC1 pin. +maxItems: 1 + + vconn-en2-gpios: +description: Controls the VC
[PATCH] drm: bridge: rename the function drm_bridge_hpd_notify to drm_bridge_hpd_cb
drm_bridge_funcs has a function called 'hpd_notify'.
The function drm_bridge_hpd_notify does not call
'hpd_notify' but it calls 'hpd_cb'. This is rather
confusing. Rename the function to fix this confusion.
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c| 2 +-
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 ++--
drivers/gpu/drm/bridge/display-connector.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 8
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
drivers/gpu/drm/drm_bridge.c| 8
include/drm/drm_bridge.h| 8
8 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 76555ae64e9c..748f82910f4f 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -449,7 +449,7 @@ static void adv7511_hpd_work(struct work_struct *work)
cec_phys_addr_invalidate(adv7511->cec_adap);
drm_kms_helper_hotplug_event(adv7511->connector.dev);
} else {
- drm_bridge_hpd_notify(&adv7511->bridge, status);
+ drm_bridge_hpd_cb(&adv7511->bridge, status);
}
}
}
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d0c65610ebb5..682da288ff6d 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -794,7 +794,7 @@ static void cdns_mhdp_fw_cb(const struct firmware *fw, void
*context)
if (mhdp->connector.dev)
drm_kms_helper_hotplug_event(mhdp->bridge.dev);
else
- drm_bridge_hpd_notify(&mhdp->bridge,
cdns_mhdp_detect(mhdp));
+ drm_bridge_hpd_cb(&mhdp->bridge,
cdns_mhdp_detect(mhdp));
}
}
@@ -2314,7 +2314,7 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq, void
*data)
else
drm_kms_helper_hotplug_event(mhdp->bridge.dev);
} else {
- drm_bridge_hpd_notify(&mhdp->bridge,
cdns_mhdp_detect(mhdp));
+ drm_bridge_hpd_cb(&mhdp->bridge,
cdns_mhdp_detect(mhdp));
}
}
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index 05eb759da6fc..8ccd69d7fe34 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -98,7 +98,7 @@ static irqreturn_t display_connector_hpd_irq(int irq, void
*arg)
struct display_connector *conn = arg;
struct drm_bridge *bridge = &conn->bridge;
- drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
+ drm_bridge_hpd_cb(bridge, display_connector_detect(bridge));
return IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index fee27952ec6d..58f61b5da605 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -175,10 +175,10 @@ static void lt9611uxc_hpd_work(struct work_struct *work)
connected = lt9611uxc->hdmi_connected;
mutex_unlock(<9611uxc->ocm_lock);
- drm_bridge_hpd_notify(<9611uxc->bridge,
- connected ?
- connector_status_connected :
- connector_status_disconnected);
+ drm_bridge_hpd_cb(<9611uxc->bridge,
+ connected ?
+ connector_status_connected :
+ connector_status_disconnected);
}
}
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..984ab5c4bc71 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3026,7 +3026,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (hdmi->bridge.dev) {
drm_helper_hpd_irq_event(hdmi->bridge.dev);
- drm_bridge_hpd_notify(&hdmi->bridge, status);
+ drm_bridge_hpd_cb(&hdmi->bridge, status);
}
}
diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c
b/drivers/gpu/drm/bridge/ti-tpd12s015.c
index e0e015243a60..2f079b6f51bc 100644
--- a/drivers/gpu/drm/bridge/ti-tpd12s015.c
+
[PATCH v3 2/2] drm/mediatek: Don't support hdmi connector creation
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment.
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() to report HPD. This provides the
necessary API to support disabling connector creation.
In addition, the field 'conn' is removed from the mtk_hdmi struct since
mtk_hdmi don't create a connector. It is replaced with a pointer
'curr_conn' that points to the current connector which can be access
through the global state.
This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c:
commit ec971aaa6775 ("drm: bridge: dw-hdmi: Make connector creation optional")
But with the difference that in mtk-hdmi only the option of not creating
a connector is supported.
Fixes: f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 151 +++-
1 file changed, 56 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index f2c810b767ef..7fb358167f8d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -153,7 +153,7 @@ struct mtk_hdmi_conf {
struct mtk_hdmi {
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
- struct drm_connector conn;
+ struct drm_connector *curr_conn;/* current connector (only valid when
'enabled') */
struct device *dev;
const struct mtk_hdmi_conf *conf;
struct phy *phy;
@@ -186,11 +186,6 @@ static inline struct mtk_hdmi *hdmi_ctx_from_bridge(struct
drm_bridge *b)
return container_of(b, struct mtk_hdmi, bridge);
}
-static inline struct mtk_hdmi *hdmi_ctx_from_conn(struct drm_connector *c)
-{
- return container_of(c, struct mtk_hdmi, conn);
-}
-
static u32 mtk_hdmi_read(struct mtk_hdmi *hdmi, u32 offset)
{
return readl(hdmi->regs + offset);
@@ -974,7 +969,7 @@ static int mtk_hdmi_setup_avi_infoframe(struct mtk_hdmi
*hdmi,
ssize_t err;
err = drm_hdmi_avi_infoframe_from_display_mode(&frame,
- &hdmi->conn, mode);
+ hdmi->curr_conn, mode);
if (err < 0) {
dev_err(hdmi->dev,
"Failed to get AVI infoframe from mode: %zd\n", err);
@@ -1054,7 +1049,7 @@ static int
mtk_hdmi_setup_vendor_specific_infoframe(struct mtk_hdmi *hdmi,
ssize_t err;
err = drm_hdmi_vendor_infoframe_from_display_mode(&frame,
- &hdmi->conn, mode);
+ hdmi->curr_conn,
mode);
if (err) {
dev_err(hdmi->dev,
"Failed to get vendor infoframe from mode: %zd\n", err);
@@ -1201,48 +1196,16 @@ mtk_hdmi_update_plugged_status(struct mtk_hdmi *hdmi)
connector_status_connected : connector_status_disconnected;
}
-static enum drm_connector_status hdmi_conn_detect(struct drm_connector *conn,
- bool force)
+static enum drm_connector_status mtk_hdmi_detect(struct mtk_hdmi *hdmi)
{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
return mtk_hdmi_update_plugged_status(hdmi);
}
-static void hdmi_conn_destroy(struct drm_connector *conn)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
-
- mtk_cec_set_hpd_event(hdmi->cec_dev, NULL, NULL);
-
- drm_connector_cleanup(conn);
-}
-
-static int mtk_hdmi_conn_get_modes(struct drm_connector *conn)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
- struct edid *edid;
- int ret;
-
- if (!hdmi->ddc_adpt)
- return -ENODEV;
-
- edid = drm_get_edid(conn, hdmi->ddc_adpt);
- if (!edid)
- return -ENODEV;
-
- hdmi->dvi_mode = !drm_detect_monitor_audio(edid);
-
- drm_connector_update_edid_property(conn, edid);
-
- ret = drm_add_edid_modes(conn, edid);
- kfree(edid);
- return ret;
-}
-
-static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
- struct drm_display_mode *mode)
+static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
+
[PATCH v3 1/2] drm/mediatek: Switch the hdmi bridge ops to the atomic versions
The bridge operation '.enable' and the audio cb '.get_eld'
access hdmi->conn. In the future we will want to support
the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
not have direct access to the connector.
The atomic version '.atomic_enable' allows accessing the
current connector from the state.
This patch switches the bridge to the atomic version to
prepare access to the connector in later patches.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ee55f9e2954..f2c810b767ef 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1357,7 +1357,8 @@ static bool mtk_hdmi_bridge_mode_fixup(struct drm_bridge
*bridge,
return true;
}
-static void mtk_hdmi_bridge_disable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1371,7 +1372,8 @@ static void mtk_hdmi_bridge_disable(struct drm_bridge
*bridge)
hdmi->enabled = false;
}
-static void mtk_hdmi_bridge_post_disable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1406,7 +1408,8 @@ static void mtk_hdmi_bridge_mode_set(struct drm_bridge
*bridge,
drm_mode_copy(&hdmi->mode, adjusted_mode);
}
-static void mtk_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1426,7 +1429,8 @@ static void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi,
mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
}
-static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1440,13 +1444,16 @@ static void mtk_hdmi_bridge_enable(struct drm_bridge
*bridge)
}
static const struct drm_bridge_funcs mtk_hdmi_bridge_funcs = {
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
.attach = mtk_hdmi_bridge_attach,
.mode_fixup = mtk_hdmi_bridge_mode_fixup,
- .disable = mtk_hdmi_bridge_disable,
- .post_disable = mtk_hdmi_bridge_post_disable,
+ .atomic_disable = mtk_hdmi_bridge_atomic_disable,
+ .atomic_post_disable = mtk_hdmi_bridge_atomic_post_disable,
.mode_set = mtk_hdmi_bridge_mode_set,
- .pre_enable = mtk_hdmi_bridge_pre_enable,
- .enable = mtk_hdmi_bridge_enable,
+ .atomic_pre_enable = mtk_hdmi_bridge_atomic_pre_enable,
+ .atomic_enable = mtk_hdmi_bridge_atomic_enable,
};
static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] drm/mediatek: Don't support hdmi connector creation
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
These three patches fix that by adding support for
DRM_BRIDGE_ATTACH_NO_CONNECTOR
in mtk_hdmi bridge attachment.
changes since v2:
1. squash patch 3 with patch 2 to not break bisection
2. remove the funtion mtk_hdmi_get_edid and inline its code in
mtk_hdmi_bridge_get_edid
3. small aligment
changes since v1:
1. split the first patch - now the first patch only moves the bridge ops to the
atomic API
while the replacement of the field 'conn' with the field '*curr_conn' is done
in a new third patch.
2. in the function 'get_eld' use the current conn only if 'enabled = true'.
Dafna Hirschfeld (2):
drm/mediatek: Switch the hdmi bridge ops to the atomic versions
drm/mediatek: Don't support hdmi connector creation
drivers/gpu/drm/mediatek/mtk_hdmi.c | 174
1 file changed, 71 insertions(+), 103 deletions(-)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/mediatek: Don't support hdmi connector creation
Hi,
On 30.03.21 02:08, Laurent Pinchart wrote:
Hi Dafna,
Thank you for the patch.
On Mon, Mar 29, 2021 at 05:36:31PM +0200, Dafna Hirschfeld wrote:
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment.
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() to report HPD. This provides the
necessary API to support disabling connector creation.
This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c:
commit ec971aaa6775 ("drm: bridge: dw-hdmi: Make connector creation optional")
But with the difference that in mtk-hdmi only the option of not creating
a connector is supported.
Fixes: f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 129 ++--
1 file changed, 44 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index f2c810b767ef..1eeb211b1536 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -186,11 +186,6 @@ static inline struct mtk_hdmi *hdmi_ctx_from_bridge(struct
drm_bridge *b)
return container_of(b, struct mtk_hdmi, bridge);
}
-static inline struct mtk_hdmi *hdmi_ctx_from_conn(struct drm_connector *c)
-{
- return container_of(c, struct mtk_hdmi, conn);
-}
-
static u32 mtk_hdmi_read(struct mtk_hdmi *hdmi, u32 offset)
{
return readl(hdmi->regs + offset);
@@ -1201,48 +1196,30 @@ mtk_hdmi_update_plugged_status(struct mtk_hdmi *hdmi)
connector_status_connected : connector_status_disconnected;
}
-static enum drm_connector_status hdmi_conn_detect(struct drm_connector *conn,
- bool force)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
- return mtk_hdmi_update_plugged_status(hdmi);
-}
-
-static void hdmi_conn_destroy(struct drm_connector *conn)
+static struct edid *mtk_hdmi_get_edid(struct mtk_hdmi *hdmi,
+ struct drm_connector *connector)
{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
-
- mtk_cec_set_hpd_event(hdmi->cec_dev, NULL, NULL);
-
- drm_connector_cleanup(conn);
-}
-
-static int mtk_hdmi_conn_get_modes(struct drm_connector *conn)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
struct edid *edid;
- int ret;
if (!hdmi->ddc_adpt)
- return -ENODEV;
-
- edid = drm_get_edid(conn, hdmi->ddc_adpt);
+ return NULL;
+ edid = drm_get_edid(connector, hdmi->ddc_adpt);
if (!edid)
- return -ENODEV;
-
+ return NULL;
hdmi->dvi_mode = !drm_detect_monitor_audio(edid);
+ return edid;
+}
- drm_connector_update_edid_property(conn, edid);
-
- ret = drm_add_edid_modes(conn, edid);
- kfree(edid);
- return ret;
+static enum drm_connector_status mtk_hdmi_detect(struct mtk_hdmi *hdmi)
+{
+ return mtk_hdmi_update_plugged_status(hdmi);
}
-static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
- struct drm_display_mode *mode)
+static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
+ struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
struct drm_bridge *next_bridge;
dev_dbg(hdmi->dev, "xres=%d, yres=%d, refresh=%d, intl=%d clock=%d\n",
@@ -1267,74 +1244,50 @@ static int mtk_hdmi_conn_mode_valid(struct
drm_connector *conn,
return drm_mode_validate_size(mode, 0x1fff, 0x1fff);
}
-static struct drm_encoder *mtk_hdmi_conn_best_enc(struct drm_connector *conn)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
-
- return hdmi->bridge.encoder;
-}
-
-static const struct drm_connector_funcs mtk_hdmi_connector_funcs = {
- .detect = hdmi_conn_detect,
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = hdmi_conn_destroy,
- .reset = drm_atomic_helper_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static const struct drm_connector_helper_funcs
- mtk_hdmi_connector_helper_funcs = {
- .get_modes = mtk_hdmi_conn_get_modes,
- .mode_valid = mtk_hdmi_conn_mode_valid,
-
[PATCH v2 2/3] drm/mediatek: Don't support hdmi connector creation
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment.
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() to report HPD. This provides the
necessary API to support disabling connector creation.
This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c:
commit ec971aaa6775 ("drm: bridge: dw-hdmi: Make connector creation optional")
But with the difference that in mtk-hdmi only the option of not creating
a connector is supported.
Fixes: f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 129 ++--
1 file changed, 44 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index f2c810b767ef..1eeb211b1536 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -186,11 +186,6 @@ static inline struct mtk_hdmi *hdmi_ctx_from_bridge(struct
drm_bridge *b)
return container_of(b, struct mtk_hdmi, bridge);
}
-static inline struct mtk_hdmi *hdmi_ctx_from_conn(struct drm_connector *c)
-{
- return container_of(c, struct mtk_hdmi, conn);
-}
-
static u32 mtk_hdmi_read(struct mtk_hdmi *hdmi, u32 offset)
{
return readl(hdmi->regs + offset);
@@ -1201,48 +1196,30 @@ mtk_hdmi_update_plugged_status(struct mtk_hdmi *hdmi)
connector_status_connected : connector_status_disconnected;
}
-static enum drm_connector_status hdmi_conn_detect(struct drm_connector *conn,
- bool force)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
- return mtk_hdmi_update_plugged_status(hdmi);
-}
-
-static void hdmi_conn_destroy(struct drm_connector *conn)
+static struct edid *mtk_hdmi_get_edid(struct mtk_hdmi *hdmi,
+ struct drm_connector *connector)
{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
-
- mtk_cec_set_hpd_event(hdmi->cec_dev, NULL, NULL);
-
- drm_connector_cleanup(conn);
-}
-
-static int mtk_hdmi_conn_get_modes(struct drm_connector *conn)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
struct edid *edid;
- int ret;
if (!hdmi->ddc_adpt)
- return -ENODEV;
-
- edid = drm_get_edid(conn, hdmi->ddc_adpt);
+ return NULL;
+ edid = drm_get_edid(connector, hdmi->ddc_adpt);
if (!edid)
- return -ENODEV;
-
+ return NULL;
hdmi->dvi_mode = !drm_detect_monitor_audio(edid);
+ return edid;
+}
- drm_connector_update_edid_property(conn, edid);
-
- ret = drm_add_edid_modes(conn, edid);
- kfree(edid);
- return ret;
+static enum drm_connector_status mtk_hdmi_detect(struct mtk_hdmi *hdmi)
+{
+ return mtk_hdmi_update_plugged_status(hdmi);
}
-static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
- struct drm_display_mode *mode)
+static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
+ struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
struct drm_bridge *next_bridge;
dev_dbg(hdmi->dev, "xres=%d, yres=%d, refresh=%d, intl=%d clock=%d\n",
@@ -1267,74 +1244,50 @@ static int mtk_hdmi_conn_mode_valid(struct
drm_connector *conn,
return drm_mode_validate_size(mode, 0x1fff, 0x1fff);
}
-static struct drm_encoder *mtk_hdmi_conn_best_enc(struct drm_connector *conn)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
-
- return hdmi->bridge.encoder;
-}
-
-static const struct drm_connector_funcs mtk_hdmi_connector_funcs = {
- .detect = hdmi_conn_detect,
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = hdmi_conn_destroy,
- .reset = drm_atomic_helper_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static const struct drm_connector_helper_funcs
- mtk_hdmi_connector_helper_funcs = {
- .get_modes = mtk_hdmi_conn_get_modes,
- .mode_valid = mtk_hdmi_conn_mode_valid,
- .best_encoder = mtk_hdmi_conn_best_enc,
-};
-
static void mtk_hdmi_hpd_event(bool hpd, struct device *dev)
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
-
[PATCH v2 0/3] drm/mediatek: Don't support hdmi connector creation
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
These three patches fix that by adding support for
DRM_BRIDGE_ATTACH_NO_CONNECTOR
in mtk_hdmi bridge attachment.
changes since v1:
1. split the first patch - now the first patch only moves the bridge ops to the
atomic API
while the replacement of the field 'conn' with the field '*curr_conn' is done
in a new third patch.
2. in the function 'get_eld' use the current conn only if 'enabled = true'.
Dafna Hirschfeld (3):
drm/mediatek: Switch the hdmi bridge ops to the atomic versions
drm/mediatek: Don't support hdmi connector creation
drm/mediatek: in struct mtk_hdmi, replace conn field with curr_conn
ptr
drivers/gpu/drm/mediatek/mtk_hdmi.c | 171
1 file changed, 73 insertions(+), 98 deletions(-)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/mediatek: in struct mtk_hdmi, replace conn field with curr_conn ptr
The mtk_hdmi does not support creating a bridge with a connector.
Therefore the field 'conn' should be removed from the mtk_hdmi struct.
It is replaced with a pointer curr_conn that points to the current
connector which can be access through the global state.
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 1eeb211b1536..0d95d2cfe3de 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -153,7 +153,7 @@ struct mtk_hdmi_conf {
struct mtk_hdmi {
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
- struct drm_connector conn;
+ struct drm_connector *curr_conn;/* current connector (only valid when
'enabled') */
struct device *dev;
const struct mtk_hdmi_conf *conf;
struct phy *phy;
@@ -969,7 +969,7 @@ static int mtk_hdmi_setup_avi_infoframe(struct mtk_hdmi
*hdmi,
ssize_t err;
err = drm_hdmi_avi_infoframe_from_display_mode(&frame,
- &hdmi->conn, mode);
+ hdmi->curr_conn, mode);
if (err < 0) {
dev_err(hdmi->dev,
"Failed to get AVI infoframe from mode: %zd\n", err);
@@ -1049,7 +1049,7 @@ static int
mtk_hdmi_setup_vendor_specific_infoframe(struct mtk_hdmi *hdmi,
ssize_t err;
err = drm_hdmi_vendor_infoframe_from_display_mode(&frame,
- &hdmi->conn, mode);
+ hdmi->curr_conn,
mode);
if (err) {
dev_err(hdmi->dev,
"Failed to get vendor infoframe from mode: %zd\n", err);
@@ -1322,6 +1322,8 @@ static void mtk_hdmi_bridge_atomic_disable(struct
drm_bridge *bridge,
clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
+ hdmi->curr_conn = NULL;
+
hdmi->enabled = false;
}
@@ -1385,8 +1387,13 @@ static void mtk_hdmi_send_infoframe(struct mtk_hdmi
*hdmi,
static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
struct drm_bridge_state *old_state)
{
+ struct drm_atomic_state *state = old_state->base.state;
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
+ /* Retrieve the connector through the atomic state. */
+ hdmi->curr_conn = drm_atomic_get_new_connector_for_encoder(state,
+
bridge->encoder);
+
mtk_hdmi_output_set_display_mode(hdmi, &hdmi->mode);
clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
@@ -1625,8 +1632,10 @@ static int mtk_hdmi_audio_get_eld(struct device *dev,
void *data, uint8_t *buf,
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
- memcpy(buf, hdmi->conn.eld, min(sizeof(hdmi->conn.eld), len));
-
+ if (hdmi->enabled)
+ memcpy(buf, hdmi->curr_conn->eld,
min(sizeof(hdmi->curr_conn->eld), len));
+ else
+ memset(buf, 0, len);
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/mediatek: Switch the hdmi bridge ops to the atomic versions
The bridge operation '.enable' and the audio cb '.get_eld'
access hdmi->conn. In the future we will want to support
the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
not have direct access to the connector.
The atomic version '.atomic_enable' allows accessing the
current connector from the state.
This patch switches the bridge to the atomic version to
prepare access to the connector in later patches.
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ee55f9e2954..f2c810b767ef 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1357,7 +1357,8 @@ static bool mtk_hdmi_bridge_mode_fixup(struct drm_bridge
*bridge,
return true;
}
-static void mtk_hdmi_bridge_disable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1371,7 +1372,8 @@ static void mtk_hdmi_bridge_disable(struct drm_bridge
*bridge)
hdmi->enabled = false;
}
-static void mtk_hdmi_bridge_post_disable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1406,7 +1408,8 @@ static void mtk_hdmi_bridge_mode_set(struct drm_bridge
*bridge,
drm_mode_copy(&hdmi->mode, adjusted_mode);
}
-static void mtk_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1426,7 +1429,8 @@ static void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi,
mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
}
-static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1440,13 +1444,16 @@ static void mtk_hdmi_bridge_enable(struct drm_bridge
*bridge)
}
static const struct drm_bridge_funcs mtk_hdmi_bridge_funcs = {
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
.attach = mtk_hdmi_bridge_attach,
.mode_fixup = mtk_hdmi_bridge_mode_fixup,
- .disable = mtk_hdmi_bridge_disable,
- .post_disable = mtk_hdmi_bridge_post_disable,
+ .atomic_disable = mtk_hdmi_bridge_atomic_disable,
+ .atomic_post_disable = mtk_hdmi_bridge_atomic_post_disable,
.mode_set = mtk_hdmi_bridge_mode_set,
- .pre_enable = mtk_hdmi_bridge_pre_enable,
- .enable = mtk_hdmi_bridge_enable,
+ .atomic_pre_enable = mtk_hdmi_bridge_atomic_pre_enable,
+ .atomic_enable = mtk_hdmi_bridge_atomic_enable,
};
static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/bridge: fix typo in Kconfig
fix 's/controller/controllers/' in the sentence: Most display controller handle display connectors... Signed-off-by: Dafna Hirschfeld --- drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3..cc55915dd0eb 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -42,7 +42,7 @@ config DRM_DISPLAY_CONNECTOR depends on OF help Driver for display connectors with support for DDC and hot-plug - detection. Most display controller handle display connectors + detection. Most display controllers handle display connectors internally and don't need this driver, but the DRM subsystem is moving towards separating connector handling from display controllers on ARM-based platforms. Saying Y here when this driver is not needed -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Fix 3 typos in the inline doc
Fix the following typos:
1. When mentioning a list of functions, the function
drm_atomic_helper_disable_plane is mentioned twice.
2. drop the word 'afterwards':
s/afterwards after that/after that/'
3. drop extra 'the':
s/but do not the support the full/but do not support the full/
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/drm_atomic_helper.c | 15 +++
include/drm/drm_drv.h | 2 +-
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 560aaecba31b..eb527b63ceaa 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -61,9 +61,9 @@
*
* This library also provides implementations for all the legacy driver
* interfaces on top of the atomic interface. See
drm_atomic_helper_set_config(),
- * drm_atomic_helper_disable_plane(), drm_atomic_helper_disable_plane() and the
- * various functions to implement set_property callbacks. New drivers must not
- * implement these functions themselves but must use the provided helpers.
+ * drm_atomic_helper_disable_plane(), and the various functions to implement
+ * set_property callbacks. New drivers must not implement these functions
+ * themselves but must use the provided helpers.
*
* The atomic helper uses the same function table structures as all other
* modesetting helpers. See the documentation for &struct
drm_crtc_helper_funcs,
@@ -592,11 +592,10 @@ mode_valid(struct drm_atomic_state *state)
*
* Drivers which set &drm_crtc_state.mode_changed (e.g. in their
* &drm_plane_helper_funcs.atomic_check hooks if a plane update can't be done
- * without a full modeset) _must_ call this function afterwards after that
- * change. It is permitted to call this function multiple times for the same
- * update, e.g. when the &drm_crtc_helper_funcs.atomic_check functions depend
- * upon the adjusted dotclock for fifo space allocation and watermark
- * computation.
+ * without a full modeset) _must_ call this function after that change. It is
+ * permitted to call this function multiple times for the same update, e.g.
+ * when the &drm_crtc_helper_funcs.atomic_check functions depend upon the
+ * adjusted dotclock for fifo space allocation and watermark computation.
*
* RETURNS:
* Zero for success or -errno
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 827838e0a97e..b439ae1921b8 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -74,7 +74,7 @@ enum drm_driver_feature {
* @DRIVER_ATOMIC:
*
* Driver supports the full atomic modesetting userspace API. Drivers
-* which only use atomic internally, but do not the support the full
+* which only use atomic internally, but do not support the full
* userspace API (e.g. not all properties converted to atomic, or
* multi-plane updates are not guaranteed to be tear-free) should not
* set this flag.
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Add linux-mediatek ML for drm Mediatek drivers
Add the linux-mediatek mailing list to drm Mediatek drivers Signed-off-by: Dafna Hirschfeld --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9e876927c60d..8260bc5afe66 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5963,6 +5963,7 @@ DRM DRIVERS FOR MEDIATEK M: Chun-Kuang Hu M: Philipp Zabel L: dri-devel@lists.freedesktop.org +L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/display/mediatek/ F: drivers/gpu/drm/mediatek/ -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/mediatek: Switch the hdmi bridge ops to the atomic versions
Hi,
On 25.03.21 11:43, Enric Balletbo i Serra wrote:
Hi Dafna,
Thank you for your patch. It'd be nice if you can cc the linux-mediatek ML for
next version, so Mediatek people is more aware of this change. IMHO cc'ing the
lkml is also a good practice.
ok, I added all the mails from get_maintainer.pl. linux-mediatek was not there,
I can add it.
On 24/3/21 20:12, Dafna Hirschfeld wrote:
The bridge operation '.enable' and the audio cb '.get_eld'
access hdmi->conn. In the future we will want to support
the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
not have direct access to the connector.
The atomic version '.atomic_enable' allows accessing the
current connector from the state.
This patch switches the bridge to the atomic version and
saves the current connector in a new field 'curr_conn'.
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 41 -
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ee55f9e2954..9f415c508b33 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -154,6 +154,7 @@ struct mtk_hdmi {
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector conn;
+ struct drm_connector *curr_conn;
Adding a new drm_connector (curr_conn) is something that surprised me at the
beginning, then I saw that in the second patch you remove the first
drm_connector (conn). I didn't test it yet, but did you test this patch alone?
without the second one, maybe I'm missing something but looks to me that this
patch alone breaks more functionalities of the driver? (and I know that the
driver is broken right now)
Hi, I didn't test it alone, but indeed this patch was wirrten with the intention
that 'conn' will be removed next patch. But I don't think that patch should
break
functionality.
Is really needed to create a new drm_connector to switch to the atomic versions?
No, indeed this is the wrong patch to add curr_conn, I should add curr_conn to
the
second patch or maybe to a seperate last patch so not to overload the patch.
Thanks,
Dafna
struct device *dev;
const struct mtk_hdmi_conf *conf;
struct phy *phy;
@@ -974,7 +975,7 @@ static int mtk_hdmi_setup_avi_infoframe(struct mtk_hdmi
*hdmi,
ssize_t err;
err = drm_hdmi_avi_infoframe_from_display_mode(&frame,
- &hdmi->conn, mode);
+ hdmi->curr_conn, mode);
if (err < 0) {
dev_err(hdmi->dev,
"Failed to get AVI infoframe from mode: %zd\n", err);
@@ -1054,7 +1055,7 @@ static int
mtk_hdmi_setup_vendor_specific_infoframe(struct mtk_hdmi *hdmi,
ssize_t err;
err = drm_hdmi_vendor_infoframe_from_display_mode(&frame,
- &hdmi->conn, mode);
+ hdmi->curr_conn,
mode);
if (err) {
dev_err(hdmi->dev,
"Failed to get vendor infoframe from mode: %zd\n", err);
@@ -1357,7 +1358,8 @@ static bool mtk_hdmi_bridge_mode_fixup(struct drm_bridge
*bridge,
return true;
}
-static void mtk_hdmi_bridge_disable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1368,10 +1370,13 @@ static void mtk_hdmi_bridge_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
+ hdmi->curr_conn = NULL;
+
hdmi->enabled = false;
}
-static void mtk_hdmi_bridge_post_disable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1406,7 +1411,8 @@ static void mtk_hdmi_bridge_mode_set(struct drm_bridge *bridge,
drm_mode_copy(&hdmi->mode, adjusted_mode);
}
-static void mtk_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1426,10 +1432,16 @@ static void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi,
mtk_hdmi_setup_vendor_specific_inf
[PATCH 1/2] drm/mediatek: Switch the hdmi bridge ops to the atomic versions
The bridge operation '.enable' and the audio cb '.get_eld'
access hdmi->conn. In the future we will want to support
the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
not have direct access to the connector.
The atomic version '.atomic_enable' allows accessing the
current connector from the state.
This patch switches the bridge to the atomic version and
saves the current connector in a new field 'curr_conn'.
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 41 -
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ee55f9e2954..9f415c508b33 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -154,6 +154,7 @@ struct mtk_hdmi {
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector conn;
+ struct drm_connector *curr_conn;
struct device *dev;
const struct mtk_hdmi_conf *conf;
struct phy *phy;
@@ -974,7 +975,7 @@ static int mtk_hdmi_setup_avi_infoframe(struct mtk_hdmi
*hdmi,
ssize_t err;
err = drm_hdmi_avi_infoframe_from_display_mode(&frame,
- &hdmi->conn, mode);
+ hdmi->curr_conn, mode);
if (err < 0) {
dev_err(hdmi->dev,
"Failed to get AVI infoframe from mode: %zd\n", err);
@@ -1054,7 +1055,7 @@ static int
mtk_hdmi_setup_vendor_specific_infoframe(struct mtk_hdmi *hdmi,
ssize_t err;
err = drm_hdmi_vendor_infoframe_from_display_mode(&frame,
- &hdmi->conn, mode);
+ hdmi->curr_conn,
mode);
if (err) {
dev_err(hdmi->dev,
"Failed to get vendor infoframe from mode: %zd\n", err);
@@ -1357,7 +1358,8 @@ static bool mtk_hdmi_bridge_mode_fixup(struct drm_bridge
*bridge,
return true;
}
-static void mtk_hdmi_bridge_disable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1368,10 +1370,13 @@ static void mtk_hdmi_bridge_disable(struct drm_bridge
*bridge)
clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
+ hdmi->curr_conn = NULL;
+
hdmi->enabled = false;
}
-static void mtk_hdmi_bridge_post_disable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1406,7 +1411,8 @@ static void mtk_hdmi_bridge_mode_set(struct drm_bridge
*bridge,
drm_mode_copy(&hdmi->mode, adjusted_mode);
}
-static void mtk_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_state)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1426,10 +1432,16 @@ static void mtk_hdmi_send_infoframe(struct mtk_hdmi
*hdmi,
mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
}
-static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
+static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_state)
{
+ struct drm_atomic_state *state = old_state->base.state;
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
+ /* Retrieve the connector through the atomic state. */
+ hdmi->curr_conn = drm_atomic_get_new_connector_for_encoder(state,
+
bridge->encoder);
+
mtk_hdmi_output_set_display_mode(hdmi, &hdmi->mode);
clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
@@ -1440,13 +1452,16 @@ static void mtk_hdmi_bridge_enable(struct drm_bridge
*bridge)
}
static const struct drm_bridge_funcs mtk_hdmi_bridge_funcs = {
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
.attach = mtk_hdmi_bridge_attach,
.mode_fixup = mtk_hdmi_bridge_mode_fixup,
- .disable = mtk_hdmi_bridge_disable,
[PATCH 2/2] drm/mediatek: Don't support hdmi connector creation
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment.
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() to report HPD. This provides the
necessary API to support disabling connector creation.
This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c:
commit ec971aaa6775 ("drm: bridge: dw-hdmi: Make connector creation optional")
But with the difference that in mtk-hdmi only the option of not creating
a connector is supported.
Fixes: f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 130 ++--
1 file changed, 44 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 9f415c508b33..9da5dfb7c7fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -153,7 +153,6 @@ struct mtk_hdmi_conf {
struct mtk_hdmi {
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
- struct drm_connector conn;
struct drm_connector *curr_conn;
struct device *dev;
const struct mtk_hdmi_conf *conf;
@@ -187,11 +186,6 @@ static inline struct mtk_hdmi *hdmi_ctx_from_bridge(struct
drm_bridge *b)
return container_of(b, struct mtk_hdmi, bridge);
}
-static inline struct mtk_hdmi *hdmi_ctx_from_conn(struct drm_connector *c)
-{
- return container_of(c, struct mtk_hdmi, conn);
-}
-
static u32 mtk_hdmi_read(struct mtk_hdmi *hdmi, u32 offset)
{
return readl(hdmi->regs + offset);
@@ -1202,48 +1196,30 @@ mtk_hdmi_update_plugged_status(struct mtk_hdmi *hdmi)
connector_status_connected : connector_status_disconnected;
}
-static enum drm_connector_status hdmi_conn_detect(struct drm_connector *conn,
- bool force)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
- return mtk_hdmi_update_plugged_status(hdmi);
-}
-
-static void hdmi_conn_destroy(struct drm_connector *conn)
+static struct edid *mtk_hdmi_get_edid(struct mtk_hdmi *hdmi,
+ struct drm_connector *connector)
{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
-
- mtk_cec_set_hpd_event(hdmi->cec_dev, NULL, NULL);
-
- drm_connector_cleanup(conn);
-}
-
-static int mtk_hdmi_conn_get_modes(struct drm_connector *conn)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
struct edid *edid;
- int ret;
if (!hdmi->ddc_adpt)
- return -ENODEV;
-
- edid = drm_get_edid(conn, hdmi->ddc_adpt);
+ return NULL;
+ edid = drm_get_edid(connector, hdmi->ddc_adpt);
if (!edid)
- return -ENODEV;
-
+ return NULL;
hdmi->dvi_mode = !drm_detect_monitor_audio(edid);
+ return edid;
+}
- drm_connector_update_edid_property(conn, edid);
-
- ret = drm_add_edid_modes(conn, edid);
- kfree(edid);
- return ret;
+static enum drm_connector_status mtk_hdmi_detect(struct mtk_hdmi *hdmi)
+{
+ return mtk_hdmi_update_plugged_status(hdmi);
}
-static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
- struct drm_display_mode *mode)
+static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
+ struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
struct drm_bridge *next_bridge;
dev_dbg(hdmi->dev, "xres=%d, yres=%d, refresh=%d, intl=%d clock=%d\n",
@@ -1268,74 +1244,50 @@ static int mtk_hdmi_conn_mode_valid(struct
drm_connector *conn,
return drm_mode_validate_size(mode, 0x1fff, 0x1fff);
}
-static struct drm_encoder *mtk_hdmi_conn_best_enc(struct drm_connector *conn)
-{
- struct mtk_hdmi *hdmi = hdmi_ctx_from_conn(conn);
-
- return hdmi->bridge.encoder;
-}
-
-static const struct drm_connector_funcs mtk_hdmi_connector_funcs = {
- .detect = hdmi_conn_detect,
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = hdmi_conn_destroy,
- .reset = drm_atomic_helper_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static const struct drm_connector_helper_funcs
- mtk_hdmi_connect
[PATCH 2/2] drm/mediatek: Don't support hdmi connector creation
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
These two patches fix that by adding support for DRM_BRIDGE_ATTACH_NO_CONNECTOR
in mtk_hdmi bridge attachment. The first patch moves the mkt-hdmi bridge
to the atomic API in order to be able to access the connector through the
global state.
Dafna Hirschfeld (2):
drm/mediatek: Switch the hdmi bridge ops to the atomic versions
drm/mediatek: Don't support hdmi connector creation
drivers/gpu/drm/mediatek/mtk_hdmi.c | 171
1 file changed, 73 insertions(+), 98 deletions(-)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm/bridge: anx7688: Add ANX7688 bridge driver support
Adding meg...@megous.com and linux-...@vger.kernel.org to the list
Thanks,
Dafna
On 05.03.21 13:43, Dafna Hirschfeld wrote:
From: Enric Balletbo i Serra
This driver adds support for the ANX7688 HDMI to DP converter block of the
ANX7688 device.
For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP bandwidth and lane count are reported by the bridge via
2 registers and, as far as we know, only chips that have a firmware
version greater than 0.85 support these two registers.
Signed-off-by: Nicolas Boichat
Signed-off-by: Hsin-Yi Wang
[The driver is OF only so should depends on CONFIG_OF]
Reported-by: kbuild test robot
Signed-off-by: Enric Balletbo i Serra
[convert the driver to be a i2c driver]
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/bridge/analogix/Kconfig | 11 ++
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
.../drm/bridge/analogix/analogix-anx7688.c| 186 ++
3 files changed, 198 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index 024ea2a570e7..323327aabc38 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -11,6 +11,17 @@ config DRM_ANALOGIX_ANX6345
ANX6345 transforms the LVTTL RGB output of an
application processor to eDP or DisplayPort.
+config DRM_ANALOGIX_ANX7688
+ tristate "Analogix ANX7688 bridge"
+ depends on OF
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ANX7688 is an ultra-low power 4K Ultra-HD (4096x2160p60)
+ mobile HD transmitter designed for portable
+ devices. The ANX7688 converts HDMI 2.0 to
+ DisplayPort 1.3 Ultra-HD.
+
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_ANALOGIX_DP
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index 44da392bb9f9..8f2272b8b732 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -2,5 +2,6 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
new file mode 100644
index ..85a4b1a23035
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright 2020 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register addresses */
+#define ANX7688_VENDOR_ID_REG 0x00
+#define ANX7688_DEVICE_ID_REG 0x02
+
+#define ANX7688_FW_VERSION_REG 0x80
+
+#define ANX7688_DP_BANDWIDTH_REG 0x85
+#define ANX7688_DP_LANE_COUNT_REG 0x86
+
+#define ANX7688_VENDOR_ID 0x1f29
+#define ANX7688_DEVICE_ID 0x7688
+
+/* First supported firmware version (0.85) */
+#define ANX7688_MINIMUM_FW_VERSION 0x0085
+
+static const struct regmap_config anx7688_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+struct anx7688 {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct drm_bridge bridge;
+ bool filter;
+};
+
+static inline struct anx7688 *
+bridge_to_anx7688(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct anx7688, bridge);
+}
+
+static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct anx7688 *anx = bridge_to_anx7688(bridge);
+ int totalbw, requiredbw;
+ u8 dpbw, lanecount;
+ u8 regs[2];
+ int ret;
+
+ if (!anx->filter)
+ return true;
+
+ /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+ ret = regmap_bulk_read(anx->regmap, ANX7688_DP_BANDWIDTH_REG, regs, 2);
+ if (ret < 0) {
+ DRM_ERROR("Failed to read bandwidth/lane count\n");
+ return false;
+ }
+ dpbw = regs[0];
+ lanecount = regs[1];
+
+ /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+ if (dpbw > 0x19 || lanecount > 2) {
+ DRM_ERROR("Invalid bandwidth/lane count (%02x/%d)\n", dpbw,
+ lanecount);
+
Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml
Hi On 05.03.21 15:34, Laurent Pinchart wrote: Hi Dafna, Thank you for the patch. On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote: ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to DisplayPort 1.3 Ultra-HDi (4096x2160p60). The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer along with the DisplayPort Alternate Mode signaling over USB Type-C. Additionally, an on-chip microcontroller (OCM) is available to manage the signal switching, Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other functions as defined in the USB TypeC and USB Power Delivery specifications. ANX7688 is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone. Signed-off-by: Dafna Hirschfeld --- .../bindings/usb/analogix,anx7688.yaml| 177 ++ 1 file changed, 177 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/analogix,anx7688.yaml diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml new file mode 100644 index ..6c4dd6b4b28b --- /dev/null +++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml @@ -0,0 +1,177 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analogix ANX7688 Type-C Port Controller with HDMI to DP conversion + +maintainers: + - Nicolas Boichat + - Enric Balletbo i Serra + +description: | + ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to + DisplayPort 1.3 Ultra-HDi (4096x2160p60). + The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer along with + the DisplayPort Alternate Mode signaling over USB Type-C. Additionally, + an on-chip microcontroller (OCM) is available to manage the signal switching, + Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor + Defined Message (VDM) protocol support and other functions as defined in the + USB TypeC and USB Power Delivery specifications. + + Extra blank line ? +properties: + compatible: +const: analogix,anx7688 + + reg: +maxItems: 1 + + avdd33-supply: +description: 3.3V Analog core supply voltage. + + dvdd18-supply: +description: 1.8V Digital I/O supply voltage. + + avdd18-supply: +description: 1.8V Analog core power supply voltage. + + avdd10-supply: +description: 1.0V Analog core power supply voltage. + + dvdd10-supply: +description: 1.0V Digital core supply voltage. + That's lots of supplies. If there's a reasonable chance that some of them will always be driven by the same regulator (especially if the ANX7688 documentation requires that), then they could be grouped. For instance dvdd18-supply and avdd18-supply could be grouped into vdd18-supply. It would still allow us to extend the bindings in a backward compatible way later if a system uses different regulators. You have more information about the hardware than I do, so it's your call. + hdmi5v-supply: +description: 5V power supply for the HDMI. + + hdmi_vt-supply: +description: Termination voltage for HDMI input. Maybe hdmi-vt-supply ? + + clocks: +description: The input clock specifier. +maxItems: 1 How about items: - description: The input clock specifier. + + clock-names: +items: + - const: xtal + + hpd-gpios: +description: | + In USB Type-C applications, DP_HPD has no use. In standard DisplayPort + applications, DP_HPD is used as DP hot-plug. +maxItems: 1 + + enable-gpios: +description: Chip power down control. No internal pull-down or pull-up resistor. +maxItems: 1 + + reset-gpios: +description: Reset input signal. Active low. +maxItems: 1 + + vbus-det-gpios: +description: | + An input gpio for VBUS detection and high voltage detection, + external resistance divide VBUS voltage to 1/8. +maxItems: 1 + + interrupts: +description: | + The interrupt notifies 4 possible events - TCPC ALERT int, PD int, DP int, HDMI int. +maxItems: 1 + + cabledet-gpios: +description: An output gpio, indicates by the device that a cable is plugged. +maxItems: 1 + + vbus-ctrl-gpios: +description: + External VBUS power path. Enable VBUS source and disable VBUS sink or vice versa. +maxItems: 1 + + vconn-en1-gpios: +description: Controls the VCONN switch on the CC1 pin. +maxItems: 1 + + vconn-en2-gpios: +description: Controls the VCONN switch on the CC2 pin. +maxItems: 1 + + ports: +$ref: /schemas/graph.yaml#/properties/ports + +properties: + port@0: +$ref: /schemas/graph.yaml#/properties/port +description: Video port for HDMI input. + + port@1: +$ref: /sch
[PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml
ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
DisplayPort 1.3 Ultra-HDi (4096x2160p60).
The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer
along with the DisplayPort Alternate Mode signaling over USB Type-C.
Additionally, an on-chip microcontroller (OCM) is available to manage the
signal switching, Channel Configuration (CC) detection, USB Power
Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other
functions as defined in the USB TypeC and USB Power Delivery
specifications.
ANX7688 is found on Acer Chromebook R13 (elm) and on
Pine64 PinePhone.
Signed-off-by: Dafna Hirschfeld
---
.../bindings/usb/analogix,anx7688.yaml| 177 ++
1 file changed, 177 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
new file mode 100644
index ..6c4dd6b4b28b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
@@ -0,0 +1,177 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analogix ANX7688 Type-C Port Controller with HDMI to DP conversion
+
+maintainers:
+ - Nicolas Boichat
+ - Enric Balletbo i Serra
+
+description: |
+ ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
+ DisplayPort 1.3 Ultra-HDi (4096x2160p60).
+ The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer
along with
+ the DisplayPort Alternate Mode signaling over USB Type-C. Additionally,
+ an on-chip microcontroller (OCM) is available to manage the signal switching,
+ Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor
+ Defined Message (VDM) protocol support and other functions as defined in the
+ USB TypeC and USB Power Delivery specifications.
+
+
+properties:
+ compatible:
+const: analogix,anx7688
+
+ reg:
+maxItems: 1
+
+ avdd33-supply:
+description: 3.3V Analog core supply voltage.
+
+ dvdd18-supply:
+description: 1.8V Digital I/O supply voltage.
+
+ avdd18-supply:
+description: 1.8V Analog core power supply voltage.
+
+ avdd10-supply:
+description: 1.0V Analog core power supply voltage.
+
+ dvdd10-supply:
+description: 1.0V Digital core supply voltage.
+
+ hdmi5v-supply:
+description: 5V power supply for the HDMI.
+
+ hdmi_vt-supply:
+description: Termination voltage for HDMI input.
+
+ clocks:
+description: The input clock specifier.
+maxItems: 1
+
+ clock-names:
+items:
+ - const: xtal
+
+ hpd-gpios:
+description: |
+ In USB Type-C applications, DP_HPD has no use. In standard DisplayPort
+ applications, DP_HPD is used as DP hot-plug.
+maxItems: 1
+
+ enable-gpios:
+description: Chip power down control. No internal pull-down or pull-up
resistor.
+maxItems: 1
+
+ reset-gpios:
+description: Reset input signal. Active low.
+maxItems: 1
+
+ vbus-det-gpios:
+description: |
+ An input gpio for VBUS detection and high voltage detection,
+ external resistance divide VBUS voltage to 1/8.
+maxItems: 1
+
+ interrupts:
+description: |
+ The interrupt notifies 4 possible events - TCPC ALERT int, PD int, DP
int, HDMI int.
+maxItems: 1
+
+ cabledet-gpios:
+description: An output gpio, indicates by the device that a cable is
plugged.
+maxItems: 1
+
+ vbus-ctrl-gpios:
+description:
+ External VBUS power path. Enable VBUS source and disable VBUS sink or
vice versa.
+maxItems: 1
+
+ vconn-en1-gpios:
+description: Controls the VCONN switch on the CC1 pin.
+maxItems: 1
+
+ vconn-en2-gpios:
+description: Controls the VCONN switch on the CC2 pin.
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for HDMI input.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: USB port for the USB3 input.
+
+ port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description: USB Type-c connector, see connector/usb-connector.yaml.
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+anx7688: anx7688@2c {
+compatible = "analogix,anx7688";
+reg = <0x2c>;
+avdd33-supply = <®_dcdc1>;
+dvdd18-supply = <®_ldo_io1>;
+avdd18-supply = <®_ldo_io1>;
+avdd10-supply = <
[PATCH v5 0/2] Add support for ANX7688
ANX7688 is a typec port controller that also converts HDMI to DP. ANX7688 is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone. On Acer Chromebook R13, the device is powered-up and controller by the Embedded Controller. Therefore the dt-bindings requires only the 'compatible' and 'reg' properties. In v4 of this set, the device was added as an 'mfd' device and an additional 'bridge' device for the HDMI-DP conversion, see [1]. In this version we add the device as a typec controller. [1] https://lkml.org/lkml/2020/3/18/64 Changes from v4: Send the device as a typec controller instead of mfd. The bridge driver should therefore convert from a platform driver to an i2c driver. Dafna Hirschfeld (1): dt-bindings: usb: add analogix,anx7688.yaml Enric Balletbo i Serra (1): drm/bridge: anx7688: Add ANX7688 bridge driver support .../bindings/usb/analogix,anx7688.yaml| 177 + drivers/gpu/drm/bridge/analogix/Kconfig | 11 ++ drivers/gpu/drm/bridge/analogix/Makefile | 1 + .../drm/bridge/analogix/analogix-anx7688.c| 186 ++ 4 files changed, 375 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/analogix,anx7688.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] drm/bridge: anx7688: Add ANX7688 bridge driver support
From: Enric Balletbo i Serra
This driver adds support for the ANX7688 HDMI to DP converter block of the
ANX7688 device.
For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP bandwidth and lane count are reported by the bridge via
2 registers and, as far as we know, only chips that have a firmware
version greater than 0.85 support these two registers.
Signed-off-by: Nicolas Boichat
Signed-off-by: Hsin-Yi Wang
[The driver is OF only so should depends on CONFIG_OF]
Reported-by: kbuild test robot
Signed-off-by: Enric Balletbo i Serra
[convert the driver to be a i2c driver]
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/bridge/analogix/Kconfig | 11 ++
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
.../drm/bridge/analogix/analogix-anx7688.c| 186 ++
3 files changed, 198 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index 024ea2a570e7..323327aabc38 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -11,6 +11,17 @@ config DRM_ANALOGIX_ANX6345
ANX6345 transforms the LVTTL RGB output of an
application processor to eDP or DisplayPort.
+config DRM_ANALOGIX_ANX7688
+ tristate "Analogix ANX7688 bridge"
+ depends on OF
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ANX7688 is an ultra-low power 4K Ultra-HD (4096x2160p60)
+ mobile HD transmitter designed for portable
+ devices. The ANX7688 converts HDMI 2.0 to
+ DisplayPort 1.3 Ultra-HD.
+
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_ANALOGIX_DP
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index 44da392bb9f9..8f2272b8b732 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -2,5 +2,6 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
new file mode 100644
index ..85a4b1a23035
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright 2020 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register addresses */
+#define ANX7688_VENDOR_ID_REG 0x00
+#define ANX7688_DEVICE_ID_REG 0x02
+
+#define ANX7688_FW_VERSION_REG 0x80
+
+#define ANX7688_DP_BANDWIDTH_REG 0x85
+#define ANX7688_DP_LANE_COUNT_REG 0x86
+
+#define ANX7688_VENDOR_ID 0x1f29
+#define ANX7688_DEVICE_ID 0x7688
+
+/* First supported firmware version (0.85) */
+#define ANX7688_MINIMUM_FW_VERSION 0x0085
+
+static const struct regmap_config anx7688_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+struct anx7688 {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct drm_bridge bridge;
+ bool filter;
+};
+
+static inline struct anx7688 *
+bridge_to_anx7688(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct anx7688, bridge);
+}
+
+static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct anx7688 *anx = bridge_to_anx7688(bridge);
+ int totalbw, requiredbw;
+ u8 dpbw, lanecount;
+ u8 regs[2];
+ int ret;
+
+ if (!anx->filter)
+ return true;
+
+ /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+ ret = regmap_bulk_read(anx->regmap, ANX7688_DP_BANDWIDTH_REG, regs, 2);
+ if (ret < 0) {
+ DRM_ERROR("Failed to read bandwidth/lane count\n");
+ return false;
+ }
+ dpbw = regs[0];
+ lanecount = regs[1];
+
+ /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+ if (dpbw > 0x19 || lanecount > 2) {
+ DRM_ERROR("Invalid bandwidth/lane count (%02x/%d)\n", dpbw,
+ lanecount);
+ return false;
+ }
+
+ /* Compute available bandwidth (kHz) */
+ totalbw = dpbw * lanecount * 27
Re: [PATCH v2] dt-bindings: convert rockchip-drm.txt to rockchip-drm.yaml
On 21.01.20 16:11, Johan Jonker wrote: Hi Dafna, On 21.01.20 15:03, Rob Herring wrote: On Tue, Jan 21, 2020 at 6:35 AM Dafna Hirschfeld wrote: convert the binding file rockchip-drm.txt to yaml format. This was tested and verified with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml Also, make sure just 'make dt_binding_check' passes as that checks the example against all schemas. But this also checks the other schemas in general, and when running it, it fails because of bugs in other schemas. For example with arm=ARM I get: Use: # enable Rockchip arm in menuconfig make ARCH=arm menuconfig make ARCH=arm dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml and not: arm=ARM yes, sorry, this is what I did. When running with the DT_SCHEMA_FILES set then it passes both on ARM and ARM64 but when this variable is not set I get the above error. Dafna DTC Documentation/devicetree/bindings/clock/qcom,gcc.example.dt.yaml Error: Documentation/devicetree/bindings/clock/qcom,gcc.example.dts:111.28-29 syntax error FATAL ERROR: Unable to parse input tree Dafna make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dt-bindings: convert rockchip-drm.txt to rockchip-drm.yaml
On 21.01.20 15:03, Rob Herring wrote:
On Tue, Jan 21, 2020 at 6:35 AM Dafna Hirschfeld
wrote:
convert the binding file rockchip-drm.txt to yaml format.
This was tested and verified with:
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
Also, make sure just 'make dt_binding_check' passes as that checks the
example against all schemas.
But this also checks the other schemas in general, and when running it,
it fails because of bugs in other schemas.
For example with arm=ARM I get:
DTC Documentation/devicetree/bindings/clock/qcom,gcc.example.dt.yaml
Error:
Documentation/devicetree/bindings/clock/qcom,gcc.example.dts:111.28-29
syntax error
FATAL ERROR: Unable to parse input tree
Dafna
make dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
Signed-off-by: Dafna Hirschfeld
---
Changes since v1:
- fixed worng sign-off
- fixed the path of the $id property to be the path of the yaml file
.../display/rockchip/rockchip-drm.txt | 19 --
.../display/rockchip/rockchip-drm.yaml| 38 +++
2 files changed, 38 insertions(+), 19 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
deleted file mode 100644
index 5707af89319d..
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Rockchip DRM master device
-
-
-The Rockchip DRM master device is a virtual device needed to list all
-vop devices or other display interface nodes that comprise the
-graphics subsystem.
-
-Required properties:
-- compatible: Should be "rockchip,display-subsystem"
-- ports: Should contain a list of phandles pointing to display interface port
- of vop devices. vop definitions as defined in
- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
-
-example:
-
-display-subsystem {
- compatible = "rockchip,display-subsystem";
- ports = <&vopl_out>, <&vopb_out>;
-};
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
new file mode 100644
index ..538898ada9d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
Do you have rights to change the license? The default is GPL-2.0-only.
Looks like Rockchip owns the copyright.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-drm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip DRM master device
+
+maintainers:
+ - Sandy Huang
+
+description: |
+ The Rockchip DRM master device is a virtual device needed to list all
+ vop devices or other display interface nodes that comprise the
+ graphics subsystem.
+
+properties:
+ compatible:
+const: rockchip,display-subsystem
+
+ ports:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ Should contain a list of phandles pointing to display interface port
+ of vop devices. vop definitions as defined in
+ Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+
+required:
+ - compatible
+ - ports
Add:
additionalProperties: false
+
+examples:
+ - |
+display-subsystem {
+compatible = "rockchip,display-subsystem";
+ports = <&vopl_out>, <&vopb_out>;
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] dt-bindings: convert rockchip-drm.txt to rockchip-drm.yaml
convert the binding file rockchip-drm.txt to yaml format.
This was tested and verified on ARM and ARM64 with:
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
make dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
Signed-off-by: Dafna Hirschfeld
---
the detail of the ARM tests:
export ARCH=arm KBUILD_OUTPUT=../kbuild/arm-test-dtc/
CROSS_COMPILE=arm-linux-gnueabi-
make menuconfig # set rockchip system
make clean
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
make dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
the detail of the ARM64 tests:
export ARCH=arm64 KBUILD_OUTPUT=../kbuild/arm64-test-dtc/
CROSS_COMPILE=aarch64-linux-gnu-
make menuconfig # set rockchip system
make clean
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
make dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
Changes since v1:
- fixed worng sign-off
- fixed the path of the $id property to be the path of the yaml file
Changes since v2:
- add a missing ">" sign in maintainers list
- change the licens to GPL-2.0-only
- add "additionalProperties: false"
- change the commit message to conform that it was tested on both ARM and ARM64
.../display/rockchip/rockchip-drm.txt | 19 -
.../display/rockchip/rockchip-drm.yaml| 40 +++
2 files changed, 40 insertions(+), 19 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
deleted file mode 100644
index 5707af89319d..
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Rockchip DRM master device
-
-
-The Rockchip DRM master device is a virtual device needed to list all
-vop devices or other display interface nodes that comprise the
-graphics subsystem.
-
-Required properties:
-- compatible: Should be "rockchip,display-subsystem"
-- ports: Should contain a list of phandles pointing to display interface port
- of vop devices. vop definitions as defined in
- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
-
-example:
-
-display-subsystem {
- compatible = "rockchip,display-subsystem";
- ports = <&vopl_out>, <&vopb_out>;
-};
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
new file mode 100644
index ..ec8ae742d4da
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-drm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip DRM master device
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+description: |
+ The Rockchip DRM master device is a virtual device needed to list all
+ vop devices or other display interface nodes that comprise the
+ graphics subsystem.
+
+properties:
+ compatible:
+const: rockchip,display-subsystem
+
+ ports:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ Should contain a list of phandles pointing to display interface port
+ of vop devices. vop definitions as defined in
+ Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+display-subsystem {
+compatible = "rockchip,display-subsystem";
+ports = <&vopl_out>, <&vopb_out>;
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] dt-bindings: convert rockchip-drm.txt to rockchip-drm.yaml
convert the binding file rockchip-drm.txt to yaml format.
This was tested and verified with:
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
make dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
Signed-off-by: Dafna Hirschfeld
---
Changes since v1:
- fixed worng sign-off
- fixed the path of the $id property to be the path of the yaml file
.../display/rockchip/rockchip-drm.txt | 19 --
.../display/rockchip/rockchip-drm.yaml| 38 +++
2 files changed, 38 insertions(+), 19 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
deleted file mode 100644
index 5707af89319d..
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Rockchip DRM master device
-
-
-The Rockchip DRM master device is a virtual device needed to list all
-vop devices or other display interface nodes that comprise the
-graphics subsystem.
-
-Required properties:
-- compatible: Should be "rockchip,display-subsystem"
-- ports: Should contain a list of phandles pointing to display interface port
- of vop devices. vop definitions as defined in
- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
-
-example:
-
-display-subsystem {
- compatible = "rockchip,display-subsystem";
- ports = <&vopl_out>, <&vopb_out>;
-};
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
new file mode 100644
index ..538898ada9d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-drm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip DRM master device
+
+maintainers:
+ - Sandy Huang
+
+description: |
+ The Rockchip DRM master device is a virtual device needed to list all
+ vop devices or other display interface nodes that comprise the
+ graphics subsystem.
+
+properties:
+ compatible:
+const: rockchip,display-subsystem
+
+ ports:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ Should contain a list of phandles pointing to display interface port
+ of vop devices. vop definitions as defined in
+ Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+
+required:
+ - compatible
+ - ports
+
+examples:
+ - |
+display-subsystem {
+compatible = "rockchip,display-subsystem";
+ports = <&vopl_out>, <&vopb_out>;
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: convert rockchip-drm.txt to rockchip-drm.yaml
From: Dafna Hirschfeld
convert the binding file rockchip-drm.txt to yaml format.
This was tested and verified with:
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
make dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
Signed-off-by: Dafna Hirschfeld
---
.../display/rockchip/rockchip-drm.txt | 19 --
.../display/rockchip/rockchip-drm.yaml| 38 +++
2 files changed, 38 insertions(+), 19 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
deleted file mode 100644
index 5707af89319d..
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Rockchip DRM master device
-
-
-The Rockchip DRM master device is a virtual device needed to list all
-vop devices or other display interface nodes that comprise the
-graphics subsystem.
-
-Required properties:
-- compatible: Should be "rockchip,display-subsystem"
-- ports: Should contain a list of phandles pointing to display interface port
- of vop devices. vop definitions as defined in
- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
-
-example:
-
-display-subsystem {
- compatible = "rockchip,display-subsystem";
- ports = <&vopl_out>, <&vopb_out>;
-};
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
new file mode 100644
index ..e4ef1a02196d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rockchip-drm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip DRM master device
+
+maintainers:
+ - Sandy Huang
+
+description: |
+ The Rockchip DRM master device is a virtual device needed to list all
+ vop devices or other display interface nodes that comprise the
+ graphics subsystem.
+
+properties:
+ compatible:
+const: rockchip,display-subsystem
+
+ ports:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ Should contain a list of phandles pointing to display interface port
+ of vop devices. vop definitions as defined in
+ Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+
+required:
+ - compatible
+ - ports
+
+examples:
+ - |
+display-subsystem {
+compatible = "rockchip,display-subsystem";
+ports = <&vopl_out>, <&vopb_out>;
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
