On Sat, 9 Sep 2023 17:42:02 +0100
Adrián Larumbe wrote:
> On 06.09.2023 10:01, Boris Brezillon wrote:
> >On Tue, 5 Sep 2023 19:45:23 +0100
> >Adrián Larumbe wrote:
> >
> >> BO's RSS is updated every time new pages are allocated on demand and mapped
> >> for the object at GPU page fault's IRQ
On Sat, 9 Sep 2023 17:55:17 +0100
Adrián Larumbe wrote:
> On 06.09.2023 10:11, Boris Brezillon wrote:
> >On Tue, 5 Sep 2023 19:45:24 +0100
> >Adrián Larumbe wrote:
> >
> >> The current implementation will try to pick the highest available size
> >> display unit as soon as the BO size exceeds
On 9/8/23 03:26, Abhinav Kumar wrote:
_dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
used during plane bandwidth calculations. However for high resolution
displays this overflows easily and leads to below errors
[dpu error]crtc83 failed performance check -7
Promote the i
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Vetter
[ Upstream commit fd0ad3b2365c1c58aa5a761c18efc4817193beb6 ]
Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state->commit refcou
6.4-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Vetter
[ Upstream commit fd0ad3b2365c1c58aa5a761c18efc4817193beb6 ]
Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state->commit refcou
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Vetter
[ Upstream commit fd0ad3b2365c1c58aa5a761c18efc4817193beb6 ]
Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state->commit refcou
On 23/08/2023 15:55, Konrad Dybcio wrote:
A7xx GPUs are - from kernel's POV anyway - basically another generation
of A6xx. They build upon the A650/A660_family advancements, skipping some
writes (presumably more values are preset correctly on reset), adding
some new ones and changing others.
One
On 9/8/2023 4:06 PM, Dmitry Baryshkov wrote:
On Fri, 8 Sept 2023 at 21:56, Abhinav Kumar wrote:
Currently, dpu_plane_atomic_check() does not check whether the
plane can process the image without exceeding the per chipset
limits for MDP clock. This leads to underflow issues because the
SSPP
On 9/8/2023 4:30 PM, Dmitry Baryshkov wrote:
On Fri, 8 Sept 2023 at 21:55, Abhinav Kumar wrote:
It's certainly possible that for large resolutions a single DPU SSPP
cannot process the image without exceeding the MDP clock limits but
it can still process it in multirect mode because the sour
On 06/09/2023 16:38, Heikki Krogerus wrote:
On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus
wrote:
On Tue, Sep 05, 2023 at 01:56:59PM +0300, Dmitry Baryshkov wrote:
Hi Heikki,
On Tue, 5 Sept 2023 at 11:50, Heikki Krogerus
wrot
The function _dpu_hw_sspp_setup_scaler3() passes and
dpu_hw_setup_scaler3() uses scaler_blk.version to determine in which way
the scaler (QSEED3) block should be programmed. However up to now we
were not setting this field. Set it now, splitting the vig_sblk data
which has different version fields.
The handling code also usually knows, which sub-block it is now looking
at. Drop unused 'id' field and arguments and merge some of sub-block
declarations.
While we are at it, also fix all VIG subblocks to contain correct scaler
block version and drop the becoming unused QSEED-related feature bits.
From: Marijn Suijten
The SSPP scaler subblk is responsible for reporting its version (via the
.id field, feature bits on the parent SSPP block, and since recently
also from reading a register to supersede a read-but-unset version field
in the catalog), leaving this global qseed_type field logical
In preparation to deduplicating SSPP subblocks, drop the (unused)
`smart_dma_priority' field from struct dpu_sspp_sub_blks. If it is
needed later (e.g. for SmartDMA v1), it should be added to the SSPP
declarations themselves.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_c
The field `id' is not used for subblocks. The handling code usually
knows, which sub-block it is now looking at. Drop the field completely.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 76 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|
From: Marijn Suijten
This pointer callback is never used and should be removed.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
[DB: dropped the helpers completely, which are unused now]
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 13 +---
As we have dropped the variadic parts of SSPP sub-blocks declarations,
deduplicate them now, reducing memory cruft.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 16 +--
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 16 +--
.../msm/disp/dpu1/catalog/dpu_5_
As the subblock info is now mostly gone, inline and drop the macro
DPU_HW_SUBBLK_INFO.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 40 ++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_
After folding QSEED3LITE and QSEED4 feature bits into QSEED3 several
VIG feature masks became equal. Drop these duplicates.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h| 2 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 8
.../
Three different features, DPU_SSPP_SCALER_QSEED3, QSEED3LITE and QSEED4
are all related to different versions of the same HW scaling block.
Corresponding driver parts use scaler_blk.version to identify the
correct way to program the hardware. In order to simplify the driver
codepath, merge these th
It's certainly possible that for large resolutions a single DPU SSPP
cannot process the image without exceeding the MDP clock limits but
it can still process it in multirect mode because the source rectangles
will get divided and can fall within the MDP clock limits.
If the SSPP cannot process the
Currently, dpu_plane_atomic_check() does not check whether the
plane can process the image without exceeding the per chipset
limits for MDP clock. This leads to underflow issues because the
SSPP is not able to complete the processing for the data rate of
the display.
Fail the dpu_plane_atomic_chec
On 9/11/2023 2:45 PM, Dmitry Baryshkov wrote:
From: Marijn Suijten
This pointer callback is never used and should be removed.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
[DB: dropped the helpers completely, which are unused now]
Signed-off-by: Dmitry Baryshkov
---
drive
On 9/11/2023 2:45 PM, Dmitry Baryshkov wrote:
From: Marijn Suijten
The SSPP scaler subblk is responsible for reporting its version (via the
.id field, feature bits on the parent SSPP block, and since recently
also from reading a register to supersede a read-but-unset version field
in the cat
On 9/11/2023 2:45 PM, Dmitry Baryshkov wrote:
The field `id' is not used for subblocks. The handling code usually
knows, which sub-block it is now looking at. Drop the field completely.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 76 +
On 9/11/2023 2:45 PM, Dmitry Baryshkov wrote:
In preparation to deduplicating SSPP subblocks, drop the (unused)
`smart_dma_priority' field from struct dpu_sspp_sub_blks. If it is
needed later (e.g. for SmartDMA v1), it should be added to the SSPP
declarations themselves.
Signed-off-by: Dmitry
26 matches
Mail list logo
