As promised in the basic wide planes support ([1]) here comes a series
supporting 2*max_linewidth for all the planes.
Note: Unlike v1 and v2 this series finally includes support for
additional planes - having more planes than the number of SSPP blocks.
Note: this iteration features handling of ro
It is possible to slightly bend the limitations of the HW blender. If
two rectangles are contiguous (like two rectangles of a single plane)
they can be blended using a single LM blending stage, allowing one to
blend more planes via a single LM.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm
Make dpu_rm_print_state() also output the SSPP allocation state.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 1b0166bc9
Virtual wide planes give high amount of flexibility, but it is not
always enough:
In parallel multirect case only the half of the usual width is supported
for tiled formats. Thus the whole width of two tiled multirect
rectangles can not be greater than max_linewidth, which is not enough
for some p
Since SmartDMA planes provide two rectangles, it is possible to use them
to drive two different DRM planes, first plane getting the rect_0,
another one using rect_1 of the same SSPP. The sharing algorithm is
pretty simple, it requires that each of the planes can be driven by the
single rectangle an
Since we have enabled sharing of SSPP blocks between two planes, it is
now possible to use twice as much planes as there are hardware SSPP
blocks. Create additional overlay planes.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12
1 file changed, 12 i
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situ
Move a call to dpu_plane_check_inline_rotation() to the
dpu_plane_atomic_check_pipe() function, so that the rot90 constraints
are checked for both pipes. Also move rotation field from struct
dpu_plane_state to struct dpu_sw_pipe_cfg.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/d
In preparation for virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dis
Provide atomic_print_state callback to the DPU's private object. This
way the debugfs/dri/0/state will also include RM's internal state.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 ++
drivers/gpu/drm/msm/disp
Split dpu_plane_atomic_check() function into two pieces:
dpu_plane_atomic_check_nopipe() performing generic checks on the pstate,
without touching the associated pipe,
and
dpu_plane_atomic_check_pipes(), which takes into account used pipes.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/
Take into account the plane rotation and flipping when calculating src
positions for the wide plane parts.
This is not an issue yet, because rotation is only supported for the
UBWC planes and wide UBWC planes are rejected anyway because in parallel
multirect case only the half of the usual width i
The helper drm_atomic_helper_check_plane_state() runs several checks on
plane src and dst rectangles, including the check whether required
scaling fits into the required margins. The msm driver would benefit
from having a function that does all these checks except the scaling
one. Split them into a
SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
to zero decimal places.
The vendor's FW GMU is called a618_gmu.bin. And also a618 on SM7150 uses
a615 zapfw.
Add this as machine = "qcom,sm7150", because s
On 13.09.2023 21:19, Danila Tikhonov wrote:
> SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
> 128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
> to zero decimal places.
>
> The vendor's FW GMU is called a618_gmu.bin. And also a618 on SM7150 uses
> a61
On Wed, 13 Sep 2023 09:46:45 -0700
Rob Clark wrote:
> On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
> wrote:
> >
> > On Tue, 12 Sep 2023 19:14:35 -0700
> > Rob Clark wrote:
> >
> > > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> > > >
> > > > On Tue, Sep 12, 2023 at 2:32 AM Boris B
On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 19:14:35 -0700
> Rob Clark wrote:
>
> > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> > >
> > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> > > wrote:
> > > >
> > > > On Tue, 12 Sep 2023 09:37:00 +0100
>
On Wed, 13 Sept 2023 at 16:15, Heikki Krogerus
wrote:
>
> On Wed, Sep 13, 2023 at 01:26:14PM +0300, Dmitry Baryshkov wrote:
> > Hi Heikki,
> >
> > On Wed, 13 Sept 2023 at 12:27, Heikki Krogerus
> > wrote:
> > > On Tue, Sep 12, 2023 at 08:39:45PM +0300, Dmitry Baryshkov wrote:
> > > > On 12/09/202
Hi Heikki,
On Wed, 13 Sept 2023 at 12:27, Heikki Krogerus
wrote:
> On Tue, Sep 12, 2023 at 08:39:45PM +0300, Dmitry Baryshkov wrote:
> > On 12/09/2023 14:05, Heikki Krogerus wrote:
> > > On Tue, Sep 12, 2023 at 12:15:10AM +0300, Dmitry Baryshkov wrote:
> > > > On 06/09/2023 16:38, Heikki Krogerus
On 12/09/2023 19:39, Dmitry Baryshkov wrote:
On 12/09/2023 14:05, Heikki Krogerus wrote:
On Tue, Sep 12, 2023 at 12:15:10AM +0300, Dmitry Baryshkov wrote:
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
On Tue, 12 Sep 2023 19:14:35 -0700
Rob Clark wrote:
> On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> >
> > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> > wrote:
> > >
> > > On Tue, 12 Sep 2023 09:37:00 +0100
> > > Adrián Larumbe wrote:
> > >
> > > > The current implementation will
21 matches
Mail list logo
