Hello Dmitry Baryshkov,
The patch 6a4bc73915af: "drm/msm/dpu: drop separate
dpu_core_perf_tune overrides" from Jul 30, 2023 (linux-next), leads
to the following Smatch static checker warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:295
_dpu_core_perf_get_core_clk_rate()
err
On Fri, 4 Aug 2023 at 00:13, Danila Tikhonov wrote:
>
> So here too I add new sm7150_vig_sblk_0 and sm7150_vig_sblk_1 with v3lite?
>
> static const struct dpu_sspp_sub_blks sm7150_vig_sblk_0 =
> _VIG_SBLK(5, DPU_SSPP_SCALER_QSEED3LITE);
> static const struct dpu_sspp_sub_blks sm7150_vig_sblk_1
From: Rob Clark
Now that the runpm/qos/interconnect lockdep vs reclaim issues are
solved, we can enable the fence signalling annotations without lockdep
making it's immediate displeasure known.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_ringbuffer.c | 1 +
1 file changed, 1 insertion
From: Rob Clark
Based on
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
but made to be optional.
Signed-off-by: Rob Clark
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_main.c | 9 +
include/drm/gpu_scheduler.h| 2 ++
2 fi
From: Rob Clark
Teach lockdep that icc_bw_lock is needed in code paths that could
deadlock if they trigger reclaim.
Signed-off-by: Rob Clark
---
drivers/interconnect/core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers/inter
From: Rob Clark
For cases where icc_bw_set() can be called in callbaths that could
deadlock against shrinker/reclaim, such as runpm resume, we need to
decouple the icc locking. Introduce a new icc_bw_lock for cases where
we need to serialize bw aggregation and update to decouple that from
paths
From: Rob Clark
Annotate dev_pm_qos_mtx to teach lockdep to scream about allocations
that could trigger reclaim under dev_pm_qos_mtx.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/base/power/qos.c b/drivers/base/p
From: Rob Clark
Similar to the previous patch, move the allocation out from under
dev_pm_qos_mtx, by speculatively doing the allocation and handle
any race after acquiring dev_pm_qos_mtx by freeing the redundant
allocation.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 14 +++
From: Rob Clark
In the process of adding lockdep annotation for drm GPU scheduler's
job_run() to detect potential deadlock against shrinker/reclaim, I hit
this lockdep splat:
==
WARNING: possible circular locking dependency detected
6.
From: Rob Clark
In the process of adding lockdep annotation for GPU job_run() path to
catch potential deadlocks against the shrinker/reclaim path, I turned
up this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
This will make it easier to catch places doing allocations that can
trigger reclaim under devfreq->lock.
Because devfreq->lock is held over various devfreq_dev_profile
callbacks, there might be some fallout if those callbacks do allocations
that can trigger reclaim, but I've look
From: Rob Clark
Inspired by
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
it seemed like a good idea to get rid of memory allocation in job_run()
fence signaling path, and use lockdep annotations to yell at us about
anything that could deadlock against shrink
On 2023-08-03 22:47:24, Danila Tikhonov wrote:
> Add definitions for the display hardware used on the Qualcomm SM7150
> platform.
>
> Signed-off-by: Danila Tikhonov
> ---
> .../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 277 ++
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|
On 2023-08-03 22:47:23, Danila Tikhonov wrote:
> Document the DPU hardware found on the Qualcomm SM7150 platform.
>
> Signed-off-by: Danila Tikhonov
> ---
> .../bindings/display/msm/qcom,sm7150-dpu.yaml | 116 ++
> 1 file changed, 116 insertions(+)
> create mode 100644
> Docume
So here too I add new sm7150_vig_sblk_0 and sm7150_vig_sblk_1 with v3lite?
static const struct dpu_sspp_sub_blks sm7150_vig_sblk_0 =
_VIG_SBLK(5, DPU_SSPP_SCALER_QSEED3LITE);
static const struct dpu_sspp_sub_blks sm7150_vig_sblk_1 =
_VIG_SBLK(6, DPU_SSPP_SCALER_QSEED3LITE);
> +static con
On 8/3/2023 1:45 PM, Daniel Vetter wrote:
Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state->commit refcount a few years ago
in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
early by tracking commits, v3.")
Fix it by usi
On Thu, 3 Aug 2023 at 23:45, Daniel Vetter wrote:
>
> Apparently no one noticed that mdp5 plane states leak like a sieve
> ever since we introduced plane_state->commit refcount a few years ago
> in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
> early by tracking commits, v3.")
On Thu, 3 Aug 2023 at 22:47, Danila Tikhonov wrote:
>
> This series adds DPU support for Qualcomm SM7150 SoC.
>
> Danila Tikhonov (2):
> dt-bindings: display/msm: document DPU on SM7150
> drm/msm/dpu: Add SM7150 support
>
> .../bindings/display/msm/qcom,sm7150-dpu.yaml | 116
> .../m
On Thu, 3 Aug 2023 at 22:47, Danila Tikhonov wrote:
>
> Add definitions for the display hardware used on the Qualcomm SM7150
> platform.
>
> Signed-off-by: Danila Tikhonov
> ---
> .../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 277 ++
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
On Thu, Aug 3, 2023 at 1:45 PM Daniel Vetter wrote:
>
> Apparently no one noticed that mdp5 plane states leak like a sieve
> ever since we introduced plane_state->commit refcount a few years ago
> in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
> early by tracking commits, v3."
Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state->commit refcount a few years ago
in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
early by tracking commits, v3.")
Fix it by using the right helpers.
Fixes: 21a01abbe32a ("dr
Document the DPU hardware found on the Qualcomm SM7150 platform.
Signed-off-by: Danila Tikhonov
---
.../bindings/display/msm/qcom,sm7150-dpu.yaml | 116 ++
1 file changed, 116 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
d
Add definitions for the display hardware used on the Qualcomm SM7150
platform.
Signed-off-by: Danila Tikhonov
---
.../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 277 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
This series adds DPU support for Qualcomm SM7150 SoC.
Danila Tikhonov (2):
dt-bindings: display/msm: document DPU on SM7150
drm/msm/dpu: Add SM7150 support
.../bindings/display/msm/qcom,sm7150-dpu.yaml | 116
.../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 277 ++
..
From: Rob Clark
Mesa stopped using these pretty early in a6xx bringup[1]. Take advantage
of this to disallow some legacy UABI.
[1]
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ef722861b691ce99be3827ed05f8c0ddf2cd66e
Signed-off-by: Rob Clark
Acked-by: Daniel Vetter
---
drivers/gpu/drm
From: Rob Clark
For normal GPU devfreq, we need to acquire the GMU lock while already
holding devfreq locks. But in the teardown path, we were calling
dev_pm_domain_detach() while already holding the GMU lock, resulting in
this lockdep splat:
=
On Thu, Aug 3, 2023 at 1:38 AM Daniel Vetter wrote:
>
> On Wed, Aug 02, 2023 at 03:21:52PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > This was not strictly necessary, as page unpinning (ie. shrinker) only
> > cares about the resv. It did give us some extra sanity checking for
> > usersp
On Wed, 02 Aug 2023 09:48:53 -0400, Jonathan Marek wrote:
> sm8550 has 16 vbif clients.
>
> This fixes the extra 2 clients (DMA4/DMA5) not having their memtype
> initialized. This fixes DMA4/DMA5 planes not displaying correctly.
>
>
Applied, thanks!
[1/1] drm/msm/dpu: increase memtype count
On Wed, 02 Aug 2023 21:36:54 +0300, Dmitry Baryshkov wrote:
> All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
> This includes the common block itself, enc subblocks and some empty
> space around. Change that to pass 0x4 instead, the length of common
> register block itsel
On 28/06/2023 22:35, Konrad Dybcio wrote:
This series attempts to introduce Adreno 700 support (with A730 and A740
found on SM8450 and SM8550 respectively), reusing much of the existing
A6xx code. This submission largely lays the groundwork for expansion and
more or less gives us feature parity (
On Wed, Aug 02, 2023 at 03:21:52PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> This was not strictly necessary, as page unpinning (ie. shrinker) only
> cares about the resv. It did give us some extra sanity checking for
> userspace controlled iova, and was useful to catch issues on kernel and
On Wed, Aug 02, 2023 at 03:10:44PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Mesa stopped using these pretty early in a6xx bringup. Take advantage
> of this to disallow some legacy UABI.
>
> Signed-off-by: Rob Clark
> ---
> So, it was late 2018 when mesa stopped using relocs. At that poin
32 matches
Mail list logo
