The code doesn't use dpu_caps::smart_dma_rev field. It checks if the
corresponding feature is enabled in the SSPP features. Drop the
smart_dma_rev field completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 13 -
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 47 +--
1 file changed, 27 insertions(+),
The plane's clipped coordinates has already been validated against FB
size in the drm_atomic_plane_check(). There is no need to check them
again. Remove corresponding checks and inline dpu_plane_validate_src().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 30
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 enabling setup_multirect callback. Add corresponding SmartDMA SSPP
feature bits to dpu hw
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 | 79 +++-
1 file changed, 50 insertions(+), 29 deletions(-)
From: Abhinav Kumar
Lets print the multirect_index as well in _dpu_crtc_blend_setup_pipe()
as it will give the complete information of the sw_pipe as well.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Rework bandwidth/clock calculation functions to use mode directly rather
than fetching it through the plane data.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 39 ++-
1 file changed, 17 insertions(+), 22
From: Abhinav Kumar
After cleaning up the older multirect support the function
dpu_plane_validate_multirect_v2() is unused. Lets remove it.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 111 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 7
Enable SmartDMA features for the rest of the platforms where it is
supposed to work.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 54 ---
1 file changed, 23 insertions(+), 31 deletions(-)
diff --git
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
---
Now as all accesses to pipe_cfg and pstate have been cleaned, add
struct dpu_hw_sspp_cfg to struct 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
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 | 69 +--
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git
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
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 | 90 ++-
1 file changed,
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.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98
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
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Reviewed-by: Abhinav Kumar
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
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().
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry
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 ++
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.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +
1 file changed, 5 insertions(+)
diff --git
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.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
1 file
As struct dpu_hw_sspp_cfg describes only the source and destination
rectangles, it is a software pipe configuration now. Rename it
accordingly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 6 +++---
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.
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 -
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
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 ++-
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
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
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.
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 ++
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.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
This patchset brings in multirect usage to support using two SSPP
rectangles for a single plane. Full virtual planes support is omitted
from this pull request, it will come later.
Changes since v4:
- Incorporate two fixes and two cleanup patches from Abhinav
Changes since v3:
- moved if
Lets print the multirect_index as well in _dpu_crtc_blend_setup_pipe()
as it will give the complete information of the sw_pipe as well.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
After cleaning up the older multirect support the function
dpu_plane_validate_multirect_v2() is unused. Lets remove it.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 111 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 7 --
2 files
dpu_plane_atomic_check() checks for the format to make sure its
not YUV before using multirect.
However the format is not initialized before this. This causes
a compilation issue and also would not work if YUV content
is tried.
Fix it by setting the format before the check.
Signed-off-by:
_dpu_crtc_blend_setup_mixer() should call _dpu_crtc_blend_setup_pipe()
to stage the rectangles of the sspp for both the left and right
halves.
However, it incorrectly invokes it only for the left half causing
basic wide planes to not work and only half the screen is shown
on the display.
This
While validating the DPU wide planes series [1], some issues were seen
so decided to send this out in a separate series.
Changes include compilation fixes, critical bug fixes and cleanups.
These can easily be absorbed into that series as well but for the sake
of having a clean series and also to
On 10/03/2023 00:20, Jordan Crouse wrote:
While booting with amd,imageon on a headless target the GPU probe was
failing with -ENOSPC in get_pages() from msm_gem.c.
Investigation showed that the driver was using the default 16MB VRAM
carveout because msm_use_mmu() was returning false since
While booting with amd,imageon on a headless target the GPU probe was
failing with -ENOSPC in get_pages() from msm_gem.c.
Investigation showed that the driver was using the default 16MB VRAM
carveout because msm_use_mmu() was returning false since headless devices
use a dummy parent device. Avoid
Hi Dave,
A few fixes for v6.3. Summary below. There is a back-merge of
last-cycles -fixes to avoid a merge conflict in commit 6153c44392b0
("drm/msm/adreno: fix runtime PM imbalance at unbind")
The following changes since commit 92dd0575729a423aa5524d89055e34295152a2dd:
Merge tag
On Wed, 8 Mar 2023 07:52:51 -0800
Rob Clark wrote:
> From: Rob Clark
>
> This series adds a deadline hint to fences, so realtime deadlines
> such as vblank can be communicated to the fence signaller for power/
> frequency management decisions.
>
> This is partially inspired by a trick i915
Add the Display Port controller subnode to the MDSS node.
Tested-by: Dmitry Baryshkov #SM8350-HDK
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 79
1 file changed, 79 insertions(+)
diff --git
The first QMP PHY is an USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.
Reviewed-by: Dmitry Baryshkov
Tested-by: Dmitry Baryshkov #SM8350-HDK
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 42
Add the Display Port controller subnode to the MDSS node.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 79
1 file changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
The QMP PHY is a USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 42 +---
1 file changed,
The SM8450 & SM350 shares the same DT TX IP version, use the
SM8350 compatible as fallback for SM8450.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Neil Armstrong
---
.../bindings/display/msm/dp-controller.yaml| 25 +-
1 file changed, 15 insertions(+), 10
Switch the QMP PHY to the newly documented USB3/DP Combo PHY
bindings at [1] and add the DP controller nodes.
The DP output is shared with the USB3 SuperSpeed lanes and is
usually connected to an USB-C port which Altmode is controlled
by the PMIC Glink infrastructure in discution at [1] & [2].
On 09/03/2023 01:14, Abhinav Kumar wrote:
On 3/3/2023 4:57 AM, Dmitry Baryshkov wrote:
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
On 08/03/2023 22:02, Abhinav Kumar wrote:
For DRM property blobs created by user mode using
drm_property_create_blob(), if the blob value needs to be updated the
only way is to destroy the previous blob and create a new one instead.
For some of the property blobs, if the size of the blob is
50 matches
Mail list logo
