From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: abhinavk@codeaurora.org Cc: Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>, Jonathan Marek <jonathan@marek.ca>, Stephen Boyd <sboyd@kernel.org>, linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>, freedreno@lists.freedesktop.org Subject: Re: [Freedreno] [PATCH v2 16/22] drm/msm/dpu: do not limit the zpos property Date: Tue, 9 Nov 2021 23:21:23 +0300 [thread overview] Message-ID: <CAA8EJpoKiu32oqGLpus-W8Z1ifKKVyAyOOp9kPF6NnxRLS6+fw@mail.gmail.com> (raw) In-Reply-To: <3a48e580272ceb9d5d499455d8f35630@codeaurora.org> On Tue, 9 Nov 2021 at 23:15, <abhinavk@codeaurora.org> wrote: > > On 2021-07-04 18:21, Dmitry Baryshkov wrote: > > Stop limiting zpos property values, we use normalized_zpos anyway. And > > nothing stops userspace from assigning several planes to a single zpos > > (it is a userspace bug, but the kernel is forgiving about it). > > Userspace assigning several planes to a single zpos was intended to > identify > cases where src split can be used. Downstream does not use normalized > zpos, > hence it did not come across as a bug but mostly as a way to identify > when > usermode needs src split to be enabled based on the composition > strategy. > > We can talk about that more in the rest of the patches of this series. > > For this one, I only have a couple of questions: > > 1) Across different vendors, some have gone with limiting the zpos and > some have gone with > the max, so is there an issue with sticking with the max_blend_stages > limit? > > 2) If there is no hard reason to make this change, I think its better to > keep it the way it is. Short answer to both questions: we want to have more planes than the max_blend_stages. So we should remove the limit. Consider this to be a unification with MDP5, which uses 255 here. > > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 11 +---------- > > 1 file changed, 1 insertion(+), 10 deletions(-) > > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > > index 8ed7b8f0db69..3850f2714bf3 100644 > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > > @@ -44,7 +44,6 @@ > > #define DPU_NAME_SIZE 12 > > > > #define DPU_PLANE_COLOR_FILL_FLAG BIT(31) > > -#define DPU_ZPOS_MAX 255 > > > > /* multirect rect index */ > > enum { > > @@ -1374,7 +1373,6 @@ struct drm_plane *dpu_plane_init(struct > > drm_device *dev, > > struct dpu_plane *pdpu; > > struct msm_drm_private *priv = dev->dev_private; > > struct dpu_kms *kms = to_dpu_kms(priv->kms); > > - int zpos_max = DPU_ZPOS_MAX; > > uint32_t num_formats; > > int ret = -EINVAL; > > > > @@ -1412,14 +1410,7 @@ struct drm_plane *dpu_plane_init(struct > > drm_device *dev, > > > > pdpu->catalog = kms->catalog; > > > > - if (kms->catalog->mixer_count && > > - kms->catalog->mixer[0].sblk->maxblendstages) { > > - zpos_max = kms->catalog->mixer[0].sblk->maxblendstages - 1; > > - if (zpos_max > DPU_STAGE_MAX - DPU_STAGE_0 - 1) > > - zpos_max = DPU_STAGE_MAX - DPU_STAGE_0 - 1; > > - } > > - > > - ret = drm_plane_create_zpos_property(plane, 0, 0, zpos_max); > > + ret = drm_plane_create_zpos_property(plane, 0, 0, 255); > > if (ret) > > DPU_ERROR("failed to install zpos property, rc = %d\n", ret); -- With best wishes Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: abhinavk@codeaurora.org Cc: freedreno@lists.freedesktop.org, Jonathan Marek <jonathan@marek.ca>, Stephen Boyd <sboyd@kernel.org>, linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, Bjorn Andersson <bjorn.andersson@linaro.org>, David Airlie <airlied@linux.ie>, Sean Paul <sean@poorly.run> Subject: Re: [Freedreno] [PATCH v2 16/22] drm/msm/dpu: do not limit the zpos property Date: Tue, 9 Nov 2021 23:21:23 +0300 [thread overview] Message-ID: <CAA8EJpoKiu32oqGLpus-W8Z1ifKKVyAyOOp9kPF6NnxRLS6+fw@mail.gmail.com> (raw) In-Reply-To: <3a48e580272ceb9d5d499455d8f35630@codeaurora.org> On Tue, 9 Nov 2021 at 23:15, <abhinavk@codeaurora.org> wrote: > > On 2021-07-04 18:21, Dmitry Baryshkov wrote: > > Stop limiting zpos property values, we use normalized_zpos anyway. And > > nothing stops userspace from assigning several planes to a single zpos > > (it is a userspace bug, but the kernel is forgiving about it). > > Userspace assigning several planes to a single zpos was intended to > identify > cases where src split can be used. Downstream does not use normalized > zpos, > hence it did not come across as a bug but mostly as a way to identify > when > usermode needs src split to be enabled based on the composition > strategy. > > We can talk about that more in the rest of the patches of this series. > > For this one, I only have a couple of questions: > > 1) Across different vendors, some have gone with limiting the zpos and > some have gone with > the max, so is there an issue with sticking with the max_blend_stages > limit? > > 2) If there is no hard reason to make this change, I think its better to > keep it the way it is. Short answer to both questions: we want to have more planes than the max_blend_stages. So we should remove the limit. Consider this to be a unification with MDP5, which uses 255 here. > > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 11 +---------- > > 1 file changed, 1 insertion(+), 10 deletions(-) > > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > > index 8ed7b8f0db69..3850f2714bf3 100644 > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > > @@ -44,7 +44,6 @@ > > #define DPU_NAME_SIZE 12 > > > > #define DPU_PLANE_COLOR_FILL_FLAG BIT(31) > > -#define DPU_ZPOS_MAX 255 > > > > /* multirect rect index */ > > enum { > > @@ -1374,7 +1373,6 @@ struct drm_plane *dpu_plane_init(struct > > drm_device *dev, > > struct dpu_plane *pdpu; > > struct msm_drm_private *priv = dev->dev_private; > > struct dpu_kms *kms = to_dpu_kms(priv->kms); > > - int zpos_max = DPU_ZPOS_MAX; > > uint32_t num_formats; > > int ret = -EINVAL; > > > > @@ -1412,14 +1410,7 @@ struct drm_plane *dpu_plane_init(struct > > drm_device *dev, > > > > pdpu->catalog = kms->catalog; > > > > - if (kms->catalog->mixer_count && > > - kms->catalog->mixer[0].sblk->maxblendstages) { > > - zpos_max = kms->catalog->mixer[0].sblk->maxblendstages - 1; > > - if (zpos_max > DPU_STAGE_MAX - DPU_STAGE_0 - 1) > > - zpos_max = DPU_STAGE_MAX - DPU_STAGE_0 - 1; > > - } > > - > > - ret = drm_plane_create_zpos_property(plane, 0, 0, zpos_max); > > + ret = drm_plane_create_zpos_property(plane, 0, 0, 255); > > if (ret) > > DPU_ERROR("failed to install zpos property, rc = %d\n", ret); -- With best wishes Dmitry
next prev parent reply other threads:[~2021-11-09 20:21 UTC|newest] Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-05 1:20 [PATCH v2 00/22] drm/msm/dpu: switch dpu_plane to be virtual Dmitry Baryshkov 2021-07-05 1:20 ` Dmitry Baryshkov 2021-07-05 1:20 ` [PATCH v2 01/22] drm/msm/dpu: move LUT levels out of QOS config Dmitry Baryshkov 2021-07-05 1:20 ` Dmitry Baryshkov 2021-07-05 1:20 ` [PATCH v2 02/22] drm/msm/dpu: remove pipe_qos_cfg from struct dpu_plane Dmitry Baryshkov 2021-07-05 1:20 ` Dmitry Baryshkov 2021-07-05 1:20 ` [PATCH v2 03/22] drm/msm/dpu: drop pipe_name " Dmitry Baryshkov 2021-07-05 1:20 ` Dmitry Baryshkov 2021-07-05 1:20 ` [PATCH v2 04/22] drm/msm/dpu: remove stage_cfg from struct dpu_crtc Dmitry Baryshkov 2021-07-05 1:20 ` Dmitry Baryshkov 2021-07-05 1:20 ` [PATCH v2 05/22] drm/msm/dpu: rip out master planes support Dmitry Baryshkov 2021-07-05 1:20 ` Dmitry Baryshkov 2021-07-05 1:20 ` [PATCH v2 06/22] drm/msm/dpu: move dpu_hw_pipe_cfg out of struct dpu_plane Dmitry Baryshkov 2021-07-05 1:20 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 07/22] drm/msm/dpu: drop scaler config from plane state Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 08/22] drm/msm/dpu: drop dpu_csc_cfg from dpu_plane Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 09/22] drm/msm/dpu: remove dpu_hw_pipe_cdp_cfg " Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 10/22] drm/msm/dpu: don't cache pipe->cap->features in dpu_plane Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 11/22] drm/msm/dpu: don't cache pipe->cap->sblk " Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 12/22] drm/msm/dpu: rip out debugfs support from dpu_plane Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 13/22] drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 14/22] drm/msm/dpu: add list of supported formats to the DPU caps Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-11-09 20:05 ` [Freedreno] " abhinavk 2021-11-09 20:05 ` abhinavk 2021-07-05 1:21 ` [PATCH v2 15/22] drm/msm/dpu: simplify DPU_SSPP features checks Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-11-09 20:06 ` [Freedreno] " abhinavk 2021-11-09 20:06 ` abhinavk 2021-07-05 1:21 ` [PATCH v2 16/22] drm/msm/dpu: do not limit the zpos property Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-11-09 20:15 ` [Freedreno] " abhinavk 2021-11-09 20:15 ` abhinavk 2021-11-09 20:21 ` Dmitry Baryshkov [this message] 2021-11-09 20:21 ` Dmitry Baryshkov 2021-11-10 1:35 ` abhinavk 2021-11-10 1:35 ` abhinavk 2021-11-10 1:58 ` Dmitry Baryshkov 2021-11-10 1:58 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 17/22] drm/msm/dpu: add support for SSPP allocation to RM Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-11-10 0:30 ` [Freedreno] " abhinavk 2021-11-10 0:30 ` abhinavk 2021-07-05 1:21 ` [PATCH v2 18/22] drm/msm/dpu: move pipe_hw to dpu_plane_state Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 19/22] drm/msm/dpu: add support for virtualized planes Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-07-05 1:21 ` [PATCH v2 20/22] drm/msm/dpu: fix smart dma support Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-11-10 2:06 ` [Freedreno] " abhinavk 2021-11-10 2:06 ` abhinavk 2021-07-05 1:21 ` [PATCH v2 21/22] drm/msm/dpu: fix CDP setup to account for multirect index Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-11-10 2:12 ` [Freedreno] " abhinavk 2021-11-10 2:12 ` abhinavk 2021-07-05 1:21 ` [PATCH v2 22/22] drm/msm/dpu: add multirect support Dmitry Baryshkov 2021-07-05 1:21 ` Dmitry Baryshkov 2021-11-10 2:22 ` [Freedreno] " abhinavk 2021-11-10 2:22 ` abhinavk 2021-09-30 2:19 ` [Freedreno] [PATCH v2 00/22] drm/msm/dpu: switch dpu_plane to be virtual abhinavk 2021-09-30 10:56 ` Dmitry Baryshkov 2021-09-30 10:56 ` Dmitry Baryshkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAA8EJpoKiu32oqGLpus-W8Z1ifKKVyAyOOp9kPF6NnxRLS6+fw@mail.gmail.com \ --to=dmitry.baryshkov@linaro.org \ --cc=abhinavk@codeaurora.org \ --cc=airlied@linux.ie \ --cc=bjorn.andersson@linaro.org \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=jonathan@marek.ca \ --cc=linux-arm-msm@vger.kernel.org \ --cc=robdclark@gmail.com \ --cc=sboyd@kernel.org \ --cc=sean@poorly.run \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.