On Tue, 4 Mar 2025 at 03:44, Jessica Zhang wrote:
>
>
>
> On 3/3/2025 3:49 PM, Dmitry Baryshkov wrote:
> > On Mon, Mar 03, 2025 at 10:28:00AM -0800, Jessica Zhang wrote:
> >> If new CTLs are reserved by CRTC but atomic_enable() is skipped, the
> >> encoders will configure the stale CTL instead of
On 3/3/2025 3:49 PM, Dmitry Baryshkov wrote:
On Mon, Mar 03, 2025 at 10:28:00AM -0800, Jessica Zhang wrote:
If new CTLs are reserved by CRTC but atomic_enable() is skipped, the
encoders will configure the stale CTL instead of the newly reserved one.
The CTLs are propagates in .atomic_mode_s
On Mon, Mar 03, 2025 at 01:23:11PM -0800, Abhinav Kumar wrote:
>
>
> On 2/24/2025 7:14 PM, Dmitry Baryshkov wrote:
> > On Mon, 24 Feb 2025 at 20:59, Abhinav Kumar
> > wrote:
> > >
> > >
> > >
> > > On 2/19/2025 9:08 AM, Dmitry Baryshkov wrote:
> > > > On Wed, Feb 19, 2025 at 06:02:20PM +0100
On Mon, Mar 03, 2025 at 10:45:19AM -0800, Jessica Zhang wrote:
>
>
> On 2/27/2025 7:07 AM, Dmitry Baryshkov wrote:
> > On Fri, Feb 14, 2025 at 04:14:26PM -0800, Jessica Zhang wrote:
> > > From: Dmitry Baryshkov
> > >
> > > Up to now the driver has been using encoder to allocate hardware
> > > r
On Mon, Mar 03, 2025 at 10:28:00AM -0800, Jessica Zhang wrote:
> If new CTLs are reserved by CRTC but atomic_enable() is skipped, the
> encoders will configure the stale CTL instead of the newly reserved one.
The CTLs are propagates in .atomic_mode_set(), not in .atomic_enable().
>
> Avoid this
On 2/24/2025 7:14 PM, Dmitry Baryshkov wrote:
On Mon, 24 Feb 2025 at 20:59, Abhinav Kumar wrote:
On 2/19/2025 9:08 AM, Dmitry Baryshkov wrote:
On Wed, Feb 19, 2025 at 06:02:20PM +0100, Krzysztof Kozlowski wrote:
On 17/02/2025 19:58, Dmitry Baryshkov wrote:
On Mon, Feb 17, 2025 at 05:41
On 2/27/2025 7:07 AM, Dmitry Baryshkov wrote:
On Fri, Feb 14, 2025 at 04:14:26PM -0800, Jessica Zhang wrote:
From: Dmitry Baryshkov
Up to now the driver has been using encoder to allocate hardware
resources. Switch it to use CRTC id in preparation for the next step.
Reviewed-by: Abhinav Ku
If new CTLs are reserved by CRTC but atomic_enable() is skipped, the
encoders will configure the stale CTL instead of the newly reserved one.
Avoid this by setting mode_changed to true if new CTLs have been
reserved by CRTC.
Note: This patch only adds tracking for the CTL reservation, but eventua
To support high-resolution cases that exceed the width limitation of
a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate,
additional pipes are necessary to enable parallel data processing
within the SSPP width constraints and MDP clock rate.
Request 4 mixers and 4 DSCs for high-r
The content of every half of screen is sent out via one interface in
dual-DSI case. The content for every interface is blended by a LM
pair in quad-pipe case, thus a LM pair should not blend any content
that cross the half of screen in this case. Clip plane into pipes per
left and right half screen
Currently, SSPPs are assigned to a maximum of two pipes. However,
quad-pipe usage scenarios require four pipes and involve configuring
two stages. In quad-pipe case, the first two pipes share a set of
mixer configurations and enable multi-rect mode when certain
conditions are met. The same applies
Currently, only 2 pipes are used at most for a plane. A stage structure
describes the configuration for a mixer pair. So only one stage is needed
for current usage cases. The quad-pipe case will be added in future and 2
stages are used in the case. So extend the stage to an array with array
size ST
The stage contains configuration for a mixer pair. Currently the plane
supports just one stage and 2 pipes. Quad-pipe support will require
handling 2 stages and 4 pipes at the same time. In preparation for that
add a separate define, PIPES_PER_PLANE, to denote number of pipes that
can be used by th
There are 2 interfaces and 4 pingpong in quad pipe. Map the 2nd
interface to 3rd PP instead of the 2nd PP.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
1 file changed, 8 insertions(+), 2 deletio
Add pipe as trace argument in trace_dpu_crtc_setup_mixer() to ease
converting pipe into pipe array later.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
There are 2 pipes in a drm plane at most currently, while 4 pipes are
required for quad-pipe case. Generalize the handling to pipe pair and
ease handling to another pipe pair later. Store pipes in array with
removing dedicated r_pipe.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed
Up to now the driver has been using encoder to allocate hardware resources.
Switch it to use CRTC id so that mixer number can be known in
dpu_plane_virtual_assign_resources() via CRTC id for sspp alloation.
Because the mixer allocation is done in drm_atomic_helper_check_modeset()
as part of CRTC o
Current code only supports usage cases with one pair of mixers at
most. To support quad-pipe usage case, two pairs of mixers need to
be reserved. The lm_count for all pairs is cleared if a peer
allocation fails in current implementation. Reset the current lm_count
to an even number instead of compl
Currently, only one pair of mixers is supported, so a non-zero counter
value is sufficient to identify the correct mixer within that pair.
However, future implementations may involve multiple mixer pairs. With
the current implementation, all mixers within the second pair would be
incorrectly select
Currently, if DSC is enabled, only 2 DSC engines are supported so far.
More usage cases will be added, such as 4 DSC in 4:4:2 topology. So
get the real number of DSCs to decide whether DSC merging is needed.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
dr
It is more likely that resource allocation may fail in complex usage
case, such as quad-pipe case, than existing usage cases.
A resource type ID is printed on failure in the current implementation,
but the raw ID number is not explicit enough to help easily understand
which resource caused the fail
Currently if DSC support is requested, the driver only supports using
2 DSC blocks. We need 4 DSC in quad-pipe topology in future. So Only
configure DSC engines in use, instead of the maximum number of DSC
engines.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
The capability stored in sblk and pipe_hw_caps is checked only for
SSPP of the first pipe in the pair with current implementation. That
of the 2nd pipe, r_pipe, is not checked and may violate hardware
capability. Move requirement check to dpu_plane_atomic_check_pipe()
for the check of every pipe.
2 or more SSPPs and dual-DSI interface are need for super wide panel.
And 4 DSC are preferred for power optimal in this case due to width
limitation of SSPP and MDP clock rate constrain. This patch set
extends number of pipes to 4 and revise related mixer blending logic
to support quad pipe. All th
On Mon, Mar 03, 2025 at 09:15:14AM +0100, Markus Elfring wrote:
> >>> The address of a data structure member was determined before
> >>> a corresponding null pointer check in the implementation of
> >>> the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
> >>>
> >>> Thus avoid the r
25 matches
Mail list logo
