LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dmitry Baryshkov <email@example.com>
To: Jeffrey Hugo <firstname.lastname@example.org>
Cc: AngeloGioacchino Del Regno
Rob Clark <email@example.com>, Sean Paul <firstname.lastname@example.org>,
Dave Airlie <email@example.com>, Daniel Vetter <firstname.lastname@example.org>,
Abhinav Kumar <email@example.com>,
Rob Herring <firstname.lastname@example.org>,
"open list:DRM PANEL DRIVERS" <email@example.com>,
Konrad Dybcio <firstname.lastname@example.org>,
Marijn Suijten <email@example.com>,
Martin Botka <firstname.lastname@example.org>,
Subject: Re: [Freedreno] [PATCH 2/3] drm/msm/dpu1: Add MSM8998 to hw catalog
Date: Thu, 9 Sep 2021 16:46:25 +0300 [thread overview]
Message-ID: <email@example.com> (raw)
On 08/09/2021 17:22, Jeffrey Hugo wrote:
> On Wed, Sep 8, 2021 at 2:26 AM Dmitry Baryshkov
> <firstname.lastname@example.org> wrote:
>> On Tue, 7 Sept 2021 at 22:13, Jeffrey Hugo <email@example.com> wrote:
>>> On Wed, Sep 1, 2021 at 12:11 PM AngeloGioacchino Del Regno
>>> <firstname.lastname@example.org> wrote:
>>>> Bringup functionality for MSM8998 in the DPU, driver which is mostly
>>>> the same as SDM845 (just a few variations).
>>>> Signed-off-by: AngeloGioacchino Del Regno <email@example.com>
>>> I don't seem to see a cover letter for this series.
>>> Eh, there are a fair number of differences between the MDSS versions
>>> for 8998 and 845.
>>> Probably a bigger question, why extend the DPU driver for 8998, when
>>> the MDP5 driver already supports it? The MDP/DPU split is pretty
>>> dumb, but I don't see a valid reason for both drivers supporting the
>>> same target/display revision. IMO, if you want this support in DPU,
>>> remove it from MDP5.
>>>  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.14&id=d6c7b2284b14c66a268a448a7a8d54f585d38785
>> I don't think that we should enforce such requirements. Having support
>> both in MDP5 and DPU would allow one to compare those two drivers,
>> performance, features, etc.
>> It might be that all MDP5-supported hardware would be also supported
>> by DPU, thus allowing us to remove the former driver. But until that
>> time I'd suggest leaving support in place.
> Well, then you have a host of problems to solve.
> Lets ignore the code duplication for a minute and assume we've gone
> with this grand experiment. Two drivers enter, one leaves the victor.
> How are the clients supposed to pick which driver to use in the mean
> time? We already have one DT binding for 8998 (which the MDP5 driver
> services). This series proposes a second. If we go forward with what
> you propose, we'll have two bindings for the same hardware, which IMO
> doesn't make sense in the context of DT, and the reason for that is to
> select which driver is "better". Driver selection is not supposed to
> be tied to DT like this.
> So, some boards think MDP5 is better, and some boards think DPU is
> better. At some point, we decide one of the drivers is the clear
> winner (lets assume DPU). Then what happens to the existing DTs that
> were using the MDP5 description? Are they really compatible with DPU?
> From a DT perspective, there should be one description, but then how
> do you pick which driver to load? Both can't bind on the single
> description, and while you could argue that the users should build one
> driver or the other, but not both (thus picking which one at build
> time), that doesn't work for distros that want to build both drivers
> so that they can support all platforms with a single build (per arch).
Yep, the DT issue wasn't thought about from my side at the review time.
I considered qcom,msm8998-dpu as an extension/upgrade of bare qcom,mdp5
compatibility string (as we usually add chip-specific compatibilities).
In fact using just 'qcom,mdp5' prevents us from having such kind of
What I'd propose if everybody else agrees on moving 8998 (and maybe
others later) from MDP5 to DPU would be to continue supporting qcom,mdp5
binding in the mdp5 driver and to add qcom,msm8998-dpu binding used by
the DPU driver. Maybe with the warning telling to update the binding.
Then at some point if all the MDP5-supported hardware is supported by
the DPU we can drop the MDP5 driver and implement required bindings
compatibility in the DPU.
> From where I sit, your position starts with a good idea, but isn't
> fully thought out and leads to problems.
> If there is some reason why DPU is better for 8998, please enumerate
> it. Does DPU support some config that MDP5 doesn't, which is valuable
> to you?
The DPU receives more attention from both Qualcomm and Linaro, so it
will continue acquiring features (which MDP5 might not have at the moment).
For example consider the SmartDMA (multirect) support. For now the
multirect patchset it is limited to newer versions, but it might be
extended to support older chips (in the DPU) too. We did not have plans
to backport SmartDMA v1 support to MDP5.
Writeback also has more chances to be supported in the DPU rather than
in the MDP5 driver (I remember Rob's patches for the MDP5, but they
never actually landed upstream).
Last but not least at this moment DPU has bandwidth scaling support,
while MDP5 does not. I've sent a patch for MDP5 earlier, which then got
reverted because of armv7 support. At this moment I did not resend it
since we found some underrun issues on resume or when quickly changing
bw down and up.
> I'm ok with ripping out the MDP5 support, the reason I didn't
> go with DPU was that the DPU driver was clearly written only for 845
> at the time, and needed significant rework to "downgrade" to an
> earlier hardware. However, the "reason" DPU exists separate from MDP5
> is the claim that the MDP hardware underwent a significant
> rearchitecture, and thus it was too cumbersome to extend MDP5. While
> I disagree with the premise, that "rearch" started with 8998.
Just checked, the SDE, the origin (or parent) of the DPU driver starts
it's support from the 8996 and 8998.
With best wishes
next prev parent reply other threads:[~2021-09-09 14:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-01 18:11 [PATCH 1/3] drm/msm/dpu1: Add DMA2, DMA3 clock control to enum AngeloGioacchino Del Regno
2021-09-01 18:11 ` [PATCH 2/3] drm/msm/dpu1: Add MSM8998 to hw catalog AngeloGioacchino Del Regno
2021-09-02 22:25 ` Dmitry Baryshkov
2021-09-03 18:23 ` Dmitry Baryshkov
2021-09-07 19:12 ` [Freedreno] " Jeffrey Hugo
2021-09-08 8:25 ` Dmitry Baryshkov
2021-09-08 14:22 ` Jeffrey Hugo
2021-09-09 13:46 ` Dmitry Baryshkov [this message]
2021-09-09 18:00 ` AngeloGioacchino Del Regno
2021-09-01 18:11 ` [PATCH 3/3] dt-bindings: display: msm: Add binding for msm8998 dpu AngeloGioacchino Del Regno
2021-09-07 18:37 ` Rob Herring
2021-11-25 11:53 ` Dmitry Baryshkov
2021-11-25 15:26 ` AngeloGioacchino Del Regno
2021-09-02 22:21 ` [PATCH 1/3] drm/msm/dpu1: Add DMA2, DMA3 clock control to enum Dmitry Baryshkov
2021-09-03 18:24 ` Dmitry Baryshkov
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [Freedreno] [PATCH 2/3] drm/msm/dpu1: Add MSM8998 to hw catalog' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).