On 02/02/2023 22:14, Abhinav Kumar wrote:
On 2/2/2023 12:10 PM, Dmitry Baryshkov wrote:
On 02/02/2023 21:54, Abhinav Kumar wrote:
On 2/2/2023 11:45 AM, Dmitry Baryshkov wrote:
On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar
wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
Remove dpu_
On 02/02/2023 21:15, Abhinav Kumar wrote:
On 2/2/2023 10:55 AM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Thu, 2 Feb 2023 at 20:41, Abhinav Kumar
wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_
On 28/01/2023 01:59, Abhinav Kumar wrote:
On 1/26/2023 10:05 PM, Dmitry Baryshkov wrote:
On Fri, 27 Jan 2023 at 02:52, Abhinav Kumar
wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
The pipe's layout is not cached, corresponding data structure is zeroed
out each time in the dpu_pla
On 2/3/2023 6:16 AM, Dmitry Baryshkov wrote:
On 28/01/2023 01:59, Abhinav Kumar wrote:
On 1/26/2023 10:05 PM, Dmitry Baryshkov wrote:
On Fri, 27 Jan 2023 at 02:52, Abhinav Kumar
wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
The pipe's layout is not cached, corresponding data
On 2/3/2023 6:09 AM, Dmitry Baryshkov wrote:
On 02/02/2023 22:14, Abhinav Kumar wrote:
On 2/2/2023 12:10 PM, Dmitry Baryshkov wrote:
On 02/02/2023 21:54, Abhinav Kumar wrote:
On 2/2/2023 11:45 AM, Dmitry Baryshkov wrote:
On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar
wrote:
On 12/29/2
When any of the components in the mdss hierarchy fails to bind,
previously bound components are being unbound again.
One such case happens when the DP controller fails to find its bridge or
panel, where adreno_unbind() will be invoked without adreno_load_gpu()
being called to invoke pm_runtime_ena
The review of the first half of v2 took more than a month. Let's update
the reviewed patches in attempt to get the first half of the series into
the acked and mergeable state. This would allow us to lower the impact
(and the patch count). At 27 patches this series is approaching the
limits of manag
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Also rename struct dpu_hw_pipe_cfg to dpu_hw_sspp_cfg to follow this
change.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms. We are going to break
the 1:1 correspondence between planes and SSPPs, so it makes no sense
anymore to create SSPP debugfs entries in dpu_plane.c
Reviewed-by: Abhinav Kumar
Signed
Follow the example of all other hw blocks and initialize SSPP blocks in
Resource Manager.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 22 ++
drive
The pipe's layout is not cached, corresponding data structure is zeroed
out each time in the dpu_plane_sspp_atomic_update(), right before the
call to _dpu_plane_set_scanout() -> dpu_format_populate_layout().
Drop plane_addr comparison against previous layout and corresponding
EAGAIN handling.
Rev
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (variable, changes during runtime) rather
than part of a plane (ideally should be statically allocated during boot).
The sspp point
There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
drivers/gpu/drm/msm/di
Where feasible, use dpu_sw_pipe rather than a combo of dpu_hw_sspp and
multirect_index/_mode arguments.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 59 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 46 +--
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 9 -
drivers/gpu/drm/msm
Wrap SSPP and multirect index/mode into a single structure that
represents software view on the pipe used.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 9 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 16 ++-
drivers/gpu/drm/
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
1 file changed, 29 insertions(+), 28 deleti
Neither source split nor multirect are properly supported at this
moment. Both of these checks depend on normalized_zpos being equal for
several planes (which is never the case for normalized zpos).
Drop these checks to simplify dpu_crtc_atomic_check(). The actual
support for either of these featur
Set SSPP_SRCn_ADDR registers to 0 while setting up solid fill, as we can
not be sure that the previous address is still valid.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dp
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
drivers/
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP
feature bits to dpu hw cat
Remove dpu_hw_fmt_layout instance from struct dpu_hw_sspp_cfg, leaving
only src_rect and dst_rect. This way all the pipes used by the plane
will have a common layout instance (as the framebuffer is shared between
them), while still keeping a separate src/dst rectangle configuration
for each pipe.
Rework bandwidth/clock calculation functions to use mode directly rather
than fetching it through the plane data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 39 ++-
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/gp
Since the driver uses clipped src coordinates, there is no need to check
against the fb coordinates. Remove corresponding checks and inline
dpu_plane_validate_src().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 30 ---
1 file changed, 10 ins
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98 +++
1 file changed, 47 ins
Split pipe-dependent code from dpu_plane_sspp_atomic_update() into the
separate function dpu_plane_sspp_update_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 --
1 file chan
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +--
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88 ++-
1 file changed,
Now as all accesses to pipe_cfg and pstate have been cleaned, re-add
struct dpu_hw_pipe_cfg back to dpu_plane_state, so that
dpu_plane_atomic_check() and dpu_plane_atomic_update() do not have a
chance to disagree about src/dst rectangles (currently
dpu_plane_atomic_check() uses unclipped rectangles
Typically SSPP can support rectangle with width up to 2560. However it's
possible to use multirect feature and split source to use the SSPP to
output two consecutive rectangles. This commit brings in this capability
to support wider screen resolutions.
Signed-off-by: Dmitry Baryshkov
---
drivers
Rework static color fill code to separate the pipe / pipe_cfg handling.
This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 70 +--
1 file changed, 41 insertions(+), 29 deletions(-)
diff --git a/driver
Rework _dpu_crtc_blend_setup_mixer() to split away pipe handling to a
separate functon. This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 86 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 ++-
2
On 03/02/2023 20:21, Dmitry Baryshkov wrote:
The review of the first half of v2 took more than a month. Let's update
the reviewed patches in attempt to get the first half of the series into
the acked and mergeable state. This would allow us to lower the impact
(and the patch count). At 27 patches
On Wed, 18 Jan 2023 05:20:24 +0200, Dmitry Baryshkov wrote:
> Add the per-SoC (qcom,sm8350-dsi-ctrl) compatible strings to DSI nodes
> to follow the pending DSI bindings changes.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sm8350: use qcom,sm8350-dsi-ctrl compatibles
commit: d7133d6d25
On Wed, 18 Jan 2023 05:17:15 +0200, Dmitry Baryshkov wrote:
> Add qcom,sc8280xp-edp to the list of eDP devices, unblocking `aux-bus'
> property and fobidding `#sound-dai-cells' property. Also since
> sc8280xp-edp, overriding sc8280xp-dp, will contain 5 reg resources, drop
> the reg contraint (as
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Also rename struct dpu_hw_pipe_cfg to dpu_hw_sspp_cfg to follow this
change.
Signed-off-by: Dmitry Baryshkov
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (variable, changes during runtime) rather
than part of a plane (ideally should be
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
LGTM now,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Set SSPP_SRCn_ADDR registers to 0 while setting up solid fill, as we can
not be sure that the previous address is still valid.
Signed-off-by: Dmitry Baryshkov
I am yet to confirm with HW team if programming 0 stride and 0 address
is absolutely
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Signed-off-by: Dmitry Baryshkov
Now with the prev change, this is
Reviewed-by: Abhinav Kumar
--
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Signed
Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h.
This removes 1 of a few remaining Qualcomm-specific headers into a more
approciate subdirectory under include/.
Suggested-by: Bjorn Andersson
Signed-off-by: Elliot Berman
---
arch/arm/mach-qcom/platsmp.c
On Feb 03 2023 13:09, Elliot Berman wrote:
> Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h.
> This removes 1 of a few remaining Qualcomm-specific headers into a more
> approciate subdirectory under include/.
>
> Suggested-by: Bjorn Andersson
> Signed-off-by: Elliot Berma
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/di
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Signed-
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
Nothing wrong with the change as such but why
On 04/02/2023 01:07, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
Noth
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enbaling setup_multirect callback. Add cor
On 04/02/2023 01:35, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not
On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote:
On 04/02/2023 01:35, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver d
On 04/02/2023 04:43, Abhinav Kumar wrote:
On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote:
On 04/02/2023 01:35, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the sup
On 2/3/2023 8:10 PM, Dmitry Baryshkov wrote:
On 04/02/2023 04:43, Abhinav Kumar wrote:
On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote:
On 04/02/2023 01:35, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->ca
55 matches
Mail list logo
