Currently, plane splitting and SSPP allocation occur during the plane
check phase. Defer these operations until dpu_assign_plane_resources()
is called from the CRTC side to ensure the topology information from
the CRTC check is available.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 112 +++++++++++++++++++-----------
2 files changed, 71 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 2d06c950e8143..debdbbe6160dd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1484,8 +1484,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
return rc;
}
- if (dpu_use_virtual_planes &&
- (crtc_state->planes_changed || crtc_state->zpos_changed)) {
+ if (crtc_state->planes_changed || crtc_state->zpos_changed) {
rc = dpu_crtc_reassign_planes(crtc, crtc_state);
if (rc < 0)
return rc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 66f240ce29d07..3c629f4df461d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1119,49 +1119,25 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state,
plane);
int ret = 0;
- struct dpu_plane *pdpu = to_dpu_plane(plane);
- struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
- struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
- struct dpu_sw_pipe *pipe = &pstate->pipe[0];
- struct dpu_sw_pipe *r_pipe = &pstate->pipe[1];
- struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg[0];
- struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->pipe_cfg[1];
- const struct drm_crtc_state *crtc_state = NULL;
- uint32_t max_linewidth = dpu_kms->catalog->caps->max_linewidth;
+ struct drm_crtc_state *crtc_state = NULL;
if (new_plane_state->crtc)
crtc_state = drm_atomic_get_new_crtc_state(state,
new_plane_state->crtc);
- pipe->sspp = dpu_rm_get_sspp(&dpu_kms->rm, pdpu->pipe);
-
- if (!pipe->sspp)
- return -EINVAL;
-
ret = dpu_plane_atomic_check_nosspp(plane, new_plane_state, crtc_state);
if (ret)
return ret;
- ret = dpu_plane_split(plane, new_plane_state, crtc_state);
- if (ret)
- return ret;
-
if (!new_plane_state->visible)
return 0;
- if (!dpu_plane_try_multirect_parallel(pipe, pipe_cfg, r_pipe, r_pipe_cfg,
- pipe->sspp,
- msm_framebuffer_format(new_plane_state->fb),
- max_linewidth)) {
- DPU_DEBUG_PLANE(pdpu, "invalid " DRM_RECT_FMT " /" DRM_RECT_FMT
- " max_line:%u, can't use split source\n",
- DRM_RECT_ARG(&pipe_cfg->src_rect),
- DRM_RECT_ARG(&r_pipe_cfg->src_rect),
- max_linewidth);
- return -E2BIG;
- }
-
- return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
+ /*
+ * To trigger the callback of dpu_assign_plane_resources() to
+ * finish the deferred sspp check
+ */
+ crtc_state->planes_changed = true;
+ return 0;
}
static int dpu_plane_virtual_atomic_check(struct drm_plane *plane,
@@ -1186,10 +1162,6 @@ static int dpu_plane_virtual_atomic_check(struct drm_plane *plane,
if (ret)
return ret;
- ret = dpu_plane_split(plane, plane_state, crtc_state);
- if (ret)
- return ret;
-
if (!plane_state->visible) {
/*
* resources are freed by dpu_crtc_assign_plane_resources(),
@@ -1261,9 +1233,9 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
struct dpu_global_state *global_state,
struct drm_atomic_state *state,
struct drm_plane_state *plane_state,
+ const struct drm_crtc_state *crtc_state,
struct drm_plane_state **prev_adjacent_plane_state)
{
- const struct drm_crtc_state *crtc_state = NULL;
struct drm_plane *plane = plane_state->plane;
struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
struct dpu_rm_sspp_requirements reqs;
@@ -1273,10 +1245,6 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
const struct msm_format *fmt;
int i, ret;
- if (plane_state->crtc)
- crtc_state = drm_atomic_get_new_crtc_state(state,
- plane_state->crtc);
-
pstate = to_dpu_plane_state(plane_state);
for (i = 0; i < STAGES_PER_PLANE; i++)
prev_adjacent_pstate[i] = prev_adjacent_plane_state[i] ?
@@ -1288,6 +1256,10 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
if (!plane_state->fb)
return -EINVAL;
+ ret = dpu_plane_split(plane, plane_state, crtc_state);
+ if (ret)
+ return ret;
+
fmt = msm_framebuffer_format(plane_state->fb);
reqs.yuv = MSM_FORMAT_IS_YUV(fmt);
reqs.scale = (plane_state->src_w >> 16 != plane_state->crtc_w) ||
@@ -1318,14 +1290,59 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
}
+static int dpu_plane_assign_resources(struct drm_crtc *crtc,
+ struct dpu_global_state *global_state,
+ struct drm_atomic_state *state,
+ struct drm_plane_state *plane_state,
+ const struct drm_crtc_state *crtc_state,
+ struct drm_plane_state **prev_adjacent_plane_state)
+{
+ struct drm_plane *plane = plane_state->plane;
+ struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane_state);
+ struct dpu_sw_pipe *pipe = &pstate->pipe[0];
+ struct dpu_sw_pipe *r_pipe = &pstate->pipe[1];
+ struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg[0];
+ struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->pipe_cfg[1];
+ struct dpu_plane *pdpu = to_dpu_plane(plane);
+ int ret;
+
+ if (!plane_state->visible)
+ return 0;
+
+ pipe->sspp = dpu_rm_get_sspp(&dpu_kms->rm, pdpu->pipe);
+ if (!pipe->sspp)
+ return -EINVAL;
+
+ ret = dpu_plane_split(plane, plane_state, crtc_state);
+ if (ret)
+ return ret;
+
+ if (!dpu_plane_try_multirect_parallel(pipe, pipe_cfg, r_pipe, r_pipe_cfg,
+ pipe->sspp,
+ msm_framebuffer_format(plane_state->fb),
+ dpu_kms->catalog->caps->max_linewidth)) {
+ DPU_DEBUG_PLANE(pdpu, "invalid " DRM_RECT_FMT " /" DRM_RECT_FMT
+ " max_line:%u, can't use split source\n",
+ DRM_RECT_ARG(&pipe_cfg->src_rect),
+ DRM_RECT_ARG(&r_pipe_cfg->src_rect),
+ dpu_kms->catalog->caps->max_linewidth);
+ return -E2BIG;
+ }
+
+ return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
+}
+
int dpu_assign_plane_resources(struct dpu_global_state *global_state,
struct drm_atomic_state *state,
struct drm_crtc *crtc,
struct drm_plane_state **states,
unsigned int num_planes)
{
- unsigned int i;
struct drm_plane_state *prev_adjacent_plane_state[STAGES_PER_PLANE] = { NULL };
+ const struct drm_crtc_state *crtc_state = NULL;
+ unsigned int i;
+ int ret;
for (i = 0; i < num_planes; i++) {
struct drm_plane_state *plane_state = states[i];
@@ -1334,8 +1351,19 @@ int dpu_assign_plane_resources(struct dpu_global_state *global_state,
!plane_state->visible)
continue;
- int ret = dpu_plane_virtual_assign_resources(crtc, global_state,
+ if (plane_state->crtc)
+ crtc_state = drm_atomic_get_new_crtc_state(state,
+ plane_state->crtc);
+
+ if (!dpu_use_virtual_planes)
+ ret = dpu_plane_assign_resources(crtc, global_state,
+ state, plane_state,
+ crtc_state,
+ prev_adjacent_plane_state);
+ else
+ ret = dpu_plane_virtual_assign_resources(crtc, global_state,
state, plane_state,
+ crtc_state,
prev_adjacent_plane_state);
if (ret)
return ret;
--
2.43.0On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote:
> Currently, plane splitting and SSPP allocation occur during the plane
> check phase. Defer these operations until dpu_assign_plane_resources()
> is called from the CRTC side to ensure the topology information from
> the CRTC check is available.
Why is it important? What is broken otherwise?
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 112 +++++++++++++++++++-----------
> 2 files changed, 71 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 2d06c950e8143..debdbbe6160dd 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1484,8 +1484,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
> return rc;
> }
>
> - if (dpu_use_virtual_planes &&
> - (crtc_state->planes_changed || crtc_state->zpos_changed)) {
> + if (crtc_state->planes_changed || crtc_state->zpos_changed) {
> rc = dpu_crtc_reassign_planes(crtc, crtc_state);
> if (rc < 0)
> return rc;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index 66f240ce29d07..3c629f4df461d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -1119,49 +1119,25 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state,
> plane);
> int ret = 0;
> - struct dpu_plane *pdpu = to_dpu_plane(plane);
> - struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
> - struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
> - struct dpu_sw_pipe *pipe = &pstate->pipe[0];
> - struct dpu_sw_pipe *r_pipe = &pstate->pipe[1];
> - struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg[0];
> - struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->pipe_cfg[1];
> - const struct drm_crtc_state *crtc_state = NULL;
> - uint32_t max_linewidth = dpu_kms->catalog->caps->max_linewidth;
> + struct drm_crtc_state *crtc_state = NULL;
>
> if (new_plane_state->crtc)
> crtc_state = drm_atomic_get_new_crtc_state(state,
> new_plane_state->crtc);
>
> - pipe->sspp = dpu_rm_get_sspp(&dpu_kms->rm, pdpu->pipe);
> -
> - if (!pipe->sspp)
> - return -EINVAL;
> -
> ret = dpu_plane_atomic_check_nosspp(plane, new_plane_state, crtc_state);
> if (ret)
> return ret;
>
> - ret = dpu_plane_split(plane, new_plane_state, crtc_state);
> - if (ret)
> - return ret;
> -
> if (!new_plane_state->visible)
> return 0;
>
> - if (!dpu_plane_try_multirect_parallel(pipe, pipe_cfg, r_pipe, r_pipe_cfg,
> - pipe->sspp,
> - msm_framebuffer_format(new_plane_state->fb),
> - max_linewidth)) {
> - DPU_DEBUG_PLANE(pdpu, "invalid " DRM_RECT_FMT " /" DRM_RECT_FMT
> - " max_line:%u, can't use split source\n",
> - DRM_RECT_ARG(&pipe_cfg->src_rect),
> - DRM_RECT_ARG(&r_pipe_cfg->src_rect),
> - max_linewidth);
> - return -E2BIG;
> - }
> -
> - return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
> + /*
> + * To trigger the callback of dpu_assign_plane_resources() to
> + * finish the deferred sspp check
> + */
> + crtc_state->planes_changed = true;
> + return 0;
> }
>
> static int dpu_plane_virtual_atomic_check(struct drm_plane *plane,
> @@ -1186,10 +1162,6 @@ static int dpu_plane_virtual_atomic_check(struct drm_plane *plane,
> if (ret)
> return ret;
>
> - ret = dpu_plane_split(plane, plane_state, crtc_state);
> - if (ret)
> - return ret;
> -
> if (!plane_state->visible) {
> /*
> * resources are freed by dpu_crtc_assign_plane_resources(),
> @@ -1261,9 +1233,9 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
> struct dpu_global_state *global_state,
> struct drm_atomic_state *state,
> struct drm_plane_state *plane_state,
> + const struct drm_crtc_state *crtc_state,
> struct drm_plane_state **prev_adjacent_plane_state)
> {
> - const struct drm_crtc_state *crtc_state = NULL;
> struct drm_plane *plane = plane_state->plane;
> struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
> struct dpu_rm_sspp_requirements reqs;
> @@ -1273,10 +1245,6 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
> const struct msm_format *fmt;
> int i, ret;
>
> - if (plane_state->crtc)
> - crtc_state = drm_atomic_get_new_crtc_state(state,
> - plane_state->crtc);
> -
> pstate = to_dpu_plane_state(plane_state);
> for (i = 0; i < STAGES_PER_PLANE; i++)
> prev_adjacent_pstate[i] = prev_adjacent_plane_state[i] ?
> @@ -1288,6 +1256,10 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
> if (!plane_state->fb)
> return -EINVAL;
>
> + ret = dpu_plane_split(plane, plane_state, crtc_state);
> + if (ret)
> + return ret;
> +
> fmt = msm_framebuffer_format(plane_state->fb);
> reqs.yuv = MSM_FORMAT_IS_YUV(fmt);
> reqs.scale = (plane_state->src_w >> 16 != plane_state->crtc_w) ||
> @@ -1318,14 +1290,59 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
> return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
> }
>
> +static int dpu_plane_assign_resources(struct drm_crtc *crtc,
> + struct dpu_global_state *global_state,
> + struct drm_atomic_state *state,
> + struct drm_plane_state *plane_state,
> + const struct drm_crtc_state *crtc_state,
> + struct drm_plane_state **prev_adjacent_plane_state)
> +{
> + struct drm_plane *plane = plane_state->plane;
> + struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
> + struct dpu_plane_state *pstate = to_dpu_plane_state(plane_state);
> + struct dpu_sw_pipe *pipe = &pstate->pipe[0];
> + struct dpu_sw_pipe *r_pipe = &pstate->pipe[1];
> + struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg[0];
> + struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->pipe_cfg[1];
> + struct dpu_plane *pdpu = to_dpu_plane(plane);
> + int ret;
> +
> + if (!plane_state->visible)
> + return 0;
> +
> + pipe->sspp = dpu_rm_get_sspp(&dpu_kms->rm, pdpu->pipe);
> + if (!pipe->sspp)
> + return -EINVAL;
> +
> + ret = dpu_plane_split(plane, plane_state, crtc_state);
> + if (ret)
> + return ret;
> +
> + if (!dpu_plane_try_multirect_parallel(pipe, pipe_cfg, r_pipe, r_pipe_cfg,
> + pipe->sspp,
> + msm_framebuffer_format(plane_state->fb),
> + dpu_kms->catalog->caps->max_linewidth)) {
> + DPU_DEBUG_PLANE(pdpu, "invalid " DRM_RECT_FMT " /" DRM_RECT_FMT
> + " max_line:%u, can't use split source\n",
> + DRM_RECT_ARG(&pipe_cfg->src_rect),
> + DRM_RECT_ARG(&r_pipe_cfg->src_rect),
> + dpu_kms->catalog->caps->max_linewidth);
> + return -E2BIG;
> + }
> +
> + return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
> +}
> +
> int dpu_assign_plane_resources(struct dpu_global_state *global_state,
> struct drm_atomic_state *state,
> struct drm_crtc *crtc,
> struct drm_plane_state **states,
> unsigned int num_planes)
> {
> - unsigned int i;
> struct drm_plane_state *prev_adjacent_plane_state[STAGES_PER_PLANE] = { NULL };
> + const struct drm_crtc_state *crtc_state = NULL;
> + unsigned int i;
> + int ret;
>
> for (i = 0; i < num_planes; i++) {
> struct drm_plane_state *plane_state = states[i];
> @@ -1334,8 +1351,19 @@ int dpu_assign_plane_resources(struct dpu_global_state *global_state,
> !plane_state->visible)
> continue;
>
> - int ret = dpu_plane_virtual_assign_resources(crtc, global_state,
> + if (plane_state->crtc)
> + crtc_state = drm_atomic_get_new_crtc_state(state,
> + plane_state->crtc);
> +
> + if (!dpu_use_virtual_planes)
> + ret = dpu_plane_assign_resources(crtc, global_state,
> + state, plane_state,
> + crtc_state,
> + prev_adjacent_plane_state);
> + else
> + ret = dpu_plane_virtual_assign_resources(crtc, global_state,
> state, plane_state,
> + crtc_state,
> prev_adjacent_plane_state);
> if (ret)
> return ret;
>
> --
> 2.43.0
>
--
With best wishes
Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道：
>
> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote:
> > Currently, plane splitting and SSPP allocation occur during the plane
> > check phase. Defer these operations until dpu_assign_plane_resources()
> > is called from the CRTC side to ensure the topology information from
> > the CRTC check is available.
>
> Why is it important? What is broken otherwise?
I see. Thanks! Will add below lines in next version.
By default, the plane check occurs before the CRTC check.
Without topology information from the CRTC, plane splitting
cannot be properly executed. Consequently, the SSPP
engine starts without a valid memory address, which triggers
an IOMMU warning.
>
> >
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +-
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 112 +++++++++++++++++++-----------
> > 2 files changed, 71 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > index 2d06c950e8143..debdbbe6160dd 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > @@ -1484,8 +1484,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
> > return rc;
> > }
> >
> > - if (dpu_use_virtual_planes &&
> > - (crtc_state->planes_changed || crtc_state->zpos_changed)) {
> > + if (crtc_state->planes_changed || crtc_state->zpos_changed) {
> > rc = dpu_crtc_reassign_planes(crtc, crtc_state);
> > if (rc < 0)
> > return rc;
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index 66f240ce29d07..3c629f4df461d 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -1119,49 +1119,25 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
> > struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state,
> > plane);
> > int ret = 0;
> > - struct dpu_plane *pdpu = to_dpu_plane(plane);
> > - struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
> > - struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
> > - struct dpu_sw_pipe *pipe = &pstate->pipe[0];
> > - struct dpu_sw_pipe *r_pipe = &pstate->pipe[1];
> > - struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg[0];
> > - struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->pipe_cfg[1];
> > - const struct drm_crtc_state *crtc_state = NULL;
> > - uint32_t max_linewidth = dpu_kms->catalog->caps->max_linewidth;
> > + struct drm_crtc_state *crtc_state = NULL;
> >
> > if (new_plane_state->crtc)
> > crtc_state = drm_atomic_get_new_crtc_state(state,
> > new_plane_state->crtc);
> >
> > - pipe->sspp = dpu_rm_get_sspp(&dpu_kms->rm, pdpu->pipe);
> > -
> > - if (!pipe->sspp)
> > - return -EINVAL;
> > -
> > ret = dpu_plane_atomic_check_nosspp(plane, new_plane_state, crtc_state);
> > if (ret)
> > return ret;
> >
> > - ret = dpu_plane_split(plane, new_plane_state, crtc_state);
> > - if (ret)
> > - return ret;
> > -
> > if (!new_plane_state->visible)
> > return 0;
> >
> > - if (!dpu_plane_try_multirect_parallel(pipe, pipe_cfg, r_pipe, r_pipe_cfg,
> > - pipe->sspp,
> > - msm_framebuffer_format(new_plane_state->fb),
> > - max_linewidth)) {
> > - DPU_DEBUG_PLANE(pdpu, "invalid " DRM_RECT_FMT " /" DRM_RECT_FMT
> > - " max_line:%u, can't use split source\n",
> > - DRM_RECT_ARG(&pipe_cfg->src_rect),
> > - DRM_RECT_ARG(&r_pipe_cfg->src_rect),
> > - max_linewidth);
> > - return -E2BIG;
> > - }
> > -
> > - return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
> > + /*
> > + * To trigger the callback of dpu_assign_plane_resources() to
> > + * finish the deferred sspp check
> > + */
> > + crtc_state->planes_changed = true;
> > + return 0;
> > }
> >
> > static int dpu_plane_virtual_atomic_check(struct drm_plane *plane,
> > @@ -1186,10 +1162,6 @@ static int dpu_plane_virtual_atomic_check(struct drm_plane *plane,
> > if (ret)
> > return ret;
> >
> > - ret = dpu_plane_split(plane, plane_state, crtc_state);
> > - if (ret)
> > - return ret;
> > -
> > if (!plane_state->visible) {
> > /*
> > * resources are freed by dpu_crtc_assign_plane_resources(),
> > @@ -1261,9 +1233,9 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
> > struct dpu_global_state *global_state,
> > struct drm_atomic_state *state,
> > struct drm_plane_state *plane_state,
> > + const struct drm_crtc_state *crtc_state,
> > struct drm_plane_state **prev_adjacent_plane_state)
> > {
> > - const struct drm_crtc_state *crtc_state = NULL;
> > struct drm_plane *plane = plane_state->plane;
> > struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
> > struct dpu_rm_sspp_requirements reqs;
> > @@ -1273,10 +1245,6 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
> > const struct msm_format *fmt;
> > int i, ret;
> >
> > - if (plane_state->crtc)
> > - crtc_state = drm_atomic_get_new_crtc_state(state,
> > - plane_state->crtc);
> > -
> > pstate = to_dpu_plane_state(plane_state);
> > for (i = 0; i < STAGES_PER_PLANE; i++)
> > prev_adjacent_pstate[i] = prev_adjacent_plane_state[i] ?
> > @@ -1288,6 +1256,10 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
> > if (!plane_state->fb)
> > return -EINVAL;
> >
> > + ret = dpu_plane_split(plane, plane_state, crtc_state);
> > + if (ret)
> > + return ret;
> > +
> > fmt = msm_framebuffer_format(plane_state->fb);
> > reqs.yuv = MSM_FORMAT_IS_YUV(fmt);
> > reqs.scale = (plane_state->src_w >> 16 != plane_state->crtc_w) ||
> > @@ -1318,14 +1290,59 @@ static int dpu_plane_virtual_assign_resources(struct drm_crtc *crtc,
> > return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
> > }
> >
> > +static int dpu_plane_assign_resources(struct drm_crtc *crtc,
> > + struct dpu_global_state *global_state,
> > + struct drm_atomic_state *state,
> > + struct drm_plane_state *plane_state,
> > + const struct drm_crtc_state *crtc_state,
> > + struct drm_plane_state **prev_adjacent_plane_state)
> > +{
> > + struct drm_plane *plane = plane_state->plane;
> > + struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
> > + struct dpu_plane_state *pstate = to_dpu_plane_state(plane_state);
> > + struct dpu_sw_pipe *pipe = &pstate->pipe[0];
> > + struct dpu_sw_pipe *r_pipe = &pstate->pipe[1];
> > + struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg[0];
> > + struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->pipe_cfg[1];
> > + struct dpu_plane *pdpu = to_dpu_plane(plane);
> > + int ret;
> > +
> > + if (!plane_state->visible)
> > + return 0;
> > +
> > + pipe->sspp = dpu_rm_get_sspp(&dpu_kms->rm, pdpu->pipe);
> > + if (!pipe->sspp)
> > + return -EINVAL;
> > +
> > + ret = dpu_plane_split(plane, plane_state, crtc_state);
> > + if (ret)
> > + return ret;
> > +
> > + if (!dpu_plane_try_multirect_parallel(pipe, pipe_cfg, r_pipe, r_pipe_cfg,
> > + pipe->sspp,
> > + msm_framebuffer_format(plane_state->fb),
> > + dpu_kms->catalog->caps->max_linewidth)) {
> > + DPU_DEBUG_PLANE(pdpu, "invalid " DRM_RECT_FMT " /" DRM_RECT_FMT
> > + " max_line:%u, can't use split source\n",
> > + DRM_RECT_ARG(&pipe_cfg->src_rect),
> > + DRM_RECT_ARG(&r_pipe_cfg->src_rect),
> > + dpu_kms->catalog->caps->max_linewidth);
> > + return -E2BIG;
> > + }
> > +
> > + return dpu_plane_atomic_check_sspp(plane, state, crtc_state);
> > +}
> > +
> > int dpu_assign_plane_resources(struct dpu_global_state *global_state,
> > struct drm_atomic_state *state,
> > struct drm_crtc *crtc,
> > struct drm_plane_state **states,
> > unsigned int num_planes)
> > {
> > - unsigned int i;
> > struct drm_plane_state *prev_adjacent_plane_state[STAGES_PER_PLANE] = { NULL };
> > + const struct drm_crtc_state *crtc_state = NULL;
> > + unsigned int i;
> > + int ret;
> >
> > for (i = 0; i < num_planes; i++) {
> > struct drm_plane_state *plane_state = states[i];
> > @@ -1334,8 +1351,19 @@ int dpu_assign_plane_resources(struct dpu_global_state *global_state,
> > !plane_state->visible)
> > continue;
> >
> > - int ret = dpu_plane_virtual_assign_resources(crtc, global_state,
> > + if (plane_state->crtc)
> > + crtc_state = drm_atomic_get_new_crtc_state(state,
> > + plane_state->crtc);
> > +
> > + if (!dpu_use_virtual_planes)
> > + ret = dpu_plane_assign_resources(crtc, global_state,
> > + state, plane_state,
> > + crtc_state,
> > + prev_adjacent_plane_state);
> > + else
> > + ret = dpu_plane_virtual_assign_resources(crtc, global_state,
> > state, plane_state,
> > + crtc_state,
> > prev_adjacent_plane_state);
> > if (ret)
> > return ret;
> >
> > --
> > 2.43.0
> >
>
> --
> With best wishes
> Dmitry
On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > > > > On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > Currently, plane splitting and SSPP allocation occur during the plane > > > check phase. Defer these operations until dpu_assign_plane_resources() > > > is called from the CRTC side to ensure the topology information from > > > the CRTC check is available. > > > > Why is it important? What is broken otherwise? > > I see. Thanks! Will add below lines in next version. > > By default, the plane check occurs before the CRTC check. > Without topology information from the CRTC, plane splitting > cannot be properly executed. Consequently, the SSPP > engine starts without a valid memory address, which triggers > an IOMMU warning. What is plane splitting? Write commit message for somebody who doesn't exactly know what is going on. -- With best wishes Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > > On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > > > > > > On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > > Currently, plane splitting and SSPP allocation occur during the plane > > > > check phase. Defer these operations until dpu_assign_plane_resources() > > > > is called from the CRTC side to ensure the topology information from > > > > the CRTC check is available. > > > > > > Why is it important? What is broken otherwise? > > > > I see. Thanks! Will add below lines in next version. > > > > By default, the plane check occurs before the CRTC check. > > Without topology information from the CRTC, plane splitting > > cannot be properly executed. Consequently, the SSPP > > engine starts without a valid memory address, which triggers > > an IOMMU warning. > > What is plane splitting? Write commit message for somebody who doesn't > exactly know what is going on. Thanks for the suggestion! Any more revise is needed? Currently, splitting plane into SSPP rectangles the allocation occur during the plane check phase, so that a plane can be supported by multiple hardware pipe. While pipe topology is decided in CRTC check. By default, the plane check occurs before the CRTC check in DRM framework. Without topology information from the CRTC, plane splitting cannot be properly executed. Consequently, the SSPP engine starts without a valid memory address, which triggers IOMMU warning. Defer above plane operations until dpu_assign_plane_resources() is called from the CRTC side to ensure the topology information from the CRTC check is available. Regards, Jun > > > -- > With best wishes > Dmitry
On 26/01/2026 12:06, Jun Nie wrote: > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： >> >> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： >>>> >>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: >>>>> Currently, plane splitting and SSPP allocation occur during the plane >>>>> check phase. Defer these operations until dpu_assign_plane_resources() >>>>> is called from the CRTC side to ensure the topology information from >>>>> the CRTC check is available. >>>> >>>> Why is it important? What is broken otherwise? >>> >>> I see. Thanks! Will add below lines in next version. >>> >>> By default, the plane check occurs before the CRTC check. >>> Without topology information from the CRTC, plane splitting >>> cannot be properly executed. Consequently, the SSPP >>> engine starts without a valid memory address, which triggers >>> an IOMMU warning. >> >> What is plane splitting? Write commit message for somebody who doesn't >> exactly know what is going on. > > Thanks for the suggestion! Any more revise is needed? Sadly enough the text below is not a significant improvement. > > Currently, splitting plane into SSPP rectangles the allocation occur > during the plane check phase, so that a plane can be supported by > multiple hardware pipe. What does this mean? Without virtual planes in place, there are no multiple hardware pipes. > While pipe topology is decided in CRTC check. ?? What does it mean here? > By default, the plane check occurs before the CRTC check in DRM > framework. Without topology information from the CRTC, plane splitting > cannot be properly executed. What does 'properly' mean here? How is it executed? What happens? > Consequently, the SSPP engine starts > without a valid memory address, which triggers IOMMU warning. IOMMU faults. There are no "warnings". > > Defer above plane operations until dpu_assign_plane_resources() > is called from the CRTC side to ensure the topology information from > the CRTC check is available. -- With best wishes Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： > > On 26/01/2026 12:06, Jun Nie wrote: > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > >> > >> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > >>>> > >>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > >>>>> Currently, plane splitting and SSPP allocation occur during the plane > >>>>> check phase. Defer these operations until dpu_assign_plane_resources() > >>>>> is called from the CRTC side to ensure the topology information from > >>>>> the CRTC check is available. > >>>> > >>>> Why is it important? What is broken otherwise? > >>> > >>> I see. Thanks! Will add below lines in next version. > >>> > >>> By default, the plane check occurs before the CRTC check. > >>> Without topology information from the CRTC, plane splitting > >>> cannot be properly executed. Consequently, the SSPP > >>> engine starts without a valid memory address, which triggers > >>> an IOMMU warning. > >> > >> What is plane splitting? Write commit message for somebody who doesn't > >> exactly know what is going on. > > > > Thanks for the suggestion! Any more revise is needed? > > Sadly enough the text below is not a significant improvement. > > > > > Currently, splitting plane into SSPP rectangles the allocation occur > > during the plane check phase, so that a plane can be supported by > > multiple hardware pipe. > > What does this mean? Without virtual planes in place, there are no > multiple hardware pipes. > > > While pipe topology is decided in CRTC check. > > ?? What does it mean here? > > > By default, the plane check occurs before the CRTC check in DRM > > framework. Without topology information from the CRTC, plane splitting > > cannot be properly executed. > > What does 'properly' mean here? How is it executed? What happens? > > > Consequently, the SSPP engine starts > > without a valid memory address, which triggers IOMMU warning. > > IOMMU faults. There are no "warnings". > > > > > Defer above plane operations until dpu_assign_plane_resources() > > is called from the CRTC side to ensure the topology information from > > the CRTC check is available. > > Thanks for the patience! Currently, splitting plane into SSPP rectangles and allocation occur during the plane check phase. When virtual plane is enabled to support quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that a plane can be supported by 4 hardware pipes. And pipe number is decided in CRTC check per interface number, resolution and hardware feature. By default, the plane check occurs before the CRTC check in DRM framework. Without topology information from the CRTC, plane splitting will be skipped for the first time as pipe number is 0. Consequently, the SSPP engine starts without a valid memory address, which triggers IOMMU fault. Defer above plane related operations until dpu_assign_plane_resources() is called from the CRTC side to ensure the topology information from the CRTC check is available. Regards, Jun > > -- > With best wishes > Dmitry
On 26/01/2026 12:29, Jun Nie wrote: > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： >> >> On 26/01/2026 12:06, Jun Nie wrote: >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： >>>> >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: >>>>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： >>>>>> >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: >>>>>>> Currently, plane splitting and SSPP allocation occur during the plane >>>>>>> check phase. Defer these operations until dpu_assign_plane_resources() >>>>>>> is called from the CRTC side to ensure the topology information from >>>>>>> the CRTC check is available. >>>>>> >>>>>> Why is it important? What is broken otherwise? >>>>> >>>>> I see. Thanks! Will add below lines in next version. >>>>> >>>>> By default, the plane check occurs before the CRTC check. >>>>> Without topology information from the CRTC, plane splitting >>>>> cannot be properly executed. Consequently, the SSPP >>>>> engine starts without a valid memory address, which triggers >>>>> an IOMMU warning. >>>> >>>> What is plane splitting? Write commit message for somebody who doesn't >>>> exactly know what is going on. >>> >>> Thanks for the suggestion! Any more revise is needed? >> >> Sadly enough the text below is not a significant improvement. >> >>> >>> Currently, splitting plane into SSPP rectangles the allocation occur >>> during the plane check phase, so that a plane can be supported by >>> multiple hardware pipe. >> >> What does this mean? Without virtual planes in place, there are no >> multiple hardware pipes. >> >>> While pipe topology is decided in CRTC check. >> >> ?? What does it mean here? >> >>> By default, the plane check occurs before the CRTC check in DRM >>> framework. Without topology information from the CRTC, plane splitting >>> cannot be properly executed. >> >> What does 'properly' mean here? How is it executed? What happens? >> >>> Consequently, the SSPP engine starts >>> without a valid memory address, which triggers IOMMU warning. >> >> IOMMU faults. There are no "warnings". >> >>> >>> Defer above plane operations until dpu_assign_plane_resources() >>> is called from the CRTC side to ensure the topology information from >>> the CRTC check is available. >> >> > Thanks for the patience! > > > Currently, splitting plane into SSPP rectangles and allocation occur > during the plane check phase. When virtual plane is enabled to support > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that > a plane can be supported by 4 hardware pipes. And pipe number is number of pipes > decided in CRTC check per interface number, resolution and hardware > feature. Okay, but IOMMU errors were reported with virtual planes being disabled. So how is it relevant? > > By default, the plane check occurs before the CRTC check in DRM > framework. Without topology information from the CRTC, plane splitting WHat is plane splitting? > will be skipped for the first time as pipe number is 0. Consequently, > the SSPP engine starts without a valid memory address, which triggers > IOMMU fault. > > Defer above plane related operations until dpu_assign_plane_resources() > is called from the CRTC side to ensure the topology information from > the CRTC check is available. > > Regards, > Jun >> >> -- >> With best wishes >> Dmitry -- With best wishes Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:49写道： > > On 26/01/2026 12:29, Jun Nie wrote: > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： > >> > >> On 26/01/2026 12:06, Jun Nie wrote: > >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > >>>> > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > >>>>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > >>>>>> > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > >>>>>>> Currently, plane splitting and SSPP allocation occur during the plane > >>>>>>> check phase. Defer these operations until dpu_assign_plane_resources() > >>>>>>> is called from the CRTC side to ensure the topology information from > >>>>>>> the CRTC check is available. > >>>>>> > >>>>>> Why is it important? What is broken otherwise? > >>>>> > >>>>> I see. Thanks! Will add below lines in next version. > >>>>> > >>>>> By default, the plane check occurs before the CRTC check. > >>>>> Without topology information from the CRTC, plane splitting > >>>>> cannot be properly executed. Consequently, the SSPP > >>>>> engine starts without a valid memory address, which triggers > >>>>> an IOMMU warning. > >>>> > >>>> What is plane splitting? Write commit message for somebody who doesn't > >>>> exactly know what is going on. > >>> > >>> Thanks for the suggestion! Any more revise is needed? > >> > >> Sadly enough the text below is not a significant improvement. > >> > >>> > >>> Currently, splitting plane into SSPP rectangles the allocation occur > >>> during the plane check phase, so that a plane can be supported by > >>> multiple hardware pipe. > >> > >> What does this mean? Without virtual planes in place, there are no > >> multiple hardware pipes. > >> > >>> While pipe topology is decided in CRTC check. > >> > >> ?? What does it mean here? > >> > >>> By default, the plane check occurs before the CRTC check in DRM > >>> framework. Without topology information from the CRTC, plane splitting > >>> cannot be properly executed. > >> > >> What does 'properly' mean here? How is it executed? What happens? > >> > >>> Consequently, the SSPP engine starts > >>> without a valid memory address, which triggers IOMMU warning. > >> > >> IOMMU faults. There are no "warnings". > >> > >>> > >>> Defer above plane operations until dpu_assign_plane_resources() > >>> is called from the CRTC side to ensure the topology information from > >>> the CRTC check is available. > >> > >> > > Thanks for the patience! > > > > > > Currently, splitting plane into SSPP rectangles and allocation occur > > during the plane check phase. When virtual plane is enabled to support > > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that > > a plane can be supported by 4 hardware pipes. And pipe number is > > number of pipes > > > decided in CRTC check per interface number, resolution and hardware > > feature. > > Okay, but IOMMU errors were reported with virtual planes being disabled. > So how is it relevant? After revise of splitting plane into pipes, the number of pipes will be decided by CRTC check for both virtual plane and non-virtual plane case to unify the plane handling, instead of assumption of 2 pipes at most. > > > > > By default, the plane check occurs before the CRTC check in DRM > > framework. Without topology information from the CRTC, plane splitting > > WHat is plane splitting? How about: s/plane splitting/splitting plane into pipes ? > > > will be skipped for the first time as pipe number is 0. Consequently, > > the SSPP engine starts without a valid memory address, which triggers > > IOMMU fault. > > > > Defer above plane related operations until dpu_assign_plane_resources() > > is called from the CRTC side to ensure the topology information from > > the CRTC check is available. > > > > Regards, > > Jun > >> > >> -- > >> With best wishes > >> Dmitry > > > -- > With best wishes > Dmitry
On Mon, Jan 26, 2026 at 08:01:00PM +0800, Jun Nie wrote: > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:49写道： > > > > On 26/01/2026 12:29, Jun Nie wrote: > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： > > >> > > >> On 26/01/2026 12:06, Jun Nie wrote: > > >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > > >>>> > > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > >>>>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > > >>>>>> > > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > >>>>>>> Currently, plane splitting and SSPP allocation occur during the plane > > >>>>>>> check phase. Defer these operations until dpu_assign_plane_resources() > > >>>>>>> is called from the CRTC side to ensure the topology information from > > >>>>>>> the CRTC check is available. > > >>>>>> > > >>>>>> Why is it important? What is broken otherwise? > > >>>>> > > >>>>> I see. Thanks! Will add below lines in next version. > > >>>>> > > >>>>> By default, the plane check occurs before the CRTC check. > > >>>>> Without topology information from the CRTC, plane splitting > > >>>>> cannot be properly executed. Consequently, the SSPP > > >>>>> engine starts without a valid memory address, which triggers > > >>>>> an IOMMU warning. > > >>>> > > >>>> What is plane splitting? Write commit message for somebody who doesn't > > >>>> exactly know what is going on. > > >>> > > >>> Thanks for the suggestion! Any more revise is needed? > > >> > > >> Sadly enough the text below is not a significant improvement. > > >> > > >>> > > >>> Currently, splitting plane into SSPP rectangles the allocation occur > > >>> during the plane check phase, so that a plane can be supported by > > >>> multiple hardware pipe. > > >> > > >> What does this mean? Without virtual planes in place, there are no > > >> multiple hardware pipes. > > >> > > >>> While pipe topology is decided in CRTC check. > > >> > > >> ?? What does it mean here? > > >> > > >>> By default, the plane check occurs before the CRTC check in DRM > > >>> framework. Without topology information from the CRTC, plane splitting > > >>> cannot be properly executed. > > >> > > >> What does 'properly' mean here? How is it executed? What happens? > > >> > > >>> Consequently, the SSPP engine starts > > >>> without a valid memory address, which triggers IOMMU warning. > > >> > > >> IOMMU faults. There are no "warnings". > > >> > > >>> > > >>> Defer above plane operations until dpu_assign_plane_resources() > > >>> is called from the CRTC side to ensure the topology information from > > >>> the CRTC check is available. > > >> > > >> > > > Thanks for the patience! > > > > > > > > > Currently, splitting plane into SSPP rectangles and allocation occur > > > during the plane check phase. When virtual plane is enabled to support > > > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that > > > a plane can be supported by 4 hardware pipes. And pipe number is > > > > number of pipes > > > > > decided in CRTC check per interface number, resolution and hardware > > > feature. > > > > Okay, but IOMMU errors were reported with virtual planes being disabled. > > So how is it relevant? > > After revise of splitting plane into pipes, the number of pipes will be decided > by CRTC check for both virtual plane and non-virtual plane case to unify the > plane handling, instead of assumption of 2 pipes at most. This needs to be explicitly written. > > > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > framework. Without topology information from the CRTC, plane splitting > > > > WHat is plane splitting? > > How about: s/plane splitting/splitting plane into pipes ? This plane is not being split into anything. It's being mapped onto hw pipes. But before that, the number of necessary hw pipes is being determined based on foo, bar an baz, > > > > > > will be skipped for the first time as pipe number is 0. Consequently, > > > the SSPP engine starts without a valid memory address, which triggers > > > IOMMU fault. > > > > > > Defer above plane related operations until dpu_assign_plane_resources() > > > is called from the CRTC side to ensure the topology information from > > > the CRTC check is available. > > > > > > Regards, > > > Jun > > >> > > >> -- > > >> With best wishes > > >> Dmitry > > > > > > -- > > With best wishes > > Dmitry -- With best wishes Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 20:31写道： > > On Mon, Jan 26, 2026 at 08:01:00PM +0800, Jun Nie wrote: > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:49写道： > > > > > > On 26/01/2026 12:29, Jun Nie wrote: > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： > > > >> > > > >> On 26/01/2026 12:06, Jun Nie wrote: > > > >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > > > >>>> > > > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > > >>>>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > > > >>>>>> > > > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > >>>>>>> Currently, plane splitting and SSPP allocation occur during the plane > > > >>>>>>> check phase. Defer these operations until dpu_assign_plane_resources() > > > >>>>>>> is called from the CRTC side to ensure the topology information from > > > >>>>>>> the CRTC check is available. > > > >>>>>> > > > >>>>>> Why is it important? What is broken otherwise? > > > >>>>> > > > >>>>> I see. Thanks! Will add below lines in next version. > > > >>>>> > > > >>>>> By default, the plane check occurs before the CRTC check. > > > >>>>> Without topology information from the CRTC, plane splitting > > > >>>>> cannot be properly executed. Consequently, the SSPP > > > >>>>> engine starts without a valid memory address, which triggers > > > >>>>> an IOMMU warning. > > > >>>> > > > >>>> What is plane splitting? Write commit message for somebody who doesn't > > > >>>> exactly know what is going on. > > > >>> > > > >>> Thanks for the suggestion! Any more revise is needed? > > > >> > > > >> Sadly enough the text below is not a significant improvement. > > > >> > > > >>> > > > >>> Currently, splitting plane into SSPP rectangles the allocation occur > > > >>> during the plane check phase, so that a plane can be supported by > > > >>> multiple hardware pipe. > > > >> > > > >> What does this mean? Without virtual planes in place, there are no > > > >> multiple hardware pipes. > > > >> > > > >>> While pipe topology is decided in CRTC check. > > > >> > > > >> ?? What does it mean here? > > > >> > > > >>> By default, the plane check occurs before the CRTC check in DRM > > > >>> framework. Without topology information from the CRTC, plane splitting > > > >>> cannot be properly executed. > > > >> > > > >> What does 'properly' mean here? How is it executed? What happens? > > > >> > > > >>> Consequently, the SSPP engine starts > > > >>> without a valid memory address, which triggers IOMMU warning. > > > >> > > > >> IOMMU faults. There are no "warnings". > > > >> > > > >>> > > > >>> Defer above plane operations until dpu_assign_plane_resources() > > > >>> is called from the CRTC side to ensure the topology information from > > > >>> the CRTC check is available. > > > >> > > > >> > > > > Thanks for the patience! > > > > > > > > > > > > Currently, splitting plane into SSPP rectangles and allocation occur > > > > during the plane check phase. When virtual plane is enabled to support > > > > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that > > > > a plane can be supported by 4 hardware pipes. And pipe number is > > > > > > number of pipes > > > > > > > decided in CRTC check per interface number, resolution and hardware > > > > feature. > > > > > > Okay, but IOMMU errors were reported with virtual planes being disabled. > > > So how is it relevant? > > > > After revise of splitting plane into pipes, the number of pipes will be decided > > by CRTC check for both virtual plane and non-virtual plane case to unify the > > plane handling, instead of assumption of 2 pipes at most. > > This needs to be explicitly written. > > > > > > > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > > framework. Without topology information from the CRTC, plane splitting > > > > > > WHat is plane splitting? > > > > How about: s/plane splitting/splitting plane into pipes ? > > This plane is not being split into anything. It's being mapped onto hw > pipes. But before that, the number of necessary hw pipes is being determined > based on foo, bar an baz, Thanks for the correction! Currently, plane is mapped onto at most 2 hardware pipes and 1 SSPP allocation occur during the plane check phase. When virtual plane is enabled to support quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that a plane can be supported by 4 hardware pipes. After revise of quad-pipe, the number of pipes is decided in CRTC check per number of interfaces, resolution, clock rate constrain, hardware feature and virtual plane enablement. The decidsion of number of pipes will happen in CRTC check for both virtual plane and non-virtual plane case to unify the plane handling. Before that, the the number of necessary hw pipes is being determined based on resolution and clock rate constrain. By default, the plane check occurs before the CRTC check in DRM framework. Without topology information from the CRTC, plane mapping will be skipped for the first time as number of pipe is 0. Consequently, the SSPP engine starts without a valid memory address, which triggers IOMMU fault. Defer above plane related operations until dpu_assign_plane_resources() is called from the CRTC side to ensure the topology information from the CRTC check is available. > > > > > > > > > > will be skipped for the first time as pipe number is 0. Consequently, > > > > the SSPP engine starts without a valid memory address, which triggers > > > > IOMMU fault. > > > > > > > > Defer above plane related operations until dpu_assign_plane_resources() > > > > is called from the CRTC side to ensure the topology information from > > > > the CRTC check is available. > > > > > > > > Regards, > > > > Jun > > > >> > > > >> -- > > > >> With best wishes > > > >> Dmitry > > > > > > > > > -- > > > With best wishes > > > Dmitry > > -- > With best wishes > Dmitry
On Mon, Jan 26, 2026 at 09:29:44PM +0800, Jun Nie wrote: > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 20:31写道： > > > > On Mon, Jan 26, 2026 at 08:01:00PM +0800, Jun Nie wrote: > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:49写道： > > > > > > > > On 26/01/2026 12:29, Jun Nie wrote: > > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： > > > > >> > > > > >> On 26/01/2026 12:06, Jun Nie wrote: > > > > >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > > > > >>>> > > > > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > > > >>>>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > > > > >>>>>> > > > > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > > >>>>>>> Currently, plane splitting and SSPP allocation occur during the plane > > > > >>>>>>> check phase. Defer these operations until dpu_assign_plane_resources() > > > > >>>>>>> is called from the CRTC side to ensure the topology information from > > > > >>>>>>> the CRTC check is available. > > > > >>>>>> > > > > >>>>>> Why is it important? What is broken otherwise? > > > > >>>>> > > > > >>>>> I see. Thanks! Will add below lines in next version. > > > > >>>>> > > > > >>>>> By default, the plane check occurs before the CRTC check. > > > > >>>>> Without topology information from the CRTC, plane splitting > > > > >>>>> cannot be properly executed. Consequently, the SSPP > > > > >>>>> engine starts without a valid memory address, which triggers > > > > >>>>> an IOMMU warning. > > > > >>>> > > > > >>>> What is plane splitting? Write commit message for somebody who doesn't > > > > >>>> exactly know what is going on. > > > > >>> > > > > >>> Thanks for the suggestion! Any more revise is needed? > > > > >> > > > > >> Sadly enough the text below is not a significant improvement. > > > > >> > > > > >>> > > > > >>> Currently, splitting plane into SSPP rectangles the allocation occur > > > > >>> during the plane check phase, so that a plane can be supported by > > > > >>> multiple hardware pipe. > > > > >> > > > > >> What does this mean? Without virtual planes in place, there are no > > > > >> multiple hardware pipes. > > > > >> > > > > >>> While pipe topology is decided in CRTC check. > > > > >> > > > > >> ?? What does it mean here? > > > > >> > > > > >>> By default, the plane check occurs before the CRTC check in DRM > > > > >>> framework. Without topology information from the CRTC, plane splitting > > > > >>> cannot be properly executed. > > > > >> > > > > >> What does 'properly' mean here? How is it executed? What happens? > > > > >> > > > > >>> Consequently, the SSPP engine starts > > > > >>> without a valid memory address, which triggers IOMMU warning. > > > > >> > > > > >> IOMMU faults. There are no "warnings". > > > > >> > > > > >>> > > > > >>> Defer above plane operations until dpu_assign_plane_resources() > > > > >>> is called from the CRTC side to ensure the topology information from > > > > >>> the CRTC check is available. > > > > >> > > > > >> > > > > > Thanks for the patience! > > > > > > > > > > > > > > > Currently, splitting plane into SSPP rectangles and allocation occur > > > > > during the plane check phase. When virtual plane is enabled to support > > > > > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that > > > > > a plane can be supported by 4 hardware pipes. And pipe number is > > > > > > > > number of pipes > > > > > > > > > decided in CRTC check per interface number, resolution and hardware > > > > > feature. > > > > > > > > Okay, but IOMMU errors were reported with virtual planes being disabled. > > > > So how is it relevant? > > > > > > After revise of splitting plane into pipes, the number of pipes will be decided > > > by CRTC check for both virtual plane and non-virtual plane case to unify the > > > plane handling, instead of assumption of 2 pipes at most. > > > > This needs to be explicitly written. > > > > > > > > > > > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > > > framework. Without topology information from the CRTC, plane splitting > > > > > > > > WHat is plane splitting? > > > > > > How about: s/plane splitting/splitting plane into pipes ? > > > > This plane is not being split into anything. It's being mapped onto hw > > pipes. But before that, the number of necessary hw pipes is being determined > > based on foo, bar an baz, > > Thanks for the correction! > > Currently, plane is mapped onto at most 2 hardware pipes and 1 SSPP > allocation occur during the plane check phase. When virtual plane is > enabled to support quad-pipe topology later, 2 SSPPs with 4 rect will > be needed, so that a plane can be supported by 4 hardware pipes. > > After revise of quad-pipe, the number of pipes is decided in CRTC > check per number of interfaces, resolution, clock rate constrain, Where? > hardware feature and virtual plane enablement. The decidsion of decision > number of pipes will happen in CRTC check for both virtual plane and > non-virtual plane case to unify the plane handling. Before that, the will? Do you mean, after this patch? If so, please use imperative language. See Documentation/process/submitting-patches.rst > the number of necessary hw pipes is being determined based on > resolution and clock rate constrain. > > By default, the plane check occurs before the CRTC check in DRM > framework. Without topology information from the CRTC, plane mapping > will be skipped for the first time as number of pipe is 0. > Consequently, the SSPP engine starts without a valid memory address, > which triggers IOMMU fault. > > Defer above plane related operations until dpu_assign_plane_resources() > is called from the CRTC side to ensure the topology information from > the CRTC check is available. > > > > > > > > > > > > > > > will be skipped for the first time as pipe number is 0. Consequently, > > > > > the SSPP engine starts without a valid memory address, which triggers > > > > > IOMMU fault. > > > > > > > > > > Defer above plane related operations until dpu_assign_plane_resources() > > > > > is called from the CRTC side to ensure the topology information from > > > > > the CRTC check is available. -- With best wishes Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月27日周二 03:06写道： > > On Mon, Jan 26, 2026 at 09:29:44PM +0800, Jun Nie wrote: > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 20:31写道： > > > > > > On Mon, Jan 26, 2026 at 08:01:00PM +0800, Jun Nie wrote: > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:49写道： > > > > > > > > > > On 26/01/2026 12:29, Jun Nie wrote: > > > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： > > > > > >> > > > > > >> On 26/01/2026 12:06, Jun Nie wrote: > > > > > >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > > > > > >>>> > > > > > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > > > > >>>>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > > > > > >>>>>> > > > > > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > > > >>>>>>> Currently, plane splitting and SSPP allocation occur during the plane > > > > > >>>>>>> check phase. Defer these operations until dpu_assign_plane_resources() > > > > > >>>>>>> is called from the CRTC side to ensure the topology information from > > > > > >>>>>>> the CRTC check is available. > > > > > >>>>>> > > > > > >>>>>> Why is it important? What is broken otherwise? > > > > > >>>>> > > > > > >>>>> I see. Thanks! Will add below lines in next version. > > > > > >>>>> > > > > > >>>>> By default, the plane check occurs before the CRTC check. > > > > > >>>>> Without topology information from the CRTC, plane splitting > > > > > >>>>> cannot be properly executed. Consequently, the SSPP > > > > > >>>>> engine starts without a valid memory address, which triggers > > > > > >>>>> an IOMMU warning. > > > > > >>>> > > > > > >>>> What is plane splitting? Write commit message for somebody who doesn't > > > > > >>>> exactly know what is going on. > > > > > >>> > > > > > >>> Thanks for the suggestion! Any more revise is needed? > > > > > >> > > > > > >> Sadly enough the text below is not a significant improvement. > > > > > >> > > > > > >>> > > > > > >>> Currently, splitting plane into SSPP rectangles the allocation occur > > > > > >>> during the plane check phase, so that a plane can be supported by > > > > > >>> multiple hardware pipe. > > > > > >> > > > > > >> What does this mean? Without virtual planes in place, there are no > > > > > >> multiple hardware pipes. > > > > > >> > > > > > >>> While pipe topology is decided in CRTC check. > > > > > >> > > > > > >> ?? What does it mean here? > > > > > >> > > > > > >>> By default, the plane check occurs before the CRTC check in DRM > > > > > >>> framework. Without topology information from the CRTC, plane splitting > > > > > >>> cannot be properly executed. > > > > > >> > > > > > >> What does 'properly' mean here? How is it executed? What happens? > > > > > >> > > > > > >>> Consequently, the SSPP engine starts > > > > > >>> without a valid memory address, which triggers IOMMU warning. > > > > > >> > > > > > >> IOMMU faults. There are no "warnings". > > > > > >> > > > > > >>> > > > > > >>> Defer above plane operations until dpu_assign_plane_resources() > > > > > >>> is called from the CRTC side to ensure the topology information from > > > > > >>> the CRTC check is available. > > > > > >> > > > > > >> > > > > > > Thanks for the patience! > > > > > > > > > > > > > > > > > > Currently, splitting plane into SSPP rectangles and allocation occur > > > > > > during the plane check phase. When virtual plane is enabled to support > > > > > > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that > > > > > > a plane can be supported by 4 hardware pipes. And pipe number is > > > > > > > > > > number of pipes > > > > > > > > > > > decided in CRTC check per interface number, resolution and hardware > > > > > > feature. > > > > > > > > > > Okay, but IOMMU errors were reported with virtual planes being disabled. > > > > > So how is it relevant? > > > > > > > > After revise of splitting plane into pipes, the number of pipes will be decided > > > > by CRTC check for both virtual plane and non-virtual plane case to unify the > > > > plane handling, instead of assumption of 2 pipes at most. > > > > > > This needs to be explicitly written. > > > > > > > > > > > > > > > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > > > > framework. Without topology information from the CRTC, plane splitting > > > > > > > > > > WHat is plane splitting? > > > > > > > > How about: s/plane splitting/splitting plane into pipes ? > > > > > > This plane is not being split into anything. It's being mapped onto hw > > > pipes. But before that, the number of necessary hw pipes is being determined > > > based on foo, bar an baz, > > > > Thanks for the correction! > > > > Currently, plane is mapped onto at most 2 hardware pipes and 1 SSPP > > allocation occur during the plane check phase. When virtual plane is > > enabled to support quad-pipe topology later, 2 SSPPs with 4 rect will > > be needed, so that a plane can be supported by 4 hardware pipes. > > > > After revise of quad-pipe, the number of pipes is decided in CRTC > > check per number of interfaces, resolution, clock rate constrain, > > Where? The pipe is decided in dpu_crtc_get_topology(). Change to quad-pipe is made in later patch. So I drop this in this patch message below. > > > hardware feature and virtual plane enablement. The decidsion of > > decision > > > number of pipes will happen in CRTC check for both virtual plane and > > non-virtual plane case to unify the plane handling. Before that, the > > will? Do you mean, after this patch? If so, please use imperative > language. See Documentation/process/submitting-patches.rst Yes, it is in later patch. So drop it in this patch message. It is possible to keep plane check unchanged, and rely on re-allocation in later stage to support quad-pipe, if quad-pipe use case is detected. But to unify the allocation logic for both non-virtual and virtual plane use cases, and to centralize resource management, we'd better defer the allocation. > > > the number of necessary hw pipes is being determined based on > > resolution and clock rate constrain. > > > > By default, the plane check occurs before the CRTC check in DRM > > framework. Without topology information from the CRTC, plane mapping > > will be skipped for the first time as number of pipe is 0. > > Consequently, the SSPP engine starts without a valid memory address, > > which triggers IOMMU fault. > > > > Defer above plane related operations until dpu_assign_plane_resources() > > is called from the CRTC side to ensure the topology information from > > the CRTC check is available. > > > > > > > > > > > > > > > > > > > > will be skipped for the first time as pipe number is 0. Consequently, > > > > > > the SSPP engine starts without a valid memory address, which triggers > > > > > > IOMMU fault. > > > > > > > > > > > > Defer above plane related operations until dpu_assign_plane_resources() > > > > > > is called from the CRTC side to ensure the topology information from > > > > > > the CRTC check is available. > How about this commit message? It is more coherent with the change in this patch. Currently, a plane maps to at most two hardware pipes, and SSPP allocation occurs during the plane check phase. However, when virtual planes are enabled, SSPP re-allocation can occur within dpu_assign_plane_resources() during the CRTC check. To support future quad-pipe topologies, which require allocating two SSPPs with four rectangles by default, it is more efficient to perform the primary allocation in a single pass rather than relying on later re-allocations. So defer the allocation to CRTC check phase by default. Allocation logic for both non-virtual and virtual plane use cases is unified in this way. > -- > With best wishes > Dmitry
On Mon, Feb 02, 2026 at 03:15:14PM +0800, Jun Nie wrote: > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月27日周二 03:06写道： > > > > On Mon, Jan 26, 2026 at 09:29:44PM +0800, Jun Nie wrote: > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 20:31写道： > > > > > > > > On Mon, Jan 26, 2026 at 08:01:00PM +0800, Jun Nie wrote: > > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:49写道： > > > > > > > > > > > > On 26/01/2026 12:29, Jun Nie wrote: > > > > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： > > > > > > >> > > > > > > >> On 26/01/2026 12:06, Jun Nie wrote: > > > > > > >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > > > > > > >>>> > > > > > > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > > > > > >>>>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > > > > > > >>>>>> > > > > > > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > > > > >>>>>>> Currently, plane splitting and SSPP allocation occur during the plane > > > > > > >>>>>>> check phase. Defer these operations until dpu_assign_plane_resources() > > > > > > >>>>>>> is called from the CRTC side to ensure the topology information from > > > > > > >>>>>>> the CRTC check is available. > > > > > > >>>>>> > > > > > > >>>>>> Why is it important? What is broken otherwise? > > > > > > >>>>> > > > > > > >>>>> I see. Thanks! Will add below lines in next version. > > > > > > >>>>> > > > > > > >>>>> By default, the plane check occurs before the CRTC check. > > > > > > >>>>> Without topology information from the CRTC, plane splitting > > > > > > >>>>> cannot be properly executed. Consequently, the SSPP > > > > > > >>>>> engine starts without a valid memory address, which triggers > > > > > > >>>>> an IOMMU warning. > > > > > > >>>> > > > > > > >>>> What is plane splitting? Write commit message for somebody who doesn't > > > > > > >>>> exactly know what is going on. > > > > > > >>> > > > > > > >>> Thanks for the suggestion! Any more revise is needed? > > > > > > >> > > > > > > >> Sadly enough the text below is not a significant improvement. > > > > > > >> > > > > > > >>> > > > > > > >>> Currently, splitting plane into SSPP rectangles the allocation occur > > > > > > >>> during the plane check phase, so that a plane can be supported by > > > > > > >>> multiple hardware pipe. > > > > > > >> > > > > > > >> What does this mean? Without virtual planes in place, there are no > > > > > > >> multiple hardware pipes. > > > > > > >> > > > > > > >>> While pipe topology is decided in CRTC check. > > > > > > >> > > > > > > >> ?? What does it mean here? > > > > > > >> > > > > > > >>> By default, the plane check occurs before the CRTC check in DRM > > > > > > >>> framework. Without topology information from the CRTC, plane splitting > > > > > > >>> cannot be properly executed. > > > > > > >> > > > > > > >> What does 'properly' mean here? How is it executed? What happens? > > > > > > >> > > > > > > >>> Consequently, the SSPP engine starts > > > > > > >>> without a valid memory address, which triggers IOMMU warning. > > > > > > >> > > > > > > >> IOMMU faults. There are no "warnings". > > > > > > >> > > > > > > >>> > > > > > > >>> Defer above plane operations until dpu_assign_plane_resources() > > > > > > >>> is called from the CRTC side to ensure the topology information from > > > > > > >>> the CRTC check is available. > > > > > > >> > > > > > > >> > > > > > > > Thanks for the patience! > > > > > > > > > > > > > > > > > > > > > Currently, splitting plane into SSPP rectangles and allocation occur > > > > > > > during the plane check phase. When virtual plane is enabled to support > > > > > > > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that > > > > > > > a plane can be supported by 4 hardware pipes. And pipe number is > > > > > > > > > > > > number of pipes > > > > > > > > > > > > > decided in CRTC check per interface number, resolution and hardware > > > > > > > feature. > > > > > > > > > > > > Okay, but IOMMU errors were reported with virtual planes being disabled. > > > > > > So how is it relevant? > > > > > > > > > > After revise of splitting plane into pipes, the number of pipes will be decided > > > > > by CRTC check for both virtual plane and non-virtual plane case to unify the > > > > > plane handling, instead of assumption of 2 pipes at most. > > > > > > > > This needs to be explicitly written. > > > > > > > > > > > > > > > > > > > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > > > > > framework. Without topology information from the CRTC, plane splitting > > > > > > > > > > > > WHat is plane splitting? > > > > > > > > > > How about: s/plane splitting/splitting plane into pipes ? > > > > > > > > This plane is not being split into anything. It's being mapped onto hw > > > > pipes. But before that, the number of necessary hw pipes is being determined > > > > based on foo, bar an baz, > > > > > > Thanks for the correction! > > > > > > Currently, plane is mapped onto at most 2 hardware pipes and 1 SSPP > > > allocation occur during the plane check phase. When virtual plane is > > > enabled to support quad-pipe topology later, 2 SSPPs with 4 rect will > > > be needed, so that a plane can be supported by 4 hardware pipes. > > > > > > After revise of quad-pipe, the number of pipes is decided in CRTC > > > check per number of interfaces, resolution, clock rate constrain, > > > > Where? > > The pipe is decided in dpu_crtc_get_topology(). Change to quad-pipe > is made in later patch. So I drop this in this patch message below. The pipe isn't decides in that function. > > > > > hardware feature and virtual plane enablement. The decidsion of > > > > decision > > > > > number of pipes will happen in CRTC check for both virtual plane and > > > non-virtual plane case to unify the plane handling. Before that, the > > > > will? Do you mean, after this patch? If so, please use imperative > > language. See Documentation/process/submitting-patches.rst > > Yes, it is in later patch. So drop it in this patch message. > > It is possible to keep plane check unchanged, and rely on re-allocation > in later stage to support quad-pipe, if quad-pipe use case is detected. > But to unify the allocation logic for both non-virtual and virtual plane > use cases, and to centralize resource management, we'd better defer > the allocation. Which allocation? The non-virtual-planes case is more or less static. > > > > > > > the number of necessary hw pipes is being determined based on > > > resolution and clock rate constrain. > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > framework. Without topology information from the CRTC, plane mapping > > > will be skipped for the first time as number of pipe is 0. > > > Consequently, the SSPP engine starts without a valid memory address, > > > which triggers IOMMU fault. > > > > > > Defer above plane related operations until dpu_assign_plane_resources() > > > is called from the CRTC side to ensure the topology information from > > > the CRTC check is available. > > > > > > > > > > > > > > > > > > > > > > > > > will be skipped for the first time as pipe number is 0. Consequently, > > > > > > > the SSPP engine starts without a valid memory address, which triggers > > > > > > > IOMMU fault. > > > > > > > > > > > > > > Defer above plane related operations until dpu_assign_plane_resources() > > > > > > > is called from the CRTC side to ensure the topology information from > > > > > > > the CRTC check is available. > > > How about this commit message? It is more coherent with the change > in this patch. > > > Currently, a plane maps to at most two hardware pipes, and SSPP > allocation occurs during the plane check phase. However, when virtual > planes are enabled, SSPP re-allocation can occur within > dpu_assign_plane_resources() during the CRTC check. There is no _allocation_ for non-virtual-plane case. The SSPP are statically assigned to the planes. > > To support future quad-pipe topologies, which require allocating two > SSPPs with four rectangles by default, it is more efficient to perform > the primary allocation in a single pass rather than relying on later > re-allocations. So defer the allocation to CRTC check phase by default. > Allocation logic for both non-virtual and virtual plane use cases is > unified in this way. > > > -- > > With best wishes > > Dmitry -- With best wishes Dmitry
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年2月4日周三 10:44写道： > > On Mon, Feb 02, 2026 at 03:15:14PM +0800, Jun Nie wrote: > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月27日周二 03:06写道： > > > > > > On Mon, Jan 26, 2026 at 09:29:44PM +0800, Jun Nie wrote: > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 20:31写道： > > > > > > > > > > On Mon, Jan 26, 2026 at 08:01:00PM +0800, Jun Nie wrote: > > > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:49写道： > > > > > > > > > > > > > > On 26/01/2026 12:29, Jun Nie wrote: > > > > > > > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月26日周一 18:13写道： > > > > > > > >> > > > > > > > >> On 26/01/2026 12:06, Jun Nie wrote: > > > > > > > >>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月22日周四 18:22写道： > > > > > > > >>>> > > > > > > > >>>> On Thu, Jan 22, 2026 at 02:03:25PM +0800, Jun Nie wrote: > > > > > > > >>>>> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年1月21日周三 17:30写道： > > > > > > > >>>>>> > > > > > > > >>>>>> On Wed, Jan 21, 2026 at 04:01:51PM +0800, Jun Nie wrote: > > > > > > > >>>>>>> Currently, plane splitting and SSPP allocation occur during the plane > > > > > > > >>>>>>> check phase. Defer these operations until dpu_assign_plane_resources() > > > > > > > >>>>>>> is called from the CRTC side to ensure the topology information from > > > > > > > >>>>>>> the CRTC check is available. > > > > > > > >>>>>> > > > > > > > >>>>>> Why is it important? What is broken otherwise? > > > > > > > >>>>> > > > > > > > >>>>> I see. Thanks! Will add below lines in next version. > > > > > > > >>>>> > > > > > > > >>>>> By default, the plane check occurs before the CRTC check. > > > > > > > >>>>> Without topology information from the CRTC, plane splitting > > > > > > > >>>>> cannot be properly executed. Consequently, the SSPP > > > > > > > >>>>> engine starts without a valid memory address, which triggers > > > > > > > >>>>> an IOMMU warning. > > > > > > > >>>> > > > > > > > >>>> What is plane splitting? Write commit message for somebody who doesn't > > > > > > > >>>> exactly know what is going on. > > > > > > > >>> > > > > > > > >>> Thanks for the suggestion! Any more revise is needed? > > > > > > > >> > > > > > > > >> Sadly enough the text below is not a significant improvement. > > > > > > > >> > > > > > > > >>> > > > > > > > >>> Currently, splitting plane into SSPP rectangles the allocation occur > > > > > > > >>> during the plane check phase, so that a plane can be supported by > > > > > > > >>> multiple hardware pipe. > > > > > > > >> > > > > > > > >> What does this mean? Without virtual planes in place, there are no > > > > > > > >> multiple hardware pipes. > > > > > > > >> > > > > > > > >>> While pipe topology is decided in CRTC check. > > > > > > > >> > > > > > > > >> ?? What does it mean here? > > > > > > > >> > > > > > > > >>> By default, the plane check occurs before the CRTC check in DRM > > > > > > > >>> framework. Without topology information from the CRTC, plane splitting > > > > > > > >>> cannot be properly executed. > > > > > > > >> > > > > > > > >> What does 'properly' mean here? How is it executed? What happens? > > > > > > > >> > > > > > > > >>> Consequently, the SSPP engine starts > > > > > > > >>> without a valid memory address, which triggers IOMMU warning. > > > > > > > >> > > > > > > > >> IOMMU faults. There are no "warnings". > > > > > > > >> > > > > > > > >>> > > > > > > > >>> Defer above plane operations until dpu_assign_plane_resources() > > > > > > > >>> is called from the CRTC side to ensure the topology information from > > > > > > > >>> the CRTC check is available. > > > > > > > >> > > > > > > > >> > > > > > > > > Thanks for the patience! > > > > > > > > > > > > > > > > > > > > > > > > Currently, splitting plane into SSPP rectangles and allocation occur > > > > > > > > during the plane check phase. When virtual plane is enabled to support > > > > > > > > quad-pipe topology later, 2 SSPPs with 4 rect will be needed, so that > > > > > > > > a plane can be supported by 4 hardware pipes. And pipe number is > > > > > > > > > > > > > > number of pipes > > > > > > > > > > > > > > > decided in CRTC check per interface number, resolution and hardware > > > > > > > > feature. > > > > > > > > > > > > > > Okay, but IOMMU errors were reported with virtual planes being disabled. > > > > > > > So how is it relevant? > > > > > > > > > > > > After revise of splitting plane into pipes, the number of pipes will be decided > > > > > > by CRTC check for both virtual plane and non-virtual plane case to unify the > > > > > > plane handling, instead of assumption of 2 pipes at most. > > > > > > > > > > This needs to be explicitly written. > > > > > > > > > > > > > > > > > > > > > > > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > > > > > > framework. Without topology information from the CRTC, plane splitting > > > > > > > > > > > > > > WHat is plane splitting? > > > > > > > > > > > > How about: s/plane splitting/splitting plane into pipes ? > > > > > > > > > > This plane is not being split into anything. It's being mapped onto hw > > > > > pipes. But before that, the number of necessary hw pipes is being determined > > > > > based on foo, bar an baz, > > > > > > > > Thanks for the correction! > > > > > > > > Currently, plane is mapped onto at most 2 hardware pipes and 1 SSPP > > > > allocation occur during the plane check phase. When virtual plane is > > > > enabled to support quad-pipe topology later, 2 SSPPs with 4 rect will > > > > be needed, so that a plane can be supported by 4 hardware pipes. > > > > > > > > After revise of quad-pipe, the number of pipes is decided in CRTC > > > > check per number of interfaces, resolution, clock rate constrain, > > > > > > Where? > > > > The pipe is decided in dpu_crtc_get_topology(). Change to quad-pipe > > is made in later patch. So I drop this in this patch message below. > > The pipe isn't decides in that function. Sorry for the inaccurate word. I mean the number of pipes is decided in dpu_crtc_get_topology(), is it correct? Of course, the number of pipe may be increased from 1 to 2 with filling r_pipe_cfg in dpu_plane_atomic_check_nosspp() due to width or clock rate constrain in non-virtual-plane case. So the code logic allows 2 mixers co-work with 1 SSPP rect, mixer number is decided in topology and pipe is decided in plane side, though it is not very reasonable. Does DPU support such topology? If not, the number of pipe shall be aliged with the number of mixers info from topology side. Please help teach me on the relation number of mixers and SSPP rectangles. Thanks! > > > > > > > > hardware feature and virtual plane enablement. The decidsion of > > > > > > decision > > > > > > > number of pipes will happen in CRTC check for both virtual plane and > > > > non-virtual plane case to unify the plane handling. Before that, the > > > > > > will? Do you mean, after this patch? If so, please use imperative > > > language. See Documentation/process/submitting-patches.rst > > > > Yes, it is in later patch. So drop it in this patch message. > > > > It is possible to keep plane check unchanged, and rely on re-allocation > > in later stage to support quad-pipe, if quad-pipe use case is detected. > > But to unify the allocation logic for both non-virtual and virtual plane > > use cases, and to centralize resource management, we'd better defer > > the allocation. > > Which allocation? The non-virtual-planes case is more or less static. You are right. The SSPP is assigned to plane in non-virtual-planes case statically. The plane may be re-mapped to other SSPP only in virtual-plane case. Just got your point here. I will try to keep the SSPP assignment unchanged for non-virtual-plane case, avoiding mixing assignment with allocation. > > > > > > > > > > > > the number of necessary hw pipes is being determined based on > > > > resolution and clock rate constrain. > > > > > > > > By default, the plane check occurs before the CRTC check in DRM > > > > framework. Without topology information from the CRTC, plane mapping > > > > will be skipped for the first time as number of pipe is 0. > > > > Consequently, the SSPP engine starts without a valid memory address, > > > > which triggers IOMMU fault. > > > > > > > > Defer above plane related operations until dpu_assign_plane_resources() > > > > is called from the CRTC side to ensure the topology information from > > > > the CRTC check is available. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > will be skipped for the first time as pipe number is 0. Consequently, > > > > > > > > the SSPP engine starts without a valid memory address, which triggers > > > > > > > > IOMMU fault. > > > > > > > > > > > > > > > > Defer above plane related operations until dpu_assign_plane_resources() > > > > > > > > is called from the CRTC side to ensure the topology information from > > > > > > > > the CRTC check is available. > > > > > How about this commit message? It is more coherent with the change > > in this patch. > > > > > > Currently, a plane maps to at most two hardware pipes, and SSPP > > allocation occurs during the plane check phase. However, when virtual > > planes are enabled, SSPP re-allocation can occur within > > dpu_assign_plane_resources() during the CRTC check. > > There is no _allocation_ for non-virtual-plane case. The SSPP are > statically assigned to the planes. > > > > > To support future quad-pipe topologies, which require allocating two > > SSPPs with four rectangles by default, it is more efficient to perform > > the primary allocation in a single pass rather than relying on later > > re-allocations. So defer the allocation to CRTC check phase by default. > > Allocation logic for both non-virtual and virtual plane use cases is > > unified in this way. > > > > > -- > > > With best wishes > > > Dmitry > > -- > With best wishes > Dmitry
© 2016 - 2026 Red Hat, Inc.