On 1/15/2025 5:14 PM, Dmitry Baryshkov wrote:
On Wed, Jan 15, 2025 at 04:40:39PM -0800, Abhinav Kumar wrote:
On 1/15/2025 4:32 PM, Dmitry Baryshkov wrote:
On Wed, Jan 15, 2025 at 11:41:27AM -0800, Abhinav Kumar wrote:
On 1/15/2025 12:27 AM, Dmitry Baryshkov wrote:
On Tue, Jan 14, 2025
On 2025-01-17 6:47 pm, Connor Abbott wrote:
On some SMMUv2 implementations, including MMU-500, SMMU_CBn_FSR.SS
asserts an interrupt. The only way to clear that bit is to resume the
transaction by writing SMMU_CBn_RESUME, but typically resuming the
transaction requires complex operations (copying
Up until now we have only called the set_stall callback during
initialization when the device is off. But we will soon start calling it
to temporarily disable stall-on-fault when the device is on, so handle
that by checking if the device is on and writing SCTLR.
Signed-off-by: Connor Abbott
---
mmu-qcom.c | 46 +---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 32 +
drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 +-
9 files changed, 167 insertions(+), 6 deletions(-)
---
base-commit: 0907e7fb35756464aa34c35d6abb02998418164b
change-id: 20250117-msm-gpu-fault-fixes-next-96e
When things go wrong, the GPU is capable of quickly generating millions
of faulting translation requests per second. When that happens, in the
stall-on-fault model each access will stall until it wins the race to
signal the fault and then the RESUME register is written. This slows
processing page f
On some SMMUv2 implementations, including MMU-500, SMMU_CBn_FSR.SS
asserts an interrupt. The only way to clear that bit is to resume the
transaction by writing SMMU_CBn_RESUME, but typically resuming the
transaction requires complex operations (copying in pages, etc.) that
can't be done in IRQ cont
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 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
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
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
---
dri
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
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
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
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
2 files changed, 6 ins
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 | 15 +--
1 file changed, 13 insertions(+), 2 d
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
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
---
drivers/gpu/drm/msm/dis
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
---
drivers/gpu/drm/msm/disp/dpu1/
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.
+ enum drm_mode_subconnector subtype;
/**
* @interlace_allowed: Indicate that the bridge can handle interlaced
* modes.
---
base-commit: 8defad9f57376a89914d16757717a27b567de04e
change-id: 20250117-subconnector-246b6fe49488
Best regards,
--
Dmitry Baryshkov
Existing DPCD access functions return an error code or the number of
bytes being read / write in case of partial access. However a lot of
drivers either (incorrectly) ignore partial access or mishandle error
codes. In other cases this results in a boilerplate code which compares
returned value with
Switch drm_dp_helper.c to use new set of DPCD read / write helpers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dp_helper.c | 309
1 file changed, 118 insertions(+), 191 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/dri
Existing DPCD access functions return an error code or the number of
bytes being read / write in case of partial access. However a lot of
drivers either (incorrectly) ignore partial access or mishandle error
codes. In other cases this results in a boilerplate code which compares
returned value with
drm_dp_dpcd_read_link_status() follows the "return error code or number
of bytes read" protocol, with the code returning less bytes than
requested in case of some errors. However most of the drivers (except
the drm/msm one) interpreted that as "return error code in case of any
error". Move return l
Switch drm_dp_mst_topology.c to use new set of DPCD read / write helpers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 105 +-
1 file changed, 51 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topolog
Switch drm_dp_tunnel.c to use new set of DPCD read / write helpers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dp_tunnel.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_tunnel.c
b/drivers/gpu/drm/di
Switch drm_dp_cec.c to use new set of DPCD read / write helpers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dp_cec.c | 37 ++--
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_cec.c
b/drivers/gpu
Switch drm_dp_aux_dev.c to use new set of DPCD read / write helpers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dp_aux_dev.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_aux_dev.c
b/drivers/gpu/drm/display/d
31 matches
Mail list logo
