[PATCH] drm/i915: Add locking to i915_gem_evict_vm(), v3.
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some objects' locks.
Previously, this was spread over several commits, but it makes
more sense to commit the changes to i915_gem_evict_vm separately
from the changes to i915_gem_evict_something() and
i915_gem_evict_for_node().
Changes since v1:
- Handle evicting dead objects better.
Changes since v2:
- Use for_i915_gem_ww in igt_evict_vm. (Thomas)
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/i915_gem_evict.c | 32 +--
drivers/gpu/drm/i915/i915_gem_evict.h | 4 ++-
drivers/gpu/drm/i915/i915_vma.c | 7 +++-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 12 ---
6 files changed, 49 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cf283b5f6ffe..4d832d6696b5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -767,7 +767,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
case 1:
/* Too fragmented, unbind everything and retry */
mutex_lock(>context->vm->mutex);
- err = i915_gem_evict_vm(eb->context->vm);
+ err = i915_gem_evict_vm(eb->context->vm, >ww);
mutex_unlock(>context->vm->mutex);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fafd158e5313..a69787999d09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -367,7 +367,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
if (vma == ERR_PTR(-ENOSPC)) {
ret = mutex_lock_interruptible(>vm.mutex);
if (!ret) {
- ret = i915_gem_evict_vm(>vm);
+ ret = i915_gem_evict_vm(>vm, );
mutex_unlock(>vm.mutex);
}
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 24eee0c2055f..91f82ecb9ef4 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -368,7 +368,7 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
* To clarify: This is for freeing up virtual address space, not for freeing
* memory in e.g. the shrinker.
*/
-int i915_gem_evict_vm(struct i915_address_space *vm)
+int i915_gem_evict_vm(struct i915_address_space *vm, struct i915_gem_ww_ctx
*ww)
{
int ret = 0;
@@ -389,24 +389,52 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
do {
struct i915_vma *vma, *vn;
LIST_HEAD(eviction_list);
+ LIST_HEAD(locked_eviction_list);
list_for_each_entry(vma, >bound_list, vm_link) {
if (i915_vma_is_pinned(vma))
continue;
+ /*
+* If we already own the lock, trylock fails. In case
+* the resv is shared among multiple objects, we still
+* need the object ref.
+*/
+ if (!kref_read(>obj->base.refcount) ||
+ (ww && (dma_resv_locking_ctx(vma->obj->base.resv)
== >ctx))) {
+ __i915_vma_pin(vma);
+ list_add(>evict_link,
_eviction_list);
+ continue;
+ }
+
+ if (!i915_gem_object_trylock(vma->obj, ww))
+ continue;
+
__i915_vma_pin(vma);
list_add(>evict_link, _list);
}
- if (list_empty(_list))
+ if (list_empty(_list) &&
list_empty(_eviction_list))
break;
ret = 0;
+ /* Unbind locked objects first, before unlocking the
eviction_list */
+ list_for_each_entry_safe(vma, vn, _eviction_list,
evict_link) {
+ __i915_vma_unpin(vma);
+
+ if (ret == 0)
+ ret = __i915_vma_unbind(vma);
+ if (ret != -EINTR) /* "Get me out of here!" */
+ ret = 0;
+ }
+
list_for_each_entry_safe(vma, vn, _list, evict_link) {
[PATCH] drm/radeon: fix UVD suspend error
I met a bug recently and the kernel log:
[ 330.171875] radeon :03:00.0: couldn't schedule ib
[ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD
(-22)!
In radeon drivers, using UVD suspend is as follows:
if (rdev->has_uvd) {
uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
}
In radeon_ib_schedule function, we check the 'ring->ready' state,
but in uvd_v1_0_fini funciton, we've cleared the ready state.
So, just modify the suspend code flow to fix error.
Signed-off-by: Qiang Ma
---
drivers/gpu/drm/radeon/cik.c | 2 +-
drivers/gpu/drm/radeon/evergreen.c | 2 +-
drivers/gpu/drm/radeon/ni.c| 2 +-
drivers/gpu/drm/radeon/r600.c | 2 +-
drivers/gpu/drm/radeon/rv770.c | 2 +-
drivers/gpu/drm/radeon/si.c| 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 81b4de7be9f2..5819737c21c6 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -8517,8 +8517,8 @@ int cik_suspend(struct radeon_device *rdev)
cik_cp_enable(rdev, false);
cik_sdma_enable(rdev, false);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
if (rdev->has_vce)
radeon_vce_suspend(rdev);
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index eeb590d2dec2..455f8036aa54 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -5156,8 +5156,8 @@ int evergreen_suspend(struct radeon_device *rdev)
radeon_pm_suspend(rdev);
radeon_audio_fini(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
r700_cp_stop(rdev);
r600_dma_stop(rdev);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 4a364ca7a1be..927e5f42e97d 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2323,8 +2323,8 @@ int cayman_suspend(struct radeon_device *rdev)
cayman_cp_enable(rdev, false);
cayman_dma_stop(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
evergreen_irq_suspend(rdev);
radeon_wb_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index ca3fcae2adb5..dd78fc499402 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3232,8 +3232,8 @@ int r600_suspend(struct radeon_device *rdev)
radeon_audio_fini(rdev);
r600_cp_stop(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
r600_irq_suspend(rdev);
radeon_wb_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index e592e57be1bb..38796af4fadd 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1894,8 +1894,8 @@ int rv770_suspend(struct radeon_device *rdev)
radeon_pm_suspend(rdev);
radeon_audio_fini(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
r700_cp_stop(rdev);
r600_dma_stop(rdev);
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 013e44ed0f39..8d5e4b25609d 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6800,8 +6800,8 @@ int si_suspend(struct radeon_device *rdev)
si_cp_enable(rdev, false);
cayman_dma_stop(rdev);
if (rdev->has_uvd) {
- uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
+ uvd_v1_0_fini(rdev);
}
if (rdev->has_vce)
radeon_vce_suspend(rdev);
--
2.20.1
Re: [RFC 4/6] dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup.
Am 15.01.22 um 02:06 schrieb Hridya Valsaraju:
The optional exporter op provides a way for processes to transfer
charge of a buffer to a different process. This is essential for the
cases where a central allocator process does allocations for various
subsystems, hands over the fd to the client who
requested the memory and drops all references to the allocated memory.
Signed-off-by: Hridya Valsaraju
---
include/linux/dma-buf.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 7ab50076e7a6..d5e52f81cc6f 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -13,6 +13,7 @@
#ifndef __DMA_BUF_H__
#define __DMA_BUF_H__
+#include
#include
#include
#include
@@ -285,6 +286,23 @@ struct dma_buf_ops {
int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
+
+ /**
+* @charge_to_cgroup:
+*
+* This is called by an exporter to charge a buffer to the specified
+* cgroup.
Well that sentence makes absolutely no sense at all.
The dma_buf_ops are supposed to be called by the DMA-buf subsystem on
behalves of the importer and never by the exporter itself.
I hope that this is just a documentation mixup.
Regards,
Christian.
The caller must hold a reference to @gpucg obtained via
+* gpucg_get(). The DMA-BUF will be uncharged from the cgroup it is
+* currently charged to before being charged to @gpucg. The caller must
+* belong to the cgroup the buffer is currently charged to.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* 0 on success or negative error code on failure.
+*/
+ int (*charge_to_cgroup)(struct dma_buf *dmabuf, struct gpucg *gpucg);
};
/**
Re: [PATCH v2 2/3] drm/rockchip: cdn-dp: Support HDMI codec plug-change callback
On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote: > > Some audio servers like to monitor a jack device (perhaps combined with > EDID, for audio-presence info) to determine DP/HDMI audio presence. > > Signed-off-by: Brian Norris Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2 1/3] arm64: dts: rockchip: Switch RK3399-Gru DP to SPDIF output
On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote:
>
> Commit b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
> switched the platform to SPDIF, but we didn't fix up the device tree.
>
> Drop the pinctrl settings, because the 'spdif_bus' pins are either:
> * unused (on kevin, bob), so the settings is ~harmless
> * used by a different function (on scarlet), which causes probe
>failures (!!)
I suppose that means the default pinctrl should be dropped? Or maybe this
use case is the outlier. Up to Heiko?
> Fixes: b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
> Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
Re: [PATCH] drm/amdgpu: remove duplicate include
Am 15.01.22 um 08:02 schrieb cgel@gmail.com: From: Changcheng Deng 'drm/drm_drv.h' included in 'amdgpu_ttm.c' is duplicated. It is also included on 53 line. Reported-by: Zeal Robot Signed-off-by: Changcheng Deng Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 953d68b26f0b..ebd40d1a8aff 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -43,7 +43,6 @@ #include #include -#include #include #include #include -- 2.25.1
[PATCH v10 13/13] arm64: dts: mediatek: Get rid of mediatek, larb for MM nodes
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --
2 files changed, 22 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index dee66e5f054c..417e82891a70 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1010,7 +1010,6 @@
< CLK_MM_MUTEX_32K>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_RDMA0>;
- mediatek,larb = <>;
mediatek,vpu = <>;
};
@@ -1021,7 +1020,6 @@
< CLK_MM_MUTEX_32K>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_RDMA1>;
- mediatek,larb = <>;
};
mdp_rsz0: rsz@14003000 {
@@ -1051,7 +1049,6 @@
clocks = < CLK_MM_MDP_WDMA>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WDMA>;
- mediatek,larb = <>;
};
mdp_wrot0: wrot@14007000 {
@@ -1060,7 +1057,6 @@
clocks = < CLK_MM_MDP_WROT0>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WROT0>;
- mediatek,larb = <>;
};
mdp_wrot1: wrot@14008000 {
@@ -1069,7 +1065,6 @@
clocks = < CLK_MM_MDP_WROT1>;
power-domains = < MT8173_POWER_DOMAIN_MM>;
iommus = < M4U_PORT_MDP_WROT1>;
- mediatek,larb = <>;
};
ovl0: ovl@1400c000 {
@@ -1079,7 +1074,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL0>;
iommus = < M4U_PORT_DISP_OVL0>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1400 0xc000
0x1000>;
};
@@ -1090,7 +1084,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL1>;
iommus = < M4U_PORT_DISP_OVL1>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1400 0xd000
0x1000>;
};
@@ -1101,7 +1094,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA0>;
iommus = < M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1400 0xe000
0x1000>;
};
@@ -1112,7 +1104,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1400 0xf000
0x1000>;
};
@@ -1123,7 +1114,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA2>;
iommus = < M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1401 0
0x1000>;
};
@@ -1134,7 +1124,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA0>;
iommus = < M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1401 0x1000
0x1000>;
};
@@ -1145,7 +1134,6 @@
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA1>;
iommus = < M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <>;
mediatek,gce-client-reg = < SUBSYS_1401 0x2000
0x1000>;
};
@@ -1397,7 +1385,6 @@
<0 0x16027800 0 0x800>, /* VDEC_HWB */
<0 0x16028400 0 0x400>; /* VDEC_HWG */
interrupts = ;
- mediatek,larb = <>;
iommus = < M4U_PORT_HW_VDEC_MC_EXT>,
< M4U_PORT_HW_VDEC_PP_EXT>,
<
[PATCH v10 12/13] arm: dts: mediatek: Get rid of mediatek, larb for MM nodes
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5 -
2 files changed, 7 deletions(-)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 4776f85d6d5b..ef583cfd3baf 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -564,7 +564,6 @@
clock-names = "jpgdec-smi",
"jpgdec";
power-domains = < MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <>;
iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
< MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
@@ -577,7 +576,6 @@
clocks = < CLK_IMG_VENC>;
clock-names = "jpgenc";
power-domains = < MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <>;
iommus = < MT2701_M4U_PORT_JPGENC_RDMA>,
< MT2701_M4U_PORT_JPGENC_BSDMA>;
};
diff --git a/arch/arm/boot/dts/mt7623n.dtsi b/arch/arm/boot/dts/mt7623n.dtsi
index bcb0846e29fd..3adab5cd1fef 100644
--- a/arch/arm/boot/dts/mt7623n.dtsi
+++ b/arch/arm/boot/dts/mt7623n.dtsi
@@ -121,7 +121,6 @@
clock-names = "jpgdec-smi",
"jpgdec";
power-domains = < MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <>;
iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
< MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
@@ -144,7 +143,6 @@
interrupts = ;
clocks = < CLK_MM_DISP_OVL>;
iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
- mediatek,larb = <>;
};
rdma0: rdma@14008000 {
@@ -154,7 +152,6 @@
interrupts = ;
clocks = < CLK_MM_DISP_RDMA>;
iommus = < MT2701_M4U_PORT_DISP_RDMA>;
- mediatek,larb = <>;
};
wdma@14009000 {
@@ -164,7 +161,6 @@
interrupts = ;
clocks = < CLK_MM_DISP_WDMA>;
iommus = < MT2701_M4U_PORT_DISP_WDMA>;
- mediatek,larb = <>;
};
bls: pwm@1400a000 {
@@ -215,7 +211,6 @@
interrupts = ;
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < MT2701_M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <>;
};
dpi0: dpi@14014000 {
--
2.18.0
[PATCH v10 11/13] memory: mtk-smi: Get rid of mtk_smi_larb_get/put
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
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Reviewed-by: AngeloGioacchino Del Regno
---
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 b883dcc0bbfa..1b348bb93f0b 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -149,20 +149,6 @@ struct mtk_smi_larb { /* larb: local arbiter */
unsigned char *bank;
};
-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
--
2.18.0
[PATCH v10 10/13] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec devices 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_drv.c | 2 -
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 41 +++--
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 2 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 45 +++
7 files changed, 12 insertions(+), 83 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 86b639d82be8..8d11510e441e 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -450,7 +450,6 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
destroy_workqueue(dev->core_workqueue);
err_res:
pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
err_dec_pm:
mtk_vcodec_fw_release(dev->fw_handler);
return ret;
@@ -494,7 +493,6 @@ static int mtk_vcodec_dec_remove(struct platform_device
*pdev)
v4l2_device_unregister(>v4l2_dev);
pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
mtk_vcodec_fw_release(dev->fw_handler);
return 0;
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
index 7b5da3e4cac2..8d2a641d92f1 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
@@ -184,7 +184,6 @@ static int mtk_vdec_hw_probe(struct platform_device *pdev)
return 0;
err:
pm_runtime_disable(subdev_dev->pm.dev);
- put_device(subdev_dev->pm.larbvdec);
return ret;
}
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 44035a50e335..7e0c2644bf7b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include "mtk_vcodec_dec_hw.h"
#include "mtk_vcodec_dec_pm.h"
@@ -17,25 +16,11 @@
int mtk_vcodec_init_dec_clk(struct platform_device *pdev, struct mtk_vcodec_pm
*pm)
{
- struct device_node *node;
- struct platform_device *larb_pdev;
struct mtk_vcodec_clk *dec_clk;
struct mtk_vcodec_clk_info *clk_info;
- int i = 0, ret = 0;
+ int i = 0, ret;
dec_clk = >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;
- }
-
- larb_pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (WARN_ON(!larb_pdev))
- return -1;
-
- pm->larbvdec = _pdev->dev;
pm->dev = >dev;
dec_clk->clk_num =
@@ -44,14 +29,11 @@ int mtk_vcodec_init_dec_clk(struct platform_device *pdev,
struct mtk_vcodec_pm *
dec_clk->clk_info = devm_kcalloc(>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++) {
@@ -60,22 +42,18 @@ int mtk_vcodec_init_dec_clk(struct platform_device *pdev,
struct mtk_vcodec_pm *
"clock-names", i, _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(>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);
}
}
return 0;
-put_device:
- put_device(pm->larbvdec);
-
[PATCH v10 09/13] drm/mediatek: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device calls 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
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 --
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(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ce5bbd6918cf..12c6a2097142 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
@@ -548,22 +547,14 @@ 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) {
- mtk_smi_larb_put(comp->larb_dev);
DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
ret);
return;
}
ret = mtk_crtc_ddp_hw_init(mtk_crtc);
if (ret) {
- mtk_smi_larb_put(comp->larb_dev);
pm_runtime_put(comp->dev);
return;
}
@@ -600,7 +591,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", ret);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 99cbf44463e4..48642e814370 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -414,37 +414,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 = _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;
@@ -460,16 +438,6 @@ int mtk_ddp_comp_init(struct device_node *node, struct
mtk_ddp_comp *comp,
}
comp->dev = _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_AAL ||
type == MTK_DISP_BLS ||
type == MTK_DISP_CCORR ||
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 aec39724ebeb..c234293fc2c3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -603,11
[PATCH v10 08/13] drm/mediatek: Add pm runtime support for ovl and rdma
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
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 +++-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 9 -
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 13 -
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 5326989d5206..716eac6831f2 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,9 +415,13 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}
+ pm_runtime_enable(dev);
+
ret = component_add(dev, _disp_ovl_component_ops);
- if (ret)
+ if (ret) {
+ pm_runtime_disable(dev);
dev_err(dev, "Failed to add component: %d\n", ret);
+ }
return ret;
}
@@ -424,6 +429,7 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
static int mtk_disp_ovl_remove(struct platform_device *pdev)
{
component_del(>dev, _disp_ovl_component_ops);
+ pm_runtime_disable(>dev);
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 75d7f45579e2..251f034acb09 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, _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(>dev, _disp_rdma_component_ops);
+ pm_runtime_disable(>dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index a4e80e499674..ce5bbd6918cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -554,9 +554,17 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
return;
}
+ ret = pm_runtime_resume_and_get(comp->dev);
+ if (ret < 0) {
+ mtk_smi_larb_put(comp->larb_dev);
+ DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
ret);
+ return;
+ }
+
ret = mtk_crtc_ddp_hw_init(mtk_crtc);
if (ret) {
mtk_smi_larb_put(comp->larb_dev);
+ pm_runtime_put(comp->dev);
return;
}
@@ -569,7 +577,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)
@@ -593,6 +601,9 @@ 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;
}
--
2.18.0
[PATCH v10 07/13] media: mtk-mdp: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device calls 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
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 40 ---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 -
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 1 -
3 files changed, 43 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index b3426a551bea..1e3833f1c9ae 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include "mtk_mdp_comp.h"
@@ -18,14 +17,6 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
mtk_mdp_comp *comp)
{
int i, err;
- if (comp->larb_dev) {
- err = mtk_smi_larb_get(comp->larb_dev);
- if (err)
- dev_err(dev,
- "failed to get larb, err %d. type:%d\n",
- err, comp->type);
- }
-
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
if (IS_ERR(comp->clk[i]))
continue;
@@ -46,17 +37,12 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
mtk_mdp_comp *comp)
continue;
clk_disable_unprepare(comp->clk[i]);
}
-
- if (comp->larb_dev)
- mtk_smi_larb_put(comp->larb_dev);
}
int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
struct mtk_mdp_comp *comp,
enum mtk_mdp_comp_type comp_type)
{
- struct device_node *larb_node;
- struct platform_device *larb_pdev;
int ret;
int i;
@@ -77,32 +63,6 @@ int mtk_mdp_comp_init(struct device *dev, struct device_node
*node,
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 put_dev;
- }
-
- 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 put_dev;
- }
- of_node_put(larb_node);
-
- comp->larb_dev = _pdev->dev;
-
return 0;
put_dev:
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 7897766c96bb..ae41dd3cd72a 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -26,14 +26,12 @@ enum mtk_mdp_comp_type {
* @node: list node to track sibing MDP components
* @dev_node: component device node
* @clk: clocks required for component
- * @larb_dev: SMI device required for component
* @type: component type
*/
struct mtk_mdp_comp {
struct list_headnode;
struct device_node *dev_node;
struct clk *clk[2];
- struct device *larb_dev;
enum mtk_mdp_comp_type type;
};
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 976aa1f4829b..70a8eab16863 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include "mtk_mdp_core.h"
#include "mtk_mdp_m2m.h"
--
2.18.0
[PATCH v10 06/13] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device calls 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
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Acked-by: AngeloGioacchino Del Regno
---
.../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 af994b9913a6..1e29ca0aad77 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 = >dev;
-
- ret = devm_clk_bulk_get(jpeg->dev, jpeg->variant->num_clks,
- jpeg->variant->clks);
- if (ret) {
- dev_err(>dev, "failed to get jpeg clock:%d\n", ret);
- put_device(>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;
@@ -1374,7 +1334,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(>dev, "Failed to init clk, err %d\n", ret);
goto err_clk_init;
@@ -1440,7 +1401,6 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
v4l2_device_unregister(>v4l2_dev);
err_dev_register:
- mtk_jpeg_clk_release(jpeg);
err_clk_init:
@@ -1458,7 +1418,6 @@ static int mtk_jpeg_remove(struct platform_device *pdev)
video_device_release(jpeg->vdev);
v4l2_m2m_release(jpeg->m2m_dev);
v4l2_device_unregister(>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;
};
--
2.18.0
[PATCH v10 05/13] iommu/mediatek: Add device_link between the consumer and the larb devices
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.
Meanwhile, Currently we don't have a device connect with 2 larbs at the
same time. Disallow this case, print the error log.
[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
Acked-by: Joerg Roedel
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c| 30 ++
drivers/iommu/mtk_iommu_v1.c | 29 -
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 5cff5bc556d4..77df61092be3 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -562,22 +562,52 @@ 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, larbidx, i;
if (!fwspec || fwspec->ops != _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 that connects with each a larb is a independent HW.
+* All the ports in each a device should be in the same larbs.
+*/
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ for (i = 1; i < fwspec->num_ids; i++) {
+ larbidx = MTK_M4U_TO_LARB(fwspec->ids[i]);
+ if (larbid != larbidx) {
+ dev_err(dev, "Can only use one larb. Fail@larb%d-%d.\n",
+ larbid, larbidx);
+ return ERR_PTR(-EINVAL);
+ }
+ }
+ 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 >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 != _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 4089077256f4..4052aad75a81 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, larbidx;
+ struct device_link *link;
+ struct device *larbdev;
/*
* In the deferred case, free the existed fwspec.
@@ -453,6 +455,23 @@ 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]);
+ for (idx = 1; idx < fwspec->num_ids; idx++) {
+
[PATCH v10 04/13] iommu/mediatek: Add probe_defer for smi-larb
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
Acked-by: Joerg Roedel
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c| 4
drivers/iommu/mtk_iommu_v1.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 77ae20ff9b35..5cff5bc556d4 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -850,6 +850,10 @@ static int mtk_iommu_probe(struct platform_device *pdev)
of_node_put(larbnode);
return -ENODEV;
}
+ if (!plarbdev->dev.driver) {
+ of_node_put(larbnode);
+ return -EPROBE_DEFER;
+ }
data->larb_imu[id].dev = >dev;
component_match_add_release(dev, , release_of,
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 68bf02f87cfd..4089077256f4 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -606,6 +606,10 @@ static int mtk_iommu_probe(struct platform_device *pdev)
of_node_put(larbnode);
return -ENODEV;
}
+ if (!plarbdev->dev.driver) {
+ of_node_put(larbnode);
+ return -EPROBE_DEFER;
+ }
data->larb_imu[i].dev = >dev;
component_match_add_release(dev, , release_of,
--
2.18.0
[PATCH v10 03/13] iommu/mediatek: Return ENODEV if the device is NULL
The platform device is created at:
of_platform_default_populate_init: arch_initcall_sync
->of_platform_populate
->of_platform_device_create_pdata
When entering our probe, all the devices should be already created.
if it is null, means NODEV. Currently we don't get the fail case.
It's a minor fix, no need add fixes tags.
Signed-off-by: Yong Wu
Acked-by: Joerg Roedel
Reviewed-by: AngeloGioacchino Del Regno
---
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 25b834104790..77ae20ff9b35 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -848,7 +848,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
plarbdev = of_find_device_by_node(larbnode);
if (!plarbdev) {
of_node_put(larbnode);
- return -EPROBE_DEFER;
+ return -ENODEV;
}
data->larb_imu[id].dev = >dev;
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 1467ba1e4417..68bf02f87cfd 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -604,7 +604,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
plarbdev = of_find_device_by_node(larbnode);
if (!plarbdev) {
of_node_put(larbnode);
- return -EPROBE_DEFER;
+ return -ENODEV;
}
data->larb_imu[i].dev = >dev;
--
2.18.0
[PATCH v10 02/13] iommu/mediatek-v1: Free the existed fwspec if the master dev already has
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_init) from []
(of_iommu_xlate+0x7c/0x12c)
[] (of_iommu_xlate) from []
(of_iommu_configure+0x144/0x1e8)
BUT the mtk_iommu_v1.c only supports arm32, the probing flow still is a bit
weird. We always expect create the fwspec internally. otherwise it will
enter here and return fail.
static int mtk_iommu_create_mapping(struct device *dev,
struct of_phandle_args *args)
{
...
if (!fwspec) {
} else if (dev_iommu_fwspec_get(dev)->ops != _iommu_ops) {
>>Enter here. return fail.
return -EINVAL;
}
...
}
Thus, Free the existed fwspec if the master device already has fwspec.
This issue is reported at:
https://lore.kernel.org/linux-mediatek/trinity-7d9ebdc9-4849-4d93-bfb5-429dcb4ee449-1626253158870@3c-app-gmx-bs01/
Reported-by: Frank Wunderlich
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Signed-off-by: Yong Wu
Acked-by: Joerg Roedel
Acked-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu_v1.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index be22fcf988ce..1467ba1e4417 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -425,6 +425,15 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
struct mtk_iommu_data *data;
int err, idx = 0;
+ /*
+* In the deferred case, free the existed fwspec.
+* Always initialize the fwspec internally.
+*/
+ if (fwspec) {
+ iommu_fwspec_free(dev);
+ fwspec = dev_iommu_fwspec_get(dev);
+ }
+
while (!of_parse_phandle_with_args(dev->of_node, "iommus",
"#iommu-cells",
idx, _spec)) {
--
2.18.0
[PATCH v10 01/13] dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW
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 this 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
Acked-by: AngeloGioacchino Del Regno
---
.../bindings/display/mediatek/mediatek,disp.txt | 9 -
.../bindings/media/mediatek,vcodec-decoder.yaml | 7 ---
.../bindings/media/mediatek,vcodec-encoder.yaml | 8
.../devicetree/bindings/media/mediatek-jpeg-decoder.yaml | 9 -
.../devicetree/bindings/media/mediatek-jpeg-encoder.yaml | 9 -
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 8
6 files changed, 50 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 78044c340e20..8b575e11bcec 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 = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL0>;
iommus = < M4U_PORT_DISP_OVL0>;
- mediatek,larb = <>;
};
ovl1: ovl@1400d000 {
@@ -101,7 +98,6 @@ ovl1: ovl@1400d000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OVL1>;
iommus = < M4U_PORT_DISP_OVL1>;
- mediatek,larb = <>;
};
rdma0: rdma@1400e000 {
@@ -111,7 +107,6 @@ rdma0: rdma@1400e000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA0>;
iommus = < M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <>;
mediatek,rdma-fifosize = <8192>;
};
@@ -122,7 +117,6 @@ rdma1: rdma@1400f000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA1>;
iommus = < M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <>;
};
rdma2: rdma@1401 {
@@ -132,7 +126,6 @@ rdma2: rdma@1401 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_RDMA2>;
iommus = < M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <>;
};
wdma0: wdma@14011000 {
@@ -142,7 +135,6 @@ wdma0: wdma@14011000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA0>;
iommus = < M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <>;
};
wdma1: wdma@14012000 {
@@ -152,7 +144,6 @@ wdma1: wdma@14012000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_WDMA1>;
iommus = < M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <>;
};
color0: color@14013000 {
diff --git
a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
index df1d677098fd..9b179bb44dfb 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
@@ -61,12 +61,6 @@ properties:
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
@@ -137,7 +131,6 @@ examples:
<0x16027800 0x800>, /*VP8_VL*/
<0x16028400 0x400>; /*VP9_VD*/
interrupts = ;
- mediatek,larb = <>;
iommus = < M4U_PORT_HW_VDEC_MC_EXT>,
< M4U_PORT_HW_VDEC_PP_EXT>,
< M4U_PORT_HW_VDEC_AVC_MV_EXT>,
diff --git
a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index b72c1a50e89e..e7b65a91c92c 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -53,12 +53,6 @@ properties:
description: |
Describes the physical address space of IOMMU maps to memory.
- mediatek,larb:
-$ref: /schemas/types.yaml#/definitions/phandle
-maxItems: 1
-
[PATCH v10 00/13] Clean up "mediatek,larb"
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. Base on the media branch [1] and a jpeg dtbinding patchset[2] that already got the necessary R-b. [1] git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.18d [2] https://lore.kernel.org/linux-mediatek/20211206130425.184420-1-hsi...@chromium.org/ Change notes: v10: a) Rebase on the media tree. Respin the "media: mtk-vcodec:" patches. b) Add Joerg's Ack for iommu patches. v9: https://lore.kernel.org/linux-mediatek/2022105509.12010-1-yong...@mediatek.com/ 1) Add return -ENODEV when the dev is null. 2) Add more strict about the case that a iommu consume device use the ports in different larbs. Don't allow this case. 3) Remove two codec interface: mtk_vcodec_release_enc/dec_pm since it only has one line now. v8: https://lore.kernel.org/linux-mediatek/20210929013719.25120-1-yong...@mediatek.com/ 1) Rebase on v5.15-rc1. 2) Don't rebase the below mdp patchset that may still need more discuss. https://lore.kernel.org/linux-mediatek/20210709022324.1607884-1-ei...@chromium.org/ 3) Add Frank's Tested-by. Remove Dafna's Tested-by as he requested. v7: https://lore.kernel.org/linux-mediatek/20210730025238.22456-1-yong...@mediatek.com/ 1) Fix a arm32 boot fail issue. reported from Frank. 2) Add a return fail in the mtk drm. suggested by Dafna. v6: https://lore.kernel.org/linux-mediatek/20210714025626.5528-1-yong...@mediatek.com/ 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 (12): dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW iommu/mediatek-v1: Free the existed fwspec if the master dev already has iommu/mediatek: Return ENODEV if the device is NULL 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 .../media/mediatek,vcodec-decoder.yaml| 7 --- .../media/mediatek,vcodec-encoder.yaml| 8 .../bindings/media/mediatek-jpeg-decoder.yaml | 9 .../bindings/media/mediatek-jpeg-encoder.yaml | 9 .../bindings/media/mediatek-mdp.txt | 8 arch/arm/boot/dts/mt2701.dtsi
Re: [GIT PULL] fbdev updates for v5.17-rc1
The pull request you sent on Sun, 16 Jan 2022 20:31:09 +0100: > http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > tags/fbdev-5.17-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3c750c7b614322a4ab50be0d57a76addb598d51d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH v3] drm: bridge: fix unmet dependency on DRM_KMS_HELPER for DRM_PANEL_BRIDGE
When DRM_CHIPONE_ICN6211 is selected, and DRM_KMS_HELPER is not selected,
Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE
Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n]
Selected by [y]:
- DRM_CHIPONE_ICN6211 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y]
&& OF [=y]
This is because DRM_CHIPONE_ICN6211 selects DRM_PANEL_BRIDGE
without depending on or selecting DRM_KMS_HELPER,
despite DRM_PANEL_BRIDGE depending on DRM_KMS_HELPER.
This unmet dependency bug was detected by Kismet,
a static analysis tool for Kconfig.
Please advise if this is not the appropriate solution.
Fixes: ce517f18944e ("drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB bridge")
Reviewed-by: Robert Foss
Reviewed-by: Laurent Pinchart
Signed-off-by: Julian Braha
---
v2:
- changed from "select" to "depends on"
v3:
- new line now uses tabs instead of spaces.
drivers/gpu/drm/bridge/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 61db5a66b493..a1b52eaf26e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -30,6 +30,7 @@ config DRM_CDNS_DSI
config DRM_CHIPONE_ICN6211
tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
depends on OF
+ depends on DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
help
--
2.32.0
Re: [RFC PATCH v3 2/3] drm: add support modifiers for drivers whose planes only support linear layout
Thank you for your reviews.
On 2022/01/14 23:16, Andy Shevchenko wrote:
On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers.
...
+ const uint64_t default_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+ Comma?
There is no mention in the coding style about adding/removing a comma to
the last element of an array. Is there a policy in drm driver?
I think the advantage of adding a comma to the last element of an array
is that diff is only one line when an element is added to the end.
However since INVALID is always the last element in the modifiers array,
I think it can be either in this case.
If there is a policy, I will match it.
Thanks,
Tomohito Esaki
Re: [GIT PULL] fbdev updates for v5.17-rc1
On Sun, Jan 16, 2022 at 9:32 PM Helge Deller wrote: > > This pull request contains only one single initial patch which adds > myself to the MAINTAINERS file for the FRAMBUFFER LAYER. I'll pull this (as my test builds for other things complete), but this is just a note to say that this pull request email was marked as spam for me, with gmail saying something along the lines of "lots of emails from gmx.de have been marked as spam" I see nothing odd in the email itself, and it has proper SPF and DKIM, but it's possible that you end up sharing a subnet (or an ISP) with spammers... Or maybe it was a random one-off. We'll see. I check spam filters enough that I _usually_ tend to catch these things. Linus
Re: [PATCH 4/4] drm/bridge: tc358767: Add DSI-to-DPI mode support
On 11/27/21 04:24, Marek Vasut wrote: The TC358767/TC358867/TC9595 are all capable of operating in multiple modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Add support for the DSI-to-DPI mode. This requires skipping most of the (e)DP initialization code, which is currently a large part of this driver, hence it is better to have far simpler separate tc_dpi_bridge_funcs and their implementation. The configuration of DPI output is also much simpler. The configuration of the DSI input is rather similar to the other TC bridge chips. The Pixel PLL in DPI output mode does not have the 65..150 MHz limitation imposed on the (e)DP output mode, so this limitation is skipped to permit operating panels with far slower pixel clock, even below 9 MHz. This mode of operation of the PLL is valid and tested. The detection of bridge mode is now added into tc_probe_bridge_mode(), where in case a DPI panel is found on port@1 endpoint@1, the mode is assumed to be DSI-to-DPI. If (e)DP is detected on port@2, the mode is assumed to be DPI-to-(e)DP. The DSI-to-(e)DP mode is not supported due to lack of proper hardware, but this would be some sort of mix between the two aforementioned modes. [...] Would it be possible to get some feedback on this patchset ?
Re: [RFC PATH 1/3] drm: add support modifiers for drivers whose planes only support linear layout
Thank you for your reviews.
On 2022/01/15 1:50, Daniel Vetter wrote:
On Wed, Dec 22, 2021 at 02:27:25PM +0900, Tomohito Esaki wrote:
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers. However, there are legacy drivers such as radeon that do not
support modifiers but infer the actual layout of the underlying buffer.
Therefore, a new flag not_support_fb_modifires is introduced for these
legacy drivers. Allow_fb_modifiers will be replaced with this new flag.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/drm_plane.c | 34 ++
include/drm/drm_mode_config.h | 10 ++
include/drm/drm_plane.h | 3 +++
3 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 82afb854141b..75308ee240c0 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -161,6 +161,16 @@ modifiers_ptr(struct drm_format_modifier_blob *blob)
return (struct drm_format_modifier *)(((char *)blob) +
blob->modifiers_offset);
}
+static bool check_format_modifier(struct drm_plane *plane, uint32_t format,
+ uint64_t modifier)
+{
+ if (plane->funcs->format_mod_supported)
+ return plane->funcs->format_mod_supported(plane, format,
+ modifier);
+
+ return modifier == DRM_FORMAT_MOD_LINEAR;
+}
+
static int create_in_format_blob(struct drm_device *dev, struct drm_plane
*plane)
{
const struct drm_mode_config *config = >mode_config;
@@ -203,16 +213,15 @@ static int create_in_format_blob(struct drm_device *dev,
struct drm_plane *plane
memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
/* If we can't determine support, just bail */
- if (!plane->funcs->format_mod_supported)
+ if (config->fb_modifiers_not_supported)
goto done;
mod = modifiers_ptr(blob_data);
for (i = 0; i < plane->modifier_count; i++) {
for (j = 0; j < plane->format_count; j++) {
- if (plane->funcs->format_mod_supported(plane,
-
plane->format_types[j],
-
plane->modifiers[i])) {
-
+ if (check_format_modifier(plane,
+ plane->format_types[j],
+ plane->modifiers[i])) {
mod->formats |= 1ULL << j;
}
}
@@ -242,6 +251,10 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
const char *name, va_list ap)
{
struct drm_mode_config *config = >mode_config;
+ const uint64_t default_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+ };
unsigned int format_modifier_count = 0;
int ret;
@@ -282,6 +295,11 @@ static int __drm_universal_plane_init(struct drm_device *dev,
while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
format_modifier_count++;
+ } else {
+ if (!dev->mode_config.fb_modifiers_not_supported) {
+ format_modifiers = default_modifiers;
+ format_modifier_count = 1;
+ }
}
/* autoset the cap and check for consistency across all planes */
@@ -346,7 +364,7 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
drm_object_attach_property(>base, config->prop_src_h, 0);
}
- if (config->allow_fb_modifiers)
+ if (format_modifier_count)
create_in_format_blob(dev, plane);
return 0;
@@ -373,8 +391,8 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
* drm_universal_plane_init() to let the DRM managed resource infrastructure
* take care of cleanup and deallocation.
*
- * Drivers supporting modifiers must set @format_modifiers on all their planes,
- * even those that only support DRM_FORMAT_MOD_LINEAR.
+ * For drivers supporting modifiers, all planes will advertise
+ * DRM_FORMAT_MOD_LINEAR support, if @format_modifiers is not set.
*
* Returns:
* Zero on success, error code on failure.
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 48b7de80daf5..c56f298c55bd 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -920,6 +920,16 @@ struct drm_mode_config {
*/
bool allow_fb_modifiers;
+ /**
+* @fb_modifiers_not_supported:
+*
+* This flag is for legacy drivers such as radeon that do not support
Maybe don't put specific driver names into kerneldoc (in commit message to
motivate your changes it's fine). It's unlikely
RE: [PATCH 1/1] video: hyperv_fb: Fix validation of screen resolution
> -Original Message-
> From: Michael Kelley (LINUX)
> Sent: Sunday, January 16, 2022 2:19 PM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen
> Hemminger ; wei@kernel.org; Wei Hu
> ; Dexuan
> Cui ; drawat.fl...@gmail.com; hhei ;
> linux-
> ker...@vger.kernel.org; linux-hyp...@vger.kernel.org;
> linux-fb...@vger.kernel.org; dri-
> de...@lists.freedesktop.org
> Cc: Michael Kelley (LINUX)
> Subject: [PATCH 1/1] video: hyperv_fb: Fix validation of screen resolution
>
> In the WIN10 version of the Synthetic Video protocol with Hyper-V,
> Hyper-V reports a list of supported resolutions as part of the protocol
> negotiation. The driver calculates the maximum width and height from
> the list of resolutions, and uses those maximums to validate any screen
> resolution specified in the video= option on the kernel boot line.
>
> This method of validation is incorrect. For example, the list of
> supported resolutions could contain 1600x1200 and 1920x1080, both of
> which fit in an 8 Mbyte frame buffer. But calculating the max width
> and height yields 1920 and 1200, and 1920x1200 resolution does not fit
> in an 8 Mbyte frame buffer. Unfortunately, this resolution is accepted,
> causing a kernel fault when the driver accesses memory outside the
> frame buffer.
>
> Instead, validate the specified screen resolution by calculating
> its size, and comparing against the frame buffer size. Delete the
> code for calculating the max width and height from the list of
> resolutions, since these max values have no use. Also add the
> frame buffer size to the info message to aid in understanding why
> a resolution might be rejected.
>
> Fixes: 67e7cdb4829d ("video: hyperv: hyperv_fb: Obtain screen resolution from
> Hyper-V
> host")
> Signed-off-by: Michael Kelley
> ---
> drivers/video/fbdev/hyperv_fb.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index 23999df..c8e0ea2 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -287,8 +287,6 @@ struct hvfb_par {
>
> static uint screen_width = HVFB_WIDTH;
> static uint screen_height = HVFB_HEIGHT;
> -static uint screen_width_max = HVFB_WIDTH;
> -static uint screen_height_max = HVFB_HEIGHT;
> static uint screen_depth;
> static uint screen_fb_size;
> static uint dio_fb_size; /* FB size for deferred IO */
> @@ -582,7 +580,6 @@ static int synthvid_get_supported_resolution(struct
> hv_device *hdev)
> int ret = 0;
> unsigned long t;
> u8 index;
> - int i;
>
> memset(msg, 0, sizeof(struct synthvid_msg));
> msg->vid_hdr.type = SYNTHVID_RESOLUTION_REQUEST;
> @@ -613,13 +610,6 @@ static int synthvid_get_supported_resolution(struct
> hv_device *hdev)
> goto out;
> }
>
> - for (i = 0; i < msg->resolution_resp.resolution_count; i++) {
> - screen_width_max = max_t(unsigned int, screen_width_max,
> - msg->resolution_resp.supported_resolution[i].width);
> - screen_height_max = max_t(unsigned int, screen_height_max,
> - msg->resolution_resp.supported_resolution[i].height);
> - }
> -
> screen_width =
> msg->resolution_resp.supported_resolution[index].width;
> screen_height =
> @@ -941,7 +931,7 @@ static void hvfb_get_option(struct fb_info *info)
>
> if (x < HVFB_WIDTH_MIN || y < HVFB_HEIGHT_MIN ||
> (synthvid_ver_ge(par->synthvid_version, SYNTHVID_VERSION_WIN10) &&
> - (x > screen_width_max || y > screen_height_max)) ||
> + (x * y * screen_depth / 8 > screen_fb_size)) ||
> (par->synthvid_version == SYNTHVID_VERSION_WIN8 &&
>x * y * screen_depth / 8 > SYNTHVID_FB_SIZE_WIN8) ||
> (par->synthvid_version == SYNTHVID_VERSION_WIN7 &&
> @@ -1194,8 +1184,8 @@ static int hvfb_probe(struct hv_device *hdev,
> }
>
> hvfb_get_option(info);
> - pr_info("Screen resolution: %dx%d, Color depth: %d\n",
> - screen_width, screen_height, screen_depth);
> + pr_info("Screen resolution: %dx%d, Color depth: %d, Frame buffer size:
> %d\n",
> + screen_width, screen_height, screen_depth, screen_fb_size);
>
> ret = hvfb_getmem(hdev, info);
> if (ret) {
Thank you!
Reviewed-by: Haiyang Zhang
[Bug 215499] AMDGPU: Tahiti flagged as "[drm] Unsupported asic. Remove me when IP discovery init is in place."
https://bugzilla.kernel.org/show_bug.cgi?id=215499 --- Comment #1 from Alexandre Demers (alexandre.f.dem...@gmail.com) --- Also, the kernel provided by ArchLinux is built with CONFIG_DRM_AMDGPU_SI=y -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 215499] AMDGPU: Tahiti flagged as "[drm] Unsupported asic. Remove me when IP discovery init is in place."
https://bugzilla.kernel.org/show_bug.cgi?id=215499 Alexandre Demers (alexandre.f.dem...@gmail.com) changed: What|Removed |Added CC||alexandre.f.dem...@gmail.co ||m, alexdeuc...@gmail.com Regression|No |Yes -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 215499] New: AMDGPU: Tahiti flagged as "[drm] Unsupported asic. Remove me when IP discovery init is in place."
https://bugzilla.kernel.org/show_bug.cgi?id=215499 Bug ID: 215499 Summary: AMDGPU: Tahiti flagged as "[drm] Unsupported asic. Remove me when IP discovery init is in place." Product: Drivers Version: 2.5 Kernel Version: 5.16 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: alexandre.f.dem...@gmail.com Regression: No Until kernel 5.16, using a Tahiti GPU was working great along the amdgpu driver. With the move to IP discovery table, Tahiti is listed as not supported. Here, both kernels 5.15.2 and 5.16 are launched with the following parameters: radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.dpm=1 amdgpu.dc=1 amdgpu.ppfeaturemask=0x This is what's reported by amdgpu since kernel 5.16 related to the IP discovery table integration: --- jan 15 20:23:04 Xander kernel: [drm] radeon kernel modesetting enabled. jan 15 20:23:04 Xander kernel: radeon :04:00.0: SI support disabled by module param jan 15 20:23:04 Xander kernel: [drm] amdgpu kernel modesetting enabled. jan 15 20:23:04 Xander kernel: amdgpu: Ignoring ACPI CRAT on non-APU system jan 15 20:23:04 Xander kernel: amdgpu: Virtual CRAT table created for CPU jan 15 20:23:04 Xander kernel: amdgpu: Topology: Add CPU node jan 15 20:23:04 Xander kernel: [drm] Unsupported asic. Remove me when IP discovery init is in place. ... This is what was reported prior, in version 5.15.2: --- déc 11 16:30:33 Xander kernel: [drm] radeon kernel modesetting enabled. déc 11 16:30:33 Xander kernel: radeon :04:00.0: SI support disabled by module param déc 11 16:30:33 Xander kernel: [drm] amdgpu kernel modesetting enabled. déc 11 16:30:33 Xander kernel: amdgpu: Ignoring ACPI CRAT on non-APU system déc 11 16:30:33 Xander kernel: amdgpu: Virtual CRAT table created for CPU déc 11 16:30:33 Xander kernel: amdgpu: Topology: Add CPU node déc 11 16:30:33 Xander kernel: checking generic (e000 7f) vs hw (e000 1000) déc 11 16:30:33 Xander kernel: fb0: switching to amdgpu from EFI VGA déc 11 16:30:33 Xander kernel: Console: switching to colour dummy device 80x25 déc 11 16:30:33 Xander kernel: amdgpu :04:00.0: vgaarb: deactivate vga console déc 11 16:30:33 Xander kernel: [drm] initializing kernel modesetting (TAHITI 0x1002:0x6798 0x174B:0x3001 0x00). déc 11 16:30:33 Xander kernel: amdgpu :04:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported déc 11 16:30:33 Xander kernel: [drm] register mmio base: 0xFCA0 déc 11 16:30:33 Xander kernel: [drm] register mmio size: 262144 déc 11 16:30:33 Xander kernel: [drm] PCIE atomic ops is not supported déc 11 16:30:33 Xander kernel: [drm] add ip block number 0 déc 11 16:30:33 Xander kernel: [drm] add ip block number 1 déc 11 16:30:33 Xander kernel: [drm] add ip block number 2 déc 11 16:30:33 Xander kernel: [drm] add ip block number 3 déc 11 16:30:33 Xander kernel: [drm] add ip block number 4 déc 11 16:30:33 Xander kernel: [drm] add ip block number 5 déc 11 16:30:33 Xander kernel: [drm] add ip block number 6 déc 11 16:30:33 Xander kernel: [drm] add ip block number 7 ... Moving to IP discovery table shouldn't remove support to any already supported ASIC, even if this doesn't add any new feature. Is this expected? Is the support to be added? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[GIT PULL] fbdev updates for v5.17-rc1
Hi Linus, The fbdev layer is orphaned, but seems to need some care. So I'd like to step up as new maintainer. This pull request contains only one single initial patch which adds myself to the MAINTAINERS file for the FRAMBUFFER LAYER. This was Acked-by: Geert Uytterhoeven Thanks, Helge The following changes since commit df0cc57e057f18e44dac8e6c18aba47ab53202f9: Linux 5.16 (2022-01-09 14:55:34 -0800) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-5.17-1 for you to fetch changes up to f346f32701ebacf6fe397f6f1d254256f73da321: MAINTAINERS: Add Helge as fbdev maintainer (2022-01-14 21:49:23 +0100) fbdev updates for v5.17-rc1 Add me as maintainer for the framebuffer code. Helge Deller (1): MAINTAINERS: Add Helge as fbdev maintainer MAINTAINERS | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)
[PATCH 1/1] video: hyperv_fb: Fix validation of screen resolution
In the WIN10 version of the Synthetic Video protocol with Hyper-V,
Hyper-V reports a list of supported resolutions as part of the protocol
negotiation. The driver calculates the maximum width and height from
the list of resolutions, and uses those maximums to validate any screen
resolution specified in the video= option on the kernel boot line.
This method of validation is incorrect. For example, the list of
supported resolutions could contain 1600x1200 and 1920x1080, both of
which fit in an 8 Mbyte frame buffer. But calculating the max width
and height yields 1920 and 1200, and 1920x1200 resolution does not fit
in an 8 Mbyte frame buffer. Unfortunately, this resolution is accepted,
causing a kernel fault when the driver accesses memory outside the
frame buffer.
Instead, validate the specified screen resolution by calculating
its size, and comparing against the frame buffer size. Delete the
code for calculating the max width and height from the list of
resolutions, since these max values have no use. Also add the
frame buffer size to the info message to aid in understanding why
a resolution might be rejected.
Fixes: 67e7cdb4829d ("video: hyperv: hyperv_fb: Obtain screen resolution from
Hyper-V host")
Signed-off-by: Michael Kelley
---
drivers/video/fbdev/hyperv_fb.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 23999df..c8e0ea2 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -287,8 +287,6 @@ struct hvfb_par {
static uint screen_width = HVFB_WIDTH;
static uint screen_height = HVFB_HEIGHT;
-static uint screen_width_max = HVFB_WIDTH;
-static uint screen_height_max = HVFB_HEIGHT;
static uint screen_depth;
static uint screen_fb_size;
static uint dio_fb_size; /* FB size for deferred IO */
@@ -582,7 +580,6 @@ static int synthvid_get_supported_resolution(struct
hv_device *hdev)
int ret = 0;
unsigned long t;
u8 index;
- int i;
memset(msg, 0, sizeof(struct synthvid_msg));
msg->vid_hdr.type = SYNTHVID_RESOLUTION_REQUEST;
@@ -613,13 +610,6 @@ static int synthvid_get_supported_resolution(struct
hv_device *hdev)
goto out;
}
- for (i = 0; i < msg->resolution_resp.resolution_count; i++) {
- screen_width_max = max_t(unsigned int, screen_width_max,
- msg->resolution_resp.supported_resolution[i].width);
- screen_height_max = max_t(unsigned int, screen_height_max,
- msg->resolution_resp.supported_resolution[i].height);
- }
-
screen_width =
msg->resolution_resp.supported_resolution[index].width;
screen_height =
@@ -941,7 +931,7 @@ static void hvfb_get_option(struct fb_info *info)
if (x < HVFB_WIDTH_MIN || y < HVFB_HEIGHT_MIN ||
(synthvid_ver_ge(par->synthvid_version, SYNTHVID_VERSION_WIN10) &&
- (x > screen_width_max || y > screen_height_max)) ||
+ (x * y * screen_depth / 8 > screen_fb_size)) ||
(par->synthvid_version == SYNTHVID_VERSION_WIN8 &&
x * y * screen_depth / 8 > SYNTHVID_FB_SIZE_WIN8) ||
(par->synthvid_version == SYNTHVID_VERSION_WIN7 &&
@@ -1194,8 +1184,8 @@ static int hvfb_probe(struct hv_device *hdev,
}
hvfb_get_option(info);
- pr_info("Screen resolution: %dx%d, Color depth: %d\n",
- screen_width, screen_height, screen_depth);
+ pr_info("Screen resolution: %dx%d, Color depth: %d, Frame buffer size:
%d\n",
+ screen_width, screen_height, screen_depth, screen_fb_size);
ret = hvfb_getmem(hdev, info);
if (ret) {
--
1.8.3.1
[PATCH] drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
The function performs a check on the "phy" input parameter, however, it
is used before the check.
Initialize the "dev" variable after the sanity check to avoid a possible
NULL pointer dereference.
Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files")
Addresses-Coverity-ID: 1493860 ("Null pointer dereference")
Signed-off-by: José Expósito
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 9842e04b5858..baa6af0c3bcc 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -808,12 +808,14 @@ int msm_dsi_phy_enable(struct msm_dsi_phy *phy,
struct msm_dsi_phy_clk_request *clk_req,
struct msm_dsi_phy_shared_timings *shared_timings)
{
- struct device *dev = >pdev->dev;
+ struct device *dev;
int ret;
if (!phy || !phy->cfg->ops.enable)
return -EINVAL;
+ dev = >pdev->dev;
+
ret = dsi_phy_enable_resource(phy);
if (ret) {
DRM_DEV_ERROR(dev, "%s: resource enable failed, %d\n",
--
2.25.1
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
Hi Tommaso, On Sat, Jan 15, 2022 at 8:23 PM Tommaso Merciai wrote: > Hi Fabio, > I'm working on bring up urt,umsh-8596md-20t lvds kit panel, but after enable > following node I get the following error: I assume you are trying to connect an external panel via connector CN3. This connector is for LVDS panel, not parallel. The eLCDIF parallel interface is connected to the TDA19988. Anyway, this is a different topic. My goal here is to fix the kernel warning when using the TDA19988 HDMI output. Thanks
[Bug 215492] amdgpu si_support no longer working in 5.16
https://bugzilla.kernel.org/show_bug.cgi?id=215492 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
