[PATCH V3 RESEND] drm/i915: Fix "mitigations" parsing if i915 is builtin
I met below error during boot with i915 builtin if pass
"i915.mitigations=off":
[0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
The reason is slab subsystem isn't ready at that time, so kstrdup()
returns NULL. Fix this issue by using stack var instead of kstrdup().
Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
mitigations")
Signed-off-by: Jisheng Zhang
---
Since v2:
- Use strscpy() per Ville's suggestion
Since v1:
- Ensure "str" is properly terminated. Thanks Ville for pointing this out
drivers/gpu/drm/i915/i915_mitigations.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
b/drivers/gpu/drm/i915/i915_mitigations.c
index 84f12598d145..70944764a77e 100644
--- a/drivers/gpu/drm/i915/i915_mitigations.c
+++ b/drivers/gpu/drm/i915/i915_mitigations.c
@@ -29,15 +29,13 @@ bool i915_mitigate_clear_residuals(void)
static int mitigations_set(const char *val, const struct kernel_param *kp)
{
unsigned long new = ~0UL;
- char *str, *sep, *tok;
+ char str[64], *sep, *tok;
bool first = true;
int err = 0;
BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
- str = kstrdup(val, GFP_KERNEL);
- if (!str)
- return -ENOMEM;
+ strscpy(str, val, sizeof(str));
for (sep = str; (tok = strsep(&sep, ","));) {
bool enable = true;
@@ -86,7 +84,6 @@ static int mitigations_set(const char *val, const struct
kernel_param *kp)
break;
}
}
- kfree(str);
if (err)
return err;
--
2.31.0
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #18 from Jerome C (m...@jeromec.com) --- (In reply to Alex Deucher from comment #17) > I don't think we've been able to reproduce it. That said, we did double > check the programmign sequences and I believe it may be fixed with these > patches: > https://gitlab.freedesktop.org/agd5f/linux/-/commit/ > 71efc8701a47aa9e3de74bab06020da81757893f > https://gitlab.freedesktop.org/agd5f/linux/-/commit/ > a8f768874aaf751738a2e0350bf2e70085f93ace I've tried these two commits and the issue still there unfortunately -- 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 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #17 from Alex Deucher (alexdeuc...@gmail.com) --- I don't think we've been able to reproduce it. That said, we did double check the programmign sequences and I believe it may be fixed with these patches: https://gitlab.freedesktop.org/agd5f/linux/-/commit/71efc8701a47aa9e3de74bab06020da81757893f https://gitlab.freedesktop.org/agd5f/linux/-/commit/a8f768874aaf751738a2e0350bf2e70085f93ace -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH -next] drm/panfrost: Fix PM reference leak in panfrost_job_hw_submit()
Hi Steven, Thanks for your review and also answer my doubts. Looking forward to your patch. On 2021/5/12 23:23, Steven Price wrote: On 11/05/2021 07:29, Zou Wei wrote: pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Zou Wei Thanks for the patch, but this is actually incorrect. panfrost_job_hw_submit() is expected to unconditionally increment the pm usage counter. This is because panfrost_job_hw_submit() can (currently) never fail, so in this case the job is considered "submitted" (even though it never reaches the hardware) and it's handled by the job timeout. However this is at least the second time[1] this phantom "reference leak" has been raised, so perhaps it's time to handle this better. I'll post a patch reworking panfrost_job_hw_submit() so it can fail. Thanks, Steve [1] https://lore.kernel.org/r/20200520110504.24388-1-dinghao.liu%40zju.edu.cn --- drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index 6003cfe..42d8dbc 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -157,7 +157,7 @@ static void panfrost_job_hw_submit(struct panfrost_job *job, int js) panfrost_devfreq_record_busy(&pfdev->pfdevfreq); - ret = pm_runtime_get_sync(pfdev->dev); + ret = pm_runtime_resume_and_get(pfdev->dev); if (ret < 0) return; .
[PATCH 5/5] drm/msm/a6xx: add a660 hwcg table
Add a660 hwcg table, ported over from downstream.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 53 ++
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 2 +-
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 261a20076f9d..d9753c62035c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -427,6 +427,59 @@ const struct adreno_reglist a650_hwcg[] = {
{},
};
+const struct adreno_reglist a660_hwcg[] = {
+ {REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0220},
+ {REG_A6XX_RBBM_CLOCK_DELAY_SP0, 0x0080},
+ {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xF3CF},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL4_TP0, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY4_TP0, 0x0001},
+ {REG_A6XX_RBBM_CLOCK_HYST_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST4_TP0, 0x0007},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RB0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RB0, 0x0100},
+ {REG_A6XX_RBBM_CLOCK_CNTL_CCU0, 0x2220},
+ {REG_A6XX_RBBM_CLOCK_HYST_RB_CCU0, 0x00040F00},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RAC, 0x25222022},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RAC, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_RAC, 0x0011},
+ {REG_A6XX_RBBM_CLOCK_HYST_RAC, 0x00445044},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TSE_RAS_RBBM, 0x0422},
+ {REG_A6XX_RBBM_CLOCK_MODE_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_MODE_GPC, 0x0022},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ_2, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_MODE_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TSE_RAS_RBBM, 0x4000},
+ {REG_A6XX_RBBM_CLOCK_DELAY_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GPC, 0x0200},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_TSE_RAS_RBBM, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_GPC, 0x04104004},
+ {REG_A6XX_RBBM_CLOCK_HYST_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TEX_FCHE, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TEX_FCHE, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_TEX_FCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_UCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_UCHE, 0x0004},
+ {REG_A6XX_RBBM_CLOCK_DELAY_UCHE, 0x0002},
+ {REG_A6XX_RBBM_ISDB_CNT, 0x0182},
+ {REG_A6XX_RBBM_RAC_THRESHOLD_CNT, 0x},
+ {REG_A6XX_RBBM_SP_HYST_CNT, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x0555},
+ {},
+};
+
static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index e4db0683d381..6dad8015c9a1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -299,6 +299,7 @@ static const struct adreno_info gpulist[] = {
.inactive_period = DRM_MSM_INACTIVE_PERIOD,
.init = a6xx_gpu_init,
.zapfw = "a660_zap.mdt",
+ .hwcg = a660_hwcg,
},
};
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 63c050919d85..e6b11e6ec82d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -55,7 +55,7 @@ struct adreno_reglist {
u32 value;
};
-extern const struct adreno_reglist a630_hwcg[], a640_hwcg[], a650_hwcg[];
+extern const struct adreno_reglist a630_hwcg[], a640_hwcg[], a650_hwcg[],
a660_hwcg[];
struct adreno_info {
struct adreno_rev rev;
--
2.26.1
[PATCH 4/5] drm/msm/a6xx: update a6xx_ucode_check_version for a660
Accept all SQE firmware versions for A660.
Re-organize the function a bit and print an error message for unexpected
GPU IDs instead of failing silently.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 36 +--
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 4467273e66c0..261a20076f9d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -541,6 +541,11 @@ static bool a6xx_ucode_check_version(struct a6xx_gpu
*a6xx_gpu,
* Targets up to a640 (a618, a630 and a640) need to check for a
* microcode version that is patched to support the whereami opcode or
* one that is new enough to include it by default.
+*
+* a650 tier targets don't need whereami but still need to be
+* equal to or newer than 0.95 for other security fixes
+*
+* a660 targets have all the critical security fixes from the start
*/
if (adreno_is_a618(adreno_gpu) || adreno_is_a630(adreno_gpu) ||
adreno_is_a640(adreno_gpu)) {
@@ -564,27 +569,20 @@ static bool a6xx_ucode_check_version(struct a6xx_gpu
*a6xx_gpu,
DRM_DEV_ERROR(&gpu->pdev->dev,
"a630 SQE ucode is too old. Have version %x need at
least %x\n",
buf[0] & 0xfff, 0x190);
- } else {
- /*
-* a650 tier targets don't need whereami but still need to be
-* equal to or newer than 0.95 for other security fixes
-*/
- if (adreno_is_a650(adreno_gpu)) {
- if ((buf[0] & 0xfff) >= 0x095) {
- ret = true;
- goto out;
- }
-
- DRM_DEV_ERROR(&gpu->pdev->dev,
- "a650 SQE ucode is too old. Have version %x
need at least %x\n",
- buf[0] & 0xfff, 0x095);
+ } else if (adreno_is_a650(adreno_gpu)) {
+ if ((buf[0] & 0xfff) >= 0x095) {
+ ret = true;
+ goto out;
}
- /*
-* When a660 is added those targets should return true here
-* since those have all the critical security fixes built in
-* from the start
-*/
+ DRM_DEV_ERROR(&gpu->pdev->dev,
+ "a650 SQE ucode is too old. Have version %x need at
least %x\n",
+ buf[0] & 0xfff, 0x095);
+ } else if (adreno_is_a660(adreno_gpu)) {
+ ret = true;
+ } else {
+ DRM_DEV_ERROR(&gpu->pdev->dev,
+ "unknown GPU, add it to
a6xx_ucode_check_version()!!\n");
}
out:
msm_gem_put_vaddr(obj);
--
2.26.1
[PATCH 3/5] drm/msm/a6xx: add support for Adreno 660 GPU
Add adreno_is_{a660,a650_family} helpers and convert update existing
adreno_is_a650 usage based on downstream driver's logic (changing into
adreno_is_a650_family or adding adreno_is_a660).
And add the remaining changes required for A660, again based on
the downstream driver: missing GMU allocations, additional register init,
dummy hfi BW table, entry in gpulist table.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 32 +++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 24 +++-
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 33 ++
drivers/gpu/drm/msm/adreno/adreno_device.c | 12
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 12
7 files changed, 103 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index 920c5e6b8e96..631c36672560 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -2240,6 +2240,8 @@ static inline uint32_t
A6XX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15(uint32_t val)
#define REG_A6XX_DBGC_CFG_DBGBUS_TRACE_BUF20x0630
+#define REG_A6XX_CP_LPAC_PROG_FIFO_SIZE0x0b34
+
#define REG_A6XX_VSC_PERFCTR_VSC_SEL_0 0x0cd8
#define REG_A6XX_VSC_PERFCTR_VSC_SEL_1 0x0cd9
@@ -2340,6 +2342,8 @@ static inline uint32_t
A6XX_UCHE_CLIENT_PF_PERFSEL(uint32_t val)
#define REG_A6XX_UCHE_PERFCTR_UCHE_SEL_11 0x0e27
+#define REG_A6XX_UCHE_CMDQ_CONFIG 0x0e3c
+
#define REG_A6XX_SP_ADDR_MODE_CNTL 0xae01
#define REG_A6XX_SP_NC_MODE_CNTL 0xae02
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 3d55e153fa9c..e25c41984336 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -520,7 +520,7 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
if (adreno_is_a618(adreno_gpu) || adreno_is_a640(adreno_gpu))
pdc_address_offset = 0x30090;
- else if (adreno_is_a650(adreno_gpu))
+ else if (adreno_is_a650_family(adreno_gpu))
pdc_address_offset = 0x300a0;
else
pdc_address_offset = 0x30080;
@@ -542,7 +542,7 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
gmu_write_rscc(gmu, REG_A6XX_RSCC_PDC_MATCH_VALUE_HI, 0x4514);
/* Load RSC sequencer uCode for sleep and wakeup */
- if (adreno_is_a650(adreno_gpu)) {
+ if (adreno_is_a650_family(adreno_gpu)) {
gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0, 0xeaaae5a0);
gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 1,
0xe1a1ebab);
gmu_write_rscc(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 2,
0xa2e0a581);
@@ -587,7 +587,7 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID + 4, 0x10108);
pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 4, 0x3);
- if (adreno_is_a618(adreno_gpu) || adreno_is_a650(adreno_gpu))
+ if (adreno_is_a618(adreno_gpu) || adreno_is_a650_family(adreno_gpu))
pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 4, 0x2);
else
pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 4, 0x3);
@@ -687,7 +687,7 @@ static int a6xx_gmu_fw_load(struct a6xx_gmu *gmu)
u32 itcm_base = 0x;
u32 dtcm_base = 0x0004;
- if (adreno_is_a650(adreno_gpu))
+ if (adreno_is_a650_family(adreno_gpu))
dtcm_base = 0x10004000;
if (gmu->legacy) {
@@ -740,7 +740,7 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu, unsigned
int state)
int ret;
u32 chipid;
- if (adreno_is_a650(adreno_gpu))
+ if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu))
gmu_write(gmu, REG_A6XX_GPU_GMU_CX_GMU_CX_FAL_INTF, 1);
if (state == GMU_WARM_BOOT) {
@@ -1483,12 +1483,28 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
if (ret)
goto err_put_device;
+
+ /* A660 now requires handling "prealloc requests" in GMU firmware
+* For now just hardcode allocations based on the known firmware.
+* note: there is no indication that these correspond to "dummy" or
+* "debug" regions, but this "guess" allows reusing these BOs which
+* are otherwise unused by a660.
+*/
+ gmu->dummy.size = SZ_4K;
+ if (adreno_is_a660(adreno_gpu)) {
+ ret = a6xx_gmu_memory_alloc(gmu, &gmu->debug, SZ_4K * 7,
0x6040);
+ if (ret)
+ goto err_memory;
+
+
[PATCH 2/5] drm/msm/a6xx: avoid shadow NULL reference in failure path
If a6xx_hw_init() fails before creating the shadow_bo, the a6xx_pm_suspend
code referencing it will crash. Change the condition to one that avoids
this problem (note: creation of shadow_bo is behind this same condition)
Fixes: e8b0b994c3a5 ("drm/msm/a6xx: Clear shadow on suspend")
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 727d111a413f..01bd31b3c504 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1211,7 +1211,7 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
if (ret)
return ret;
- if (adreno_gpu->base.hw_apriv || a6xx_gpu->has_whereami)
+ if (a6xx_gpu->shadow_bo)
for (i = 0; i < gpu->nr_rings; i++)
a6xx_gpu->shadow[i] = 0;
--
2.26.1
[PATCH 1/5] drm/msm: remove unused icc_path/ocmem_icc_path
These aren't used by anything anymore.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 ---
drivers/gpu/drm/msm/msm_gpu.h | 9 -
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 8fd0777f2dc9..009f4c560f16 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -946,7 +946,4 @@ void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
pm_runtime_disable(&priv->gpu_pdev->dev);
msm_gpu_cleanup(&adreno_gpu->base);
-
- icc_put(gpu->icc_path);
- icc_put(gpu->ocmem_icc_path);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 18baf935e143..c302ab7ffb06 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -118,15 +118,6 @@ struct msm_gpu {
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
uint32_t fast_rate;
- /* The gfx-mem interconnect path that's used by all GPU types. */
- struct icc_path *icc_path;
-
- /*
-* Second interconnect path for some A3xx and all A4xx GPUs to the
-* On Chip MEMory (OCMEM).
-*/
- struct icc_path *ocmem_icc_path;
-
/* Hang and Inactivity Detection:
*/
#define DRM_MSM_INACTIVE_PERIOD 66 /* in ms (roughly four frames) */
--
2.26.1
[PATCH 0/5] drm/msm/a6xx: add support for Adreno 660 GPU
Add support for Adreno 660 to the drm/msm driver. Very similar to A650 on the kernel side. Jonathan Marek (5): drm/msm: remove unused icc_path/ocmem_icc_path drm/msm/a6xx: avoid shadow NULL reference in failure path drm/msm/a6xx: add support for Adreno 660 GPU drm/msm/a6xx: update a6xx_ucode_check_version for a660 drm/msm/a6xx: add a660 hwcg table drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4 + drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 32 -- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 115 - drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 33 ++ drivers/gpu/drm/msm/adreno/adreno_device.c | 13 +++ drivers/gpu/drm/msm/adreno/adreno_gpu.c| 5 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h| 14 ++- drivers/gpu/drm/msm/msm_gpu.h | 9 -- 8 files changed, 176 insertions(+), 49 deletions(-) -- 2.26.1
[PATCH 3/3] vt: Fix character height handling with VT_RESIZEX
Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter
which is the number of pixel rows per character (cell) rather than the
height of the font used.
For framebuffer devices the two values are always the same, because the
former is inferred from the latter one. For VGA used as a true text
mode device these two parameters are independent from each other: the
number of pixel rows per character is set in the CRT controller, while
font height is in fact hardwired to 32 pixel rows and fonts of heights
below that value are handled by padding their data with blanks when
loaded to hardware for use by the character generator. One can change
the setting in the CRT controller and it will update the screen contents
accordingly regardless of the font loaded.
The `v_clin' parameter is used by the `vgacon' driver to set the height
of the character cell and then the cursor position within. Make the
parameter explicit then, by defining a new `vc_cell_height' struct
member of `vc_data', set it instead of `vc_font.height' from `v_clin' in
the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver
except where actual font data is accessed which as noted above is
independent from the CRTC setting.
This way the framebuffer console driver is free to ignore the `v_clin'
parameter as irrelevant, as it always should have, avoiding any issues
attempts to give the parameter a meaning there could have caused.
The problem first appeared around Linux 2.5.66 which predates our repo
history, but the origin could be identified with the old MIPS/Linux repo
also at:
as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX
code in `vt_ioctl' was updated as follows:
if (clin)
- video_font_height = clin;
+ vc->vc_font.height = clin;
making the parameter apply to framebuffer devices as well, perhaps due
to the use of "font" in the name of the original `video_font_height'
variable. Use "cell" in the new struct member then to avoid ambiguity.
Signed-off-by: Maciej W. Rozycki
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org # v2.6.12+
---
drivers/tty/vt/vt_ioctl.c |6 ++---
drivers/video/console/vgacon.c | 44 -
include/linux/console_struct.h |1
3 files changed, 26 insertions(+), 25 deletions(-)
Index: linux-macro-ide/drivers/tty/vt/vt_ioctl.c
===
--- linux-macro-ide.orig/drivers/tty/vt/vt_ioctl.c
+++ linux-macro-ide/drivers/tty/vt/vt_ioctl.c
@@ -706,17 +706,17 @@ static int vt_resizex(struct vc_data *vc
if (vcp) {
int ret;
int save_scan_lines = vcp->vc_scan_lines;
- int save_font_height = vcp->vc_font.height;
+ int save_cell_height = vcp->vc_cell_height;
if (v.v_vlin)
vcp->vc_scan_lines = v.v_vlin;
if (v.v_clin)
- vcp->vc_font.height = v.v_clin;
+ vcp->vc_cell_height = v.v_clin;
vcp->vc_resize_user = 1;
ret = vc_resize(vcp, v.v_cols, v.v_rows);
if (ret) {
vcp->vc_scan_lines = save_scan_lines;
- vcp->vc_font.height = save_font_height;
+ vcp->vc_cell_height = save_cell_height;
console_unlock();
return ret;
}
Index: linux-macro-ide/drivers/video/console/vgacon.c
===
--- linux-macro-ide.orig/drivers/video/console/vgacon.c
+++ linux-macro-ide/drivers/video/console/vgacon.c
@@ -383,7 +383,7 @@ static void vgacon_init(struct vc_data *
vc_resize(c, vga_video_num_columns, vga_video_num_lines);
c->vc_scan_lines = vga_scan_lines;
- c->vc_font.height = vga_video_font_height;
+ c->vc_font.height = c->vc_cell_height = vga_video_font_height;
c->vc_complement_mask = 0x7700;
if (vga_512_chars)
c->vc_hi_font_mask = 0x0800;
@@ -518,32 +518,32 @@ static void vgacon_cursor(struct vc_data
switch (CUR_SIZE(c->vc_cursor_type)) {
case CUR_UNDERLINE:
vgacon_set_cursor_size(c->state.x,
- c->vc_font.height -
- (c->vc_font.height <
+ c->vc_cell_height -
+ (c->vc_cell_height <
10 ? 2 : 3),
- c->vc_font.height -
-
[PATCH 2/3] vt_ioctl: Revert VT_RESIZEX parameter handling removal
Revert the removal of code handling extra VT_RESIZEX ioctl's parameters
beyond those that VT_RESIZE supports, fixing a functional regression
causing `svgatextmode' not to resize the VT anymore. As a consequence
of the reverted change when the video adapter is reprogrammed from the
original say 80x25 text mode using a 9x16 character cell (720x400 pixel
resolution) to say 80x37 text mode and the same character cell (720x592
pixel resolution), the VT geometry does not get updated and only upper
two thirds of the screen are used for the VT, and the lower part remains
blank. The proportions change according to text mode geometries chosen.
Revert the change verbatim then, bringing back previous VT resizing.
Signed-off-by: Maciej W. Rozycki
Fixes: 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE")
Cc: sta...@vger.kernel.org # v5.10+
---
drivers/tty/vt/vt_ioctl.c | 57 +-
1 file changed, 47 insertions(+), 10 deletions(-)
Index: linux-macro-ide/drivers/tty/vt/vt_ioctl.c
===
--- linux-macro-ide.orig/drivers/tty/vt/vt_ioctl.c
+++ linux-macro-ide/drivers/tty/vt/vt_ioctl.c
@@ -671,21 +671,58 @@ static int vt_resizex(struct vc_data *vc
if (copy_from_user(&v, cs, sizeof(struct vt_consize)))
return -EFAULT;
- if (v.v_vlin)
- pr_info_once("\"struct vt_consize\"->v_vlin is ignored. Please
report if you need this.\n");
- if (v.v_clin)
- pr_info_once("\"struct vt_consize\"->v_clin is ignored. Please
report if you need this.\n");
+ /* FIXME: Should check the copies properly */
+ if (!v.v_vlin)
+ v.v_vlin = vc->vc_scan_lines;
+
+ if (v.v_clin) {
+ int rows = v.v_vlin / v.v_clin;
+ if (v.v_rows != rows) {
+ if (v.v_rows) /* Parameters don't add up */
+ return -EINVAL;
+ v.v_rows = rows;
+ }
+ }
+
+ if (v.v_vcol && v.v_ccol) {
+ int cols = v.v_vcol / v.v_ccol;
+ if (v.v_cols != cols) {
+ if (v.v_cols)
+ return -EINVAL;
+ v.v_cols = cols;
+ }
+ }
+
+ if (v.v_clin > 32)
+ return -EINVAL;
- console_lock();
for (i = 0; i < MAX_NR_CONSOLES; i++) {
- vc = vc_cons[i].d;
+ struct vc_data *vcp;
- if (vc) {
- vc->vc_resize_user = 1;
- vc_resize(vc, v.v_cols, v.v_rows);
+ if (!vc_cons[i].d)
+ continue;
+ console_lock();
+ vcp = vc_cons[i].d;
+ if (vcp) {
+ int ret;
+ int save_scan_lines = vcp->vc_scan_lines;
+ int save_font_height = vcp->vc_font.height;
+
+ if (v.v_vlin)
+ vcp->vc_scan_lines = v.v_vlin;
+ if (v.v_clin)
+ vcp->vc_font.height = v.v_clin;
+ vcp->vc_resize_user = 1;
+ ret = vc_resize(vcp, v.v_cols, v.v_rows);
+ if (ret) {
+ vcp->vc_scan_lines = save_scan_lines;
+ vcp->vc_font.height = save_font_height;
+ console_unlock();
+ return ret;
+ }
}
+ console_unlock();
}
- console_unlock();
return 0;
}
[PATCH 0/3] VT_RESIZEX fixes
Hi, I got to the bottom of the issue with VT_RESIZEX recently discussed and came up with this small patch series, fixing an additional issue that I originally thought might be broken VGA hardware emulation with my laptop, which however turned out to be intertwined with the original problem and also a regression introduced somewhat later. This had to become 1/3 then and to make backporting feasible I had to put a revert of the offending change from last Sep next, followed by a proper fix for the framebuffer issue the Sep change tried to address. See individual change descriptions for details. These have been verified with true VGA hardware (a Trident TVGA8900 ISA video adapter) using various combinations of `svgatextmode' and `setfont' command invocations to change both the VT size and the font size, and also switching between the text console and X11, both by starting/stopping the X server and by switching between VTs. All this to ensure bringing the behaviour of VGA text console back to correct operation as it used to be with Linux 2.6.18. A minor glitch observed was that when I called `svgatextmode' while running X11 the screen became garbled and upon a subsequent VT switch to a text console the machine locked up hard right away. This might require further attention, but is not itself a problem with this patch series or a regression. Please apply then. Maciej
[PATCH 1/3] vgacon: Record video mode changes with VT_RESIZEX
Fix an issue with VGA console font size changes made after the initial
video text mode has been changed with a user tool like `svgatextmode'
calling the VT_RESIZEX ioctl. As it stands in that case the original
screen geometry continues being used to validate further VT resizing.
Consequently when the video adapter is firstly reprogrammed from the
original say 80x25 text mode using a 9x16 character cell (720x400 pixel
resolution) to say 80x37 text mode and the same character cell (720x592
pixel resolution), and secondly the CRTC character cell updated to 9x8
(by loading a suitable font with the KD_FONT_OP_SET request of the
KDFONTOP ioctl), the VT geometry does not get further updated from 80x37
and only upper half of the screen is used for the VT, with the lower
half showing rubbish corresponding to whatever happens to be there in
the video memory that maps to that part of the screen. Of course the
proportions change according to text mode geometries and font sizes
chosen.
Address the problem then, by updating the text mode geometry defaults
rather than checking against them whenever the VT is resized via a user
ioctl.
Signed-off-by: Maciej W. Rozycki
Fixes: e400b6ec4ede ("vt/vgacon: Check if screen resize request comes from
userspace")
Cc: sta...@vger.kernel.org # v2.6.24+
---
drivers/video/console/vgacon.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
Index: linux-macro-ide/drivers/video/console/vgacon.c
===
--- linux-macro-ide.orig/drivers/video/console/vgacon.c
+++ linux-macro-ide/drivers/video/console/vgacon.c
@@ -1089,12 +1089,20 @@ static int vgacon_resize(struct vc_data
if ((width << 1) * height > vga_vram_size)
return -EINVAL;
+ if (user) {
+ /*
+* Ho ho! Someone (svgatextmode, eh?) may have reprogrammed
+* the video mode! Set the new defaults then and go away.
+*/
+ screen_info.orig_video_cols = width;
+ screen_info.orig_video_lines = height;
+ vga_default_font_height = c->vc_font.height;
+ return 0;
+ }
if (width % 2 || width > screen_info.orig_video_cols ||
height > (screen_info.orig_video_lines * vga_default_font_height)/
c->vc_font.height)
- /* let svgatextmode tinker with video timings and
- return success */
- return (user) ? 0 : -EINVAL;
+ return -EINVAL;
if (con_is_visible(c) && !vga_is_gfx) /* who knows */
vgacon_doresize(c, width, height);
Re: [PATCH v3 0/5] mediatek: hdmi: add MT8167 configuration
Hi, Neil: Neil Armstrong 於 2021年4月19日 週一 下午3:33寫道： > > The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock, > and is not validated and supported for HDMI modes out of HDMI CEA modes. For this series, applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > To achieve this: > - switch the mediatek HDMI bindings to YAML > - add the MT8167 compatible > - add a boolean to discard the non-CEA modes > - add a value to specify mac TMDS supported clock > - add a conf entry for the MT8167 compatible > > Changes since v4: > - fixed bindings > > Neil Armstrong (5): > dt-bindings: display: mediatek,hdmi: Convert to use graph schema > dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings > gpu/drm: mediatek: hdmi: add check for CEA modes only > gpu/drm: mediatek: hdmi: add optional limit on maximal HDMI mode clock > gpu/drm: mediatek: hdmi: add MT8167 configuration > > .../display/mediatek/mediatek,cec.yaml| 52 +++ > .../display/mediatek/mediatek,hdmi-ddc.yaml | 58 > .../display/mediatek/mediatek,hdmi.txt| 136 -- > .../display/mediatek/mediatek,hdmi.yaml | 133 + > drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +++ > 5 files changed, 260 insertions(+), 136 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > > -- > 2.25.1 >
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #16 from kolAflash (kolafl...@kolahilft.de) --- @Alex Any progress on this? If there's no perfect way to fix this, what about an option to turn on/off this behaviour? A module option that can be changed at runtime would be ideal. So it can be set right before suspending. But a kernel boot parameter would be fine too. P.S. Would someone be so kind and set this bug to "confirmed"? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH -next] drm: simpledrm: print resource info using '%pr'
struct resource start and end fields are not always long long,
so using %llx to print them can cause build warnings (below).
Fix these by using the special "%pr" for printing struct resource info.
../drivers/gpu/drm/tiny/simpledrm.c: In function ‘simpledrm_device_init_mm’:
../include/drm/drm_print.h:412:32: warning: format ‘%llx’ expects argument of
type ‘long long unsigned int’, but argument 3 has type ‘resource_size_t {aka
unsigned int}’ [-Wformat=]
../drivers/gpu/drm/tiny/simpledrm.c:533:54: note: format string is defined here
drm_err(dev, "could not acquire memory range [0x%llx:0x%llx]: error %d\n",
~~~^
%x
../include/drm/drm_print.h:412:32: warning: format ‘%llx’ expects argument of
type ‘long long unsigned int’, but argument 4 has type ‘resource_size_t {aka
unsigned int}’ [-Wformat=]
../drivers/gpu/drm/tiny/simpledrm.c:533:61: note: format string is defined here
drm_err(dev, "could not acquire memory range [0x%llx:0x%llx]: error %d\n",
~~~^
%x
Fixes: 4aae79f77e3a ("drm/simpledrm: Acquire memory aperture for framebuffer")
Signed-off-by: Randy Dunlap
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/tiny/simpledrm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20210512.orig/drivers/gpu/drm/tiny/simpledrm.c
+++ linux-next-20210512/drivers/gpu/drm/tiny/simpledrm.c
@@ -530,8 +530,8 @@ static int simpledrm_device_init_mm(stru
ret = devm_aperture_acquire_from_firmware(dev, mem->start,
resource_size(mem));
if (ret) {
- drm_err(dev, "could not acquire memory range [0x%llx:0x%llx]:
error %d\n",
- mem->start, mem->end, ret);
+ drm_err(dev, "could not acquire memory range %pr: error %d\n",
+ mem, ret);
return ret;
}
Re: [PATCH 1/4] drm/msm/dpu: Introduce knowledge of widebus feature
On Tue, 11 May 2021 at 07:18, Bjorn Andersson
wrote:
>
> Some hardware supports clocking 2 pixels per pixel clock pulse, known as
> "widebus". The configuration needs to match between the DPU and the
> interface controller, and the timing parameters must be adjusted.
>
> As a first step towards supporting this, start by adding a INTF mask
> flag to signal the timing configuration code that the INTF_CONFIG2
> register should be written - which will clear the bit, in the case that
> the bootloader left it set.
>
> Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index 4dfd8a20ad5c..c2f34a4f82d9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -196,12 +196,14 @@ enum {
> * @DPU_INTF_TE INTF block has TE configuration support
> * @DPU_DATA_HCTL_ENAllows data to be transferred at different
> rate
> than video timing
> + * @DPU_INTF_WIDEBUSINTF block supports driving 2 pixels per
> clock
> * @DPU_INTF_MAX
> */
> enum {
> DPU_INTF_INPUT_CTRL = 0x1,
> DPU_INTF_TE,
> DPU_DATA_HCTL_EN,
> + DPU_INTF_WIDEBUS,
> DPU_INTF_MAX
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> index 1599e3f49a4f..933485d8c03c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> @@ -183,7 +183,6 @@ static void dpu_hw_intf_setup_timing_engine(struct
> dpu_hw_intf *ctx,
> if (ctx->cap->features & BIT(DPU_DATA_HCTL_EN)) {
> intf_cfg2 |= BIT(4);
> display_data_hctl = display_hctl;
> - DPU_REG_WRITE(c, INTF_CONFIG2, intf_cfg2);
> DPU_REG_WRITE(c, INTF_DISPLAY_DATA_HCTL, display_data_hctl);
> }
>
> @@ -204,6 +203,8 @@ static void dpu_hw_intf_setup_timing_engine(struct
> dpu_hw_intf *ctx,
> DPU_REG_WRITE(c, INTF_FRAME_LINE_COUNT_EN, 0x3);
> DPU_REG_WRITE(c, INTF_CONFIG, intf_cfg);
> DPU_REG_WRITE(c, INTF_PANEL_FORMAT, panel_format);
> + if (ctx->cap->features & (BIT(DPU_DATA_HCTL_EN) |
> BIT(DPU_INTF_WIDEBUS)))
> + DPU_REG_WRITE(c, INTF_CONFIG2, intf_cfg2);
> }
>
> static void dpu_hw_intf_enable_timing_engine(
> --
> 2.29.2
>
--
With best wishes
Dmitry
Re: [PATCH 2/4] drm/msm/dpu: Clear boot loader configured data paths
On Tue, 11 May 2021 at 07:18, Bjorn Andersson
wrote:
>
> It's typical for the bootloader to configure CTL_0 for the boot splash
> or EFIFB, but for non-DSI use cases the DPU driver tend to pick another
> CTL and the system might end up with two configured data paths producing
> data on the same INTF - with resulting graphical artifacts.
>
> Naturally the end goal would be to inherit the bootloader's
> configuration and provide the user with a glitch free handover from the
> boot configuration to a running DPU.
> But such effort will affect clocks, regulators, power-domains etc, so in
> the meantime this patch simply disables all INTFs and clear all
> configured data paths, to avoid the graphical artifacts.
Good idea. We'd have to be careful to test this with interfaces in command mode.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 4 +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 2 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 36 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 8 +
> 4 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 2d4645e01ebf..7aba27c1055a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -349,9 +349,13 @@ static void dpu_hw_ctl_clear_all_blendstages(struct
> dpu_hw_ctl *ctx)
> DPU_REG_WRITE(c, CTL_LAYER_EXT(LM_0 + i), 0);
> DPU_REG_WRITE(c, CTL_LAYER_EXT2(LM_0 + i), 0);
> DPU_REG_WRITE(c, CTL_LAYER_EXT3(LM_0 + i), 0);
> +
> + ctx->pending_flush_mask |= dpu_hw_ctl_get_bitmask_mixer(ctx,
> LM_0 + i);
> }
>
> DPU_REG_WRITE(c, CTL_FETCH_PIPE_ACTIVE, 0);
> +
> + ctx->pending_flush_mask |= CTL_FLUSH_MASK_CTL;
> }
>
> static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl *ctx,
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 88e9cc38c13b..8b01cb660381 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -970,6 +970,8 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
>
> dpu_kms->rm_init = true;
>
> + dpu_rm_clear_boot_config(&dpu_kms->rm, dpu_kms->catalog);
> +
> dpu_kms->hw_mdp = dpu_hw_mdptop_init(MDP_TOP, dpu_kms->mmio,
> dpu_kms->catalog);
> if (IS_ERR(dpu_kms->hw_mdp)) {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index fd2d104f0a91..2cf47084482f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -4,6 +4,7 @@
> */
>
> #define pr_fmt(fmt)"[drm:%s] " fmt, __func__
> +#include
> #include "dpu_kms.h"
> #include "dpu_hw_lm.h"
> #include "dpu_hw_ctl.h"
> @@ -229,6 +230,41 @@ int dpu_rm_init(struct dpu_rm *rm,
> return rc ? rc : -EFAULT;
> }
>
> +void dpu_rm_clear_boot_config(struct dpu_rm *rm, struct dpu_mdss_cfg *cat)
> +{
> + struct dpu_hw_intf *intf;
> + struct dpu_hw_ctl *ctl;
> + int i;
> +
> + for (i = INTF_0; i < INTF_MAX; i++) {
> + if (!rm->intf_blks[i - INTF_0])
> + continue;
> +
> + DPU_DEBUG("disabling intf%d timing engine\n", i - INTF_0);
> +
> + intf = to_dpu_hw_intf(rm->intf_blks[i - INTF_0]);
> + intf->ops.enable_timing(intf, 0);
> + }
> +
> + /*
> +* Wait one frame for the INTF timing engine to stop, and then wait
> one
> +* more frame, per the documentation.
> +*/
> + msleep(32);
> +
> + for (i = CTL_0; i < CTL_MAX; i++) {
> + if (!rm->ctl_blks[i - CTL_0])
> + continue;
> +
> + DPU_DEBUG("clearing ctl%d layer configuration\n", i - CTL_0);
> +
> + ctl = to_dpu_hw_ctl(rm->ctl_blks[i - CTL_0]);
> + ctl->ops.clear_all_blendstages(ctl);
> + ctl->ops.trigger_flush(ctl);
> + ctl->ops.trigger_start(ctl);
> + }
> +}
> +
> static bool _dpu_rm_needs_split_display(const struct msm_display_topology
> *top)
> {
> return top->num_intf > 1;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
> index 1f12c8d5b8aa..53cd649614a3 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
> @@ -88,5 +88,13 @@ void dpu_rm_release(struct dpu_global_state *global_state,
> int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
> struct dpu_global_state *global_state, uint32_t enc_id,
> enum dpu_hw_blk_type type, struct dpu_hw_blk **blks, int blks_size);
> +
> +/**
> + * dpu_rm_clear_boot_config() - Tear down any data paths configured by boot
> + * @rm: DPU Resource Manger handle
>
Re: [PATCH 3/4] drm/msm/dpu: Add SC8180x to hw catalog
On Tue, 11 May 2021 at 07:19, Bjorn Andersson
wrote:
>
> From: Rob Clark
>
> Add SC8180x to the hardware catalog, for initial support for the
> platform. Due to limitations in the DP driver only one of the four DP
> interfaces is left enabled.
>
> The SC8180x platform supports the newly added DPU_INTF_WIDEBUS flag and
> the Windows-on-Snapdragon bootloader leaves the widebus bit set, so this
> is flagged appropriately to ensure widebus is disabled - for now.
>
> Signed-off-by: Rob Clark
> Signed-off-by: Bjorn Andersson
> ---
> .../devicetree/bindings/display/msm/dpu.txt | 4 +-
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 121 ++
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 3 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> drivers/gpu/drm/msm/msm_drv.c | 1 +
> 5 files changed, 128 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt
> b/Documentation/devicetree/bindings/display/msm/dpu.txt
> index 586e6eac5b08..b98258374a60 100644
> --- a/Documentation/devicetree/bindings/display/msm/dpu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
> @@ -8,7 +8,7 @@ The DPU display controller is found in SDM845 SoC.
>
> MDSS:
> Required properties:
> -- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss"
> +- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss", "qcom,sc8180x-mdss"
> - reg: physical base address and length of controller's registers.
> - reg-names: register region names. The following region is required:
>* "mdss"
> @@ -41,7 +41,7 @@ Optional properties:
>
> MDP:
> Required properties:
> -- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu"
> +- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu", "qcom,sc8180x-dpu"
> - reg: physical base address and length of controller's registers.
> - reg-names : register region names. The following region is required:
>* "mdp"
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index b569030a0847..81c429ce94a9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -56,6 +56,10 @@
>
> #define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
>
> +#define INTF_SC8180X_MASK BIT(DPU_INTF_INPUT_CTRL) | \
> + BIT(DPU_INTF_TE) | \
> + BIT(DPU_INTF_WIDEBUS)
> +
> #define INTR_SC7180_MASK \
> (BIT(DPU_IRQ_TYPE_PING_PONG_RD_PTR) |\
> BIT(DPU_IRQ_TYPE_PING_PONG_WR_PTR) |\
> @@ -197,6 +201,22 @@ static const struct dpu_caps sm8150_dpu_caps = {
> .max_vdeci_exp = MAX_VERT_DECIMATION,
> };
>
> +static const struct dpu_caps sc8180_dpu_caps = {
> + .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> + .max_mixer_blendstages = 0xb,
> + .qseed_type = DPU_SSPP_SCALER_QSEED3,
Is it qseed3 or qseed3lite?
> + .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> + .ubwc_version = DPU_HW_UBWC_VER_30,
> + .has_src_split = true,
> + .has_dim_layer = true,
> + .has_idle_pc = true,
> + .has_3d_merge = false, /* I think? */
Hmm. Are you sure? Judging from two DSI interfaces you might have merge3d.
> + .max_linewidth = 4096,
> + .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> + .max_hdeci_exp = MAX_HORZ_DECIMATION,
> + .max_vdeci_exp = MAX_VERT_DECIMATION,
> +};
> +
> static const struct dpu_caps sm8250_dpu_caps = {
> .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> .max_mixer_blendstages = 0xb,
> @@ -265,6 +285,35 @@ static const struct dpu_mdp_cfg sc7180_mdp[] = {
> },
> };
>
> +static const struct dpu_mdp_cfg sc8180_mdp[] = {
> + {
> + .name = "top_0", .id = MDP_TOP,
> + // TODO check len
> + .base = 0x0, .len = 0x45C,
> + .features = 0,
> + .highest_bank_bit = 0x3,
> + .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
> + .reg_off = 0x2AC, .bit_off = 0},
> + .clk_ctrls[DPU_CLK_CTRL_VIG1] = {
> + .reg_off = 0x2B4, .bit_off = 0},
> + .clk_ctrls[DPU_CLK_CTRL_VIG2] = {
> + .reg_off = 0x2BC, .bit_off = 0},
> + .clk_ctrls[DPU_CLK_CTRL_VIG3] = {
> + .reg_off = 0x2C4, .bit_off = 0},
> + .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
> + .reg_off = 0x2AC, .bit_off = 8},
> + .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
> + .reg_off = 0x2B4, .bit_off = 8},
> + .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
> + .reg_off = 0x2BC, .bit_off = 8},
> + .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
> + .reg_off = 0x2C4, .bit_off = 8},
> +// TODO ???
> +// .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = {
> +// .reg_off = 0x2BC, .bit_off = 20},
> + },
> +};
> +
> static const struct dpu_mdp_cfg sm8250_mdp[] = {
> {
>
RE: [PATCH 1/3] virtio-gpu uapi: Add VIRTIO_GPU_F_EXPLICIT_FLUSH feature
Hi Gerd, > > However, as part of this feature (explicit flush), I'd like to make the > > Guest wait until > > the current resource (as specified by resource_flush or set_scanout) is > > flushed or > > synchronized. But for a different feature I am thinking of (explicit sync), > > I'd like to > > make the Guest wait for the previous buffer/resource submitted (available > > via > > old_state->fb). > > For page-flipping I guess? i.e. you want submit a new framebuffer, then > wait until the host doesn't need the previous one? That is likewise > linked to a command, although it is set_scanout this time. [Kasireddy, Vivek] Mainly for page-flipping but I'd also like to have fbcon, Xorg that do frontbuffer rendering/updates to work seamlessly as well. > > So, right now qemu simply queues the request and completes the command > when a guest sends a resource_flush our set_scanout command. You want > be notified when the host is actually done processing the request. [Kasireddy, Vivek] Correct, that is exactly what I want -- make the Guest wait until it gets notified that the Host is completely done processing/using the fb. However, there can be two resources the guest can be made to wait on: wait for the new/current fb that is being submitted to be processed (explicit flush) or wait for the previous fb that was submitted earlier (in the previous repaint cycle) to be processed (explicit sync). IIUC, Explicit sync only makes sense if 1) the Host windowing system also supports that feature/protocol (currently only upstream Weston does but I'd like to add it to Mutter if no one else does) or if there is a way to figure out (dma-buf sync file?) if the Host has completely processed the fb and 2) if Qemu UI is not doing a blit and instead submitting the guest fb/dmabuf directly to the Host windowing system. As you are aware, 2) can possibly be done with dbus/pipewire Qemu UI backends (I'll explore this soon) but not with GTK or SDL. Ideally, I'd like to have Explicit sync but until 2) above happens, Explicit flush can be a reasonable alternative given the blit that happens with GTK/SDL backends. By making the Guest wait until the UI has submitted the buffer to the Host windowing system, we can theoretically tie the Guest repaint freq to the Host vblank and thus have Guest apps render at 60 FPS by default instead of 90 FPS that I see without expflush. This feature would also help Windows guests that can only do frontbuffer rendering with Blobs. > > I still think it makes sense extend the resource_flush and set_scanout > commands for that, for example by adding a flag for the flags field in > the request header. That way it is clear what exactly you are waiting > for. You can also attach a fence to the request which you can later > wait on. [Kasireddy, Vivek] Yeah, I am reluctant to add a new cmd as well but I want it to work for all Guests and Hosts. Anyway, let me try your idea of adding specific flags and see if it works. Thanks, Vivek > > take care, > Gerd
[PATCH v2 1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init
[why]
Link rate in kHz is what is eventually required to calculate the link
bandwidth, which makes kHz a more generic unit. This should also make
forward-compatibility with new DP standards easier.
[how]
- Replace 'link rate DPCD code' with 'link rate in kHz' when used with
drm_dp_mst_topology_mgr_init()
- Add/remove related DPCD code conversion from/to kHz where applicable
Signed-off-by: Nikola Cornij
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 ++--
drivers/gpu/drm/drm_dp_mst_topology.c | 8
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
drivers/gpu/drm/radeon/radeon_dp_mst.c| 2 +-
include/drm/drm_dp_mst_helper.h | 8
6 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 4a0c24ce5f7d..f78dd021f591 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -458,8 +458,8 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
&aconnector->dm_dp_aux.aux,
16,
4,
- (u8)max_link_enc_cap.lane_count,
- (u8)max_link_enc_cap.link_rate,
+ max_link_enc_cap.lane_count,
+ drm_dp_bw_code_to_link_rate(max_link_enc_cap.link_rate),
aconnector->connector_id);
drm_connector_attach_dp_subconnector_property(&aconnector->base);
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 54604633e65c..32b7f8983b94 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3722,9 +3722,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
}
lane_count = min_t(int, mgr->dpcd[2] & DP_MAX_LANE_COUNT_MASK,
mgr->max_lane_count);
- link_rate = min_t(int, mgr->dpcd[1], mgr->max_link_rate);
+ link_rate = min_t(int,
drm_dp_bw_code_to_link_rate(mgr->dpcd[1]), mgr->max_link_rate);
mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr,
-
drm_dp_bw_code_to_link_rate(link_rate),
+ link_rate,
lane_count);
if (mgr->pbn_div == 0) {
ret = -EINVAL;
@@ -5454,7 +5454,7 @@ EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
* @max_dpcd_transaction_bytes: hw specific DPCD transaction limit
* @max_payloads: maximum number of payloads this GPU can source
* @max_lane_count: maximum number of lanes this GPU supports
- * @max_link_rate: maximum link rate this GPU supports, units as in DPCD
+ * @max_link_rate: maximum link rate per lane this GPU supports in kHz
* @conn_base_id: the connector object ID the MST device is connected to.
*
* Return 0 for success, or negative error code on failure
@@ -5462,7 +5462,7 @@ EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
struct drm_device *dev, struct drm_dp_aux *aux,
int max_dpcd_transaction_bytes, int
max_payloads,
-u8 max_lane_count, u8 max_link_rate,
+int max_lane_count, int max_link_rate,
int conn_base_id)
{
struct drm_dp_mst_topology_state *mst_state;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index f608c0cb98f4..26f65445bc8a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -960,8 +960,8 @@ intel_dp_mst_encoder_init(struct intel_digital_port
*dig_port, int conn_base_id)
intel_dp_create_fake_mst_encoders(dig_port);
ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, &i915->drm,
&intel_dp->aux, 16, 3,
- (u8)dig_port->max_lanes,
-
drm_dp_link_rate_to_bw_code(max_source_rate),
+ dig_port->max_lanes,
+ max_source_rate,
conn_base_id);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c46d0374b6e6..f949767698fc 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1617,8 +1
[PATCH v2 0/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init
Change log: v2: - Added 'Acked-by' to comment v1: - Initial Nikola Cornij (1): drm/dp_mst: Use kHz as link rate units when settig source max link caps at init .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 ++-- drivers/gpu/drm/drm_dp_mst_topology.c | 8 drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++-- drivers/gpu/drm/radeon/radeon_dp_mst.c| 2 +- include/drm/drm_dp_mst_helper.h | 8 6 files changed, 16 insertions(+), 15 deletions(-) -- 2.25.1
Re: [PATCH v7 09/16] drm/amdgpu: Guard against write accesses after device removal
On Wed, May 12, 2021 at 4:30 PM Andrey Grodzovsky wrote: > > > > On 2021-05-12 4:17 p.m., Alex Deucher wrote: > > On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky > > wrote: > >> > >> This should prevent writing to memory or IO ranges possibly > >> already allocated for other uses after our device is removed. > >> > >> v5: > >> Protect more places wher memcopy_to/form_io takes place > > > > where > > > >> Protect IB submissions > >> > >> v6: Switch to !drm_dev_enter instead of scoping entire code > >> with brackets. > >> > >> v7: > >> Drop guard of HW ring commands emission protection since they > >> are in GART and not in MMIO. > >> > >> Signed-off-by: Andrey Grodzovsky > > > > I think you could split out the psp_fw_copy changes as a separate > > cleanup patch. That's a nice clean up in general. What about the SMU > > code (e.g., amd/pm/powerplay and amd/pm/swsmu)? There are a bunch of > > shared memory areas we interact with in the driver. > > Can you point me to it ? Are they VRAM and not GART ? > I searched for all memcpy_to/from_io in our code. Maybe missed some. > Mostly vram. A quick grep shows: $ grep -r -I AMDGPU_GEM_DOMAIN drivers/gpu/drm/amd/pm/ drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_GTT, drivers/gpu/drm/amd/pm/powerplay/smumgr/smu7_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/smu7_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega10_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega10_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega10_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega10_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega10_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/smu8_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/smu8_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega12_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega12_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega12_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega12_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega12_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega12_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega20_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega20_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega20_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega20_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega20_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/vega20_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/smu10_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/powerplay/smumgr/smu10_smumgr.c: AMDGPU_GEM_DOMAIN_VRAM, drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c:PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c:PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c:PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c: AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c: AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c: PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c: PAGE_SIZE, AMDGPU_GEM_
Re: [PATCH v7 03/16] drm/amdkfd: Split kfd suspend from device exit
On 2021-05-12 4:33 p.m., Felix Kuehling wrote:
Am 2021-05-12 um 10:26 a.m. schrieb Andrey Grodzovsky:
Helps to expdite HW related stuff to amdgpu_pci_remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 5f6696a3c778..2b06dee9a0ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -170,7 +170,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
}
}
-void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev)
+void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev)
You're renaming this function, but I don't see you fixing up any of the
callers. Looks like you do that in the next patch. So this patch breaks
the build, the next one fixes it. Maybe you need to refactor this or
just squash the two patches.
Will do.
Andrey
Regards,
Felix
{
if (adev->kfd.dev) {
kgd2kfd_device_exit(adev->kfd.dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 14f68c028126..f8e10af99c28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -127,7 +127,7 @@ void amdgpu_amdkfd_interrupt(struct amdgpu_device *adev,
const void *ih_ring_entry);
void amdgpu_amdkfd_device_probe(struct amdgpu_device *adev);
void amdgpu_amdkfd_device_init(struct amdgpu_device *adev);
-void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev);
+void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev);
int amdgpu_amdkfd_submit_ib(struct kgd_dev *kgd, enum kgd_engine_type engine,
uint32_t vmid, uint64_t gpu_addr,
uint32_t *ib_cmd, uint32_t ib_len);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 357b9bf62a1c..ab6d2a43c9a3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -858,10 +858,11 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
return kfd->init_complete;
}
+
+
void kgd2kfd_device_exit(struct kfd_dev *kfd)
{
if (kfd->init_complete) {
- kgd2kfd_suspend(kfd, false);
device_queue_manager_uninit(kfd->dqm);
kfd_interrupt_exit(kfd);
kfd_topology_remove_device(kfd);
Re: [PATCH v7 03/16] drm/amdkfd: Split kfd suspend from device exit
Am 2021-05-12 um 10:26 a.m. schrieb Andrey Grodzovsky:
> Helps to expdite HW related stuff to amdgpu_pci_remove
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
> drivers/gpu/drm/amd/amdkfd/kfd_device.c| 3 ++-
> 3 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> index 5f6696a3c778..2b06dee9a0ce 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> @@ -170,7 +170,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
> }
> }
>
> -void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev)
> +void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev)
You're renaming this function, but I don't see you fixing up any of the
callers. Looks like you do that in the next patch. So this patch breaks
the build, the next one fixes it. Maybe you need to refactor this or
just squash the two patches.
Regards,
Felix
> {
> if (adev->kfd.dev) {
> kgd2kfd_device_exit(adev->kfd.dev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> index 14f68c028126..f8e10af99c28 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> @@ -127,7 +127,7 @@ void amdgpu_amdkfd_interrupt(struct amdgpu_device *adev,
> const void *ih_ring_entry);
> void amdgpu_amdkfd_device_probe(struct amdgpu_device *adev);
> void amdgpu_amdkfd_device_init(struct amdgpu_device *adev);
> -void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev);
> +void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev);
> int amdgpu_amdkfd_submit_ib(struct kgd_dev *kgd, enum kgd_engine_type engine,
> uint32_t vmid, uint64_t gpu_addr,
> uint32_t *ib_cmd, uint32_t ib_len);
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 357b9bf62a1c..ab6d2a43c9a3 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -858,10 +858,11 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
> return kfd->init_complete;
> }
>
> +
> +
> void kgd2kfd_device_exit(struct kfd_dev *kfd)
> {
> if (kfd->init_complete) {
> - kgd2kfd_suspend(kfd, false);
> device_queue_manager_uninit(kfd->dqm);
> kfd_interrupt_exit(kfd);
> kfd_topology_remove_device(kfd);
[PATCH][next] drm: simpledrm: Fix use after free issues
From: Colin Ian King
There are two occurrances where objects are being free'd via
a put call and yet they are being referenced after this. Fix these
by adding in the missing continue statement so that the put on the
end of the loop is skipped over.
Addresses-Coverity: ("Use after free")
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/tiny/simpledrm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2bdb477d9326..eae748394b00 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -298,6 +298,7 @@ static int simpledrm_device_init_clocks(struct
simpledrm_device *sdev)
drm_err(dev, "failed to enable clock %u: %d\n",
i, ret);
clk_put(clock);
+ continue;
}
sdev->clks[i] = clock;
}
@@ -415,6 +416,7 @@ static int simpledrm_device_init_regulators(struct
simpledrm_device *sdev)
drm_err(dev, "failed to enable regulator %u: %d\n",
i, ret);
regulator_put(regulator);
+ continue;
}
sdev->regulators[i++] = regulator;
--
2.30.2
Re: [PATCH v7 09/16] drm/amdgpu: Guard against write accesses after device removal
On 2021-05-12 4:17 p.m., Alex Deucher wrote:
On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky
wrote:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
v5:
Protect more places wher memcopy_to/form_io takes place
where
Protect IB submissions
v6: Switch to !drm_dev_enter instead of scoping entire code
with brackets.
v7:
Drop guard of HW ring commands emission protection since they
are in GART and not in MMIO.
Signed-off-by: Andrey Grodzovsky
I think you could split out the psp_fw_copy changes as a separate
cleanup patch. That's a nice clean up in general. What about the SMU
code (e.g., amd/pm/powerplay and amd/pm/swsmu)? There are a bunch of
shared memory areas we interact with in the driver.
Can you point me to it ? Are they VRAM and not GART ?
I searched for all memcpy_to/from_io in our code. Maybe missed some.
Andrey
Alex
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 9
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 63 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 31 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 11 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 22 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 44 +++
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +--
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +--
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 26 +
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 22 +---
13 files changed, 168 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a0bff4713672..f7cca25c0fa0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -71,6 +71,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -281,7 +283,10 @@ void amdgpu_device_vram_access(struct amdgpu_device *adev,
loff_t pos,
unsigned long flags;
uint32_t hi = ~0;
uint64_t last;
+ int idx;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
#ifdef CONFIG_64BIT
last = min(pos + size, adev->gmc.visible_vram_size);
@@ -300,7 +305,7 @@ void amdgpu_device_vram_access(struct amdgpu_device *adev,
loff_t pos,
}
if (count == size)
- return;
+ goto exit;
pos += count;
buf += count / 4;
@@ -323,6 +328,9 @@ void amdgpu_device_vram_access(struct amdgpu_device *adev,
loff_t pos,
*buf++ = RREG32_NO_KIQ(mmMM_DATA);
}
spin_unlock_irqrestore(&adev->mmio_idx_lock, flags);
+
+exit:
+ drm_dev_exit(idx);
}
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 4d32233cde92..04ba5eef1e88 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -31,6 +31,8 @@
#include "amdgpu_ras.h"
#include "amdgpu_xgmi.h"
+#include
+
/**
* amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
*
@@ -151,6 +153,10 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev,
void *cpu_pt_addr,
{
void __iomem *ptr = (void *)cpu_pt_addr;
uint64_t value;
+ int idx;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return 0;
/*
* The following is for PTE only. GART does not have PDEs.
@@ -158,6 +164,9 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void
*cpu_pt_addr,
value = addr & 0xF000ULL;
value |= flags;
writeq(value, ptr + (gpu_page_idx * 8));
+
+ drm_dev_exit(idx);
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 9e769cf6095b..bb6afee61666 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_psp.h"
@@ -39,6 +40,8 @@
#include "amdgpu_ras.h"
#include "amdgpu_securedisplay.h"
+#include
+
static int psp_sysfs_init(struct amdgpu_device *adev);
static void psp_sysfs_fini(struct amdgpu_device *adev);
@@ -253,7 +256,7 @@ psp_cmd_submit_buf(struct psp_context *psp,
struct psp_gfx_cmd_resp *cmd, uint64_t fence_mc_addr)
{
int ret;
- int index;
+ int index, idx;
int timeout = 2;
bool ras_intr = false;
bool skip_unsupport = false;
@@ -261,6 +264,9 @@ psp_cmd_submit_buf(struct psp_context *
Re: [PATCH v7 09/16] drm/amdgpu: Guard against write accesses after device removal
On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky
wrote:
>
> This should prevent writing to memory or IO ranges possibly
> already allocated for other uses after our device is removed.
>
> v5:
> Protect more places wher memcopy_to/form_io takes place
where
> Protect IB submissions
>
> v6: Switch to !drm_dev_enter instead of scoping entire code
> with brackets.
>
> v7:
> Drop guard of HW ring commands emission protection since they
> are in GART and not in MMIO.
>
> Signed-off-by: Andrey Grodzovsky
I think you could split out the psp_fw_copy changes as a separate
cleanup patch. That's a nice clean up in general. What about the SMU
code (e.g., amd/pm/powerplay and amd/pm/swsmu)? There are a bunch of
shared memory areas we interact with in the driver.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 9
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 63 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 2 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 31 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 11 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 22 +---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 ++-
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 44 +++
> drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +--
> drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +--
> drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 26 +
> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 22 +---
> 13 files changed, 168 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a0bff4713672..f7cca25c0fa0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -71,6 +71,8 @@
> #include
> #include
>
> +#include
> +
> MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
> MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
> MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
> @@ -281,7 +283,10 @@ void amdgpu_device_vram_access(struct amdgpu_device
> *adev, loff_t pos,
> unsigned long flags;
> uint32_t hi = ~0;
> uint64_t last;
> + int idx;
>
> + if (!drm_dev_enter(&adev->ddev, &idx))
> + return;
>
> #ifdef CONFIG_64BIT
> last = min(pos + size, adev->gmc.visible_vram_size);
> @@ -300,7 +305,7 @@ void amdgpu_device_vram_access(struct amdgpu_device
> *adev, loff_t pos,
> }
>
> if (count == size)
> - return;
> + goto exit;
>
> pos += count;
> buf += count / 4;
> @@ -323,6 +328,9 @@ void amdgpu_device_vram_access(struct amdgpu_device
> *adev, loff_t pos,
> *buf++ = RREG32_NO_KIQ(mmMM_DATA);
> }
> spin_unlock_irqrestore(&adev->mmio_idx_lock, flags);
> +
> +exit:
> + drm_dev_exit(idx);
> }
>
> /*
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 4d32233cde92..04ba5eef1e88 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -31,6 +31,8 @@
> #include "amdgpu_ras.h"
> #include "amdgpu_xgmi.h"
>
> +#include
> +
> /**
> * amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
> *
> @@ -151,6 +153,10 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev,
> void *cpu_pt_addr,
> {
> void __iomem *ptr = (void *)cpu_pt_addr;
> uint64_t value;
> + int idx;
> +
> + if (!drm_dev_enter(&adev->ddev, &idx))
> + return 0;
>
> /*
> * The following is for PTE only. GART does not have PDEs.
> @@ -158,6 +164,9 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev,
> void *cpu_pt_addr,
> value = addr & 0xF000ULL;
> value |= flags;
> writeq(value, ptr + (gpu_page_idx * 8));
> +
> + drm_dev_exit(idx);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index 9e769cf6095b..bb6afee61666 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -25,6 +25,7 @@
>
> #include
> #include
> +#include
>
> #include "amdgpu.h"
> #include "amdgpu_psp.h"
> @@ -39,6 +40,8 @@
> #include "amdgpu_ras.h"
> #include "amdgpu_securedisplay.h"
>
> +#include
> +
> static int psp_sysfs_init(struct amdgpu_device *adev);
> static void psp_sysfs_fini(struct amdgpu_device *adev);
>
> @@ -253,7 +256,7 @@ psp_cmd_submit_buf(struct psp_context *psp,
>struct psp_gfx_cmd_resp *cmd, uint64_t fence_mc_addr)
> {
> int ret;
> - int index;
> + int index, idx;
> int timeout = 2;
> bool ras_intr = false;
> bool skip_unsupport = false;
> @@ -261,6 +264,9 @@ psp_cmd_submit
Re: [PATCH V4 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On Sat, May 8, 2021 at 3:24 PM Marek Vasut wrote: > > Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge > and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS > bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, > but easy to add. > > The driver operates the chip via I2C bus. Currently the LVDS clock are > always derived from DSI clock lane, which is the usual mode of operation. > Support for clock from external oscillator is not implemented, but it is > easy to add if ever needed. Only RGB888 pixel format is implemented, the > LVDS666 is not supported, but could be added if needed. > Tested-by: Adam Ford > Reviewed-by: Linus Walleij > Reviewed-by: Frieder Schrempf > Tested-by: Frieder Schrempf > Signed-off-by: Marek Vasut > Cc: Douglas Anderson > Cc: Jagan Teki > Cc: Laurent Pinchart > Cc: Linus Walleij > Cc: Loic Poulain > Cc: Philippe Schenker > Cc: Sam Ravnborg > Cc: Stephen Boyd > Cc: Valentin Raevsky > To: dri-devel@lists.freedesktop.org > --- > V2: - Use dev_err_probe() > - Set REG_RC_RESET as volatile > - Wait for PLL stabilization by polling REG_RC_LVDS_PLL > - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set > - Add tested DSI84 support in dual-link mode > - Correctly set VCOM > - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 > datasheets, with that all the reserved bits make far more sense > as the DSI83 and DSI84 seems to be reduced version of DSI85 > V3: - Handle the dual-link LVDS with two port panel or bridge > V4: - Add RB from Linus Walleij > - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to > REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining > DSI link options from DSI85 datasheet. DSI85 can do dual and 2x > single DSI mode, but DSI85 is currently unsupported by the > driver. Add a comment about DSI85, so that all the places which > need to be adjusted for DSI85 are marked accordingly. > - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI > - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 > as fallback on output bridges until they are all fixed. > - Patch DSI bus format to fixed RGB888_1X24 instead of passing > through the LVDS bus format. > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 698 ++ > 3 files changed, 709 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index e83b8ad0d71b..32204c5f25b7 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -278,6 +278,16 @@ config DRM_TI_TFP410 > help > Texas Instruments TFP410 DVI/HDMI Transmitter driver > > +config DRM_TI_SN65DSI83 > + tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + select DRM_PANEL > + select DRM_MIPI_DSI > + help > + Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver > + > config DRM_TI_SN65DSI86 > tristate "TI SN65DSI86 DSI to eDP bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index b00f3b2ad572..7bb4c9df0415 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > new file mode 100644 > index ..1a0a71fbe91d > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > @@ -0,0 +1,698 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * TI SN65DSI83,84,85 driver > + * > + * Currently supported: > + * - SN65DSI83 > + * = 1x Single-link DSI ~ 1x Single-link LVDS > + * - Supported > + * - Single-link LVDS mode tested > + * - SN65DSI84 > + * = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS > + * - Supported > + * - Dual-link LVDS mode tested > + * - 2x Single-link LVDS mode unsupported > + * (should be easy to add by someone who has the HW) > + * - SN65DSI85 > + * = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link > LVDS > + * - Unsupported > + * (should be easy to add by someone who has the HW) > + * > + * Copyright (C) 2021 Marek Vasut > + * > + * Based on previous work of: > + * Valentin Raevsky > + * P
[PATCH][next] drm/vmwgfx: Fix memory leak of object fifo on error return
From: Colin Ian King
In the case where fifo->static_buffer fails to be allocated the
error return path neglects to kfree the fifo object. Fix this by
adding in the missing kfree.
Addresses-Coverity: ("Resource leak")
Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
index 027d7d504e78..e5fa210f589e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
@@ -107,8 +107,10 @@ struct vmw_fifo_state *vmw_fifo_create(struct vmw_private
*dev_priv)
fifo = kzalloc(sizeof(*fifo), GFP_KERNEL);
fifo->static_buffer_size = VMWGFX_FIFO_STATIC_SIZE;
fifo->static_buffer = vmalloc(fifo->static_buffer_size);
- if (unlikely(fifo->static_buffer == NULL))
+ if (unlikely(fifo->static_buffer == NULL)) {
+ kfree(fifo);
return ERR_PTR(-ENOMEM);
+ }
fifo->dynamic_buffer = NULL;
fifo->reserved_size = 0;
--
2.30.2
Re: [PATCH] drm/nouveau: Remove invalid reference to struct drm_device.pdev
On Thu, 13 May 2021 at 04:55, Thomas Zimmermann wrote:
>
> The pdev field got removed from struct drm_device recently. Replace
> the invalid reference with an upcast from the struct's dev field.
>
> Signed-off-by: Thomas Zimmermann
> Reported-by: Stephen Rothwell
> Fixes: b347e04452ff ("drm: Remove pdev field from struct drm_device")
> Cc: Thomas Zimmermann
> Cc: Maxime Ripard
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Dave Airlie
> ---
> This patch should be merged through drm-misc-next.
please land asap.
Thanks,
Dave.
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 7f38788a6c2b..2a298c171d4d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -460,7 +460,8 @@ nouveau_connector_of_detect(struct drm_connector
> *connector)
> struct drm_device *dev = connector->dev;
> struct nouveau_connector *nv_connector = nouveau_connector(connector);
> struct nouveau_encoder *nv_encoder;
> - struct device_node *cn, *dn = pci_device_to_OF_node(dev->pdev);
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> + struct device_node *cn, *dn = pci_device_to_OF_node(pdev);
>
> if (!dn ||
> !((nv_encoder = find_encoder(connector, DCB_OUTPUT_TMDS)) ||
> --
> 2.31.1
>
[pull] amdgpu, amdkfd, radeon drm-next-5.14
Hi Dave, Daniel, First set of new changes for 5.14. The following changes since commit af8352f1ff54c4fecf84e36315fd1928809a580b: Merge tag 'drm-msm-next-2021-04-11' of https://gitlab.freedesktop.org/drm/msm into drm-next (2021-04-13 23:35:54 +0200) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.14-2021-05-12 for you to fetch changes up to ae30d41eb54eb0926afb82ad5ee4fd3536cce060: drm/radeon/dpm: Disable sclk switching on Oland when two 4K 60Hz monitors are connected (2021-05-11 22:07:15 -0400) amd-drm-next-5.14-2021-05-12: amdgpu: - Aldebaran updates - More LTTPR display work - Vangogh updates - SDMA 5.x GCR fixes - RAS fixes - PCIe ASPM support - Modifier fixes - Enable TMZ on Renoir - Buffer object code cleanup - Display overlay fixes - Initial support for multiple eDP panels - Initial SR-IOV support for Aldebaran - DP link training refactor - Misc code cleanups and bug fixes - SMU regression fixes for variable sized arrays - MAINTAINERS fixes for amdgpu amdkfd: - Initial SR-IOV support for Aldebaran - Topology fixes - Initial HMM SVM support - Misc code cleanups and bug fixes radeon: - Misc code cleanups and bug fixes - SMU regression fixes for variable sized arrays - Flickering fix for Oland with multiple 4K displays UAPI: - amdgpu: Drop AMDGPU_GEM_CREATE_SHADOW flag. This was always a kernel internal flag and userspace use of it has always been blocked. It's no longer needed so remove it. - amdkgd: HMM SVM support Overview: https://patchwork.freedesktop.org/series/85562/ Porposed userspace: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/tree/fxkamd/hmm-wip Alex Deucher (12): drm/amdgpu/gmc9: remove dummy read workaround for newer chips drm/amdgpu/display: add documentation for dmcub_trace_event_en MAINTAINERS: fix a few more amdgpu tree links drm/amdgpu: Add graphics cache rinse packet for sdma 5.0 drm/amdgpu: drop the GCR packet from the emit_ib frame for sdma5.0 drm/amdgpu: change the default timeout for kernel compute queues drm/amdgpu/pm: add documentation for pp_od_clock_voltage for APUs drm/amdgpu/pm: add documentation for pp_od_clock_voltage for vangogh drm/amdgpu/display: remove an old DCN3 guard drm/amdgpu/display: fix warning when CONFIG_DRM_AMD_DC_DCN is not defined drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DCN is not defined drm/amdgpu/display: fix dal_allocation documentation Alex Sierra (12): drm/amdkfd: helper to convert gpu id and idx drm/amdkfd: add xnack enabled flag to kfd_process drm/amdkfd: add ioctl to configure and query xnack retries drm/amdgpu: enable 48-bit IH timestamp counter drm/amdkfd: SVM API call to restore page tables drm/amdkfd: add svm_bo reference for eviction fence drm/amdgpu: add param bit flag to create SVM BOs drm/amdgpu: svm bo enable_signal call condition drm/amdgpu: add svm_bo eviction to enable_signal cb drm/amdgpu: extend xnack limit page fault timeout drm/amdkfd: svm ranges creation for unregistered memory drm/amdkfd: set attribute access for default ranges Anthony Koo (6): drm/amd/display: [FW Promotion] Release 0.0.60 drm/amd/display: [FW Promotion] Release 0.0.61 drm/amd/display: [FW Promotion] Release 0.0.62 drm/amd/display: [FW Promotion] Release 0.0.63 drm/amd/display: [FW Promotion] Release 0.0.64 drm/amd/display: [FW Promotion] Release 0.0.65 Anthony Wang (4): drm/amd/display: Force vsync flip when reconfiguring MPCC drm/amd/display: Add DSC check to seamless boot validation drm/amd/display: disable seamless boot for external DP drm/amd/display: Handle potential dpp_inst mismatch with pipe_idx Aric Cyr (8): drm/amd/display: 3.2.131 drm/amd/display: Fix FreeSync when RGB MPO in use drm/amd/display: 3.2.132 drm/amd/display: 3.2.133 drm/amdgpu/dc: Revert commit "treat memory as a single-channel" drm/amd/display: 3.2.134 drm/amd/display: 3.2.135 drm/amd/display: 3.2.135.1 Bas Nieuwenhuizen (2): drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode. drm/amdgpu: Use device specific BO size & stride check. Bing Guo (1): drm/amd/display: add helper for enabling mst stream features Brandon Syu (1): drm/amd/display: fix HDCP reset sequence on reinitialize Calvin Hou (1): drm/amd/display: remove checking sink in is_timing_changed Chaitanya Dhere (1): drm/amd/display: DETBufferSizeInKbyte variable type modifications Chris Park (1): drm/amd/display: Fix BSOD with NULL check Christian König (4): drm/amdgpu: fix coding style and documentation in amdgpu_gtt_mgr.c drm/amdgpu: fix coding style and documentation
Re: linux-next: build failure after merge of the drm-misc tree
Hi
Am 12.05.21 um 07:00 schrieb Stephen Rothwell:
Hi all,
After merging the drm-misc tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpu/drm/nouveau/nouveau_connector.c: In function
'nouveau_connector_of_detect':
drivers/gpu/drm/nouveau/nouveau_connector.c:463:59: error: 'struct drm_device'
has no member named 'pdev'; did you mean 'dev'?
463 | struct device_node *cn, *dn = pci_device_to_OF_node(dev->pdev);
| ^~~~
| dev
Caused by commit
b347e04452ff ("drm: Remove pdev field from struct drm_device")
I have reverted that commit for today.
Thanks for reporting. pdev is gone, but the references are sometimes
hard to find. You may want to undo the revert and try the fix at [1].
The patch should hit drm-misc-next ASAP.
Best regards
Thomas
[1]
https://lore.kernel.org/dri-devel/20210512185527.26050-1-tzimmerm...@suse.de/T/#u
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH] drm/nouveau: Remove invalid reference to struct drm_device.pdev
The pdev field got removed from struct drm_device recently. Replace
the invalid reference with an upcast from the struct's dev field.
Signed-off-by: Thomas Zimmermann
Reported-by: Stephen Rothwell
Fixes: b347e04452ff ("drm: Remove pdev field from struct drm_device")
Cc: Thomas Zimmermann
Cc: Maxime Ripard
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
This patch should be merged through drm-misc-next.
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7f38788a6c2b..2a298c171d4d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -460,7 +460,8 @@ nouveau_connector_of_detect(struct drm_connector *connector)
struct drm_device *dev = connector->dev;
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder;
- struct device_node *cn, *dn = pci_device_to_OF_node(dev->pdev);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+ struct device_node *cn, *dn = pci_device_to_OF_node(pdev);
if (!dn ||
!((nv_encoder = find_encoder(connector, DCB_OUTPUT_TMDS)) ||
--
2.31.1
[PATCH AUTOSEL 5.4 18/23] drm/amd/display: Fix two cursor duplication when using overlay
From: Rodrigo Siqueira
[ Upstream commit 16e9b3e58bc3fce7391539e0eb3fd167cbf9951f ]
Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have constraints when userspace tries to
enable hardware cursor with various planes. Basically, we cannot draw
the cursor at the same size and position on two separated pipes since it
uses extra bandwidth and DML only run with one cursor.
For those reasons, when we enable hardware cursor and multiple planes,
our driver should accept variations like the ones described below:
+-+ +--+
| +-+ | | |
| |Primary | | | Primary |
| | | | | Overlay |
| +-+ | | |
|Overlay | | |
+-+ +--+
In this scenario, we can have the desktop UI in the overlay and some
other framebuffer attached to the primary plane (e.g., video). However,
userspace needs to obey some rules and avoid scenarios like the ones
described below (when enabling hw cursor):
++
|Overlay |
+-++-+---+ +-||--+
| ++ | ++ | | ++ |
| |Overlay | | |Overlay | | | |
| || | || | | |
| ++ | ++ | | |
| Primary || Primary | | Primary |
+-++-+ +-+
+-+ +-+
| ++ | Primary|
| |Overlay | | |
| || | |
| ++ | ++ |
| Primary | | |Overlay | |
+-+ +-||--+
++
If the userspace violates some of the above scenarios, our driver needs
to reject the commit; otherwise, we can have unexpected behavior. Since
we don't have a proper driver validation for the above case, we can see
some problems like a duplicate cursor in applications that use multiple
planes. This commit fixes the cursor issue and others by adding adequate
verification for multiple planes.
Change since V1 (Harry and Sean):
- Remove cursor verification from the equation.
Cc: Louis Li
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Hersen Wu
Cc: Sean Paul
Signed-off-by: Rodrigo Siqueira
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index fbbe611d4873..800dc67c98f1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7254,6 +7254,53 @@ static int add_affected_mst_dsc_crtcs(struct
drm_atomic_state *state, struct drm
}
#endif
+static int validate_overlay(struct drm_atomic_state *state)
+{
+ int i;
+ struct drm_plane *plane;
+ struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane_state *primary_state, *overlay_state = NULL;
+
+ /* Check if primary plane is contained inside overlay */
+ for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
new_plane_state, i) {
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
+ if (drm_atomic_plane_disabling(plane->state,
new_plane_state))
+ return 0;
+
+ overlay_state = new_plane_state;
+ continue;
+ }
+ }
+
+ /* check if we're making changes to the overlay plane */
+ if (!overlay_state)
+ return 0;
+
+ /* check if overlay plane is enabled */
+ if (!overlay_state->crtc)
+ return 0;
+
+ /* find the primary plane for the CRTC that the overlay is enabled on */
+ primary_state = drm_atomic_get_plane_state(state,
overlay_state->crtc->primary);
+ if (IS_ERR(primary_state))
+ return PTR_ERR(primary_state);
+
+ /* check if primary plane is enabled */
+ if (!primary_state->crtc)
+ return 0;
+
+ /* Perform the bounds check to ensure the overlay plane covers the
primary */
+ if (primary_state->crtc_x < overlay_state->crtc_x ||
+ primary_state->crtc_y < overlay_state->crtc_y ||
+ primary_state->crtc_x + primary_state->crtc_w >
overlay_state->crtc_x + overlay_state->crtc_w ||
+ primary_state->crtc_y + primary_state->crtc_h >
overlay_state->crtc_y + overlay_state->crtc_h) {
+ DRM_DEBUG_ATOMIC("Overlay plane is enabled with hardware cursor
but does not fully cover pr
[PATCH AUTOSEL 5.10 28/34] drm/amd/display: Fix two cursor duplication when using overlay
From: Rodrigo Siqueira
[ Upstream commit 16e9b3e58bc3fce7391539e0eb3fd167cbf9951f ]
Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have constraints when userspace tries to
enable hardware cursor with various planes. Basically, we cannot draw
the cursor at the same size and position on two separated pipes since it
uses extra bandwidth and DML only run with one cursor.
For those reasons, when we enable hardware cursor and multiple planes,
our driver should accept variations like the ones described below:
+-+ +--+
| +-+ | | |
| |Primary | | | Primary |
| | | | | Overlay |
| +-+ | | |
|Overlay | | |
+-+ +--+
In this scenario, we can have the desktop UI in the overlay and some
other framebuffer attached to the primary plane (e.g., video). However,
userspace needs to obey some rules and avoid scenarios like the ones
described below (when enabling hw cursor):
++
|Overlay |
+-++-+---+ +-||--+
| ++ | ++ | | ++ |
| |Overlay | | |Overlay | | | |
| || | || | | |
| ++ | ++ | | |
| Primary || Primary | | Primary |
+-++-+ +-+
+-+ +-+
| ++ | Primary|
| |Overlay | | |
| || | |
| ++ | ++ |
| Primary | | |Overlay | |
+-+ +-||--+
++
If the userspace violates some of the above scenarios, our driver needs
to reject the commit; otherwise, we can have unexpected behavior. Since
we don't have a proper driver validation for the above case, we can see
some problems like a duplicate cursor in applications that use multiple
planes. This commit fixes the cursor issue and others by adding adequate
verification for multiple planes.
Change since V1 (Harry and Sean):
- Remove cursor verification from the equation.
Cc: Louis Li
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Hersen Wu
Cc: Sean Paul
Signed-off-by: Rodrigo Siqueira
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c07737c45677..4d4d1cc157ae 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8589,6 +8589,53 @@ static int add_affected_mst_dsc_crtcs(struct
drm_atomic_state *state, struct drm
}
#endif
+static int validate_overlay(struct drm_atomic_state *state)
+{
+ int i;
+ struct drm_plane *plane;
+ struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane_state *primary_state, *overlay_state = NULL;
+
+ /* Check if primary plane is contained inside overlay */
+ for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
new_plane_state, i) {
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
+ if (drm_atomic_plane_disabling(plane->state,
new_plane_state))
+ return 0;
+
+ overlay_state = new_plane_state;
+ continue;
+ }
+ }
+
+ /* check if we're making changes to the overlay plane */
+ if (!overlay_state)
+ return 0;
+
+ /* check if overlay plane is enabled */
+ if (!overlay_state->crtc)
+ return 0;
+
+ /* find the primary plane for the CRTC that the overlay is enabled on */
+ primary_state = drm_atomic_get_plane_state(state,
overlay_state->crtc->primary);
+ if (IS_ERR(primary_state))
+ return PTR_ERR(primary_state);
+
+ /* check if primary plane is enabled */
+ if (!primary_state->crtc)
+ return 0;
+
+ /* Perform the bounds check to ensure the overlay plane covers the
primary */
+ if (primary_state->crtc_x < overlay_state->crtc_x ||
+ primary_state->crtc_y < overlay_state->crtc_y ||
+ primary_state->crtc_x + primary_state->crtc_w >
overlay_state->crtc_x + overlay_state->crtc_w ||
+ primary_state->crtc_y + primary_state->crtc_h >
overlay_state->crtc_y + overlay_state->crtc_h) {
+ DRM_DEBUG_ATOMIC("Overlay plane is enabled with hardware cursor
but does not fully cover pr
[PATCH AUTOSEL 5.10 24/34] amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID
From: Darren Powell
[ Upstream commit b117b3964f38a988cb79825950dbd607c02237f3 ]
Writing to dcefclk causes the gpu to become unresponsive, and requires a reboot.
Patch ignores a .force_clk_levels(SMU_DCEFCLK) call and issues an
info message.
Signed-off-by: Darren Powell
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 5 -
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index f2c8719b8395..52df6202a954 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -1110,7 +1110,6 @@ static int navi10_force_clk_levels(struct smu_context
*smu,
case SMU_SOCCLK:
case SMU_MCLK:
case SMU_UCLK:
- case SMU_DCEFCLK:
case SMU_FCLK:
/* There is only 2 levels for fine grained DPM */
if (navi10_is_support_fine_grained_dpm(smu, clk_type)) {
@@ -1130,6 +1129,10 @@ static int navi10_force_clk_levels(struct smu_context
*smu,
if (ret)
return size;
break;
+ case SMU_DCEFCLK:
+ dev_info(smu->adev->dev,"Setting DCEFCLK min/max dpm level is
not supported!\n");
+ break;
+
default:
break;
}
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 31da8fae6fa9..471bbb78884b 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -1018,7 +1018,6 @@ static int sienna_cichlid_force_clk_levels(struct
smu_context *smu,
case SMU_SOCCLK:
case SMU_MCLK:
case SMU_UCLK:
- case SMU_DCEFCLK:
case SMU_FCLK:
/* There is only 2 levels for fine grained DPM */
if (sienna_cichlid_is_support_fine_grained_dpm(smu, clk_type)) {
@@ -1038,6 +1037,9 @@ static int sienna_cichlid_force_clk_levels(struct
smu_context *smu,
if (ret)
goto forec_level_out;
break;
+ case SMU_DCEFCLK:
+ dev_info(smu->adev->dev,"Setting DCEFCLK min/max dpm level is
not supported!\n");
+ break;
default:
break;
}
--
2.30.2
[PATCH AUTOSEL 5.11 29/35] drm/amd/display: Fix two cursor duplication when using overlay
From: Rodrigo Siqueira
[ Upstream commit 16e9b3e58bc3fce7391539e0eb3fd167cbf9951f ]
Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have constraints when userspace tries to
enable hardware cursor with various planes. Basically, we cannot draw
the cursor at the same size and position on two separated pipes since it
uses extra bandwidth and DML only run with one cursor.
For those reasons, when we enable hardware cursor and multiple planes,
our driver should accept variations like the ones described below:
+-+ +--+
| +-+ | | |
| |Primary | | | Primary |
| | | | | Overlay |
| +-+ | | |
|Overlay | | |
+-+ +--+
In this scenario, we can have the desktop UI in the overlay and some
other framebuffer attached to the primary plane (e.g., video). However,
userspace needs to obey some rules and avoid scenarios like the ones
described below (when enabling hw cursor):
++
|Overlay |
+-++-+---+ +-||--+
| ++ | ++ | | ++ |
| |Overlay | | |Overlay | | | |
| || | || | | |
| ++ | ++ | | |
| Primary || Primary | | Primary |
+-++-+ +-+
+-+ +-+
| ++ | Primary|
| |Overlay | | |
| || | |
| ++ | ++ |
| Primary | | |Overlay | |
+-+ +-||--+
++
If the userspace violates some of the above scenarios, our driver needs
to reject the commit; otherwise, we can have unexpected behavior. Since
we don't have a proper driver validation for the above case, we can see
some problems like a duplicate cursor in applications that use multiple
planes. This commit fixes the cursor issue and others by adding adequate
verification for multiple planes.
Change since V1 (Harry and Sean):
- Remove cursor verification from the equation.
Cc: Louis Li
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Hersen Wu
Cc: Sean Paul
Signed-off-by: Rodrigo Siqueira
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 62a637c03f60..75c743009b04 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9145,6 +9145,53 @@ static int add_affected_mst_dsc_crtcs(struct
drm_atomic_state *state, struct drm
}
#endif
+static int validate_overlay(struct drm_atomic_state *state)
+{
+ int i;
+ struct drm_plane *plane;
+ struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane_state *primary_state, *overlay_state = NULL;
+
+ /* Check if primary plane is contained inside overlay */
+ for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
new_plane_state, i) {
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
+ if (drm_atomic_plane_disabling(plane->state,
new_plane_state))
+ return 0;
+
+ overlay_state = new_plane_state;
+ continue;
+ }
+ }
+
+ /* check if we're making changes to the overlay plane */
+ if (!overlay_state)
+ return 0;
+
+ /* check if overlay plane is enabled */
+ if (!overlay_state->crtc)
+ return 0;
+
+ /* find the primary plane for the CRTC that the overlay is enabled on */
+ primary_state = drm_atomic_get_plane_state(state,
overlay_state->crtc->primary);
+ if (IS_ERR(primary_state))
+ return PTR_ERR(primary_state);
+
+ /* check if primary plane is enabled */
+ if (!primary_state->crtc)
+ return 0;
+
+ /* Perform the bounds check to ensure the overlay plane covers the
primary */
+ if (primary_state->crtc_x < overlay_state->crtc_x ||
+ primary_state->crtc_y < overlay_state->crtc_y ||
+ primary_state->crtc_x + primary_state->crtc_w >
overlay_state->crtc_x + overlay_state->crtc_w ||
+ primary_state->crtc_y + primary_state->crtc_h >
overlay_state->crtc_y + overlay_state->crtc_h) {
+ DRM_DEBUG_ATOMIC("Overlay plane is enabled with hardware cursor
but does not fully cover pr
[PATCH AUTOSEL 5.11 25/35] amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID
From: Darren Powell
[ Upstream commit b117b3964f38a988cb79825950dbd607c02237f3 ]
Writing to dcefclk causes the gpu to become unresponsive, and requires a reboot.
Patch ignores a .force_clk_levels(SMU_DCEFCLK) call and issues an
info message.
Signed-off-by: Darren Powell
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 5 -
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index cd7efa923195..ab702e1cd9f0 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -1110,7 +1110,6 @@ static int navi10_force_clk_levels(struct smu_context
*smu,
case SMU_SOCCLK:
case SMU_MCLK:
case SMU_UCLK:
- case SMU_DCEFCLK:
case SMU_FCLK:
/* There is only 2 levels for fine grained DPM */
if (navi10_is_support_fine_grained_dpm(smu, clk_type)) {
@@ -1130,6 +1129,10 @@ static int navi10_force_clk_levels(struct smu_context
*smu,
if (ret)
return size;
break;
+ case SMU_DCEFCLK:
+ dev_info(smu->adev->dev,"Setting DCEFCLK min/max dpm level is
not supported!\n");
+ break;
+
default:
break;
}
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index d68d3dfee51d..aa231336d9f0 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -1025,7 +1025,6 @@ static int sienna_cichlid_force_clk_levels(struct
smu_context *smu,
case SMU_SOCCLK:
case SMU_MCLK:
case SMU_UCLK:
- case SMU_DCEFCLK:
case SMU_FCLK:
/* There is only 2 levels for fine grained DPM */
if (sienna_cichlid_is_support_fine_grained_dpm(smu, clk_type)) {
@@ -1045,6 +1044,9 @@ static int sienna_cichlid_force_clk_levels(struct
smu_context *smu,
if (ret)
goto forec_level_out;
break;
+ case SMU_DCEFCLK:
+ dev_info(smu->adev->dev,"Setting DCEFCLK min/max dpm level is
not supported!\n");
+ break;
default:
break;
}
--
2.30.2
[PATCH AUTOSEL 5.12 31/37] drm/amd/display: Fix two cursor duplication when using overlay
From: Rodrigo Siqueira
[ Upstream commit 16e9b3e58bc3fce7391539e0eb3fd167cbf9951f ]
Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have constraints when userspace tries to
enable hardware cursor with various planes. Basically, we cannot draw
the cursor at the same size and position on two separated pipes since it
uses extra bandwidth and DML only run with one cursor.
For those reasons, when we enable hardware cursor and multiple planes,
our driver should accept variations like the ones described below:
+-+ +--+
| +-+ | | |
| |Primary | | | Primary |
| | | | | Overlay |
| +-+ | | |
|Overlay | | |
+-+ +--+
In this scenario, we can have the desktop UI in the overlay and some
other framebuffer attached to the primary plane (e.g., video). However,
userspace needs to obey some rules and avoid scenarios like the ones
described below (when enabling hw cursor):
++
|Overlay |
+-++-+---+ +-||--+
| ++ | ++ | | ++ |
| |Overlay | | |Overlay | | | |
| || | || | | |
| ++ | ++ | | |
| Primary || Primary | | Primary |
+-++-+ +-+
+-+ +-+
| ++ | Primary|
| |Overlay | | |
| || | |
| ++ | ++ |
| Primary | | |Overlay | |
+-+ +-||--+
++
If the userspace violates some of the above scenarios, our driver needs
to reject the commit; otherwise, we can have unexpected behavior. Since
we don't have a proper driver validation for the above case, we can see
some problems like a duplicate cursor in applications that use multiple
planes. This commit fixes the cursor issue and others by adding adequate
verification for multiple planes.
Change since V1 (Harry and Sean):
- Remove cursor verification from the equation.
Cc: Louis Li
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Hersen Wu
Cc: Sean Paul
Signed-off-by: Rodrigo Siqueira
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d699a5cf6c11..c6c32456ee5f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9312,6 +9312,53 @@ static int add_affected_mst_dsc_crtcs(struct
drm_atomic_state *state, struct drm
}
#endif
+static int validate_overlay(struct drm_atomic_state *state)
+{
+ int i;
+ struct drm_plane *plane;
+ struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane_state *primary_state, *overlay_state = NULL;
+
+ /* Check if primary plane is contained inside overlay */
+ for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
new_plane_state, i) {
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
+ if (drm_atomic_plane_disabling(plane->state,
new_plane_state))
+ return 0;
+
+ overlay_state = new_plane_state;
+ continue;
+ }
+ }
+
+ /* check if we're making changes to the overlay plane */
+ if (!overlay_state)
+ return 0;
+
+ /* check if overlay plane is enabled */
+ if (!overlay_state->crtc)
+ return 0;
+
+ /* find the primary plane for the CRTC that the overlay is enabled on */
+ primary_state = drm_atomic_get_plane_state(state,
overlay_state->crtc->primary);
+ if (IS_ERR(primary_state))
+ return PTR_ERR(primary_state);
+
+ /* check if primary plane is enabled */
+ if (!primary_state->crtc)
+ return 0;
+
+ /* Perform the bounds check to ensure the overlay plane covers the
primary */
+ if (primary_state->crtc_x < overlay_state->crtc_x ||
+ primary_state->crtc_y < overlay_state->crtc_y ||
+ primary_state->crtc_x + primary_state->crtc_w >
overlay_state->crtc_x + overlay_state->crtc_w ||
+ primary_state->crtc_y + primary_state->crtc_h >
overlay_state->crtc_y + overlay_state->crtc_h) {
+ DRM_DEBUG_ATOMIC("Overlay plane is enabled with hardware cursor
but does not fully cover pr
[PATCH AUTOSEL 5.12 27/37] amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID
From: Darren Powell
[ Upstream commit b117b3964f38a988cb79825950dbd607c02237f3 ]
Writing to dcefclk causes the gpu to become unresponsive, and requires a reboot.
Patch ignores a .force_clk_levels(SMU_DCEFCLK) call and issues an
info message.
Signed-off-by: Darren Powell
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 5 -
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 6e641f1513d8..fbff3df72e6c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -1110,7 +1110,6 @@ static int navi10_force_clk_levels(struct smu_context
*smu,
case SMU_SOCCLK:
case SMU_MCLK:
case SMU_UCLK:
- case SMU_DCEFCLK:
case SMU_FCLK:
/* There is only 2 levels for fine grained DPM */
if (navi10_is_support_fine_grained_dpm(smu, clk_type)) {
@@ -1130,6 +1129,10 @@ static int navi10_force_clk_levels(struct smu_context
*smu,
if (ret)
return size;
break;
+ case SMU_DCEFCLK:
+ dev_info(smu->adev->dev,"Setting DCEFCLK min/max dpm level is
not supported!\n");
+ break;
+
default:
break;
}
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index af73e1430af5..61438940c26e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -1127,7 +1127,6 @@ static int sienna_cichlid_force_clk_levels(struct
smu_context *smu,
case SMU_SOCCLK:
case SMU_MCLK:
case SMU_UCLK:
- case SMU_DCEFCLK:
case SMU_FCLK:
/* There is only 2 levels for fine grained DPM */
if (sienna_cichlid_is_support_fine_grained_dpm(smu, clk_type)) {
@@ -1147,6 +1146,9 @@ static int sienna_cichlid_force_clk_levels(struct
smu_context *smu,
if (ret)
goto forec_level_out;
break;
+ case SMU_DCEFCLK:
+ dev_info(smu->adev->dev,"Setting DCEFCLK min/max dpm level is
not supported!\n");
+ break;
default:
break;
}
--
2.30.2
Re: New uAPI for color management proposal and feedback request
On Wed, May 12, 2021 at 9:04 AM Ville Syrjälä wrote: > > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > > Hello, > > > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm > > properties I propose 4 new properties: > > "preferred pixel encoding", "active color depth", "active color range", and > > "active pixel encoding" > > > > > > Motivation: > > > > Current monitors have a variety pixel encodings available: RGB, YCbCr > > 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. > > > > In addition they might be full or limited RGB range and the monitors accept > > different bit depths. > > > > Currently the kernel driver for AMD and Intel GPUs automatically configure > > the color settings automatically with little > > to no influence of the user. However there are several real world scenarios > > where the user might disagree with the > > default chosen by the drivers and wants to set his or her own preference. > > > > Some examples: > > > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color > > information, some screens might look better on one > > than the other because of bad internal conversion. The driver currently > > however has a fixed default that is chosen if > > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change > > this currently is by editing and overloading > > the edid reported by the monitor to the kernel. > > > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some > > hardware might report that it supports the higher > > port clock, but because of bad shielding on the PC, the cable, or the > > monitor the screen cuts out every few seconds when > > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine > > without changing hardware. The drivers > > currently however always default to the "best available" option even if it > > might be broken. > > > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color > > by rapidly switching between 2 adjacent > > colors. They advertise themselves to the kernel as 10-bit monitors but the > > user might not like the "fake" 10-bit effect > > and prefer running at the native 8-bit per color. > > > > 4. Some screens are falsely classified as full RGB range wile they actually > > use limited RGB range. This results in > > washed out colors in dark and bright scenes. A user override can be helpful > > to manually fix this issue when it occurs. > > > > There already exist several requests, discussion, and patches regarding the > > thematic: > > > > - https://gitlab.freedesktop.org/drm/amd/-/issues/476 > > > > - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 > > > > - https://lkml.org/lkml/2021/5/7/695 > > > > - https://lkml.org/lkml/2021/5/11/416 > > > > > > Current State: > > > > I only know bits about the Intel i915 and AMD amdgpu driver. I don't know > > how other driver handle color management > > > > - "max bpc", global setting applied by both i915 (only on dp i think?) and > > amdgpu. Default value is "8". For every > > resolution + frequency combination the highest possible even number between > > 6 and max_bpc is chosen. If the range > > doesn't contain a valid mode the resolution + frequency combination is > > discarded (but I guess that would be a very > > special edge case, if existent at all, when 6 doesn't work but 10 would > > work). Intel HDMI code always checks 8, 12, and > > 10 and does not check the max_bpc setting. > > i915 does limit things below max_bpc for both HDMI and DP. > > > > > - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not > > amdgpu), overwrites the kernel chosen color > > range setting (full or limited). If I recall correctly Intel HDMI code > > defaults to full unless this property is set, > > Intel dp code tries to probe the monitor to find out what to use. amdgpu > > has no corresponding setting (I don't know how > > it's decided there). > > i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP > specs. Unfortunately as you already mentioned there are quite a few > monitors (DP monitors in particular) that don't implemnt the spec > correctly. IIRC later DP specs even relaxed the wording to say > that you can basically ignore the spec and do whatever you want. > Which I supose is just admitting defeat and concluding that there > is no way to get this right 100% of the time. > > > > > - RGB pixel encoding can be forced by overloading a Monitors edid with one > > that tells the kernel that only RGB is > > possible. That doesn't work for YCbCr 4:4:4 however because of the edid > > specification. Forcing YCbCr 4:2:0 would > > theoretically also be possible this way. amdgpu has a debugfs switch > > "force_ycbcr_420" which makes the driver default to > > YCbCr 4:2:0 on all monitors if possible. > > > > > > Proposed Solution: > > > > 1. Add a new uAPI property "preferred pixel encoding", as a per port > > setting. > > > > - An amdg
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
On Wed, 2021-05-12 at 17:17 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 10:14:44 -0400
> "Theodore Ts'o" escreveu:
>
> > On Wed, May 12, 2021 at 02:50:04PM +0200, Mauro Carvalho Chehab wrote:
> > > v2:
> > > - removed EM/EN DASH conversion from this patchset;
> >
> > Are you still thinking about doing the
> >
> > EN DASH --> "--"
> > EM DASH --> "---"
> >
> > conversion?
>
> Yes, but I intend to submit it on a separate patch series, probably after
> having this one merged. Let's first cleanup the large part of the
> conversion-generated UTF-8 char noise ;-)
>
> > That's not going to change what the documentation will
> > look like in the HTML and PDF output forms, and I think it would make
> > life easier for people are reading and editing the Documentation/*
> > files in text form.
>
> Agreed. I'm also considering to add a couple of cases of this char:
>
> - U+2026 ('…'): HORIZONTAL ELLIPSIS
>
> As Sphinx also replaces "..." into HORIZONTAL ELLIPSIS.
Er, what?
The *only* part of this whole enterprise that actually seemed to make
even a tiny bit of sense — rather than seeming like a thinly veiled
retrospective excuse for dragging us back in time by 30 years — was the
bit about making it easier to grep.
But if I understand you correctly, you're talking about using something
like C trigraphs to represent the perfectly reasonable text emdash
character ("—") as two hyphen-minuses ("--") in the source code of the
documentation? Isn't that going to achieve precisely the *opposite*? If
I select some text in the HTML output of the docs and then search for
it in the source code, that's going to *stop* it matching my search?
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
Your title 'Use ASCII subset' is now at least a bit *closer* to describing what the patches are actually doing, but it's still a bit misleading because you're only doing it for *some* characters. And the wording is still indicative of a fundamentally *misguided* motivation for doing any of this. Your commit comments should be about fixing a specific thing, nothing to do with "use ASCII subset", which is pointless in itself. On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote: > Such conversion tools - plus some text editor like LibreOffice or similar - > have > a set of rules that turns some typed ASCII characters into UTF-8 alternatives, > for instance converting commas into curly commas and adding non-breakable > spaces. All of those are meant to produce better results when the text is > displayed in HTML or PDF formats. And don't we render our documentation into HTML or PDF formats? Are some of those non-breaking spaces not actually *useful* for their intended purpose? > While it is perfectly fine to use UTF-8 characters in Linux, and specially at > the documentation, it is better to stick to the ASCII subset on such > particular case, due to a couple of reasons: > > 1. it makes life easier for tools like grep; Barely, as noted, because of things like line feeds. > 2. they easier to edit with the some commonly used text/source >code editors. That is nonsense. Any but the most broken and/or anachronistic environments and editors will be just fine. smime.p7s Description: S/MIME cryptographic signature
Re: [5.12 regression] ttm->pages NULL dereference with radeon driver
Hi Christian,
I can confirm that the patch provided fixes the issue in kernel version 5.12.2
Thank you.
On Wed, May 12, 2021 at 6:21 AM Christian König
wrote:
>
> Hi guys,
>
> adding a few people who ran into the problem as well and opened a kernel
> bug.
>
> Am 07.05.21 um 17:11 schrieb Christian König:
> > Hi Takashi,
> >
> > Am 07.05.21 um 17:08 schrieb Takashi Iwai:
> >> Hi,
> >>
> >> we've received a regression report showing NULL dereference Oops with
> >> radeon driver on 5.12 kernel:
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.opensuse.org%2Fshow_bug.cgi%3Fid%3D1185516&data=04%7C01%7Cchristian.koenig%40amd.com%7C64447e9e97604aaf117008d9116a742a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637559971181187178%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1LJMLxuuMjkfgnIt%2B5Z5n19ri%2BMTLMQvEEB%2F%2Fd6SVkg%3D&reserved=0
> >>
> >> It turned out that the recent TTM cleanup / refactoring via commit
> >> 0575ff3d33cd ("drm/radeon: stop using pages with
> >> drm_prime_sg_to_page_addr_arrays v2") is the culprit. On 5.12 kernel,
> >> ttm->pages is no longer allocated / set up, while the radeon driver
> >> still has a few places assuming the valid ttm->pages, and for the
> >> reporter (running the modesettig driver), radeon_gart_bind() hits the
> >> problem.
> >>
> >> A hackish patch below was confirmed to work, at least, but obviously
> >> we need a proper fix.
> >>
> >> Could you take a look at it?
> >
> > If that's all then that looks trivial to me.
> >
> > Going to provide a patch on Monday.
>
> Sorry, was a busy start into the week. I've just send a patch which
> should address the issue to you and the mailing list.
>
> Please test since I can't reproduce the problem locally.
>
> Thanks,
> Christian.
>
> >
> > Thanks for the notice,
> > Christian.
> >
> >>
> >>
> >> thanks,
> >>
> >> Takashi
> >>
> >> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> >> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> >> @@ -253,7 +253,7 @@ void radeon_gart_unbind(struct radeon_de
> >> t = offset / RADEON_GPU_PAGE_SIZE;
> >> p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
> >> for (i = 0; i < pages; i++, p++) {
> >> -if (rdev->gart.pages[p]) {
> >> +if (1 /*rdev->gart.pages[p]*/) {
> >> rdev->gart.pages[p] = NULL;
> >> for (j = 0; j < (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
> >> j++, t++) {
> >> rdev->gart.pages_entry[t] = rdev->dummy_page.entry;
> >> @@ -301,7 +301,7 @@ int radeon_gart_bind(struct radeon_devic
> >> p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
> >> for (i = 0; i < pages; i++, p++) {
> >> -rdev->gart.pages[p] = pagelist[i];
> >> +/* rdev->gart.pages[p] = pagelist[i]; */
> >> page_base = dma_addr[i];
> >> for (j = 0; j < (PAGE_SIZE / RADEON_GPU_PAGE_SIZE); j++,
> >> t++) {
> >> page_entry = radeon_gart_get_page_entry(page_base, flags);
> >> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> >> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> >> @@ -360,6 +360,8 @@ static int radeon_ttm_tt_pin_userptr(str
> >> if (current->mm != gtt->usermm)
> >> return -EPERM;
> >> +if (!ttm->pages)
> >> +return -EPERM;
> >> if (gtt->userflags & RADEON_GEM_USERPTR_ANONONLY) {
> >> /* check that we only pin down anonymous memory
> >> ___
> >> amd-gfx mailing list
> >> amd-...@lists.freedesktop.org
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cchristian.koenig%40amd.com%7C64447e9e97604aaf117008d9116a742a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637559971181187178%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RdzGp1FLxBKE%2ByPclrUBfQomRU0pQT%2F78Ewcj%2FBZ73g%3D&reserved=0
> >>
> >
[PATCH RESEND] video: ssd1307fb: Enable charge pump only on displays that actually have it
A note in the datasheet says:
"Patterns other than those given in the Command Table are prohibited to
enter the chip as a command; as unexpected results can occur."
So do not send the charge pump command to displays that do not support it.
Signed-off-by: Michal Vokáč
---
drivers/video/fbdev/ssd1307fb.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 1b0b2a096afa..54903ea2e3ac 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -497,14 +497,16 @@ static int ssd1307fb_init_regs(struct ssd1307fb_par *par)
return ret;
/* Turn on the DC-DC Charge Pump */
- ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
- if (ret < 0)
- return ret;
+ if (par->device_info->need_chargepump) {
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
+ if (ret < 0)
+ return ret;
- ret = ssd1307fb_write_cmd(par->client,
- BIT(4) | (par->device_info->need_chargepump ? BIT(2) : 0));
- if (ret < 0)
- return ret;
+ ret = ssd1307fb_write_cmd(par->client,
+ BIT(4) | (par->device_info->need_chargepump ? BIT(2) :
0));
+ if (ret < 0)
+ return ret;
+ }
/* Set lookup table */
if (par->lookup_table_set) {
--
2.1.4
[PATCH 5.12 342/677] drm/stm: Fix bus_flags handling
From: Marek Vasut
[ Upstream commit 99e360442f223dd40fc23ae07c7a263836fd27e6 ]
The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no
matter what polarity the next bridge or display might require, these flags
are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set
and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and
DISPLAY_FLAGS_DE_HIGH were always set.
The fix for this problem is taken almost verbatim from MXSFB driver. In
case there is a bridge attached to the LTDC, the bridge might have extra
polarity requirements, so extract bus_flags from the bridge and use them
for LTDC configuration. Otherwise, extract bus_flags from the connector,
which is the display.
Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
Signed-off-by: Marek Vasut
Signed-off-by: Yannick Fertre
Cc: Alexandre Torgue
Cc: Antonio Borneo
Cc: Benjamin Gaignard
Cc: Maxime Coquelin
Cc: Philippe Cornu
Cc: Sam Ravnborg
Cc: Vincent Abriou
Cc: Yannick Fertre
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
Tested-by: Yannick Fertre
Signed-off-by: Philippe Cornu
Link:
https://patchwork.freedesktop.org/patch/msgid/20210127110756.125570-1-ma...@denx.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/stm/ltdc.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 7812094f93d6..6f3b523e16e8 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -525,13 +525,42 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
struct drm_device *ddev = crtc->dev;
+ struct drm_connector_list_iter iter;
+ struct drm_connector *connector = NULL;
+ struct drm_encoder *encoder = NULL;
+ struct drm_bridge *bridge = NULL;
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
struct videomode vm;
u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
u32 total_width, total_height;
+ u32 bus_flags = 0;
u32 val;
int ret;
+ /* get encoder from crtc */
+ drm_for_each_encoder(encoder, ddev)
+ if (encoder->crtc == crtc)
+ break;
+
+ if (encoder) {
+ /* get bridge from encoder */
+ list_for_each_entry(bridge, &encoder->bridge_chain, chain_node)
+ if (bridge->encoder == encoder)
+ break;
+
+ /* Get the connector from encoder */
+ drm_connector_list_iter_begin(ddev, &iter);
+ drm_for_each_connector_iter(connector, &iter)
+ if (connector->encoder == encoder)
+ break;
+ drm_connector_list_iter_end(&iter);
+ }
+
+ if (bridge && bridge->timings)
+ bus_flags = bridge->timings->input_bus_flags;
+ else if (connector)
+ bus_flags = connector->display_info.bus_flags;
+
if (!pm_runtime_active(ddev->dev)) {
ret = pm_runtime_get_sync(ddev->dev);
if (ret) {
@@ -567,10 +596,10 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
- if (vm.flags & DISPLAY_FLAGS_DE_LOW)
+ if (bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= GCR_DEPOL;
- if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
val |= GCR_PCPOL;
reg_update_bits(ldev->regs, LTDC_GCR,
--
2.30.2
[PATCH 5.12 078/677] drm: bridge: fix ANX7625 use of mipi_dsi_() functions
From: Randy Dunlap
commit ed01fca38717169fcb61bd45ad1c3750d9c40d59 upstream.
The Analogix DRM ANX7625 bridge driver uses mips_dsi_() function
interfaces so it should select DRM_MIPI_DSI to prevent build errors.
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/analogix/anx7625.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
[drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
ERROR: modpost: "of_find_mipi_dsi_host_by_node"
[drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
ERROR: modpost: "mipi_dsi_device_unregister"
[drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/analogix/anx7625.ko]
undefined!
Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
Reported-by: kernel test robot
Signed-off-by: Randy Dunlap
Reviewed-by: Robert Foss
Cc: Xin Ji
Cc: Sam Ravnborg
Cc: dri-devel@lists.freedesktop.org
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: sta...@vger.kernel.org
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20210415183619.1431-1-rdun...@infradead.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/bridge/analogix/Kconfig |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -30,6 +30,7 @@ config DRM_ANALOGIX_ANX7625
tristate "Analogix Anx7625 MIPI to DP interface support"
depends on DRM
depends on OF
+ select DRM_MIPI_DSI
help
ANX7625 is an ultra-low power 4K mobile HD transmitter
designed for portable devices. It converts MIPI/DPI to
[PATCH 5.12 019/677] drm: bridge: fix LONTIUM use of mipi_dsi_() functions
From: Randy Dunlap
commit ad085b3a712a89e4a48472121b231add7a8362e4 upstream.
The Lontium DRM bridge drivers use mipi_dsi_() function interfaces so
they need to select DRM_MIPI_DSI to prevent build errors.
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "of_find_mipi_dsi_host_by_node"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "mipi_dsi_device_unregister"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko]
undefined!
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "of_find_mipi_dsi_host_by_node"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "mipi_dsi_device_unregister"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611.ko]
undefined!
WARNING: modpost: suppressed 5 unresolved symbol warnings because there were
too many)
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Reported-by: kernel test robot
Signed-off-by: Randy Dunlap
Reviewed-by: Adren Grassein
Cc: Dmitry Baryshkov
Cc: Sam Ravnborg
Cc: Vinod Koul
Cc: Bjorn Andersson
Cc: Srinivas Kandagatla
Cc: Adrien Grassein
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20210415183639.1487-1-rdun...@infradead.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/bridge/Kconfig |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -67,6 +67,7 @@ config DRM_LONTIUM_LT9611UXC
depends on OF
select DRM_PANEL_BRIDGE
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
help
Driver for Lontium LT9611UXC DSI to HDMI bridge
@@ -151,6 +152,7 @@ config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
select I2C_MUX
select SND_SOC_HDMI_CODEC if SND_SOC
@@ -200,6 +202,7 @@ config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
select DRM_PANEL
help
[PATCH 5.11 308/601] drm/stm: Fix bus_flags handling
From: Marek Vasut
[ Upstream commit 99e360442f223dd40fc23ae07c7a263836fd27e6 ]
The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no
matter what polarity the next bridge or display might require, these flags
are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set
and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and
DISPLAY_FLAGS_DE_HIGH were always set.
The fix for this problem is taken almost verbatim from MXSFB driver. In
case there is a bridge attached to the LTDC, the bridge might have extra
polarity requirements, so extract bus_flags from the bridge and use them
for LTDC configuration. Otherwise, extract bus_flags from the connector,
which is the display.
Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
Signed-off-by: Marek Vasut
Signed-off-by: Yannick Fertre
Cc: Alexandre Torgue
Cc: Antonio Borneo
Cc: Benjamin Gaignard
Cc: Maxime Coquelin
Cc: Philippe Cornu
Cc: Sam Ravnborg
Cc: Vincent Abriou
Cc: Yannick Fertre
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
Tested-by: Yannick Fertre
Signed-off-by: Philippe Cornu
Link:
https://patchwork.freedesktop.org/patch/msgid/20210127110756.125570-1-ma...@denx.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/stm/ltdc.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 3980677435cb..949511a0a24f 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -525,13 +525,42 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
struct drm_device *ddev = crtc->dev;
+ struct drm_connector_list_iter iter;
+ struct drm_connector *connector = NULL;
+ struct drm_encoder *encoder = NULL;
+ struct drm_bridge *bridge = NULL;
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
struct videomode vm;
u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
u32 total_width, total_height;
+ u32 bus_flags = 0;
u32 val;
int ret;
+ /* get encoder from crtc */
+ drm_for_each_encoder(encoder, ddev)
+ if (encoder->crtc == crtc)
+ break;
+
+ if (encoder) {
+ /* get bridge from encoder */
+ list_for_each_entry(bridge, &encoder->bridge_chain, chain_node)
+ if (bridge->encoder == encoder)
+ break;
+
+ /* Get the connector from encoder */
+ drm_connector_list_iter_begin(ddev, &iter);
+ drm_for_each_connector_iter(connector, &iter)
+ if (connector->encoder == encoder)
+ break;
+ drm_connector_list_iter_end(&iter);
+ }
+
+ if (bridge && bridge->timings)
+ bus_flags = bridge->timings->input_bus_flags;
+ else if (connector)
+ bus_flags = connector->display_info.bus_flags;
+
if (!pm_runtime_active(ddev->dev)) {
ret = pm_runtime_get_sync(ddev->dev);
if (ret) {
@@ -567,10 +596,10 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
- if (vm.flags & DISPLAY_FLAGS_DE_LOW)
+ if (bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= GCR_DEPOL;
- if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
val |= GCR_PCPOL;
reg_update_bits(ldev->regs, LTDC_GCR,
--
2.30.2
Re: [PATCH 1/1] drm/panfrost: Remove redundant error printing in panfrost_device_init()
On 11/05/2021 10:04, Zhen Lei wrote:
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
binary size.
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
Reviewed-by: Steven Price
I'll push to drm-misc-next.
Thanks,
Steve
---
drivers/gpu/drm/panfrost/panfrost_device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index fbcf5edbe367521..125ed973feaad0a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -238,7 +238,6 @@ int panfrost_device_init(struct panfrost_device *pfdev)
res = platform_get_resource(pfdev->pdev, IORESOURCE_MEM, 0);
pfdev->iomem = devm_ioremap_resource(pfdev->dev, res);
if (IS_ERR(pfdev->iomem)) {
- dev_err(pfdev->dev, "failed to ioremap iomem\n");
err = PTR_ERR(pfdev->iomem);
goto out_pm_domain;
}
[PATCH 5.11 069/601] drm: bridge: fix ANX7625 use of mipi_dsi_() functions
From: Randy Dunlap
commit ed01fca38717169fcb61bd45ad1c3750d9c40d59 upstream.
The Analogix DRM ANX7625 bridge driver uses mips_dsi_() function
interfaces so it should select DRM_MIPI_DSI to prevent build errors.
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/analogix/anx7625.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
[drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
ERROR: modpost: "of_find_mipi_dsi_host_by_node"
[drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
ERROR: modpost: "mipi_dsi_device_unregister"
[drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/analogix/anx7625.ko]
undefined!
Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
Reported-by: kernel test robot
Signed-off-by: Randy Dunlap
Reviewed-by: Robert Foss
Cc: Xin Ji
Cc: Sam Ravnborg
Cc: dri-devel@lists.freedesktop.org
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: sta...@vger.kernel.org
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20210415183619.1431-1-rdun...@infradead.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/bridge/analogix/Kconfig |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -30,6 +30,7 @@ config DRM_ANALOGIX_ANX7625
tristate "Analogix Anx7625 MIPI to DP interface support"
depends on DRM
depends on OF
+ select DRM_MIPI_DSI
help
ANX7625 is an ultra-low power 4K mobile HD transmitter
designed for portable devices. It converts MIPI/DPI to
[PATCH 5.11 015/601] drm: bridge: fix LONTIUM use of mipi_dsi_() functions
From: Randy Dunlap
commit ad085b3a712a89e4a48472121b231add7a8362e4 upstream.
The Lontium DRM bridge drivers use mipi_dsi_() function interfaces so
they need to select DRM_MIPI_DSI to prevent build errors.
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "of_find_mipi_dsi_host_by_node"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "mipi_dsi_device_unregister"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko]
undefined!
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "of_find_mipi_dsi_host_by_node"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "mipi_dsi_device_unregister"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611.ko]
undefined!
WARNING: modpost: suppressed 5 unresolved symbol warnings because there were
too many)
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Reported-by: kernel test robot
Signed-off-by: Randy Dunlap
Reviewed-by: Adren Grassein
Cc: Dmitry Baryshkov
Cc: Sam Ravnborg
Cc: Vinod Koul
Cc: Bjorn Andersson
Cc: Srinivas Kandagatla
Cc: Adrien Grassein
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20210415183639.1487-1-rdun...@infradead.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/bridge/Kconfig |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -67,6 +67,7 @@ config DRM_LONTIUM_LT9611UXC
depends on OF
select DRM_PANEL_BRIDGE
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
help
Driver for Lontium LT9611UXC DSI to HDMI bridge
@@ -151,6 +152,7 @@ config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
select I2C_MUX
select SND_SOC_HDMI_CODEC if SND_SOC
@@ -200,6 +202,7 @@ config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
select DRM_PANEL
help
[PATCH] drm/panfrost: Handle failure in panfrost_job_hw_submit()
Currently panfrost_job_hw_submit() returns void and therefore cannot
propagate failures to it's caller, which is a shame because it has two
failure paths. Currently these are handled by waiting for a job timeout
on the job even though it was never submitted. But we can do better.
Refactor to return a failure code from panfrost_job_hw_submit() and
report the failure back to the DRM scheduler. This means there's no need
to wait for the scheduler to timeout on the job and the failure can be
handled immediately.
Signed-off-by: Steven Price
---
This hopefully will also stop future reports of a PM reference
leak[1][2] which doesn't actually exist.
[1] https://lore.kernel.org/r/20200520110504.24388-1-dinghao.liu%40zju.edu.cn
[2]
https://lore.kernel.org/r/1620714551-106976-1-git-send-email-zou_wei%40huawei.com
---
drivers/gpu/drm/panfrost/panfrost_job.c | 27 -
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 6003cfeb1322..ac1ae38aaf12 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -148,21 +148,22 @@ static void panfrost_job_write_affinity(struct
panfrost_device *pfdev,
job_write(pfdev, JS_AFFINITY_NEXT_HI(js), affinity >> 32);
}
-static void panfrost_job_hw_submit(struct panfrost_job *job, int js)
+static int panfrost_job_hw_submit(struct panfrost_job *job, int js)
{
struct panfrost_device *pfdev = job->pfdev;
u32 cfg;
u64 jc_head = job->jc;
int ret;
- panfrost_devfreq_record_busy(&pfdev->pfdevfreq);
-
- ret = pm_runtime_get_sync(pfdev->dev);
+ ret = pm_runtime_resume_and_get(pfdev->dev);
if (ret < 0)
- return;
+ return ret;
+
+ panfrost_devfreq_record_busy(&pfdev->pfdevfreq);
if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js {
- return;
+ pm_runtime_put_autosuspend(pfdev->dev);
+ return -EBUSY;
}
cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu);
@@ -194,6 +195,8 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
job, js, jc_head);
job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
+
+ return 0;
}
static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
@@ -347,12 +350,11 @@ static struct dma_fence *panfrost_job_run(struct
drm_sched_job *sched_job)
struct panfrost_device *pfdev = job->pfdev;
int slot = panfrost_job_get_slot(job);
struct dma_fence *fence = NULL;
+ int err;
if (unlikely(job->base.s_fence->finished.error))
return NULL;
- pfdev->jobs[slot] = job;
-
fence = panfrost_fence_create(pfdev, slot);
if (IS_ERR(fence))
return NULL;
@@ -361,7 +363,14 @@ static struct dma_fence *panfrost_job_run(struct
drm_sched_job *sched_job)
dma_fence_put(job->done_fence);
job->done_fence = dma_fence_get(fence);
- panfrost_job_hw_submit(job, slot);
+ err = panfrost_job_hw_submit(job, slot);
+
+ if (err) {
+ dma_fence_put(fence);
+ return NULL;
+ }
+
+ pfdev->jobs[slot] = job;
return fence;
}
--
2.20.1
Re: [PATCH -next] drm/panfrost: Fix PM reference leak in panfrost_job_hw_submit()
On 11/05/2021 07:29, Zou Wei wrote: pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Zou Wei Thanks for the patch, but this is actually incorrect. panfrost_job_hw_submit() is expected to unconditionally increment the pm usage counter. This is because panfrost_job_hw_submit() can (currently) never fail, so in this case the job is considered "submitted" (even though it never reaches the hardware) and it's handled by the job timeout. However this is at least the second time[1] this phantom "reference leak" has been raised, so perhaps it's time to handle this better. I'll post a patch reworking panfrost_job_hw_submit() so it can fail. Thanks, Steve [1] https://lore.kernel.org/r/20200520110504.24388-1-dinghao.liu%40zju.edu.cn --- drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index 6003cfe..42d8dbc 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -157,7 +157,7 @@ static void panfrost_job_hw_submit(struct panfrost_job *job, int js) panfrost_devfreq_record_busy(&pfdev->pfdevfreq); - ret = pm_runtime_get_sync(pfdev->dev); + ret = pm_runtime_resume_and_get(pfdev->dev); if (ret < 0) return;
[PATCH v7 2/4] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight
From: ChiYuan Huang Adds DT binding document for Richtek RT4831 backlight. Signed-off-by: ChiYuan Huang Reviewed-by: Daniel Thompson --- since v7 - Add allOf property refer to common.yaml. - Remove default-brightness/max-brightness description and refer string. --- .../leds/backlight/richtek,rt4831-backlight.yaml | 62 ++ include/dt-bindings/leds/rt4831-backlight.h| 23 2 files changed, 85 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml create mode 100644 include/dt-bindings/leds/rt4831-backlight.h diff --git a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml new file mode 100644 index ..e0ac686 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/richtek,rt4831-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT4831 Backlight + +maintainers: + - ChiYuan Huang + +description: | + RT4831 is a mutifunctional device that can provide power to the LCD display + and LCD backlight. + + For the LCD backlight, it can provide four channel WLED driving capability. + Each channel driving current is up to 30mA + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf + +allOf: + - $ref: common.yaml# + +properties: + compatible: +const: richtek,rt4831-backlight + + default-brightness: +minimum: 0 +maximum: 2048 + + max-brightness: +minimum: 0 +maximum: 2048 + + richtek,pwm-enable: +description: | + Specify the backlight dimming following by PWM duty or by SW control. +type: boolean + + richtek,bled-ovp-sel: +description: | + Backlight OVP level selection, currently support 17V/21V/25V/29V. +$ref: /schemas/types.yaml#/definitions/uint8 +default: 1 +minimum: 0 +maximum: 3 + + richtek,channel-use: +description: | + Backlight LED channel to be used. + BIT 0/1/2/3 is used to indicate led channel 1/2/3/4 enable or disable. +$ref: /schemas/types.yaml#/definitions/uint8 +minimum: 1 +maximum: 15 + +required: + - compatible + - richtek,channel-use + +additionalProperties: false diff --git a/include/dt-bindings/leds/rt4831-backlight.h b/include/dt-bindings/leds/rt4831-backlight.h new file mode 100644 index ..125c635 --- /dev/null +++ b/include/dt-bindings/leds/rt4831-backlight.h @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +/* + * This header provides constants for rt4831 backlight bindings. + * + * Copyright (C) 2020, Richtek Technology Corp. + * Author: ChiYuan Huang + */ + +#ifndef _DT_BINDINGS_RT4831_BACKLIGHT_H +#define _DT_BINDINGS_RT4831_BACKLIGHT_H + +#define RT4831_BLOVPLVL_17V0 +#define RT4831_BLOVPLVL_21V1 +#define RT4831_BLOVPLVL_25V2 +#define RT4831_BLOVPLVL_29V3 + +#define RT4831_BLED_CH1EN (1 << 0) +#define RT4831_BLED_CH2EN (1 << 1) +#define RT4831_BLED_CH3EN (1 << 2) +#define RT4831_BLED_CH4EN (1 << 3) +#define RT4831_BLED_ALLCHEN((1 << 4) - 1) + +#endif /* _DT_BINDINGS_RT4831_BACKLIGHT_H */ -- 2.7.4
[PATCH v7 1/4] mfd: rt4831: Adds support for Richtek RT4831
From: ChiYuan Huang
This adds support Richtek RT4831 core. It includes four channel WLED driver
and Display Bias Voltage outputs.
Signed-off-by: ChiYuan Huang
---
The RT4831 regulator patches are already on main stream, and can be referred to
9351ab8b0cb6 regulator: rt4831: Adds support for Richtek RT4831 DSV regulator
934b05e81862 regulator: rt4831: Adds DT binding document for Richtek RT4831 DSV
regulator
since v6
- Respin the date from 2020 to 2021.
- Rmove the shutdown routine.
- Change the macro OF_MFD_CELL to MFD_CELL_OF.
since v5
- Rename file name from rt4831-core.c to rt4831.c
- Change RICHTEK_VID to RICHTEK_VENDOR_ID.
- Change gpio_desc nameing from 'enable' to 'enable_gpio' in probe.
- Change variable 'val' to the meaningful name 'chip_id'.
- Refine the error log when vendor id is not matched.
- Remove of_match_ptr.
since v2
- Refine Kconfig descriptions.
- Add copyright.
- Refine error logs in probe.
- Refine comment lines in remove and shutdown.
---
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/rt4831.c | 115 +++
3 files changed, 126 insertions(+)
create mode 100644 drivers/mfd/rt4831.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 5c7f2b1..49e57c9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1076,6 +1076,16 @@ config MFD_RDC321X
southbridge which provides access to GPIOs and Watchdog using the
southbridge PCI device configuration space.
+config MFD_RT4831
+ tristate "Richtek RT4831 four channel WLED and Display Bias Voltage"
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ This enables support for the Richtek RT4831 that includes 4 channel
+ WLED driving and Display Bias Voltage. It's commonly used to provide
+ power to the LCD display and LCD backlight.
+
config MFD_RT5033
tristate "Richtek RT5033 Power Management IC"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4f6d2b8..eb42bd4 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -234,6 +234,7 @@ obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
obj-$(CONFIG_MFD_HI655X_PMIC) += hi655x-pmic.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
+obj-$(CONFIG_MFD_RT4831) += rt4831.o
obj-$(CONFIG_MFD_RT5033) += rt5033.o
obj-$(CONFIG_MFD_SKY81452) += sky81452.o
diff --git a/drivers/mfd/rt4831.c b/drivers/mfd/rt4831.c
new file mode 100644
index ..b169781
--- /dev/null
+++ b/drivers/mfd/rt4831.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 Richtek Technology Corp.
+ *
+ * Author: ChiYuan Huang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RT4831_REG_REVISION0x01
+#define RT4831_REG_ENABLE 0x08
+#define RT4831_REG_I2CPROT 0x15
+
+#define RICHTEK_VENDOR_ID 0x03
+#define RT4831_VID_MASKGENMASK(1, 0)
+#define RT4831_RESET_MASK BIT(7)
+#define RT4831_I2CSAFETMR_MASK BIT(0)
+
+static const struct mfd_cell rt4831_subdevs[] = {
+ MFD_CELL_OF("rt4831-backlight", NULL, NULL, 0, 0,
"richtek,rt4831-backlight"),
+ MFD_CELL_NAME("rt4831-regulator")
+};
+
+static bool rt4831_is_accessible_reg(struct device *dev, unsigned int reg)
+{
+ if (reg >= RT4831_REG_REVISION && reg <= RT4831_REG_I2CPROT)
+ return true;
+ return false;
+}
+
+static const struct regmap_config rt4831_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RT4831_REG_I2CPROT,
+
+ .readable_reg = rt4831_is_accessible_reg,
+ .writeable_reg = rt4831_is_accessible_reg,
+};
+
+static int rt4831_probe(struct i2c_client *client)
+{
+ struct gpio_desc *enable_gpio;
+ struct regmap *regmap;
+ unsigned int chip_id;
+ int ret;
+
+ enable_gpio = devm_gpiod_get_optional(&client->dev, "enable",
GPIOD_OUT_HIGH);
+ if (IS_ERR(enable_gpio)) {
+ dev_err(&client->dev, "Failed to get 'enable' GPIO\n");
+ return PTR_ERR(enable_gpio);
+ }
+
+ regmap = devm_regmap_init_i2c(client, &rt4831_regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(&client->dev, "Failed to initialize regmap\n");
+ return PTR_ERR(regmap);
+ }
+
+ ret = regmap_read(regmap, RT4831_REG_REVISION, &chip_id);
+ if (ret) {
+ dev_err(&client->dev, "Failed to get H/W revision\n");
+ return ret;
+ }
+
+ if ((chip_id & RT4831_VID_MASK) != RICHTEK_VENDOR_ID) {
+ dev_err(&client->dev, "Chip vendor ID 0x%02x not matched\n",
chip_id);
+ return -ENODEV;
+ }
+
+ /*
+* Used to prevent the abnormal shutdown.
+* If SCL/SDA both keep low for one second to reset HW.
+*/
+ ret = regmap_update_bits(r
[PATCH v7 4/4] backlight: rt4831: Adds support for Richtek RT4831 backlight
From: ChiYuan Huang
Adds support for Richtek RT4831 backlight.
Signed-off-by: ChiYuan Huang
Reviewed-by: Daniel Thompson
---
since v7
- Fix typo 'common' to 'commonly' in Kconfig description.
---
drivers/video/backlight/Kconfig| 8 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/rt4831-backlight.c | 203 +
3 files changed, 212 insertions(+)
create mode 100644 drivers/video/backlight/rt4831-backlight.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index d83c87b..858f6df 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -289,6 +289,14 @@ config BACKLIGHT_QCOM_WLED
If you have the Qualcomm PMIC, say Y to enable a driver for the
WLED block. Currently it supports PM8941 and PMI8998.
+config BACKLIGHT_RT4831
+ tristate "Richtek RT4831 Backlight Driver"
+ depends on MFD_RT4831
+ help
+ This enables support for Richtek RT4831 Backlight driver.
+ It's commonly used to drive the display WLED. There're four channels
+ inisde, and each channel can provide up to 30mA current.
+
config BACKLIGHT_SAHARA
tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
depends on X86
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 685f3f1..cae2c83 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
obj-$(CONFIG_BACKLIGHT_QCOM_WLED) += qcom-wled.o
+obj-$(CONFIG_BACKLIGHT_RT4831) += rt4831-backlight.o
obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
diff --git a/drivers/video/backlight/rt4831-backlight.c
b/drivers/video/backlight/rt4831-backlight.c
new file mode 100644
index ..42155c7
--- /dev/null
+++ b/drivers/video/backlight/rt4831-backlight.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RT4831_REG_BLCFG 0x02
+#define RT4831_REG_BLDIML 0x04
+#define RT4831_REG_ENABLE 0x08
+
+#define RT4831_BLMAX_BRIGHTNESS2048
+
+#define RT4831_BLOVP_MASK GENMASK(7, 5)
+#define RT4831_BLOVP_SHIFT 5
+#define RT4831_BLPWMEN_MASKBIT(0)
+#define RT4831_BLEN_MASK BIT(4)
+#define RT4831_BLCH_MASK GENMASK(3, 0)
+#define RT4831_BLDIML_MASK GENMASK(2, 0)
+#define RT4831_BLDIMH_MASK GENMASK(10, 3)
+#define RT4831_BLDIMH_SHIFT3
+
+struct rt4831_priv {
+ struct device *dev;
+ struct regmap *regmap;
+ struct backlight_device *bl;
+};
+
+static int rt4831_bl_update_status(struct backlight_device *bl_dev)
+{
+ struct rt4831_priv *priv = bl_get_data(bl_dev);
+ int brightness = backlight_get_brightness(bl_dev);
+ unsigned int enable = brightness ? RT4831_BLEN_MASK : 0;
+ u8 v[2];
+ int ret;
+
+ if (brightness) {
+ v[0] = (brightness - 1) & RT4831_BLDIML_MASK;
+ v[1] = ((brightness - 1) & RT4831_BLDIMH_MASK) >>
RT4831_BLDIMH_SHIFT;
+
+ ret = regmap_raw_write(priv->regmap, RT4831_REG_BLDIML, v,
sizeof(v));
+ if (ret)
+ return ret;
+ }
+
+ return regmap_update_bits(priv->regmap, RT4831_REG_ENABLE,
RT4831_BLEN_MASK, enable);
+
+}
+
+static int rt4831_bl_get_brightness(struct backlight_device *bl_dev)
+{
+ struct rt4831_priv *priv = bl_get_data(bl_dev);
+ unsigned int val;
+ u8 v[2];
+ int ret;
+
+ ret = regmap_read(priv->regmap, RT4831_REG_ENABLE, &val);
+ if (ret)
+ return ret;
+
+ if (!(val & RT4831_BLEN_MASK))
+ return 0;
+
+ ret = regmap_raw_read(priv->regmap, RT4831_REG_BLDIML, v, sizeof(v));
+ if (ret)
+ return ret;
+
+ ret = (v[1] << RT4831_BLDIMH_SHIFT) + (v[0] & RT4831_BLDIML_MASK) + 1;
+
+ return ret;
+}
+
+static const struct backlight_ops rt4831_bl_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = rt4831_bl_update_status,
+ .get_brightness = rt4831_bl_get_brightness,
+};
+
+static int rt4831_parse_backlight_properties(struct rt4831_priv *priv,
+struct backlight_properties
*bl_props)
+{
+ struct device *dev = priv->dev;
+ u8 propval;
+ u32 brightness;
+ unsigned int val = 0;
+ int ret;
+
+ /* common properties */
+ ret = device_property_read_u32(dev, "max-brightness", &brightness);
+ if (ret)
+ brightness = RT4831_BLMAX_BRIGHTNESS;
+
+ bl_props->max_brightness
[PATCH v7 3/4] mfd: rt4831: Adds DT binding document for Richtek RT4831
From: ChiYuan Huang
Adds DT binding document for Richtek RT4831.
Signed-off-by: ChiYuan Huang
Reviewed-by: Rob Herring
---
.../devicetree/bindings/mfd/richtek,rt4831.yaml| 90 ++
1 file changed, 90 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml
diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml
b/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml
new file mode 100644
index ..4762eb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/richtek,rt4831.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT4831 DSV and Backlight Integrated IC
+
+maintainers:
+ - ChiYuan Huang
+
+description: |
+ RT4831 is a multifunctional device that can provide power to the LCD display
+ and LCD backlight.
+
+ For Display Bias Voltage DSVP and DSVN, the output range is about 4V to 6.5V.
+ It's sufficient to meet the current LCD power requirement.
+
+ For the LCD backlight, it can provide four channel WLED driving capability.
+ Each channel driving current is up to 30mA
+
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf
+
+properties:
+ compatible:
+const: richtek,rt4831
+
+ reg:
+description: I2C device address.
+maxItems: 1
+
+ enable-gpios:
+description: |
+ GPIO to enable/disable the chip. It is optional.
+ Some usage directly tied this pin to follow VIO 1.8V power on sequence.
+maxItems: 1
+
+ regulators:
+$ref: ../regulator/richtek,rt4831-regulator.yaml
+
+ backlight:
+$ref: ../leds/backlight/richtek,rt4831-backlight.yaml
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rt4831@11 {
+compatible = "richtek,rt4831";
+reg = <0x11>;
+
+regulators {
+ DSVLCM {
+regulator-min-microvolt = <400>;
+regulator-max-microvolt = <715>;
+regulator-allow-bypass;
+ };
+ DSVP {
+regulator-name = "rt4831-dsvp";
+regulator-min-microvolt = <400>;
+regulator-max-microvolt = <650>;
+regulator-boot-on;
+ };
+ DSVN {
+regulator-name = "rt4831-dsvn";
+regulator-min-microvolt = <400>;
+regulator-max-microvolt = <650>;
+regulator-boot-on;
+ };
+};
+
+backlight {
+ compatible = "richtek,rt4831-backlight";
+ default-brightness = <1024>;
+ max-brightness = <2048>;
+ richtek,bled-ovp-sel = /bits/ 8 ;
+ richtek,channel-use = /bits/ 8 ;
+};
+ };
+};
--
2.7.4
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
Em Wed, 12 May 2021 10:14:44 -0400
"Theodore Ts'o" escreveu:
> On Wed, May 12, 2021 at 02:50:04PM +0200, Mauro Carvalho Chehab wrote:
> > v2:
> > - removed EM/EN DASH conversion from this patchset;
>
> Are you still thinking about doing the
>
> EN DASH --> "--"
> EM DASH --> "---"
>
> conversion?
Yes, but I intend to submit it on a separate patch series, probably after
having this one merged. Let's first cleanup the large part of the
conversion-generated UTF-8 char noise ;-)
> That's not going to change what the documentation will
> look like in the HTML and PDF output forms, and I think it would make
> life easier for people are reading and editing the Documentation/*
> files in text form.
Agreed. I'm also considering to add a couple of cases of this char:
- U+2026 ('…'): HORIZONTAL ELLIPSIS
As Sphinx also replaces "..." into HORIZONTAL ELLIPSIS.
-
Anyway, I'm opting to submitting those in separate because it seems
that at least some maintainers added EM/EN DASH intentionally.
So, it may generate case-per-case discussions.
Also, IMO, at least a couple of EN/EM DASH cases would be better served
with a single hyphen.
Thanks,
Mauro
[PATCH 5.10 278/530] drm/stm: Fix bus_flags handling
From: Marek Vasut
[ Upstream commit 99e360442f223dd40fc23ae07c7a263836fd27e6 ]
The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no
matter what polarity the next bridge or display might require, these flags
are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set
and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and
DISPLAY_FLAGS_DE_HIGH were always set.
The fix for this problem is taken almost verbatim from MXSFB driver. In
case there is a bridge attached to the LTDC, the bridge might have extra
polarity requirements, so extract bus_flags from the bridge and use them
for LTDC configuration. Otherwise, extract bus_flags from the connector,
which is the display.
Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
Signed-off-by: Marek Vasut
Signed-off-by: Yannick Fertre
Cc: Alexandre Torgue
Cc: Antonio Borneo
Cc: Benjamin Gaignard
Cc: Maxime Coquelin
Cc: Philippe Cornu
Cc: Sam Ravnborg
Cc: Vincent Abriou
Cc: Yannick Fertre
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
Tested-by: Yannick Fertre
Signed-off-by: Philippe Cornu
Link:
https://patchwork.freedesktop.org/patch/msgid/20210127110756.125570-1-ma...@denx.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/stm/ltdc.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 6e28f707092f..62488ac14923 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -525,13 +525,42 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
struct drm_device *ddev = crtc->dev;
+ struct drm_connector_list_iter iter;
+ struct drm_connector *connector = NULL;
+ struct drm_encoder *encoder = NULL;
+ struct drm_bridge *bridge = NULL;
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
struct videomode vm;
u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
u32 total_width, total_height;
+ u32 bus_flags = 0;
u32 val;
int ret;
+ /* get encoder from crtc */
+ drm_for_each_encoder(encoder, ddev)
+ if (encoder->crtc == crtc)
+ break;
+
+ if (encoder) {
+ /* get bridge from encoder */
+ list_for_each_entry(bridge, &encoder->bridge_chain, chain_node)
+ if (bridge->encoder == encoder)
+ break;
+
+ /* Get the connector from encoder */
+ drm_connector_list_iter_begin(ddev, &iter);
+ drm_for_each_connector_iter(connector, &iter)
+ if (connector->encoder == encoder)
+ break;
+ drm_connector_list_iter_end(&iter);
+ }
+
+ if (bridge && bridge->timings)
+ bus_flags = bridge->timings->input_bus_flags;
+ else if (connector)
+ bus_flags = connector->display_info.bus_flags;
+
if (!pm_runtime_active(ddev->dev)) {
ret = pm_runtime_get_sync(ddev->dev);
if (ret) {
@@ -567,10 +596,10 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
- if (vm.flags & DISPLAY_FLAGS_DE_LOW)
+ if (bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= GCR_DEPOL;
- if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
val |= GCR_PCPOL;
reg_update_bits(ldev->regs, LTDC_GCR,
--
2.30.2
[PATCH 5.10 015/530] drm: bridge: fix LONTIUM use of mipi_dsi_() functions
From: Randy Dunlap
commit ad085b3a712a89e4a48472121b231add7a8362e4 upstream.
The Lontium DRM bridge drivers use mipi_dsi_() function interfaces so
they need to select DRM_MIPI_DSI to prevent build errors.
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "of_find_mipi_dsi_host_by_node"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "mipi_dsi_device_unregister"
[drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko]
undefined!
ERROR: modpost: "mipi_dsi_attach" [drivers/gpu/drm/bridge/lontium-lt9611.ko]
undefined!
ERROR: modpost: "mipi_dsi_device_register_full"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "of_find_mipi_dsi_host_by_node"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "mipi_dsi_device_unregister"
[drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
ERROR: modpost: "mipi_dsi_detach" [drivers/gpu/drm/bridge/lontium-lt9611.ko]
undefined!
WARNING: modpost: suppressed 5 unresolved symbol warnings because there were
too many)
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Reported-by: kernel test robot
Signed-off-by: Randy Dunlap
Reviewed-by: Adren Grassein
Cc: Dmitry Baryshkov
Cc: Sam Ravnborg
Cc: Vinod Koul
Cc: Bjorn Andersson
Cc: Srinivas Kandagatla
Cc: Adrien Grassein
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20210415183639.1487-1-rdun...@infradead.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/bridge/Kconfig |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -54,6 +54,7 @@ config DRM_LONTIUM_LT9611
depends on OF
select DRM_PANEL_BRIDGE
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
help
Driver for Lontium LT9611 DSI to HDMI bridge
@@ -138,6 +139,7 @@ config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
select I2C_MUX
select SND_SOC_HDMI_CODEC if SND_SOC
@@ -187,6 +189,7 @@ config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
select REGMAP_I2C
select DRM_PANEL
help
Re: [PATCH 1/2] drm: Fix dirtyfb stalls
On Wed, May 12, 2021 at 1:23 AM Pekka Paalanen wrote: > > On Tue, 11 May 2021 18:44:17 +0200 > Daniel Vetter wrote: > > > On Mon, May 10, 2021 at 12:06:05PM -0700, Rob Clark wrote: > > > On Mon, May 10, 2021 at 10:44 AM Daniel Vetter wrote: > > > > > > > > On Mon, May 10, 2021 at 6:51 PM Rob Clark wrote: > > > > > > > > > > On Mon, May 10, 2021 at 9:14 AM Daniel Vetter wrote: > > > > > > > > > > > > On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote: > > > > > > > From: Rob Clark > > > > > > > > > > > > > > drm_atomic_helper_dirtyfb() will end up stalling for vblank on > > > > > > > "video > > > > > > > mode" type displays, which is pointless and unnecessary. Add an > > > > > > > optional helper vfunc to determine if a plane is attached to a > > > > > > > CRTC > > > > > > > that actually needs dirtyfb, and skip over them. > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > > > > > > > > > > > So this is a bit annoying because the idea of all these "remap > > > > > > legacy uapi > > > > > > to atomic constructs" helpers is that they shouldn't need/use > > > > > > anything > > > > > > beyond what userspace also has available. So adding hacks for them > > > > > > feels > > > > > > really bad. > > > > > > > > > > I suppose the root problem is that userspace doesn't know if dirtyfb > > > > > (or similar) is actually required or is a no-op. > > > > > > > > > > But it is perhaps less of a problem because this essentially boils > > > > > down to "x11 vs wayland", and it seems like wayland compositors for > > > > > non-vsync'd rendering just pageflips and throws away extra frames from > > > > > the app? > > > > > > > > Yeah it's about not adequately batching up rendering and syncing with > > > > hw. bare metal x11 is just especially stupid about it :-) > > > > > > > > > > Also I feel like it's not entirely the right thing to do here > > > > > > either. > > > > > > We've had this problem already on the fbcon emulation side (which > > > > > > also > > > > > > shouldn't be able to peek behind the atomic kms uapi curtain), and > > > > > > the fix > > > > > > there was to have a worker which batches up all the updates and > > > > > > avoids any > > > > > > stalls in bad places. > > > > > > > > > > I'm not too worried about fbcon not being able to render faster than > > > > > vblank. OTOH it is a pretty big problem for x11 > > > > > > > > That's why we'd let the worker get ahead at most one dirtyfb. We do > > > > the same with fbcon, which trivially can get ahead of vblank otherwise > > > > (if sometimes flushes each character, so you have to pile them up into > > > > a single update if that's still pending). > > > > > > > > > > Since this is for frontbuffer rendering userspace only we can > > > > > > probably get > > > > > > away with assuming there's only a single fb, so the implementation > > > > > > becomes > > > > > > pretty simple: > > > > > > > > > > > > - 1 worker, and we keep track of a single pending fb > > > > > > - if there's already a dirty fb pending on a different fb, we stall > > > > > > for > > > > > > the worker to start processing that one already (i.e. the fb we > > > > > > track is > > > > > > reset to NULL) > > > > > > - if it's pending on the same fb we just toss away all the updates > > > > > > and go > > > > > > with a full update, since merging the clip rects is too much work > > > > > > :-) I > > > > > > think there's helpers so you could be slightly more clever and > > > > > > just have > > > > > > an overall bounding box > > > > > > > > > > This doesn't really fix the problem, you still end up delaying sending > > > > > the next back-buffer to mesa > > > > > > > > With this the dirtyfb would never block. Also glorious frontbuffer > > > > tracking corruption is possible, but that's not the kernel's problem. > > > > So how would anything get held up in userspace. > > > > > > the part about stalling if a dirtyfb is pending was what I was worried > > > about.. but I suppose you meant the worker stalling, rather than > > > userspace stalling (where I had interpreted it the other way around). > > > As soon as userspace needs to stall, you're losing again. > > > > Nah, I did mean userspace stalling, so we can't pile up unlimited amounts > > of dirtyfb request in the kernel. > > > > But also I never expect userspace that uses dirtyfb to actually hit this > > stall point (otherwise we'd need to look at this again). It would really > > be only there as defense against abuse. > > > > > > > But we could re-work drm_framebuffer_funcs::dirty to operate on a > > > > > per-crtc basis and hoist the loop and check if dirtyfb is needed out > > > > > of drm_atomic_helper_dirtyfb() > > > > > > > > That's still using information that userspace doesn't have, which is a > > > > bit irky. We might as well go with your thing here then. > > > > > > arguably, this is something we should expose to userspace.. for DSI > > > command-mode panels, you probably want to make a dif
Re: New uAPI for color management proposal and feedback request
Am 12.05.21 um 14:06 schrieb Werner Sembach: > Hello, > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm > properties I propose 4 new properties: > "preferred pixel encoding", "active color depth", "active color range", and > "active pixel encoding" > > > Motivation: > > Current monitors have a variety pixel encodings available: RGB, YCbCr 4:4:4, > YCbCr 4:2:2, YCbCr 4:2:0. > > In addition they might be full or limited RGB range and the monitors accept > different bit depths. > > Currently the kernel driver for AMD and Intel GPUs automatically configure > the color settings automatically with little > to no influence of the user. However there are several real world scenarios > where the user might disagree with the > default chosen by the drivers and wants to set his or her own preference. > > Some examples: > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color > information, some screens might look better on one > than the other because of bad internal conversion. The driver currently > however has a fixed default that is chosen if > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change > this currently is by editing and overloading > the edid reported by the monitor to the kernel. > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some > hardware might report that it supports the higher > port clock, but because of bad shielding on the PC, the cable, or the monitor > the screen cuts out every few seconds when > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine > without changing hardware. The drivers > currently however always default to the "best available" option even if it > might be broken. > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color > by rapidly switching between 2 adjacent > colors. They advertise themselves to the kernel as 10-bit monitors but the > user might not like the "fake" 10-bit effect > and prefer running at the native 8-bit per color. > > 4. Some screens are falsely classified as full RGB range wile they actually > use limited RGB range. This results in > washed out colors in dark and bright scenes. A user override can be helpful > to manually fix this issue when it occurs. > > There already exist several requests, discussion, and patches regarding the > thematic: > > - https://gitlab.freedesktop.org/drm/amd/-/issues/476 > > - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 > > - https://lkml.org/lkml/2021/5/7/695 > > - https://lkml.org/lkml/2021/5/11/416 > > > Current State: > > I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how > other driver handle color management > > - "max bpc", global setting applied by both i915 (only on dp i think?) and > amdgpu. Default value is "8". For every > resolution + frequency combination the highest possible even number between 6 > and max_bpc is chosen. If the range > doesn't contain a valid mode the resolution + frequency combination is > discarded (but I guess that would be a very > special edge case, if existent at all, when 6 doesn't work but 10 would > work). Intel HDMI code always checks 8, 12, and > 10 and does not check the max_bpc setting. > > - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not > amdgpu), overwrites the kernel chosen color > range setting (full or limited). If I recall correctly Intel HDMI code > defaults to full unless this property is set, > Intel dp code tries to probe the monitor to find out what to use. amdgpu has > no corresponding setting (I don't know how > it's decided there). > > - RGB pixel encoding can be forced by overloading a Monitors edid with one > that tells the kernel that only RGB is > possible. That doesn't work for YCbCr 4:4:4 however because of the edid > specification. Forcing YCbCr 4:2:0 would > theoretically also be possible this way. amdgpu has a debugfs switch > "force_ycbcr_420" which makes the driver default to > YCbCr 4:2:0 on all monitors if possible. > > > Proposed Solution: > > 1. Add a new uAPI property "preferred pixel encoding", as a per port setting. > > - An amdgpu specific implementation was already shared here: > https://gitlab.freedesktop.org/drm/amd/-/issues/476 > > - It also writes back the actually used encoding if the one requested was > not possible, overwriting the requested > value in the process. I think it would be better to have this feedback > channel as a different, read-only property. > > - Make this solution vendor agnostic by putting it in the > drm_connector_state struct next do max_bpc > https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector.h#L654 > and add patches to amdgpu and i915 to > respect this setting > > 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor > agnostic setting. > > - Imho the name is not very fitting, but it pops up in many tutorials > throughout
[PATCH v7 14/16] drm/amd/display: Remove superfluous drm_mode_config_cleanup
It's already being released by DRM core through devm
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6c2c6a51ce6c..9728a0158bcb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3757,7 +3757,6 @@ static int amdgpu_dm_initialize_drm_device(struct
amdgpu_device *adev)
static void amdgpu_dm_destroy_drm_device(struct amdgpu_display_manager *dm)
{
- drm_mode_config_cleanup(dm->ddev);
drm_atomic_private_obj_fini(&dm->atomic_obj);
return;
}
--
2.25.1
[PATCH v7 16/16] drm/amdgpu: Unmap all MMIO mappings
Access to those must be prevented post pci_remove
v6: Drop BOs list, unampping VRAM BAR is enough.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f7cca25c0fa0..73cbc3c7453f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3666,6 +3666,25 @@ int amdgpu_device_init(struct amdgpu_device *adev,
return r;
}
+static void amdgpu_device_unmap_mmio(struct amdgpu_device *adev)
+{
+ /* Clear all CPU mappings pointing to this device */
+ unmap_mapping_range(adev->ddev.anon_inode->i_mapping, 0, 0, 1);
+
+ /* Unmap all mapped bars - Doorbell, registers and VRAM */
+ amdgpu_device_doorbell_fini(adev);
+
+ iounmap(adev->rmmio);
+ adev->rmmio = NULL;
+ if (adev->mman.aper_base_kaddr)
+ iounmap(adev->mman.aper_base_kaddr);
+ adev->mman.aper_base_kaddr = NULL;
+
+ /* Memory manager related */
+ arch_phys_wc_del(adev->gmc.vram_mtrr);
+ arch_io_free_memtype_wc(adev->gmc.aper_base, adev->gmc.aper_size);
+}
+
/**
* amdgpu_device_fini - tear down the driver
*
@@ -3712,6 +3731,8 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
amdgpu_device_ip_fini_early(adev);
amdgpu_gart_dummy_page_fini(adev);
+
+ amdgpu_device_unmap_mmio(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
@@ -3739,9 +3760,6 @@ void amdgpu_device_fini_sw(struct amdgpu_device *adev)
}
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
vga_client_register(adev->pdev, NULL, NULL, NULL);
- iounmap(adev->rmmio);
- adev->rmmio = NULL;
- amdgpu_device_doorbell_fini(adev);
if (IS_ENABLED(CONFIG_PERF_EVENTS))
amdgpu_pmu_fini(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 0adffcace326..882fb49f3c41 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -533,6 +533,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
return -ENOMEM;
drm_gem_private_object_init(adev_to_drm(adev), &bo->tbo.base, size);
INIT_LIST_HEAD(&bo->shadow_list);
+
bo->vm_bo = NULL;
bo->preferred_domains = bp->preferred_domain ? bp->preferred_domain :
bp->domain;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0d54e70278ca..58ad2fecc9e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1841,10 +1841,6 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
amdgpu_bo_free_kernel(&adev->mman.discovery_memory, NULL, NULL);
amdgpu_ttm_fw_reserve_vram_fini(adev);
- if (adev->mman.aper_base_kaddr)
- iounmap(adev->mman.aper_base_kaddr);
- adev->mman.aper_base_kaddr = NULL;
-
amdgpu_vram_mgr_fini(adev);
amdgpu_gtt_mgr_fini(adev);
ttm_range_man_fini(&adev->mman.bdev, AMDGPU_PL_GDS);
--
2.25.1
[PATCH v7 15/16] drm/amdgpu: Verify DMA opearations from device are done
In case device remove is just simualted by sysfs then verify device doesn't keep doing DMA to the released memory after pci_remove is done. Signed-off-by: Andrey Grodzovsky Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 83006f45b10b..5e6af9e0b7bf 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -1314,7 +1314,13 @@ amdgpu_pci_remove(struct pci_dev *pdev) drm_dev_unplug(dev); amdgpu_driver_unload_kms(dev); + /* +* Flush any in flight DMA operations from device. +* Clear the Bus Master Enable bit and then wait on the PCIe Device +* StatusTransactions Pending bit. +*/ pci_disable_device(pdev); + pci_wait_for_pending_transaction(pdev); } static void -- 2.25.1
[PATCH v7 12/16] drm/amdgpu: Fix hang on device removal.
If removing while commands in flight you cannot wait to flush the
HW fences on a ring since the device is gone.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 1ffb36bd0b19..fa03702ecbfb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -36,6 +36,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_trace.h"
@@ -525,8 +526,7 @@ int amdgpu_fence_driver_init(struct amdgpu_device *adev)
*/
void amdgpu_fence_driver_fini_hw(struct amdgpu_device *adev)
{
- unsigned i, j;
- int r;
+ int i, r;
for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -535,11 +535,15 @@ void amdgpu_fence_driver_fini_hw(struct amdgpu_device
*adev)
continue;
if (!ring->no_scheduler)
drm_sched_fini(&ring->sched);
- r = amdgpu_fence_wait_empty(ring);
- if (r) {
- /* no need to trigger GPU reset as we are unloading */
+ /* You can't wait for HW to signal if it's gone */
+ if (!drm_dev_is_unplugged(&adev->ddev))
+ r = amdgpu_fence_wait_empty(ring);
+ else
+ r = -ENODEV;
+ /* no need to trigger GPU reset as we are unloading */
+ if (r)
amdgpu_fence_driver_force_completion(ring);
- }
+
if (ring->fence_drv.irq_src)
amdgpu_irq_put(adev, ring->fence_drv.irq_src,
ring->fence_drv.irq_type);
--
2.25.1
[PATCH v7 13/16] drm/scheduler: Fix hang when sched_entity released
Problem: If scheduler is already stopped by the time sched_entity
is released and entity's job_queue not empty I encountred
a hang in drm_sched_entity_flush. This is because drm_sched_entity_is_idle
never becomes false.
Fix: In drm_sched_fini detach all sched_entities from the
scheduler's run queues. This will satisfy drm_sched_entity_is_idle.
Also wakeup all those processes stuck in sched_entity flushing
as the scheduler main thread which wakes them up is stopped by now.
v2:
Reverse order of drm_sched_rq_remove_entity and marking
s_entity as stopped to prevent reinserion back to rq due
to race.
v3:
Drop drm_sched_rq_remove_entity, only modify entity->stopped
and check for it in drm_sched_entity_is_idle
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 3 ++-
drivers/gpu/drm/scheduler/sched_main.c | 24
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 0249c7450188..2e93e881b65f 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -116,7 +116,8 @@ static bool drm_sched_entity_is_idle(struct
drm_sched_entity *entity)
rmb(); /* for list_empty to work without lock */
if (list_empty(&entity->list) ||
- spsc_queue_count(&entity->job_queue) == 0)
+ spsc_queue_count(&entity->job_queue) == 0 ||
+ entity->stopped)
return true;
return false;
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 8d1211e87101..a2a953693b45 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -898,9 +898,33 @@ EXPORT_SYMBOL(drm_sched_init);
*/
void drm_sched_fini(struct drm_gpu_scheduler *sched)
{
+ struct drm_sched_entity *s_entity;
+ int i;
+
if (sched->thread)
kthread_stop(sched->thread);
+ for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= DRM_SCHED_PRIORITY_MIN;
i--) {
+ struct drm_sched_rq *rq = &sched->sched_rq[i];
+
+ if (!rq)
+ continue;
+
+ spin_lock(&rq->lock);
+ list_for_each_entry(s_entity, &rq->entities, list)
+ /*
+* Prevents reinsertion and marks job_queue as idle,
+* it will removed from rq in drm_sched_entity_fini
+* eventually
+*/
+ s_entity->stopped = true;
+ spin_unlock(&rq->lock);
+
+ }
+
+ /* Wakeup everyone stuck in drm_sched_entity_flush for this scheduler */
+ wake_up_all(&sched->job_scheduled);
+
/* Confirm no work left behind accessing device structures */
cancel_delayed_work_sync(&sched->work_tdr);
--
2.25.1
[PATCH v7 10/16] drm/sched: Make timeout timer rearm conditional.
We don't want to rearm the timer if driver hook reports
that the device is gone.
v5: Update drm_gpu_sched_stat values in code.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index f4f474944169..8d1211e87101 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -314,6 +314,7 @@ static void drm_sched_job_timedout(struct work_struct *work)
{
struct drm_gpu_scheduler *sched;
struct drm_sched_job *job;
+ enum drm_gpu_sched_stat status = DRM_GPU_SCHED_STAT_NOMINAL;
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
@@ -331,7 +332,7 @@ static void drm_sched_job_timedout(struct work_struct *work)
list_del_init(&job->list);
spin_unlock(&sched->job_list_lock);
- job->sched->ops->timedout_job(job);
+ status = job->sched->ops->timedout_job(job);
/*
* Guilty job did complete and hence needs to be manually
removed
@@ -345,9 +346,11 @@ static void drm_sched_job_timedout(struct work_struct
*work)
spin_unlock(&sched->job_list_lock);
}
- spin_lock(&sched->job_list_lock);
- drm_sched_start_timeout(sched);
- spin_unlock(&sched->job_list_lock);
+ if (status != DRM_GPU_SCHED_STAT_ENODEV) {
+ spin_lock(&sched->job_list_lock);
+ drm_sched_start_timeout(sched);
+ spin_unlock(&sched->job_list_lock);
+ }
}
/**
--
2.25.1
[PATCH v7 11/16] drm/amdgpu: Prevent any job recoveries after device is unplugged.
Return DRM_TASK_STATUS_ENODEV back to the scheduler when device
is not present so they timeout timer will not be rearmed.
v5: Update to match updated return values in enum drm_gpu_sched_stat
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 759b34799221..d33e6d97cc89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -25,6 +25,8 @@
#include
#include
+#include
+
#include "amdgpu.h"
#include "amdgpu_trace.h"
@@ -34,6 +36,15 @@ static enum drm_gpu_sched_stat amdgpu_job_timedout(struct
drm_sched_job *s_job)
struct amdgpu_job *job = to_amdgpu_job(s_job);
struct amdgpu_task_info ti;
struct amdgpu_device *adev = ring->adev;
+ int idx;
+
+ if (!drm_dev_enter(&adev->ddev, &idx)) {
+ DRM_INFO("%s - device unplugged skipping recovery on
scheduler:%s",
+__func__, s_job->sched->name);
+
+ /* Effectively the job is aborted as the device is gone */
+ return DRM_GPU_SCHED_STAT_ENODEV;
+ }
memset(&ti, 0, sizeof(struct amdgpu_task_info));
@@ -41,7 +52,7 @@ static enum drm_gpu_sched_stat amdgpu_job_timedout(struct
drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent))
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return DRM_GPU_SCHED_STAT_NOMINAL;
+ goto exit;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,13 +64,15 @@ static enum drm_gpu_sched_stat amdgpu_job_timedout(struct
drm_sched_job *s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
- return DRM_GPU_SCHED_STAT_NOMINAL;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
- return DRM_GPU_SCHED_STAT_NOMINAL;
}
+
+exit:
+ drm_dev_exit(idx);
+ return DRM_GPU_SCHED_STAT_NOMINAL;
}
int amdgpu_job_alloc(struct amdgpu_device *adev, unsigned num_ibs,
--
2.25.1
[PATCH v7 09/16] drm/amdgpu: Guard against write accesses after device removal
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
v5:
Protect more places wher memcopy_to/form_io takes place
Protect IB submissions
v6: Switch to !drm_dev_enter instead of scoping entire code
with brackets.
v7:
Drop guard of HW ring commands emission protection since they
are in GART and not in MMIO.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 9
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 63 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 31 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 11 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 22 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 44 +++
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +--
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +--
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 26 +
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 22 +---
13 files changed, 168 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a0bff4713672..f7cca25c0fa0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -71,6 +71,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -281,7 +283,10 @@ void amdgpu_device_vram_access(struct amdgpu_device *adev,
loff_t pos,
unsigned long flags;
uint32_t hi = ~0;
uint64_t last;
+ int idx;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
#ifdef CONFIG_64BIT
last = min(pos + size, adev->gmc.visible_vram_size);
@@ -300,7 +305,7 @@ void amdgpu_device_vram_access(struct amdgpu_device *adev,
loff_t pos,
}
if (count == size)
- return;
+ goto exit;
pos += count;
buf += count / 4;
@@ -323,6 +328,9 @@ void amdgpu_device_vram_access(struct amdgpu_device *adev,
loff_t pos,
*buf++ = RREG32_NO_KIQ(mmMM_DATA);
}
spin_unlock_irqrestore(&adev->mmio_idx_lock, flags);
+
+exit:
+ drm_dev_exit(idx);
}
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 4d32233cde92..04ba5eef1e88 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -31,6 +31,8 @@
#include "amdgpu_ras.h"
#include "amdgpu_xgmi.h"
+#include
+
/**
* amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
*
@@ -151,6 +153,10 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev,
void *cpu_pt_addr,
{
void __iomem *ptr = (void *)cpu_pt_addr;
uint64_t value;
+ int idx;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return 0;
/*
* The following is for PTE only. GART does not have PDEs.
@@ -158,6 +164,9 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void
*cpu_pt_addr,
value = addr & 0xF000ULL;
value |= flags;
writeq(value, ptr + (gpu_page_idx * 8));
+
+ drm_dev_exit(idx);
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 9e769cf6095b..bb6afee61666 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_psp.h"
@@ -39,6 +40,8 @@
#include "amdgpu_ras.h"
#include "amdgpu_securedisplay.h"
+#include
+
static int psp_sysfs_init(struct amdgpu_device *adev);
static void psp_sysfs_fini(struct amdgpu_device *adev);
@@ -253,7 +256,7 @@ psp_cmd_submit_buf(struct psp_context *psp,
struct psp_gfx_cmd_resp *cmd, uint64_t fence_mc_addr)
{
int ret;
- int index;
+ int index, idx;
int timeout = 2;
bool ras_intr = false;
bool skip_unsupport = false;
@@ -261,6 +264,9 @@ psp_cmd_submit_buf(struct psp_context *psp,
if (psp->adev->in_pci_err_recovery)
return 0;
+ if (!drm_dev_enter(&psp->adev->ddev, &idx))
+ return 0;
+
mutex_lock(&psp->mutex);
memset(psp->cmd_buf_mem, 0, PSP_CMD_BUFFER_SIZE);
@@ -271,8 +277,7 @@ psp_cmd_submit_buf(struct psp_context *psp,
ret = psp_ring_cmd_submit(psp, psp->cmd_buf_mc_addr, fence_mc_addr,
index);
if (ret) {
atomic_dec(&psp->fence_value);
- mutex_unlock(&psp->mutex);
- return ret;
+ goto exit;
}
[PATCH v7 08/16] drm/amdgpu: Convert driver sysfs attributes to static attributes
This allows to remove explicit creation and destruction
of those attrs and by this avoids warnings on device
finalizing post physical device extraction.
v5: Use newly added pci_driver.dev_groups directly
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 17 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 25
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 14 ---
4 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index 494b2e1717d5..879ed3e50a6e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1768,6 +1768,15 @@ static ssize_t amdgpu_atombios_get_vbios_version(struct
device *dev,
static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
NULL);
+static struct attribute *amdgpu_vbios_version_attrs[] = {
+ &dev_attr_vbios_version.attr,
+ NULL
+};
+
+const struct attribute_group amdgpu_vbios_version_attr_group = {
+ .attrs = amdgpu_vbios_version_attrs
+};
+
/**
* amdgpu_atombios_fini - free the driver info and callbacks for atombios
*
@@ -1787,7 +1796,6 @@ void amdgpu_atombios_fini(struct amdgpu_device *adev)
adev->mode_info.atom_context = NULL;
kfree(adev->mode_info.atom_card_info);
adev->mode_info.atom_card_info = NULL;
- device_remove_file(adev->dev, &dev_attr_vbios_version);
}
/**
@@ -1804,7 +1812,6 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
{
struct card_info *atom_card_info =
kzalloc(sizeof(struct card_info), GFP_KERNEL);
- int ret;
if (!atom_card_info)
return -ENOMEM;
@@ -1833,12 +1840,6 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
amdgpu_atombios_allocate_fb_scratch(adev);
}
- ret = device_create_file(adev->dev, &dev_attr_vbios_version);
- if (ret) {
- DRM_ERROR("Failed to create device file for VBIOS version\n");
- return ret;
- }
-
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 5ebed4c7d9c0..83006f45b10b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1766,6 +1766,18 @@ static struct pci_error_handlers amdgpu_pci_err_handler
= {
.resume = amdgpu_pci_resume,
};
+extern const struct attribute_group amdgpu_vram_mgr_attr_group;
+extern const struct attribute_group amdgpu_gtt_mgr_attr_group;
+extern const struct attribute_group amdgpu_vbios_version_attr_group;
+
+static const struct attribute_group *amdgpu_sysfs_groups[] = {
+ &amdgpu_vram_mgr_attr_group,
+ &amdgpu_gtt_mgr_attr_group,
+ &amdgpu_vbios_version_attr_group,
+ NULL,
+};
+
+
static struct pci_driver amdgpu_kms_pci_driver = {
.name = DRIVER_NAME,
.id_table = pciidlist,
@@ -1774,6 +1786,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
.shutdown = amdgpu_pci_shutdown,
.driver.pm = &amdgpu_pm_ops,
.err_handler = &amdgpu_pci_err_handler,
+ .dev_groups = amdgpu_sysfs_groups,
};
static int __init amdgpu_init(void)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 72962de4c04c..a4404da8ca6d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -75,6 +75,16 @@ static DEVICE_ATTR(mem_info_gtt_total, S_IRUGO,
static DEVICE_ATTR(mem_info_gtt_used, S_IRUGO,
amdgpu_mem_info_gtt_used_show, NULL);
+static struct attribute *amdgpu_gtt_mgr_attributes[] = {
+ &dev_attr_mem_info_gtt_total.attr,
+ &dev_attr_mem_info_gtt_used.attr,
+ NULL
+};
+
+const struct attribute_group amdgpu_gtt_mgr_attr_group = {
+ .attrs = amdgpu_gtt_mgr_attributes
+};
+
static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func;
/**
* amdgpu_gtt_mgr_init - init GTT manager and DRM MM
@@ -89,7 +99,6 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev, uint64_t
gtt_size)
struct amdgpu_gtt_mgr *mgr = &adev->mman.gtt_mgr;
struct ttm_resource_manager *man = &mgr->manager;
uint64_t start, size;
- int ret;
man->use_tt = true;
man->func = &amdgpu_gtt_mgr_func;
@@ -102,17 +111,6 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev,
uint64_t gtt_size)
spin_lock_init(&mgr->lock);
atomic64_set(&mgr->available, gtt_size >> PAGE_SHIFT);
- ret = device_create_file(adev->dev, &dev_attr_mem_info_gtt_total);
- if (ret) {
- DRM_ERROR("Failed to create device file mem_info_gtt_total\n");
- return ret;
- }
- ret = de
[PATCH v7 07/16] PCI: Add support for dev_groups to struct pci_driver
This helps converting PCI drivers sysfs attributes to static.
Analogous to' commit b71b283e3d6d ("USB: add support for dev_groups to
struct usb_driver")'
Signed-off-by: Andrey Grodzovsky
Suggested-by: Greg Kroah-Hartman
Acked-by: Bjorn Helgaas
---
drivers/pci/pci-driver.c | 1 +
include/linux/pci.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index ec44a79e951a..3a72352aa5cf 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1385,6 +1385,7 @@ int __pci_register_driver(struct pci_driver *drv, struct
module *owner,
drv->driver.owner = owner;
drv->driver.mod_name = mod_name;
drv->driver.groups = drv->groups;
+ drv->driver.dev_groups = drv->dev_groups;
spin_lock_init(&drv->dynids.lock);
INIT_LIST_HEAD(&drv->dynids.list);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 86c799c97b77..b57755b03009 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -858,6 +858,8 @@ struct module;
* number of VFs to enable via sysfs "sriov_numvfs" file.
* @err_handler: See Documentation/PCI/pci-error-recovery.rst
* @groups:Sysfs attribute groups.
+ * @dev_groups: Attributes attached to the device that will be
+ * created once it is bound to the driver.
* @driver:Driver model structure.
* @dynids:List of dynamically added device IDs.
*/
@@ -873,6 +875,7 @@ struct pci_driver {
int (*sriov_configure)(struct pci_dev *dev, int num_vfs); /* On PF */
const struct pci_error_handlers *err_handler;
const struct attribute_group **groups;
+ const struct attribute_group **dev_groups;
struct device_driverdriver;
struct pci_dynids dynids;
};
--
2.25.1
[PATCH v7 06/16] drm/amdgpu: Remap all page faults to per process dummy page.
On device removal reroute all CPU mappings to dummy page
per drm_file instance or imported GEM object.
v4:
Update for modified ttm_bo_vm_dummy_page
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8c7ec09eb1a4..0d54e70278ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -48,6 +48,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_object.h"
@@ -1905,18 +1906,28 @@ void amdgpu_ttm_set_buffer_funcs_status(struct
amdgpu_device *adev, bool enable)
static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
{
struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ struct drm_device *ddev = bo->base.dev;
vm_fault_t ret;
+ int idx;
ret = ttm_bo_vm_reserve(bo, vmf);
if (ret)
return ret;
- ret = amdgpu_bo_fault_reserve_notify(bo);
- if (ret)
- goto unlock;
+ if (drm_dev_enter(ddev, &idx)) {
+ ret = amdgpu_bo_fault_reserve_notify(bo);
+ if (ret) {
+ drm_dev_exit(idx);
+ goto unlock;
+ }
- ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
- TTM_BO_VM_NUM_PREFAULT, 1);
+ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+ TTM_BO_VM_NUM_PREFAULT, 1);
+
+drm_dev_exit(idx);
+ } else {
+ ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot);
+ }
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
return ret;
--
2.25.1
[PATCH v7 05/16] drm/amdgpu: Handle IOMMU enabled case.
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
v7:
Drop amdgpu_gart_fini
In amdgpu_ih_ring_fini do uncinditional check (!ih->ring)
to avoid freeing uniniitalized rings.
Call amdgpu_ih_ring_fini unconditionally.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 5 +
drivers/gpu/drm/amd/amdgpu/cik_ih.c| 1 -
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/iceland_ih.c| 1 -
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/si_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 1 -
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 4
18 files changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 18598eda18f6..a0bff4713672 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3256,7 +3256,6 @@ static const struct attribute *amdgpu_dev_attributes[] = {
NULL
};
-
/**
* amdgpu_device_init - initialize the driver
*
@@ -3698,12 +3697,13 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
amdgpu_ucode_sysfs_fini(adev);
sysfs_remove_files(&adev->dev->kobj, amdgpu_dev_attributes);
-
amdgpu_fbdev_fini(adev);
amdgpu_irq_fini_hw(adev);
amdgpu_device_ip_fini_early(adev);
+
+ amdgpu_gart_dummy_page_fini(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index c5a9a4fb10d2..6460cf723f0a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct amdgpu_device
*adev)
*
* Frees the dummy page used by the driver (all asics).
*/
-static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
{
if (!adev->dummy_page_addr)
return;
@@ -365,15 +365,3 @@ int amdgpu_gart_init(struct amdgpu_device *adev)
return 0;
}
-
-/**
- * amdgpu_gart_fini - tear down the driver info for managing the gart
- *
- * @adev: amdgpu_device pointer
- *
- * Tear down the gart driver info and free the dummy page (all asics).
- */
-void amdgpu_gart_fini(struct amdgpu_device *adev)
-{
- amdgpu_gart_dummy_page_fini(adev);
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
index a25fe97b0196..030b9d4c736a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
@@ -57,7 +57,7 @@ void amdgpu_gart_table_vram_free(struct amdgpu_device *adev);
int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev);
void amdgpu_gart_table_vram_unpin(struct amdgpu_device *adev);
int amdgpu_gart_init(struct amdgpu_device *adev);
-void amdgpu_gart_fini(struct amdgpu_device *adev);
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev);
int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
int pages);
int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index faaa6aa2faaf..433469ace6f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -115,9 +115,11 @@ int amdgpu_ih_ring_init(struct amdgpu_device *adev, struct
amdgpu_ih_ring *ih,
*/
void amdgpu_ih_ring_fini(struct amdgpu_device *adev, struct amdgpu_ih_ring *ih)
{
+
+ if (!ih->ring)
+ return;
+
if (ih->use_bus_addr) {
- if (!ih->ring)
- return;
/* add 8 bytes for the rptr/wptr shadows and
* add them to the end of the ring allocation.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 233b64dab94b..32ce0e679dc7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -361,6 +361,11 @@ void amdgpu_irq_fini_hw(struct amdgpu_device *adev)
if (!amdgpu_device_has_dc_support(adev))
[PATCH v7 04/16] drm/amdgpu: Add early fini callback
Use it to call disply code dependent on device->drv_data
before it's set to NULL on device unplug
v5: Move HW finilization into this callback to prevent MMIO accesses
post cpi remove.
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 59 +--
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +++-
drivers/gpu/drm/amd/include/amd_shared.h | 2 +
3 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 3760ce7d8ff8..18598eda18f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2558,34 +2558,26 @@ static int amdgpu_device_ip_late_init(struct
amdgpu_device *adev)
return 0;
}
-/**
- * amdgpu_device_ip_fini - run fini for hardware IPs
- *
- * @adev: amdgpu_device pointer
- *
- * Main teardown pass for hardware IPs. The list of all the hardware
- * IPs that make up the asic is walked and the hw_fini and sw_fini callbacks
- * are run. hw_fini tears down the hardware associated with each IP
- * and sw_fini tears down any software state associated with each IP.
- * Returns 0 on success, negative error code on failure.
- */
-static int amdgpu_device_ip_fini(struct amdgpu_device *adev)
+static int amdgpu_device_ip_fini_early(struct amdgpu_device *adev)
{
int i, r;
- if (amdgpu_sriov_vf(adev) && adev->virt.ras_init_done)
- amdgpu_virt_release_ras_err_handler_data(adev);
+ for (i = 0; i < adev->num_ip_blocks; i++) {
+ if (!adev->ip_blocks[i].version->funcs->early_fini)
+ continue;
- amdgpu_ras_pre_fini(adev);
+ r = adev->ip_blocks[i].version->funcs->early_fini((void *)adev);
+ if (r) {
+ DRM_DEBUG("early_fini of IP block <%s> failed %d\n",
+ adev->ip_blocks[i].version->funcs->name, r);
+ }
+ }
- if (adev->gmc.xgmi.num_physical_nodes > 1)
- amdgpu_xgmi_remove_device(adev);
+ amdgpu_amdkfd_suspend(adev, false);
amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE);
amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE);
- amdgpu_amdkfd_device_fini(adev);
-
/* need to disable SMC first */
for (i = 0; i < adev->num_ip_blocks; i++) {
if (!adev->ip_blocks[i].status.hw)
@@ -2616,6 +2608,33 @@ static int amdgpu_device_ip_fini(struct amdgpu_device
*adev)
adev->ip_blocks[i].status.hw = false;
}
+ return 0;
+}
+
+/**
+ * amdgpu_device_ip_fini - run fini for hardware IPs
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Main teardown pass for hardware IPs. The list of all the hardware
+ * IPs that make up the asic is walked and the hw_fini and sw_fini callbacks
+ * are run. hw_fini tears down the hardware associated with each IP
+ * and sw_fini tears down any software state associated with each IP.
+ * Returns 0 on success, negative error code on failure.
+ */
+static int amdgpu_device_ip_fini(struct amdgpu_device *adev)
+{
+ int i, r;
+
+ if (amdgpu_sriov_vf(adev) && adev->virt.ras_init_done)
+ amdgpu_virt_release_ras_err_handler_data(adev);
+
+ amdgpu_ras_pre_fini(adev);
+
+ if (adev->gmc.xgmi.num_physical_nodes > 1)
+ amdgpu_xgmi_remove_device(adev);
+
+ amdgpu_amdkfd_device_fini_sw(adev);
for (i = adev->num_ip_blocks - 1; i >= 0; i--) {
if (!adev->ip_blocks[i].status.sw)
@@ -3683,6 +3702,8 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
amdgpu_fbdev_fini(adev);
amdgpu_irq_fini_hw(adev);
+
+ amdgpu_device_ip_fini_early(adev);
}
void amdgpu_device_fini_sw(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 296704ce3768..6c2c6a51ce6c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1251,6 +1251,15 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
return -EINVAL;
}
+static int amdgpu_dm_early_fini(void *handle)
+{
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+ amdgpu_dm_audio_fini(adev);
+
+ return 0;
+}
+
static void amdgpu_dm_fini(struct amdgpu_device *adev)
{
int i;
@@ -1259,8 +1268,6 @@ static void amdgpu_dm_fini(struct amdgpu_device *adev)
drm_encoder_cleanup(&adev->dm.mst_encoders[i].base);
}
- amdgpu_dm_audio_fini(adev);
-
amdgpu_dm_destroy_drm_device(&adev->dm);
#if defined(CONFIG_DRM_AMD_SECURE_DISPLAY)
@@ -2298,6 +2305,7 @@ static const struct amd_ip_funcs amdgpu_dm_funcs = {
.late_init = dm_late_init,
.sw_init = dm_sw_init,
.sw_fini = dm_sw_fini,
[PATCH v7 02/16] drm/amdgpu: Split amdgpu_device_fini into early and late
Some of the stuff in amdgpu_device_fini such as HW interrupts
disable and pending fences finilization must be done right away on
pci_remove while most of the stuff which relates to finilizing and
releasing driver data structures can be kept until
drm_driver.release hook is called, i.e. when the last device
reference is dropped.
v4: Change functions prefix early->hw and late->sw
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 -
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 7 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 15 -
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 26 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 12 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/cik_ih.c| 2 +-
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 2 +-
drivers/gpu/drm/amd/amdgpu/iceland_ih.c| 2 +-
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 2 +-
drivers/gpu/drm/amd/amdgpu/si_ih.c | 2 +-
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 2 +-
17 files changed, 79 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 380801b59b07..d830a541ba89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1099,7 +1099,9 @@ static inline struct amdgpu_device
*amdgpu_ttm_adev(struct ttm_device *bdev)
int amdgpu_device_init(struct amdgpu_device *adev,
uint32_t flags);
-void amdgpu_device_fini(struct amdgpu_device *adev);
+void amdgpu_device_fini_hw(struct amdgpu_device *adev);
+void amdgpu_device_fini_sw(struct amdgpu_device *adev);
+
int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
void amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,
@@ -1319,6 +1321,8 @@ void amdgpu_driver_lastclose_kms(struct drm_device *dev);
int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv);
void amdgpu_driver_postclose_kms(struct drm_device *dev,
struct drm_file *file_priv);
+void amdgpu_driver_release_kms(struct drm_device *dev);
+
int amdgpu_device_ip_suspend(struct amdgpu_device *adev);
int amdgpu_device_suspend(struct drm_device *dev, bool fbcon);
int amdgpu_device_resume(struct drm_device *dev, bool fbcon);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b4ad1c055c70..3760ce7d8ff8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3648,15 +3648,13 @@ int amdgpu_device_init(struct amdgpu_device *adev,
* Tear down the driver info (all asics).
* Called at driver shutdown.
*/
-void amdgpu_device_fini(struct amdgpu_device *adev)
+void amdgpu_device_fini_hw(struct amdgpu_device *adev)
{
dev_info(adev->dev, "amdgpu: finishing device.\n");
flush_delayed_work(&adev->delayed_init_work);
ttm_bo_lock_delayed_workqueue(&adev->mman.bdev);
adev->shutdown = true;
- kfree(adev->pci_state);
-
/* make sure IB test finished before entering exclusive mode
* to avoid preemption on IB test
* */
@@ -3673,11 +3671,24 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
else
drm_atomic_helper_shutdown(adev_to_drm(adev));
}
- amdgpu_fence_driver_fini(adev);
+ amdgpu_fence_driver_fini_hw(adev);
+
if (adev->pm_sysfs_en)
amdgpu_pm_sysfs_fini(adev);
+ if (adev->ucode_sysfs_en)
+ amdgpu_ucode_sysfs_fini(adev);
+ sysfs_remove_files(&adev->dev->kobj, amdgpu_dev_attributes);
+
+
amdgpu_fbdev_fini(adev);
+
+ amdgpu_irq_fini_hw(adev);
+}
+
+void amdgpu_device_fini_sw(struct amdgpu_device *adev)
+{
amdgpu_device_ip_fini(adev);
+ amdgpu_fence_driver_fini_sw(adev);
release_firmware(adev->firmware.gpu_info_fw);
adev->firmware.gpu_info_fw = NULL;
adev->accel_working = false;
@@ -3703,14 +3714,13 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
adev->rmmio = NULL;
amdgpu_device_doorbell_fini(adev);
- if (adev->ucode_sysfs_en)
- amdgpu_ucode_sysfs_fini(adev);
-
- sysfs_remove_files(&adev->dev->kobj, amdgpu_dev_attributes);
if (IS_ENABLED(CONFIG_PERF_EVENTS))
amdgpu_pmu_fini(adev);
if (adev->mman.discovery_bin)
amdgpu_discovery_fini(adev);
+
+ kfree(adev->pci_state);
+
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gp
[PATCH v7 03/16] drm/amdkfd: Split kfd suspend from device exit
Helps to expdite HW related stuff to amdgpu_pci_remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 5f6696a3c778..2b06dee9a0ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -170,7 +170,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
}
}
-void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev)
+void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev)
{
if (adev->kfd.dev) {
kgd2kfd_device_exit(adev->kfd.dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 14f68c028126..f8e10af99c28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -127,7 +127,7 @@ void amdgpu_amdkfd_interrupt(struct amdgpu_device *adev,
const void *ih_ring_entry);
void amdgpu_amdkfd_device_probe(struct amdgpu_device *adev);
void amdgpu_amdkfd_device_init(struct amdgpu_device *adev);
-void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev);
+void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev);
int amdgpu_amdkfd_submit_ib(struct kgd_dev *kgd, enum kgd_engine_type engine,
uint32_t vmid, uint64_t gpu_addr,
uint32_t *ib_cmd, uint32_t ib_len);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 357b9bf62a1c..ab6d2a43c9a3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -858,10 +858,11 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
return kfd->init_complete;
}
+
+
void kgd2kfd_device_exit(struct kfd_dev *kfd)
{
if (kfd->init_complete) {
- kgd2kfd_suspend(kfd, false);
device_queue_manager_uninit(kfd->dqm);
kfd_interrupt_exit(kfd);
kfd_topology_remove_device(kfd);
--
2.25.1
[PATCH v7 01/16] drm/ttm: Remap all page faults to per process dummy page.
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Move dummy page installation
into a separate function.
v4:
Map the entire BOs VA space into on demand allocated dummy page
on the first fault for that BO.
v5: Remove duplicate return.
v6: Polish ttm_bo_vm_dummy_page, remove superfluous code.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 54 -
include/drm/ttm/ttm_bo_api.h| 2 ++
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index b31b18058965..7ff9fd551357 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -34,6 +34,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -380,19 +382,69 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
}
EXPORT_SYMBOL(ttm_bo_vm_fault_reserved);
+static void ttm_bo_release_dummy_page(struct drm_device *dev, void *res)
+{
+ struct page *dummy_page = (struct page *)res;
+
+ __free_page(dummy_page);
+}
+
+vm_fault_t ttm_bo_vm_dummy_page(struct vm_fault *vmf, pgprot_t prot)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = vma->vm_private_data;
+ struct drm_device *ddev = bo->base.dev;
+ vm_fault_t ret = VM_FAULT_NOPAGE;
+ unsigned long address;
+ unsigned long pfn;
+ struct page *page;
+
+ /* Allocate new dummy page to map all the VA range in this VMA to it*/
+ page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!page)
+ return VM_FAULT_OOM;
+
+ /* Set the page to be freed using drmm release action */
+ if (drmm_add_action_or_reset(ddev, ttm_bo_release_dummy_page, page))
+ return VM_FAULT_OOM;
+
+ pfn = page_to_pfn(page);
+
+ /* Prefault the entire VMA range right away to avoid further faults */
+ for (address = vma->vm_start; address < vma->vm_end; address +=
PAGE_SIZE) {
+
+ if (vma->vm_flags & VM_MIXEDMAP)
+ ret = vmf_insert_mixed_prot(vma, address,
+ __pfn_to_pfn_t(pfn,
PFN_DEV),
+ prot);
+ else
+ ret = vmf_insert_pfn_prot(vma, address, pfn, prot);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(ttm_bo_vm_dummy_page);
+
vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
pgprot_t prot;
struct ttm_buffer_object *bo = vma->vm_private_data;
+ struct drm_device *ddev = bo->base.dev;
vm_fault_t ret;
+ int idx;
ret = ttm_bo_vm_reserve(bo, vmf);
if (ret)
return ret;
prot = vma->vm_page_prot;
- ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, 1);
+ if (drm_dev_enter(ddev, &idx)) {
+ ret = ttm_bo_vm_fault_reserved(vmf, prot,
TTM_BO_VM_NUM_PREFAULT, 1);
+ drm_dev_exit(idx);
+ } else {
+ ret = ttm_bo_vm_dummy_page(vmf, prot);
+ }
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
return ret;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 639521880c29..254ede97f8e3 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -620,4 +620,6 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
void *buf, int len, int write);
bool ttm_bo_delayed_delete(struct ttm_device *bdev, bool remove_all);
+vm_fault_t ttm_bo_vm_dummy_page(struct vm_fault *vmf, pgprot_t prot);
+
#endif
--
2.25.1
[PATCH v7 00/16] RFC Support hot device unplug in amdgpu
Until now extracting a card either by physical extraction (e.g. eGPU with thunderbolt connection or by emulation through sysfs -> /sys/bus/pci/devices/device_id/remove) would cause random crashes in user apps. The random crashes in apps were mostly due to the app having mapped a device backed BO into its address space and was still trying to access the BO while the backing device was gone. To answer this first problem Christian suggested fixing the handling of mapped memory in the clients when the device goes away by forcibly unmapping all buffers the user processes have by clearing their respective VMAs mapping the device BOs. Then when the VMAs try to fill in the page tables again we check in the fault handler if the device is removed and if so, return an error. This will generate a SIGBUS to the application which can then cleanly terminate. This indeed was done but this in turn created a problem of kernel OOPs where the OOPSes were due to the fact that while the app was terminating because of the SIGBUS it would trigger use after free in the driver by calling to access device structures that were already released from the pci remove sequence. This was handled by introducing a 'flush' sequence during device removal where we wait for drm file reference to drop to 0 meaning all user clients directly using this device terminated. v2: Based on discussions in the mailing list with Daniel and Pekka [1] and based on the document produced by Pekka from those discussions [2] the whole approach with returning SIGBUS and waiting for all user clients having CPU mapping of device BOs to die was dropped. Instead as per the document suggestion the device structures are kept alive until the last reference to the device is dropped by user client and in the meanwhile all existing and new CPU mappings of the BOs belonging to the device directly or by dma-buf import are rerouted to per user process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am trying to get the minimal set of requirements that still give useful solution to work and this is the'Requirements for Render and Cross-Device UAPI' section and so my test case is removing a secondary device, which is render only and is not involved in KMS. v3: More updates following comments from v2 such as removing loop to find DRM file when rerouting page faults to dummy page,getting rid of unnecessary sysfs handling refactoring and moving prevention of GPU recovery post device unplug from amdgpu to scheduler layer. On top of that added unplug support for the IOMMU enabled system. v4: Drop last sysfs hack and use sysfs default attribute. Guard against write accesses after device removal to avoid modifying released memory. Update dummy pages handling to on demand allocation and release through drm managed framework. Add return value to scheduler job TO handler (by Luben Tuikov) and use this in amdgpu for prevention of GPU recovery post device unplug Also rebase on top of drm-misc-mext instead of amd-staging-drm-next v5: The most significant in this series is the improved protection from kernel driver accessing MMIO ranges that were allocated for the device once the device is gone. To do this, first a patch 'drm/amdgpu: Unmap all MMIO mappings' is introduced. This patch unamps all MMIO mapped into the kernel address space in the form of BARs and kernel BOs with CPU visible VRAM mappings. This way it helped to discover multiple such access points because a page fault would be immediately generated on access. Most of them were solved by moving HW fini code into pci_remove stage (patch drm/amdgpu: Add early fini callback) and for some who were harder to unwind drm_dev_enter/exit scoping was used. In addition all the IOCTLs and all background work and timers are now protected with drm_dev_enter/exit at their root in an attempt that after drm_dev_unplug is finished none of them run anymore and the pci_remove thread is the only thread executing which might touch the HW. To prevent deadlocks in such case against threads stuck on various HW or SW fences patches 'drm/amdgpu: Finalise device fences on device remove' and drm/amdgpu: Add rw_sem to pushing job into sched queue' take care of force signaling all such existing fences and rejecting any newly added ones. v6: Drop using drm_dev_enter/exit in conjunction with signalling HW fences before setting drm_dev_unplug. We need to devise a more robust cros DRM approach to the problem of dma fence waits falling inside drm_dev_enter/exit scopes -> move to TODO. v7: Small cosmetic changes after V6 comments. Added back the patch which invalidates MMIO mappings in the driver (register, doorbell and VRAM). While waterproof protection from MMIO accessing from V5 was dropped until a more generic approach was developed I do believe that it's better to cause kernel panic once such access happens and then fix it then let those go unnotice
[PULL] drm-misc-next
Hi Dave and Daniel, here's the first PR for drm-misc-next for what will go into v5.14. Some noteable changes are * consistency between the plane formats and allow_fb_modifiers in UAPI, * overlay support in vkms, * proper HDR support in vc4, * SVGA3 support in vmwgfx, * many TTM fixes and a debugfs file to trigger TTM's shrinker, * the core's AGP code and ioctl are now behind CONFIG_DRM_LEGACY, * a generic DRM driver that can pick up the firmware-provided framebuffer, * plus the related ownership management of framebuffer apertures, * and the usual round of cleanups throughout the tree. Best regards Thomas drm-misc-next-2021-05-12: drm-misc-next for 5.14: UAPI Changes: * drm: Disable connector force-probing for non-master clients * drm: Enforce consistency between IN_FORMATS property and cap + related driver cleanups * drm/amdgpu: Track devices, process info and fence info via /proc//fdinfo * drm/ioctl: Mark AGP-related ioctls as legacy * drm/ttm: Provide tt_shrink file to trigger shrinker via debugfs; Cross-subsystem Changes: * fbdev/efifb: Special handling of non-PCI devices * fbdev/imxfb: Fix error message Core Changes: * drm: Add connector helper to attach HDR-metadata property and convert drivers * drm: Add connector helper to compare HDR-metadata and convert drivers * drm: Add conenctor helper to attach colorspace property * drm: Signal colorimetry in HDMI infoframe * drm: Support pitch for destination buffers; Add blitter function with generic format conversion * drm: Remove struct drm_device.pdev and update legacy drivers * drm: Remove obsolete DRM_KMS_FB_HELPER config option in core and drivers * drm: Remove obsolete drm_pci_alloc/drm_pci_free * drm/aperture: Add helpers for aperture ownership and convert drivers, replaces rsp fbdev helpers * drm/agp: Mark DRM AGP code as legacy and convert legacy drivers * drm/atomic-helpers: Cleanups * drm/dp: Handle downstream port counts of 0 correctly; AUX channel fixes; Use drm_err_*/drm_dbg_*(); Cleanups * drm/dp_dual_mode: Use drm_err_*/drm_dbg_*() * drm/dp_mst: Use drm_err_*/drm_dbg_*(); Use Extended Base Receiver Capability DPCD space * drm/gem-ttm-helper: Provide helper for dumb_map_offset and convert drivers * drm/panel: Use sysfs_emit; panel-simple: Use runtime PM, Power up panel when reading EDID, Cache EDID, Cleanups; Lms397KF04: DT bindings * drm/pci: Mark AGP helpers as legacy * drm/print: Handle NULL for DRM devices gracefully * drm/scheduler: Change scheduled fence track * drm/ttm: Don't count SG BOs against pages_limit; Warn about freeing pinned BOs; Fix error handling if no BO can be swapped out; Move special handling of non-GEM drivers into vmwgfx; Move page_alignment into the BO; Set drm-misc as TTM tree in MAINTAINERS; Cleanup ttm_agp_backend; Add ttm_sys_manager for system domain; Cleanups Driver Changes: * drm: Don't set allow_fb_modifiers explictly in drivers * drm/amdgpu: Pin/unpin fixes wrt to TTM; Use bo->base.size instead of mem->num_pages * drm/ast: Use managed pcim_iomap(); Fix EDID retrieval with DP501 * drm/bridge: MHDP8546: HDCP support + DT bindings, Register DP AUX channel with userspace; Sil8620: Fix module dependencies; dw-hdmi: Add option to not load CEC driver; Fix stopping in drm_bridge_chain_pre_enable(); Ti-sn65dsi86: Fix refclk handling, Break GPIO and MIPI-to-eDP into subdrivers, Use pm_runtime autosuspend, cleanups; It66121: Add driver + DT bindings; Adv7511: Support I2S IEC958 encoding; Anx7625: fix power-on delay; Nwi-dsi: Modesetting fixes; Cleanups * drm/bochs: Support screen blanking * drm/gma500: Cleanups * drm/gud: Cleanups * drm/i915: Use correct max source link rate for MST * drm/kmb: Cleanups * drm/meson: Disable dw-hdmi CEC driver * drm/nouveau: Pin/unpin fixes wrt to TTM; Use bo->base.size instead of mem->num_pages; Register AUX adapters after their connectors * drm/qxl: Fix shadow BO unpin * drm/radeon: Duplicate some DRM AGP code to uncouple from legacy drivers * drm/simpledrm: Add a generic DRM driver for simple-framebuffer devices * drm/tiny: Fix log spam if probe function gets deferred * drm/vc4: Add support for HDR-metadata property; Cleanups * drm/virtio: Create dumb BOs as guest blobs; * drm/vkms: Use managed drmm_universal_plane_alloc(); Add XRGB plane composition; Add overlay support * drm/vmwgfx: Enable console with DRM_FBDEV_EMULATION; Fix CPU updates of coherent multisample surfaces; Remove reservation semaphore; Add initial SVGA3 support; Support amd64; Use 1-based IDR; Use min_t(); Cleanups The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5: Linux 5.13-rc1 (2021-05-09 14:17:44 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-05-12 for you to fetch changes up to 66079522883
Re: [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
On Wed, May 12, 2021 at 02:50:04PM +0200, Mauro Carvalho Chehab wrote: > v2: > - removed EM/EN DASH conversion from this patchset; Are you still thinking about doing the EN DASH --> "--" EM DASH --> "---" conversion? That's not going to change what the documentation will look like in the HTML and PDF output forms, and I think it would make life easier for people are reading and editing the Documentation/* files in text form. - Ted
Re: [PATCH v6 10/16] drm/amdgpu: Guard against write accesses after device removal
Hopefyllu Alex can chime in on this.
I will respin V7 soon.
Andrey
On 2021-05-12 10:06 a.m., Christian König wrote:
Am 12.05.21 um 16:01 schrieb Andrey Grodzovsky:
Ping - need a confirmation it's ok to keep this as a single patch given
my explanation bellow.
It was just an suggestion. Key point is the approach sounds sane to me,
but I can't say much about the psp code for example.
So maximum I can give you is an Acked-by for that.
Christian.
Andrey
On 2021-05-11 1:52 p.m., Andrey Grodzovsky wrote:
On 2021-05-11 2:50 a.m., Christian König wrote:
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
v5:
Protect more places wher memcopy_to/form_io takes place
Protect IB submissions
v6: Switch to !drm_dev_enter instead of scoping entire code
with brackets.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 17 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 63 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
+++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 31 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 11 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 22 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +-
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 44 ++--
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +--
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +--
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 26 ---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 22 +++---
.../drm/amd/pm/powerplay/smumgr/smu7_smumgr.c | 2 +
17 files changed, 257 insertions(+), 145 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a0bff4713672..94c415176cdc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -71,6 +71,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -281,7 +283,10 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
unsigned long flags;
uint32_t hi = ~0;
uint64_t last;
+ int idx;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
#ifdef CONFIG_64BIT
last = min(pos + size, adev->gmc.visible_vram_size);
@@ -299,8 +304,10 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
memcpy_fromio(buf, addr, count);
}
- if (count == size)
+ if (count == size) {
+ drm_dev_exit(idx);
return;
+ }
Maybe use a goto instead, but really just a nit pick.
pos += count;
buf += count / 4;
@@ -323,6 +330,8 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
*buf++ = RREG32_NO_KIQ(mmMM_DATA);
}
spin_unlock_irqrestore(&adev->mmio_idx_lock, flags);
+
+ drm_dev_exit(idx);
}
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 4d32233cde92..04ba5eef1e88 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -31,6 +31,8 @@
#include "amdgpu_ras.h"
#include "amdgpu_xgmi.h"
+#include
+
/**
* amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
*
@@ -151,6 +153,10 @@ int amdgpu_gmc_set_pte_pde(struct
amdgpu_device *adev, void *cpu_pt_addr,
{
void __iomem *ptr = (void *)cpu_pt_addr;
uint64_t value;
+ int idx;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return 0;
/*
* The following is for PTE only. GART does not have PDEs.
@@ -158,6 +164,9 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device
*adev, void *cpu_pt_addr,
value = addr & 0xF000ULL;
value |= flags;
writeq(value, ptr + (gpu_page_idx * 8));
+
+ drm_dev_exit(idx);
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 148a3b481b12..62fcbd446c71 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "atom.h"
@@ -137,7 +138,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring
*ring, unsigned num_ibs,
bool secure;
unsigned i;
- int r = 0;
+ int idx, r = 0;
bool need_pipe_sync = false;
if (num_ibs == 0)
@@ -169,13 +170,16 @@ int amdgpu_ib_schedule(struct amdgpu_ring
*ring, un
Re: [PATCH v6 10/16] drm/amdgpu: Guard against write accesses after device removal
Am 12.05.21 um 16:01 schrieb Andrey Grodzovsky:
Ping - need a confirmation it's ok to keep this as a single patch given
my explanation bellow.
It was just an suggestion. Key point is the approach sounds sane to me,
but I can't say much about the psp code for example.
So maximum I can give you is an Acked-by for that.
Christian.
Andrey
On 2021-05-11 1:52 p.m., Andrey Grodzovsky wrote:
On 2021-05-11 2:50 a.m., Christian König wrote:
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
v5:
Protect more places wher memcopy_to/form_io takes place
Protect IB submissions
v6: Switch to !drm_dev_enter instead of scoping entire code
with brackets.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 17 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 63 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
+++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 31 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 11 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 22 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +-
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 44 ++--
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +--
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +--
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 26 ---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 22 +++---
.../drm/amd/pm/powerplay/smumgr/smu7_smumgr.c | 2 +
17 files changed, 257 insertions(+), 145 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a0bff4713672..94c415176cdc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -71,6 +71,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -281,7 +283,10 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
unsigned long flags;
uint32_t hi = ~0;
uint64_t last;
+ int idx;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
#ifdef CONFIG_64BIT
last = min(pos + size, adev->gmc.visible_vram_size);
@@ -299,8 +304,10 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
memcpy_fromio(buf, addr, count);
}
- if (count == size)
+ if (count == size) {
+ drm_dev_exit(idx);
return;
+ }
Maybe use a goto instead, but really just a nit pick.
pos += count;
buf += count / 4;
@@ -323,6 +330,8 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
*buf++ = RREG32_NO_KIQ(mmMM_DATA);
}
spin_unlock_irqrestore(&adev->mmio_idx_lock, flags);
+
+ drm_dev_exit(idx);
}
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 4d32233cde92..04ba5eef1e88 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -31,6 +31,8 @@
#include "amdgpu_ras.h"
#include "amdgpu_xgmi.h"
+#include
+
/**
* amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
*
@@ -151,6 +153,10 @@ int amdgpu_gmc_set_pte_pde(struct
amdgpu_device *adev, void *cpu_pt_addr,
{
void __iomem *ptr = (void *)cpu_pt_addr;
uint64_t value;
+ int idx;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return 0;
/*
* The following is for PTE only. GART does not have PDEs.
@@ -158,6 +164,9 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device
*adev, void *cpu_pt_addr,
value = addr & 0xF000ULL;
value |= flags;
writeq(value, ptr + (gpu_page_idx * 8));
+
+ drm_dev_exit(idx);
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 148a3b481b12..62fcbd446c71 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "atom.h"
@@ -137,7 +138,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring
*ring, unsigned num_ibs,
bool secure;
unsigned i;
- int r = 0;
+ int idx, r = 0;
bool need_pipe_sync = false;
if (num_ibs == 0)
@@ -169,13 +170,16 @@ int amdgpu_ib_schedule(struct amdgpu_ring
*ring, unsigned num_ibs,
return -EINVAL;
}
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return -ENODEV;
Re: [PATCH v6 10/16] drm/amdgpu: Guard against write accesses after device removal
Ping - need a confirmation it's ok to keep this as a single patch given
my explanation bellow.
Andrey
On 2021-05-11 1:52 p.m., Andrey Grodzovsky wrote:
On 2021-05-11 2:50 a.m., Christian König wrote:
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
v5:
Protect more places wher memcopy_to/form_io takes place
Protect IB submissions
v6: Switch to !drm_dev_enter instead of scoping entire code
with brackets.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 17 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 63 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 31 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 11 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 22 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +-
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 44 ++--
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +--
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +--
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 26 ---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 22 +++---
.../drm/amd/pm/powerplay/smumgr/smu7_smumgr.c | 2 +
17 files changed, 257 insertions(+), 145 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a0bff4713672..94c415176cdc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -71,6 +71,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -281,7 +283,10 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
unsigned long flags;
uint32_t hi = ~0;
uint64_t last;
+ int idx;
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return;
#ifdef CONFIG_64BIT
last = min(pos + size, adev->gmc.visible_vram_size);
@@ -299,8 +304,10 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
memcpy_fromio(buf, addr, count);
}
- if (count == size)
+ if (count == size) {
+ drm_dev_exit(idx);
return;
+ }
Maybe use a goto instead, but really just a nit pick.
pos += count;
buf += count / 4;
@@ -323,6 +330,8 @@ void amdgpu_device_vram_access(struct
amdgpu_device *adev, loff_t pos,
*buf++ = RREG32_NO_KIQ(mmMM_DATA);
}
spin_unlock_irqrestore(&adev->mmio_idx_lock, flags);
+
+ drm_dev_exit(idx);
}
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 4d32233cde92..04ba5eef1e88 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -31,6 +31,8 @@
#include "amdgpu_ras.h"
#include "amdgpu_xgmi.h"
+#include
+
/**
* amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
*
@@ -151,6 +153,10 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device
*adev, void *cpu_pt_addr,
{
void __iomem *ptr = (void *)cpu_pt_addr;
uint64_t value;
+ int idx;
+
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return 0;
/*
* The following is for PTE only. GART does not have PDEs.
@@ -158,6 +164,9 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device
*adev, void *cpu_pt_addr,
value = addr & 0xF000ULL;
value |= flags;
writeq(value, ptr + (gpu_page_idx * 8));
+
+ drm_dev_exit(idx);
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 148a3b481b12..62fcbd446c71 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include "amdgpu.h"
#include "atom.h"
@@ -137,7 +138,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring,
unsigned num_ibs,
bool secure;
unsigned i;
- int r = 0;
+ int idx, r = 0;
bool need_pipe_sync = false;
if (num_ibs == 0)
@@ -169,13 +170,16 @@ int amdgpu_ib_schedule(struct amdgpu_ring
*ring, unsigned num_ibs,
return -EINVAL;
}
+ if (!drm_dev_enter(&adev->ddev, &idx))
+ return -ENODEV;
+
alloc_size = ring->funcs->emit_frame_size + num_ibs *
ring->funcs->emit_ib_size;
r = amdgpu_ring_alloc(ring, alloc_size);
if (r) {
dev_err(adev->dev, "scheduling IB failed (%d).\n", r);
- return r;
Re: [PATCH v5 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
Maxime Ripard 于2021年4月30日周五 下午5:35写道：
>
> Hi,
>
> On Sun, Apr 25, 2021 at 08:36:07PM +0800, Kevin Tang wrote:
> > Adds dsi host controller support for the Unisoc's display subsystem.
> > Adds dsi phy support for the Unisoc's display subsystem.
> > Only MIPI DSI Displays supported, DP/TV/HMDI will be support
> > in the feature.
> >
> > v1:
> > - Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
> >
> > v2:
> > - Use drm_xxx to replace all DRM_XXX.
> > - Use kzalloc to replace devm_kzalloc for sprd_dsi structure init.
> >
> > v4:
> > - Use drmm_helpers to allocate encoder.
> > - Move allocate encoder and connector to bind function.
> >
> > v5:
> > - Drop the dsi ip file prefix.
> > - Fix the checkpatch warnings.
> > - Add Signed-off-by for dsi&dphy patch.
> > - Use the mode_flags of mipi_dsi_device to setup crtc DPI and EDPI
> > mode.
> >
> > Cc: Orson Zhai
> > Cc: Chunyan Zhang
> > Signed-off-by: Kevin Tang
>
> Output from checkpatch:
> total: 0 errors, 3 warnings, 100 checks, 4207 lines checked
>
> > ---
> > drivers/gpu/drm/sprd/Kconfig |1 +
> > drivers/gpu/drm/sprd/Makefile|6 +-
> > drivers/gpu/drm/sprd/dsi_ctrl.c | 794 ++
> > drivers/gpu/drm/sprd/dsi_ctrl.h | 1475 ++
> > drivers/gpu/drm/sprd/dsi_ctrl_ppi.c | 157 +++
> > drivers/gpu/drm/sprd/dsi_ctrl_ppi.h | 26 +
> > drivers/gpu/drm/sprd/megacores_pll.c | 317 ++
> > drivers/gpu/drm/sprd/megacores_pll.h | 146 +++
> > drivers/gpu/drm/sprd/sprd_dpu.c | 17 +
> > drivers/gpu/drm/sprd/sprd_drm.c |1 +
> > drivers/gpu/drm/sprd/sprd_drm.h |1 +
> > drivers/gpu/drm/sprd/sprd_dsi.c | 1124
> > drivers/gpu/drm/sprd/sprd_dsi.h | 107 ++
> > 13 files changed, 4171 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/sprd/dsi_ctrl.c
> > create mode 100644 drivers/gpu/drm/sprd/dsi_ctrl.h
> > create mode 100644 drivers/gpu/drm/sprd/dsi_ctrl_ppi.c
> > create mode 100644 drivers/gpu/drm/sprd/dsi_ctrl_ppi.h
> > create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c
> > create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h
> > create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c
> > create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h
> >
> > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> > index 37762c333..3edeaeca0 100644
> > --- a/drivers/gpu/drm/sprd/Kconfig
> > +++ b/drivers/gpu/drm/sprd/Kconfig
> > @@ -5,6 +5,7 @@ config DRM_SPRD
> > select DRM_GEM_CMA_HELPER
> > select DRM_KMS_CMA_HELPER
> > select DRM_KMS_HELPER
> > + select DRM_MIPI_DSI
> > select VIDEOMODE_HELPERS
> > help
> > Choose this option if you have a Unisoc chipset.
> > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> > index ab12b95e6..d49f4977b 100644
> > --- a/drivers/gpu/drm/sprd/Makefile
> > +++ b/drivers/gpu/drm/sprd/Makefile
> > @@ -1,4 +1,8 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > obj-y := sprd_drm.o \
> > - sprd_dpu.o
> > + sprd_dpu.o \
> > + sprd_dsi.o \
> > + dw_dsi_ctrl.o \
> > + dw_dsi_ctrl_ppi.o \
> > + megacores_pll.o
> > diff --git a/drivers/gpu/drm/sprd/dsi_ctrl.c
> > b/drivers/gpu/drm/sprd/dsi_ctrl.c
> > new file mode 100644
> > index 0..7eccf9654
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/dsi_ctrl.c
> > @@ -0,0 +1,794 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Unisoc Inc.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "dsi_ctrl.h"
> > +
> > +/*
> > + * Modify power status of DSI Host core
> > + */
> > +void dsi_power_enable(struct dsi_context *ctx, int enable)
> > +{
> > + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> > +
> > + writel(enable, ®->SOFT_RESET);
> > +}
> > +/*
> > + * Enable/disable DPI video mode
> > + */
> > +void dsi_video_mode(struct dsi_context *ctx)
> > +{
> > + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> > +
> > + writel(0, ®->DSI_MODE_CFG);
> > +}
> > +/*
> > + * Enable command mode (Generic interface)
> > + */
> > +void dsi_cmd_mode(struct dsi_context *ctx)
> > +{
> > + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> > +
> > + writel(1, ®->DSI_MODE_CFG);
> > +}
> > +
> > +bool dsi_is_cmd_mode(struct dsi_context *ctx)
> > +{
> > + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> > +
> > + return readl(®->DSI_MODE_CFG);
> > +}
> > +/*
> > + * Configure the read back virtual channel for the generic interface
> > + */
> > +void dsi_rx_vcid(struct dsi_context *ctx, u8 vc)
> > +{
> > + struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
> > + union _0x1C virtual_channel_id;
> > +
> > + virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
> > + virtual_channel_id.bits.gen_rx_vcid = vc;
> > +
> > + writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
> >
[GIT PULL] drm/imx: fixes, dma-fence annotation, and color encoding/range plane properties
Hi Dave, Daniel, The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5: Linux 5.13-rc1 (2021-05-09 14:17:44 -0700) are available in the Git repository at: git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2021-05-12 for you to fetch changes up to fc1e985b67f9f318bc5797c9370715f5d020dac3: drm/imx: ipuv3-plane: add color encoding and range properties (2021-05-10 17:20:29 +0200) drm/imx: fixes, dma-fence annotation, and color encoding/range plane properties - Annotate dma-fence critical section in atomic_commit_tail - Fix PRG modifiers after drmm resource conversion to regain tiled scanout capability - Add 8 pixel alignment fix to support 1366x768 resolution - Stop advertising YUV formats on planes that don't support them - Add COLOR_ENCODING and COLOR_RANGE plane properties on planes that support them - Remove unnecessarily exported symbols Daniel Vetter (1): drm/imx: Annotate dma-fence critical section in commit path Liu Ying (1): drm/imx: ipuv3-plane: Remove two unnecessary export symbols Lucas Stach (1): drm/imx: ipuv3-plane: fix PRG modifiers after drm managed resource conversion Philipp Zabel (3): drm/imx: ipuv3-plane: do not advertise YUV formats on planes without CSC gpu: ipu-v3: Add Rec.709 limited range support to DP drm/imx: ipuv3-plane: add color encoding and range properties Sebastian Reichel (1): drm/imx: Add 8 pixel alignment fix drivers/gpu/drm/imx/imx-drm-core.c | 21 ++- drivers/gpu/drm/imx/imx-ldb.c | 5 ++ drivers/gpu/drm/imx/ipuv3-crtc.c | 11 +++- drivers/gpu/drm/imx/ipuv3-plane.c | 115 +++-- drivers/gpu/ipu-v3/ipu-dc.c| 5 ++ drivers/gpu/ipu-v3/ipu-di.c| 7 +++ drivers/gpu/ipu-v3/ipu-dp.c| 25 +++- include/video/imx-ipu-v3.h | 2 + 8 files changed, 167 insertions(+), 24 deletions(-)
Re: [PATCH 6/7] drm/i915/ttm, drm/ttm: Introduce a TTM i915 gem object backend
On 5/12/21 3:05 PM, Christian König wrote: Am 12.05.21 um 15:02 schrieb Thomas Hellström: On Wed, 2021-05-12 at 09:09 +0200, Christian König wrote: Am 12.05.21 um 09:05 schrieb Thomas Hellström: On Wed, 2021-05-12 at 08:57 +0200, Christian König wrote: Am 11.05.21 um 16:28 schrieb Thomas Hellström: On 5/11/21 4:09 PM, Christian König wrote: Am 11.05.21 um 16:06 schrieb Thomas Hellström (Intel): On 5/11/21 3:58 PM, Christian König wrote: Am 11.05.21 um 15:25 schrieb Thomas Hellström: Most logical place to introduce TTM buffer objects is as an i915 gem object backend. We need to add some ops to account for added functionality like delayed delete and LRU list manipulation. Initially we support only LMEM and SYSTEM memory, but SYSTEM (which in this case means evicted LMEM objects) is not visible to i915 GEM yet. The plan is to move the i915 gem system region over to the TTM system memory type in upcoming patches. We set up GPU bindings directly both from LMEM and from the system region, as there is no need to use the legacy TTM_TT memory type. We reserve that for future porting of GGTT bindings to TTM. There are some changes to TTM to allow for purging system memory buffer objects and to refuse swapping of some objects: Unfortunately i915 gem still relies heavily on short-term object pinning, and we've chosen to keep short-term-pinned buffer objects on the TTM LRU lists for now, meaning that we need some sort of mechanism to tell TTM they are not swappable. A longer term goal is to get rid of the short- term pinning. Well just use the eviction_valuable interface for this. Yes, we do that for vram/lmem eviction, but we have nothing similar for system swapping. Do I understand you correctly that you want me to add a call to eviction_valuable() also for that instead of swap_possible()? You should already have that. eviction_valuable is called in both cases. Hmm. I can only see it called from ttm_mem_evict_first() which is not in the swapping path? Or do I miss something? Mhm, looks like my recollection was wrong. We should probably move the call into the ttm_bo_evict_swapout_allowable() function. Yes, I think we also need a convention whether it's called dma_resv locked or not, since the helper accesses bo->mem, which should really only be done under reservation. At the same point, there is value in calling this function while holding the LRU lock. You actually need to call it while holding the lock because eviction otherwise ends up in an endless loop. Trying to fix that for years, but so far no luck with that. Also, I wonder whether implementations of this callback might encounter unexpected data when called from the swapout path, because at least the helper assumes it not in system memory, since it is accessing bo- mem.start. So unless we use a separate callback for swapout, there's some auditing to be done. Please audit the existing callbacks and move the callback into the function after doing that. Thanks, Christian. Would it be OK if I also move the kref_get_unless_zero() to before ttm_bo_evict_swapout_allowable() to make the code less sensitive to surprises? No, because then you need a kref_put while holding the spinlock which is not allowed. Christian. Ugh. yes, you're right. /Thomas
[PATCH 1/2] drm: panel-orientation-quirks: Update the Lenovo Ideapad D330 quirk (v2)
2 improvements to the Lenovo Ideapad D330 panel-orientation quirks:
1. Some versions of the Lenovo Ideapad D330 have a DMI_PRODUCT_NAME of
"81H3" and others have "81MD". Testing has shown that the "81MD" also has
a 90 degree mounted panel. Drop the DMI_PRODUCT_NAME from the existing
quirk so that the existing quirk matches both variants.
2. Some of the Lenovo Ideapad D330 models have a HD (800x1280) screen
instead of a FHD (1200x1920) screen (both are mounted right-side-up) add
a second Lenovo Ideapad D330 quirk for the HD version.
Changes in v2:
- Add a new quirk for Lenovo Ideapad D330 models with a HD screen instead
of a FHD screen
Link: https://github.com/systemd/systemd/pull/18884
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index f6bdec7fa925..604535b1c3a9 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -211,10 +211,15 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
},
.driver_data = (void *)&lcd800x1280_rightside_up,
- }, {/* Lenovo Ideapad D330 */
+ }, {/* Lenovo Ideapad D330-10IGM (HD) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGM"),
+ },
+ .driver_data = (void *)&lcd800x1280_rightside_up,
+ }, {/* Lenovo Ideapad D330-10IGM (FHD) */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGM"),
},
.driver_data = (void *)&lcd1200x1920_rightside_up,
--
2.31.1
[PATCH 0/2] drm: panel-orientation-quirks: Update / Add 2 quirks
Hi All, The first patch in this series is a resend of one which I submitted a couple of days ago, the other patch is new. These are pretty simple/straightforward patches if someone can give me a quick ack for these then I can push them to drm-misc-next. Regards, Hans Hans de Goede (2): drm: panel-orientation-quirks: Update the Lenovo Ideapad D330 quirk (v2) drm: panel-orientation-quirks: Add quirk for KD Kurio Smart C15200 2-in-1 drivers/gpu/drm/drm_panel_orientation_quirks.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) -- 2.31.1
[PATCH 2/2] drm: panel-orientation-quirks: Add quirk for KD Kurio Smart C15200 2-in-1
The KD Kurio Smart C15200 2-in-1 uses a panel which has been mounted 90
degrees rotated. Add a quirk for this.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 604535b1c3a9..d662292560c7 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -193,6 +193,13 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_BOARD_NAME, "TW891"),
},
.driver_data = (void *)&itworks_tw891,
+ }, {/* KD Kurio Smart C15200 2-in-1 */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "KD Interactive"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Kurio Smart"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "KDM960BCP"),
+ },
+ .driver_data = (void *)&lcd800x1280_rightside_up,
}, {/*
* Lenovo Ideapad Miix 310 laptop, only some production batches
* have a portrait screen, the resolution checks makes the quirk
--
2.31.1
Re: New uAPI for color management proposal and feedback request
On Wednesday, May 12th, 2021 at 3:04 PM, Ville Syrjälä wrote: > > Adoption: > > > > A KDE dev wants to implement the settings in the KDE settings GUI: > > > > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370 > > > > Tuxedo Computers (my employer) wants to implement the settings desktop > > environment agnostic in Tuxedo Control Center. I > > will start work on this in parallel to implementing the new kernel code. > > I suspect everyone would be happier to accept new uapi if we had > multiple compositors signed up to implement it. Sign me up. We already have a patch blocked by "Broadcast RGB" standardization: https://github.com/swaywm/wlroots/pull/2310
Re: [PATCH 6/7] drm/i915/ttm, drm/ttm: Introduce a TTM i915 gem object backend
Am 12.05.21 um 15:02 schrieb Thomas Hellström: On Wed, 2021-05-12 at 09:09 +0200, Christian König wrote: Am 12.05.21 um 09:05 schrieb Thomas Hellström: On Wed, 2021-05-12 at 08:57 +0200, Christian König wrote: Am 11.05.21 um 16:28 schrieb Thomas Hellström: On 5/11/21 4:09 PM, Christian König wrote: Am 11.05.21 um 16:06 schrieb Thomas Hellström (Intel): On 5/11/21 3:58 PM, Christian König wrote: Am 11.05.21 um 15:25 schrieb Thomas Hellström: Most logical place to introduce TTM buffer objects is as an i915 gem object backend. We need to add some ops to account for added functionality like delayed delete and LRU list manipulation. Initially we support only LMEM and SYSTEM memory, but SYSTEM (which in this case means evicted LMEM objects) is not visible to i915 GEM yet. The plan is to move the i915 gem system region over to the TTM system memory type in upcoming patches. We set up GPU bindings directly both from LMEM and from the system region, as there is no need to use the legacy TTM_TT memory type. We reserve that for future porting of GGTT bindings to TTM. There are some changes to TTM to allow for purging system memory buffer objects and to refuse swapping of some objects: Unfortunately i915 gem still relies heavily on short-term object pinning, and we've chosen to keep short-term-pinned buffer objects on the TTM LRU lists for now, meaning that we need some sort of mechanism to tell TTM they are not swappable. A longer term goal is to get rid of the short- term pinning. Well just use the eviction_valuable interface for this. Yes, we do that for vram/lmem eviction, but we have nothing similar for system swapping. Do I understand you correctly that you want me to add a call to eviction_valuable() also for that instead of swap_possible()? You should already have that. eviction_valuable is called in both cases. Hmm. I can only see it called from ttm_mem_evict_first() which is not in the swapping path? Or do I miss something? Mhm, looks like my recollection was wrong. We should probably move the call into the ttm_bo_evict_swapout_allowable() function. Yes, I think we also need a convention whether it's called dma_resv locked or not, since the helper accesses bo->mem, which should really only be done under reservation. At the same point, there is value in calling this function while holding the LRU lock. You actually need to call it while holding the lock because eviction otherwise ends up in an endless loop. Trying to fix that for years, but so far no luck with that. Also, I wonder whether implementations of this callback might encounter unexpected data when called from the swapout path, because at least the helper assumes it not in system memory, since it is accessing bo- mem.start. So unless we use a separate callback for swapout, there's some auditing to be done. Please audit the existing callbacks and move the callback into the function after doing that. Thanks, Christian. Would it be OK if I also move the kref_get_unless_zero() to before ttm_bo_evict_swapout_allowable() to make the code less sensitive to surprises? No, because then you need a kref_put while holding the spinlock which is not allowed. Christian. /Thomas Pls let me know what you think. Thanks, Thomas Christian. Thanks, Thomas
Re: New uAPI for color management proposal and feedback request
On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > Hello, > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm > properties I propose 4 new properties: > "preferred pixel encoding", "active color depth", "active color range", and > "active pixel encoding" > > > Motivation: > > Current monitors have a variety pixel encodings available: RGB, YCbCr 4:4:4, > YCbCr 4:2:2, YCbCr 4:2:0. > > In addition they might be full or limited RGB range and the monitors accept > different bit depths. > > Currently the kernel driver for AMD and Intel GPUs automatically configure > the color settings automatically with little > to no influence of the user. However there are several real world scenarios > where the user might disagree with the > default chosen by the drivers and wants to set his or her own preference. > > Some examples: > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color > information, some screens might look better on one > than the other because of bad internal conversion. The driver currently > however has a fixed default that is chosen if > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change > this currently is by editing and overloading > the edid reported by the monitor to the kernel. > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some > hardware might report that it supports the higher > port clock, but because of bad shielding on the PC, the cable, or the monitor > the screen cuts out every few seconds when > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine > without changing hardware. The drivers > currently however always default to the "best available" option even if it > might be broken. > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color > by rapidly switching between 2 adjacent > colors. They advertise themselves to the kernel as 10-bit monitors but the > user might not like the "fake" 10-bit effect > and prefer running at the native 8-bit per color. > > 4. Some screens are falsely classified as full RGB range wile they actually > use limited RGB range. This results in > washed out colors in dark and bright scenes. A user override can be helpful > to manually fix this issue when it occurs. > > There already exist several requests, discussion, and patches regarding the > thematic: > > - https://gitlab.freedesktop.org/drm/amd/-/issues/476 > > - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 > > - https://lkml.org/lkml/2021/5/7/695 > > - https://lkml.org/lkml/2021/5/11/416 > > > Current State: > > I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how > other driver handle color management > > - "max bpc", global setting applied by both i915 (only on dp i think?) and > amdgpu. Default value is "8". For every > resolution + frequency combination the highest possible even number between 6 > and max_bpc is chosen. If the range > doesn't contain a valid mode the resolution + frequency combination is > discarded (but I guess that would be a very > special edge case, if existent at all, when 6 doesn't work but 10 would > work). Intel HDMI code always checks 8, 12, and > 10 and does not check the max_bpc setting. i915 does limit things below max_bpc for both HDMI and DP. > > - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not > amdgpu), overwrites the kernel chosen color > range setting (full or limited). If I recall correctly Intel HDMI code > defaults to full unless this property is set, > Intel dp code tries to probe the monitor to find out what to use. amdgpu has > no corresponding setting (I don't know how > it's decided there). i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP specs. Unfortunately as you already mentioned there are quite a few monitors (DP monitors in particular) that don't implemnt the spec correctly. IIRC later DP specs even relaxed the wording to say that you can basically ignore the spec and do whatever you want. Which I supose is just admitting defeat and concluding that there is no way to get this right 100% of the time. > > - RGB pixel encoding can be forced by overloading a Monitors edid with one > that tells the kernel that only RGB is > possible. That doesn't work for YCbCr 4:4:4 however because of the edid > specification. Forcing YCbCr 4:2:0 would > theoretically also be possible this way. amdgpu has a debugfs switch > "force_ycbcr_420" which makes the driver default to > YCbCr 4:2:0 on all monitors if possible. > > > Proposed Solution: > > 1. Add a new uAPI property "preferred pixel encoding", as a per port setting. > > - An amdgpu specific implementation was already shared here: > https://gitlab.freedesktop.org/drm/amd/-/issues/476 > > - It also writes back the actually used encoding if the one requested was > not possible, overwriting the requested > value in the process. I
Re: [PATCH 1/2] drm/doc: document how userspace should find out CRTC index
On Wed, 12 May 2021 09:50:14 -0300 Leandro Ribeiro wrote: > On 5/6/21 5:50 AM, Pekka Paalanen wrote: > > On Wed, 28 Apr 2021 18:36:50 -0300 > > Leandro Ribeiro wrote: > > > >> In this patch we add a section to document what userspace should do to > >> find out the CRTC index. This is important as there are multiple places > >> in the documentation that need this, so it's better to just point to > >> this section and avoid repetition. > >> > >> Signed-off-by: Leandro Ribeiro > >> --- > >> Documentation/gpu/drm-uapi.rst| 14 ++ > >> drivers/gpu/drm/drm_debugfs_crc.c | 9 + > >> include/uapi/drm/drm.h| 3 ++- > >> 3 files changed, 21 insertions(+), 5 deletions(-) > >> > >> diff --git a/Documentation/gpu/drm-uapi.rst > >> b/Documentation/gpu/drm-uapi.rst > >> index 04bdc7a91d53..1aa52a6ac567 100644 > >> --- a/Documentation/gpu/drm-uapi.rst > >> +++ b/Documentation/gpu/drm-uapi.rst > >> @@ -457,6 +457,20 @@ Userspace API Structures > >> .. kernel-doc:: include/uapi/drm/drm_mode.h > >> :doc: overview > >> > >> +.. _crtc_index: > >> + > >> +CRTC index > >> +-- > >> + > >> +In some situations, it is important for userspace to find out the index > >> of a > > > > That could be said about everything, so this sentence has no > > information value. Instead, you could start by stating that CRTCs have > > both an object ID and an index, and they are not the same thing. CRTC > > index is used in cases where a densely packed identifier for a CRTC is > > needed, e.g. in bit-for-crtc masks, where using the object ID would not > > work. > > > >> +CRTC. The CRTC index should not be confused with its object id. > >> + > >> +In order to do this, userspace should first query the resources object > > > > Instead of saying what userspace must do, you could just explain where > > it can be observed. > > > >> +from the device that owns the CRTC (using the DRM_IOCTL_MODE_GETRESOURCES > >> > > > > So here you might start with: DRM_IOCTL_MODE_GETRESOURCES populates a > > structure with an array of CRTC IDs. CRTC's index is its index in that > > array. > > > >> +ioctl). The resources object contains a pointer to an array of CRTC's, > >> and also > >> +the number of entries of the array. The index of the CRTC is the same as > >> its > >> +position in this array. > > > > Anyway, the idea here is right. > > > > So what about: > > CRTC's have both an object ID and an index, and they should not be > confused. The index is used in cases where a densely packed identifier > for a CRTC is needed, for instance in a bitmask of CRTC's. (maybe a link > to the possible_crtcs field of struct drm_mode_get_plane? as example) > > DRM_IOCTL_MODE_GETRESOURCES populates a structure with an array of CRTC > id's, and the CRTC index is its position in this array. Sure, sounds good. Capitalized 'ID'? Thanks, pq pgpT4K9YvEyyz.pgp Description: OpenPGP digital signature
Re: [PATCH 6/7] drm/i915/ttm, drm/ttm: Introduce a TTM i915 gem object backend
On Wed, 2021-05-12 at 09:09 +0200, Christian König wrote: > Am 12.05.21 um 09:05 schrieb Thomas Hellström: > > On Wed, 2021-05-12 at 08:57 +0200, Christian König wrote: > > > Am 11.05.21 um 16:28 schrieb Thomas Hellström: > > > > On 5/11/21 4:09 PM, Christian König wrote: > > > > > > > > > > Am 11.05.21 um 16:06 schrieb Thomas Hellström (Intel): > > > > > > On 5/11/21 3:58 PM, Christian König wrote: > > > > > > > Am 11.05.21 um 15:25 schrieb Thomas Hellström: > > > > > > > > Most logical place to introduce TTM buffer objects is > > > > > > > > as an > > > > > > > > i915 > > > > > > > > gem object backend. We need to add some ops to account > > > > > > > > for > > > > > > > > added > > > > > > > > functionality like delayed delete and LRU list > > > > > > > > manipulation. > > > > > > > > > > > > > > > > Initially we support only LMEM and SYSTEM memory, but > > > > > > > > SYSTEM > > > > > > > > (which in this case means evicted LMEM objects) is not > > > > > > > > visible to i915 GEM yet. The plan is to move the i915 > > > > > > > > gem > > > > > > > > system > > > > > > > > region > > > > > > > > over to the TTM system memory type in upcoming patches. > > > > > > > > > > > > > > > > We set up GPU bindings directly both from LMEM and from > > > > > > > > the > > > > > > > > system > > > > > > > > region, > > > > > > > > as there is no need to use the legacy TTM_TT memory > > > > > > > > type. > > > > > > > > We reserve > > > > > > > > that for future porting of GGTT bindings to TTM. > > > > > > > > > > > > > > > > There are some changes to TTM to allow for purging > > > > > > > > system > > > > > > > > memory > > > > > > > > buffer > > > > > > > > objects and to refuse swapping of some objects: > > > > > > > > Unfortunately i915 > > > > > > > > gem > > > > > > > > still relies heavily on short-term object pinning, and > > > > > > > > we've > > > > > > > > chosen to > > > > > > > > keep short-term-pinned buffer objects on the TTM LRU > > > > > > > > lists > > > > > > > > for now, > > > > > > > > meaning that we need some sort of mechanism to tell TTM > > > > > > > > they are not > > > > > > > > swappable. A longer term goal is to get rid of the > > > > > > > > short- > > > > > > > > term > > > > > > > > pinning. > > > > > > > Well just use the eviction_valuable interface for this. > > > > > > Yes, we do that for vram/lmem eviction, but we have nothing > > > > > > similar > > > > > > for system swapping. Do I understand you correctly that you > > > > > > want me > > > > > > to add a call to eviction_valuable() also for that instead > > > > > > of > > > > > > swap_possible()? > > > > > You should already have that. eviction_valuable is called in > > > > > both > > > > > cases. > > > > > > > > > Hmm. I can only see it called from ttm_mem_evict_first() which > > > > is > > > > not > > > > in the swapping path? Or do I miss something? > > > Mhm, looks like my recollection was wrong. We should probably > > > move > > > the > > > call into the ttm_bo_evict_swapout_allowable() function. > > Yes, I think we also need a convention whether it's called dma_resv > > locked or not, since the helper accesses bo->mem, which should > > really > > only be done under reservation. At the same point, there is value > > in > > calling this function while holding the LRU lock. > > You actually need to call it while holding the lock because eviction > otherwise ends up in an endless loop. > > Trying to fix that for years, but so far no luck with that. > > > Also, I wonder whether implementations of this callback might > > encounter > > unexpected data when called from the swapout path, because at least > > the > > helper assumes it not in system memory, since it is accessing bo- > > > mem.start. > > So unless we use a separate callback for swapout, there's some > > auditing > > to be done. > > Please audit the existing callbacks and move the callback into the > function after doing that. > > Thanks, > Christian. Would it be OK if I also move the kref_get_unless_zero() to before ttm_bo_evict_swapout_allowable() to make the code less sensitive to surprises? /Thomas > > > > > Pls let me know what you think. > > Thanks, > > Thomas > > > > > > > > > Christian. > > > > > > > Thanks, > > > > > > > > Thomas > > > > > > > > > > > > > > >
[PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols
This series contain basically a cleanup from all those years of converting
files to ReST.
During the conversion period, several tools like LaTeX, pandoc, DocBook
and some specially-written scripts were used in order to convert
existing documents.
Such conversion tools - plus some text editor like LibreOffice or similar -
have
a set of rules that turns some typed ASCII characters into UTF-8 alternatives,
for instance converting commas into curly commas and adding non-breakable
spaces. All of those are meant to produce better results when the text is
displayed in HTML or PDF formats.
While it is perfectly fine to use UTF-8 characters in Linux, and specially at
the documentation, it is better to stick to the ASCII subset on such
particular case, due to a couple of reasons:
1. it makes life easier for tools like grep;
2. they easier to edit with the some commonly used text/source
code editors.
Also, Sphinx already do such conversion automatically outside
literal blocks, as described at:
https://docutils.sourceforge.io/docs/user/smartquotes.html
In this series, the following UTF-8 symbols are replaced:
- U+00a0 (' '): NO-BREAK SPACE
- U+00ad (''): SOFT HYPHEN
- U+00b4 ('´'): ACUTE ACCENT
- U+00d7 ('×'): MULTIPLICATION SIGN
- U+2010 ('‐'): HYPHEN
- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
- U+2212 ('−'): MINUS SIGN
- U+2217 ('∗'): ASTERISK OPERATOR
- U+feff (''): ZERO WIDTH NO-BREAK SPACE (BOM)
---
v2:
- removed EM/EN DASH conversion from this patchset;
- removed a few fixes, as those were addressed on a separate series.
PS.:
The first version of this series was posted with a different name:
https://lore.kernel.org/lkml/cover.1620641727.git.mchehab+hua...@kernel.org/
I also changed the patch texts, in order to better describe the patches
goals.
Mauro Carvalho Chehab (40):
docs: hwmon: Use ASCII subset instead of UTF-8 alternate symbols
docs: admin-guide: Use ASCII subset instead of UTF-8 alternate symbols
docs: admin-guide: media: ipu3.rst: Use ASCII subset instead of UTF-8
alternate symbols
docs: admin-guide: perf: imx-ddr.rst: Use ASCII subset instead of
UTF-8 alternate symbols
docs: admin-guide: pm: Use ASCII subset instead of UTF-8 alternate
symbols
docs: trace: coresight: coresight-etm4x-reference.rst: Use ASCII
subset instead of UTF-8 alternate symbols
docs: driver-api: ioctl.rst: Use ASCII subset instead of UTF-8
alternate symbols
docs: driver-api: thermal: Use ASCII subset instead of UTF-8 alternate
symbols
docs: driver-api: media: drivers: Use ASCII subset instead of UTF-8
alternate symbols
docs: driver-api: firmware: other_interfaces.rst: Use ASCII subset
instead of UTF-8 alternate symbols
docs: fault-injection: nvme-fault-injection.rst: Use ASCII subset
instead of UTF-8 alternate symbols
docs: usb: Use ASCII subset instead of UTF-8 alternate symbols
docs: process: code-of-conduct.rst: Use ASCII subset instead of UTF-8
alternate symbols
docs: userspace-api: media: fdl-appendix.rst: Use ASCII subset instead
of UTF-8 alternate symbols
docs: userspace-api: media: v4l: Use ASCII subset instead of UTF-8
alternate symbols
docs: userspace-api: media: dvb: Use ASCII subset instead of UTF-8
alternate symbols
docs: vm: zswap.rst: Use ASCII subset instead of UTF-8 alternate
symbols
docs: filesystems: f2fs.rst: Use ASCII subset instead of UTF-8
alternate symbols
docs: filesystems: ext4: Use ASCII subset instead of UTF-8 alternate
symbols
docs: kernel-hacking: Use ASCII subset instead of UTF-8 alternate
symbols
docs: hid: Use ASCII subset instead of UTF-8 alternate symbols
docs: security: tpm: tpm_event_log.rst: Use ASCII subset instead of
UTF-8 alternate symbols
docs: security: keys: trusted-encrypted.rst: Use ASCII subset instead
of UTF-8 alternate symbols
docs: networking: scaling.rst: Use ASCII subset instead of UTF-8
alternate symbols
docs: networking: devlink: devlink-dpipe.rst: Use ASCII subset instead
of UTF-8 alternate symbols
docs: networking: device_drivers: Use ASCII subset instead of UTF-8
alternate symbols
docs: x86: Use ASCII subset instead of UTF-8 alternate symbols
docs: scheduler: sched-deadline.rst: Use ASCII subset instead of UTF-8
alternate symbols
docs: power: powercap: powercap.rst: Use ASCII subset instead of UTF-8
alternate symbols
docs: ABI: Use ASCII subset instead of UTF-8 alternate symbols
docs: PCI: acpi-info.rst: Use ASCII subset instead of UTF-8 alternate
symbols
docs: gpu: Use ASCII subset instead of UTF-8 alternate symbols
docs: sound: kernel-api: writing-an-alsa-driver.rst: Use ASCII subset
[PATCH v2 32/40] docs: gpu: Use ASCII subset instead of UTF-8 alternate symbols
The conversion tools used during DocBook/LaTeX/Markdown->ReST conversion
and some automatic rules which exists on certain text editors like
LibreOffice turned ASCII characters into some UTF-8 alternatives that
are better displayed on html and PDF.
While it is OK to use UTF-8 characters in Linux, it is better to
use the ASCII subset instead of using an UTF-8 equivalent character
as it makes life easier for tools like grep, and are easier to edit
with the some commonly used text/source code editors.
Also, Sphinx already do such conversion automatically outside literal blocks:
https://docutils.sourceforge.io/docs/user/smartquotes.html
So, replace the occurences of the following UTF-8 characters:
- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
Acked-by: Jani Nikula
Acked-by: Liviu Dudau
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/gpu/i915.rst | 2 +-
Documentation/gpu/komeda-kms.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 486c720f3890..2cbf54460b48 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -361,7 +361,7 @@ Locking Guidelines
real bad.
#. Do not nest different lru/memory manager locks within each other.
- Take them in turn to update memory allocations, relying on the object’s
+ Take them in turn to update memory allocations, relying on the object's
dma_resv ww_mutex to serialize against other operations.
#. The suggestion for lru/memory managers locks is that they are small
diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
index eb693c857e2d..c2067678e92c 100644
--- a/Documentation/gpu/komeda-kms.rst
+++ b/Documentation/gpu/komeda-kms.rst
@@ -324,7 +324,7 @@ the control-abilites of device.
We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
pipelines. Since komeda is not for D71 only but also intended for later
products,
-of course we’d better share as much as possible between different products. To
+of course we'd better share as much as possible between different products. To
achieve this, split the komeda device into two layers: CORE and CHIP.
- CORE: for common features and capabilities handling.
--
2.30.2
