dri-devel March 2021

dri-devel@lists.freedesktop.org

326 participants
867 discussions

[PATCH] drm: DON'T require each CRTC to have a unique primary plane
by Paul Cercueil 30 Mar '21

30 Mar '21

The ingenic-drm driver has two mutually exclusive primary planes already; so the fact that a CRTC must have one and only one primary plane is an invalid assumption. Fixes: 96962e3de725 ("drm: require each CRTC to have a unique primary plane") Cc: <stable(a)vger.kernel.org> # 5.11 Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- drivers/gpu/drm/drm_mode_config.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index 37b4b9f0e468..d86621c41047 100644 --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -626,9 +626,7 @@ void drm_mode_config_validate(struct drm_device *dev) { struct drm_encoder *encoder; struct drm_crtc *crtc; - struct drm_plane *plane; u32 primary_with_crtc = 0, cursor_with_crtc = 0; - unsigned int num_primary = 0; if (!drm_core_check_feature(dev, DRIVER_MODESET)) return; @@ -676,13 +674,4 @@ void drm_mode_config_validate(struct drm_device *dev) cursor_with_crtc |= drm_plane_mask(crtc->cursor); } } - - drm_for_each_plane(plane, dev) { - if (plane->type == DRM_PLANE_TYPE_PRIMARY) - num_primary++; - } - - WARN(num_primary != dev->mode_config.num_crtc, - "Must have as many primary planes as there are CRTCs, but have %u primary planes and %u CRTCs", - num_primary, dev->mode_config.num_crtc); } -- 2.30.2

4 16

Re: [PATCH 15/18] vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV
by Jason Gunthorpe 30 Mar '21

30 Mar '21

On Tue, Mar 23, 2021 at 08:26:30PM +0100, Christoph Hellwig wrote: > On Tue, Mar 23, 2021 at 02:55:32PM -0300, Jason Gunthorpe wrote: > > Ideally all of this would be moved to kvmgt.c, but it is entangled with > > the rest of the "generic" code in an odd way. Thus put in a kconfig > > dependency so we don't get randconfig failures when the next patch creates > > a link time dependency related to the use of MDEV_TYPE. > > Ideally that weird struct intel_gvt_mpt would go away entirely. But > that is clearly out of scope for this patchset.. Yes.. Maybe someone from Intel will take that on, along with that other note you had. Compared to all the others this driver is quite twisty! Jason

2 1

[PATCH 1/3] drm/bridge: ti-sn65dsi86: Simplify refclk handling
by Douglas Anderson 30 Mar '21

30 Mar '21

The clock framework makes it simple to deal with an optional clock. You can call clk_get_optional() and if the clock isn't specified it'll just return NULL without complaint. It's valid to pass NULL to enable/disable/prepare/unprepare. Let's make use of this to simplify things a tiny bit. NOTE: this makes things look a tad bit asymmetric now since we check for NULL before clk_prepare_enable() but not for clk_disable_unprepare(). This seemed OK to me. We already have to check for NULL in the enable case anyway so why not avoid the extra call? Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index f27306c51e4d..942019842ff4 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -1261,14 +1261,9 @@ static int ti_sn_bridge_probe(struct i2c_client *client, return ret; } - pdata->refclk = devm_clk_get(pdata->dev, "refclk"); - if (IS_ERR(pdata->refclk)) { - ret = PTR_ERR(pdata->refclk); - if (ret == -EPROBE_DEFER) - return ret; - DRM_DEBUG_KMS("refclk not found\n"); - pdata->refclk = NULL; - } + pdata->refclk = devm_clk_get_optional(pdata->dev, "refclk"); + if (IS_ERR(pdata->refclk)) + return PTR_ERR(pdata->refclk); ret = ti_sn_bridge_parse_dsi_host(pdata); if (ret) -- 2.30.1.766.gb4fecdf3b7-goog

6 19

[PATCH AUTOSEL 4.9 05/10] drm/msm: Ratelimit invalid-fence message
by Sasha Levin 29 Mar '21

29 Mar '21

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ] We have seen a couple cases where low memory situations cause something bad to happen, followed by a flood of these messages obscuring the root cause. Lets ratelimit the dmesg spam so that next time it happens we don't lose the kernel traces leading up to this. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/msm_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c index a9b9b1c95a2e..9dbd17be51f7 100644 --- a/drivers/gpu/drm/msm/msm_fence.c +++ b/drivers/gpu/drm/msm/msm_fence.c @@ -56,7 +56,7 @@ int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence, int ret; if (fence > fctx->last_fence) { - DRM_ERROR("%s: waiting on invalid fence: %u (of %u)\n", + DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of %u)\n", fctx->name, fence, fctx->last_fence); return -EINVAL; } -- 2.30.1

1 0

[PATCH AUTOSEL 4.14 06/12] drm/msm: Ratelimit invalid-fence message
by Sasha Levin 29 Mar '21

29 Mar '21

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ] We have seen a couple cases where low memory situations cause something bad to happen, followed by a flood of these messages obscuring the root cause. Lets ratelimit the dmesg spam so that next time it happens we don't lose the kernel traces leading up to this. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/msm_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c index a2f89bac9c16..4c0ac0360b93 100644 --- a/drivers/gpu/drm/msm/msm_fence.c +++ b/drivers/gpu/drm/msm/msm_fence.c @@ -56,7 +56,7 @@ int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence, int ret; if (fence > fctx->last_fence) { - DRM_ERROR("%s: waiting on invalid fence: %u (of %u)\n", + DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of %u)\n", fctx->name, fence, fctx->last_fence); return -EINVAL; } -- 2.30.1

1 0

[PATCH AUTOSEL 4.19 08/15] drm/msm: Ratelimit invalid-fence message
by Sasha Levin 29 Mar '21

29 Mar '21

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ] We have seen a couple cases where low memory situations cause something bad to happen, followed by a flood of these messages obscuring the root cause. Lets ratelimit the dmesg spam so that next time it happens we don't lose the kernel traces leading up to this. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/msm_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c index 349c12f670eb..6c11be79574e 100644 --- a/drivers/gpu/drm/msm/msm_fence.c +++ b/drivers/gpu/drm/msm/msm_fence.c @@ -56,7 +56,7 @@ int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence, int ret; if (fence > fctx->last_fence) { - DRM_ERROR("%s: waiting on invalid fence: %u (of %u)\n", + DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of %u)\n", fctx->name, fence, fctx->last_fence); return -EINVAL; } -- 2.30.1

1 0

[PATCH AUTOSEL 5.4 11/19] drm/msm: Ratelimit invalid-fence message
by Sasha Levin 29 Mar '21

29 Mar '21

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ] We have seen a couple cases where low memory situations cause something bad to happen, followed by a flood of these messages obscuring the root cause. Lets ratelimit the dmesg spam so that next time it happens we don't lose the kernel traces leading up to this. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/msm_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c index ad2703698b05..cd59a5918038 100644 --- a/drivers/gpu/drm/msm/msm_fence.c +++ b/drivers/gpu/drm/msm/msm_fence.c @@ -45,7 +45,7 @@ int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence, int ret; if (fence > fctx->last_fence) { - DRM_ERROR("%s: waiting on invalid fence: %u (of %u)\n", + DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of %u)\n", fctx->name, fence, fctx->last_fence); return -EINVAL; } -- 2.30.1

1 0

[PATCH AUTOSEL 5.4 10/19] drm/msm/adreno: a5xx_power: Don't apply A540 lm_setup to other GPUs
by Sasha Levin 29 Mar '21

29 Mar '21

From: Konrad Dybcio <konrad.dybcio(a)somainline.org> [ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ] While passing the A530-specific lm_setup func to A530 and A540 to !A530 was fine back when only these two were supported, it certainly is not a good idea to send A540 specifics to smaller GPUs like A508 and friends. Signed-off-by: Konrad Dybcio <konrad.dybcio(a)somainline.org> Signed-off-by: Rob Clark <robdclark(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c b/drivers/gpu/drm/msm/adreno/a5xx_power.c index a3a06db675ba..ee3ff32da004 100644 --- a/drivers/gpu/drm/msm/adreno/a5xx_power.c +++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c @@ -300,7 +300,7 @@ int a5xx_power_init(struct msm_gpu *gpu) /* Set up the limits management */ if (adreno_is_a530(adreno_gpu)) a530_lm_setup(gpu); - else + else if (adreno_is_a540(adreno_gpu)) a540_lm_setup(gpu); /* Set up SP/TP power collpase */ -- 2.30.1

1 0

[PATCH AUTOSEL 5.10 21/33] drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume
by Sasha Levin 29 Mar '21

29 Mar '21

From: Kalyan Thota <kalyant(a)codeaurora.org> [ Upstream commit 627dc55c273dab308303a5217bd3e767d7083ddb ] DPU runtime resume will request for a min vote on the AXI bus as it is a necessary step before turning ON the AXI clock. The change does below 1) Move the icc path set before requesting runtime get_sync. 2) remove the dependency of hw catalog for min ib vote as it is initialized at a later point. Signed-off-by: Kalyan Thota <kalyan_t(a)codeaurora.org> Tested-by: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Rob Clark <robdclark(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index d93c44f6996d..e69ea810e18d 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -43,6 +43,8 @@ #define DPU_DEBUGFS_DIR "msm_dpu" #define DPU_DEBUGFS_HWMASKNAME "hw_log_mask" +#define MIN_IB_BW 400000000ULL /* Min ib vote 400MB */ + static int dpu_kms_hw_init(struct msm_kms *kms); static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms); @@ -929,6 +931,9 @@ static int dpu_kms_hw_init(struct msm_kms *kms) DPU_DEBUG("REG_DMA is not defined"); } + if (of_device_is_compatible(dev->dev->of_node, "qcom,sc7180-mdss")) + dpu_kms_parse_data_bus_icc_path(dpu_kms); + pm_runtime_get_sync(&dpu_kms->pdev->dev); dpu_kms->core_rev = readl_relaxed(dpu_kms->mmio + 0x0); @@ -1030,9 +1035,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms) dpu_vbif_init_memtypes(dpu_kms); - if (of_device_is_compatible(dev->dev->of_node, "qcom,sc7180-mdss")) - dpu_kms_parse_data_bus_icc_path(dpu_kms); - pm_runtime_put_sync(&dpu_kms->pdev->dev); return 0; @@ -1189,10 +1191,10 @@ static int __maybe_unused dpu_runtime_resume(struct device *dev) ddev = dpu_kms->dev; + WARN_ON(!(dpu_kms->num_paths)); /* Min vote of BW is required before turning on AXI clk */ for (i = 0; i < dpu_kms->num_paths; i++) - icc_set_bw(dpu_kms->path[i], 0, - dpu_kms->catalog->perf.min_dram_ib); + icc_set_bw(dpu_kms->path[i], 0, Bps_to_icc(MIN_IB_BW)); rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true); if (rc) { -- 2.30.1

1 0

[PATCH AUTOSEL 5.10 15/33] drm/msm: Ratelimit invalid-fence message
by Sasha Levin 29 Mar '21

29 Mar '21

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ] We have seen a couple cases where low memory situations cause something bad to happen, followed by a flood of these messages obscuring the root cause. Lets ratelimit the dmesg spam so that next time it happens we don't lose the kernel traces leading up to this. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/msm_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c index ad2703698b05..cd59a5918038 100644 --- a/drivers/gpu/drm/msm/msm_fence.c +++ b/drivers/gpu/drm/msm/msm_fence.c @@ -45,7 +45,7 @@ int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence, int ret; if (fence > fctx->last_fence) { - DRM_ERROR("%s: waiting on invalid fence: %u (of %u)\n", + DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of %u)\n", fctx->name, fence, fctx->last_fence); return -EINVAL; } -- 2.30.1

1 0

← Newer
1
...
23
24
25
26
27
28
29
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2021