All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marijn Suijten <marijn.suijten@somainline.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	freedreno@lists.freedesktop.org,
	Jami Kettunen <jami.kettunen@somainline.org>,
	linux-arm-msm@vger.kernel.org,
	Bjorn Andersson <andersson@kernel.org>,
	dri-devel@lists.freedesktop.org,
	Stephen Boyd <swboyd@chromium.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	AngeloGioacchino Del Regno 
	<angelogioacchino.delregno@somainline.org>,
	David Airlie <airlied@gmail.com>
Subject: Re: [1/2] drm/msm/dpu: fix clocks settings for msm8998 SSPP blocks
Date: Tue, 24 Jan 2023 13:06:52 +0100	[thread overview]
Message-ID: <20230124120652.rqmaj2j4jytmvzbl@SoMainline.org> (raw)
In-Reply-To: <CAA8EJprPxm6PObLapAXr_D5d85oT8y2GhoCzABLq_u2xFDhkvQ@mail.gmail.com>

On 2023-01-24 13:20:57, Dmitry Baryshkov wrote:
> On Tue, 24 Jan 2023 at 13:12, Marijn Suijten
> <marijn.suijten@somainline.org> wrote:
> >
> > On 2023-01-24 12:19:27, Dmitry Baryshkov wrote:
> > > On 24/01/2023 11:59, Marijn Suijten wrote:
> > > > On 2023-01-15 14:41:42, Dmitry Baryshkov wrote:
> > > >> DMA2 and DMA3 planes on msm8998 should use corresponding DMA2 and DMA3
> > > >> clocks rather than CURSOR0/1 clocks (which are used for the CURSOR
> > > >> planes). Correct corresponding SSPP declarations.
> > > >>
> > > >> Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
> > > >> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> > > >> Cc: Jami Kettunen <jami.kettunen@somainline.org>
> > > >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > >> ---
> > > >>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 ++--
> > > >>   1 file changed, 2 insertions(+), 2 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > > >> index 0f3da480b066..ad0c55464154 100644
> > > >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > > >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > > >> @@ -1180,9 +1180,9 @@ static const struct dpu_sspp_cfg msm8998_sspp[] = {
> > > >>    SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000,  DMA_MSM8998_MASK,
> > > >>            sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1),
> > > >>    SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000,  DMA_CURSOR_MSM8998_MASK,
> > > >
> > > > Drop the _CURSOR mask here?  And the double space....
> > >
> > > Ack for the doublespace. By removing _CURSOR we would disallow using
> > > these planes as hw cursor planes. This would switch all compositors into
> > > sw cursor mode, thus damaging the performance.
> >
> > Doesn't that require special hardware support, or can any DMA pipe
> > support "hw cursor mode/planes", whatever that means?  Sorry for not
> > being well versed in this area, I'd expect DMA pipes and CURSOR pipes to
> > have a different set of features / capabilities.
> 
> Yes, they have different capabilities. but DMA_CURSOR_MSM8998_MASK =
> DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR). And the DPU_SSPP_CURSOR is
> used internally to tell the DRM core that the corresponding plane is
> going to be used as a "userspace cursor" plane.

Different capabilities for userspace, but not in terms hardware (/driver
support, yet)?  If so, then:

Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>

> > Commit 07ca1fc0f8a0 ("drm/msm/dpu: enable cursor plane on dpu") leads me
> > to believe that it's mostly to let userspace use these DMA pipes for
> > cursors (having cursor planes available in uapi) rather than requiring
> > any special hardware support (though semantics do seem to change in a
> > nontrivial way).
> 
> Correct.
> DRM/userspace cursor planes = planes which userspace can use to draw
> mouse cursor. Legacy compositors and legacy cursor IOCTLs stick to
> using them
> DPU/MDP5 CURSOR plane (sspp_12/13) = lightweight limited plane without

But these DMA pipes are _not_ lightweight/limited?

> additional features, targeting HW cursor only, not present since
> sdm845
> DPU_SSPP_CURSOR = bit which tells DPU core to mark a plane as
> 'DRM/userspace cursor plane'.

Ack, so it's not toggling anything hardware specific /yet/.  However,
does this prevent userspace from using these pipes/planes for other DMA
purposes as they're marked as a different _type_ of plane?  And will
that change when we do end up "implementing more rigorous/strict
hardware support"?  For the other SoCs, are their DMA pipes also
featureful and would the presence of DPU_SSPP_CURSOR severely limit its
functionality?  And is this thing that "virtual planes" would be going
to "solve"?

<snip>

> > As we've seen in [1] (specifically [2]) there are a few more driver/hw
> > changes required to properly implement/support DPU_SSPP_CURSOR?
> >
> > [1]: https://github.com/rawoul/linux/commits/next_20220624-msm8998-hdmi
> > [2]; https://github.com/rawoul/linux/commit/7d8d739cfbfa551120868986d5824f7b2b116ac1

Referring to changes like these ^.

- Marijn

WARNING: multiple messages have this Message-ID (diff)
From: Marijn Suijten <marijn.suijten@somainline.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Jami Kettunen <jami.kettunen@somainline.org>,
	Sean Paul <sean@poorly.run>,
	Bjorn Andersson <andersson@kernel.org>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@somainline.org>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	dri-devel@lists.freedesktop.org,
	Stephen Boyd <swboyd@chromium.org>,
	linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org
Subject: Re: [1/2] drm/msm/dpu: fix clocks settings for msm8998 SSPP blocks
Date: Tue, 24 Jan 2023 13:06:52 +0100	[thread overview]
Message-ID: <20230124120652.rqmaj2j4jytmvzbl@SoMainline.org> (raw)
In-Reply-To: <CAA8EJprPxm6PObLapAXr_D5d85oT8y2GhoCzABLq_u2xFDhkvQ@mail.gmail.com>

On 2023-01-24 13:20:57, Dmitry Baryshkov wrote:
> On Tue, 24 Jan 2023 at 13:12, Marijn Suijten
> <marijn.suijten@somainline.org> wrote:
> >
> > On 2023-01-24 12:19:27, Dmitry Baryshkov wrote:
> > > On 24/01/2023 11:59, Marijn Suijten wrote:
> > > > On 2023-01-15 14:41:42, Dmitry Baryshkov wrote:
> > > >> DMA2 and DMA3 planes on msm8998 should use corresponding DMA2 and DMA3
> > > >> clocks rather than CURSOR0/1 clocks (which are used for the CURSOR
> > > >> planes). Correct corresponding SSPP declarations.
> > > >>
> > > >> Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
> > > >> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> > > >> Cc: Jami Kettunen <jami.kettunen@somainline.org>
> > > >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > >> ---
> > > >>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 ++--
> > > >>   1 file changed, 2 insertions(+), 2 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > > >> index 0f3da480b066..ad0c55464154 100644
> > > >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > > >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > > >> @@ -1180,9 +1180,9 @@ static const struct dpu_sspp_cfg msm8998_sspp[] = {
> > > >>    SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000,  DMA_MSM8998_MASK,
> > > >>            sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1),
> > > >>    SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000,  DMA_CURSOR_MSM8998_MASK,
> > > >
> > > > Drop the _CURSOR mask here?  And the double space....
> > >
> > > Ack for the doublespace. By removing _CURSOR we would disallow using
> > > these planes as hw cursor planes. This would switch all compositors into
> > > sw cursor mode, thus damaging the performance.
> >
> > Doesn't that require special hardware support, or can any DMA pipe
> > support "hw cursor mode/planes", whatever that means?  Sorry for not
> > being well versed in this area, I'd expect DMA pipes and CURSOR pipes to
> > have a different set of features / capabilities.
> 
> Yes, they have different capabilities. but DMA_CURSOR_MSM8998_MASK =
> DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR). And the DPU_SSPP_CURSOR is
> used internally to tell the DRM core that the corresponding plane is
> going to be used as a "userspace cursor" plane.

Different capabilities for userspace, but not in terms hardware (/driver
support, yet)?  If so, then:

Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>

> > Commit 07ca1fc0f8a0 ("drm/msm/dpu: enable cursor plane on dpu") leads me
> > to believe that it's mostly to let userspace use these DMA pipes for
> > cursors (having cursor planes available in uapi) rather than requiring
> > any special hardware support (though semantics do seem to change in a
> > nontrivial way).
> 
> Correct.
> DRM/userspace cursor planes = planes which userspace can use to draw
> mouse cursor. Legacy compositors and legacy cursor IOCTLs stick to
> using them
> DPU/MDP5 CURSOR plane (sspp_12/13) = lightweight limited plane without

But these DMA pipes are _not_ lightweight/limited?

> additional features, targeting HW cursor only, not present since
> sdm845
> DPU_SSPP_CURSOR = bit which tells DPU core to mark a plane as
> 'DRM/userspace cursor plane'.

Ack, so it's not toggling anything hardware specific /yet/.  However,
does this prevent userspace from using these pipes/planes for other DMA
purposes as they're marked as a different _type_ of plane?  And will
that change when we do end up "implementing more rigorous/strict
hardware support"?  For the other SoCs, are their DMA pipes also
featureful and would the presence of DPU_SSPP_CURSOR severely limit its
functionality?  And is this thing that "virtual planes" would be going
to "solve"?

<snip>

> > As we've seen in [1] (specifically [2]) there are a few more driver/hw
> > changes required to properly implement/support DPU_SSPP_CURSOR?
> >
> > [1]: https://github.com/rawoul/linux/commits/next_20220624-msm8998-hdmi
> > [2]; https://github.com/rawoul/linux/commit/7d8d739cfbfa551120868986d5824f7b2b116ac1

Referring to changes like these ^.

- Marijn

  reply	other threads:[~2023-01-24 12:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-15 12:41 [PATCH 1/2] drm/msm/dpu: fix clocks settings for msm8998 SSPP blocks Dmitry Baryshkov
2023-01-15 12:41 ` Dmitry Baryshkov
2023-01-15 12:41 ` [PATCH 2/2] drm/msm/dpu: don't use DPU_CLK_CTRL_CURSORn for DMA SSPP clocks Dmitry Baryshkov
2023-01-15 12:41   ` Dmitry Baryshkov
2023-01-16 15:12   ` Neil Armstrong
2023-01-16 15:12     ` Neil Armstrong
2023-01-24 10:13   ` [2/2] " Marijn Suijten
2023-01-24 10:13     ` Marijn Suijten
2023-01-24 10:20     ` Dmitry Baryshkov
2023-01-24 10:20       ` Dmitry Baryshkov
2023-01-24  9:59 ` [1/2] drm/msm/dpu: fix clocks settings for msm8998 SSPP blocks Marijn Suijten
2023-01-24  9:59   ` Marijn Suijten
2023-01-24 10:19   ` Dmitry Baryshkov
2023-01-24 10:19     ` Dmitry Baryshkov
2023-01-24 11:12     ` Marijn Suijten
2023-01-24 11:12       ` Marijn Suijten
2023-01-24 11:20       ` Dmitry Baryshkov
2023-01-24 11:20         ` Dmitry Baryshkov
2023-01-24 12:06         ` Marijn Suijten [this message]
2023-01-24 12:06           ` Marijn Suijten
2023-01-24 12:29           ` Dmitry Baryshkov
2023-01-24 12:29             ` Dmitry Baryshkov
2023-01-24 14:00             ` Marijn Suijten
2023-01-24 14:00               ` Marijn Suijten
2023-02-10 13:38   ` Dmitry Baryshkov
2023-02-10 13:38     ` 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=20230124120652.rqmaj2j4jytmvzbl@SoMainline.org \
    --to=marijn.suijten@somainline.org \
    --cc=airlied@gmail.com \
    --cc=andersson@kernel.org \
    --cc=angelogioacchino.delregno@somainline.org \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jami.kettunen@somainline.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=swboyd@chromium.org \
    /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: link
Be 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.