[PATCH v5 00/14] add support MDP3 on MT8195 platform

[Chen-Yu Tsai]

On Tue, Sep 12, 2023 at 5:43 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 12/09/23 11:37, Chen-Yu Tsai ha scritto:
> > On Tue, Sep 12, 2023 at 5:00 PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno at collabora.com> wrote:
> >>
> >> Il 12/09/23 09:57, Moudy Ho ha scritto:
> >>> Changes since v4:
> >>> - Rebase on v6.6-rc1
> >>> - Remove any unnecessary DTS settings.
> >>> - Adjust the usage of MOD and clock in blending components.
> >>>
> >>> Changes since v3:
> >>> - Depend on :
> >>>     [1] https://patchwork.kernel.org/project/linux-media/list/?series=719841
> >>> - Suggested by Krzysztof, integrating all newly added bindings for
> >>>     the mt8195 MDP3 into the file "mediatek,mt8195-mdp3.yaml".
> >>> - Revise MDP3 nodes with generic names.
> >>>
> >>> Changes since v2:
> >>> - Depend on :
> >>>     [1] MMSYS/MUTEX: https://patchwork.kernel.org/project/linux-mediatek/list/?series=711592
> >>>     [2] MDP3: https://patchwork.kernel.org/project/linux-mediatek/list/?series=711618
> >>> - Suggested by Rob to revise MDP3 bindings to pass dtbs check
> >>> - Add parallel paths feature.
> >>> - Add blended components settings.
> >>>
> >>> Changes since v1:
> >>> - Depend on :
> >>>     [1] MDP3 : https://patchwork.kernel.org/project/linux-mediatek/list/?series=698872
> >>>     [2] MMSYS/MUTEX: https://patchwork.kernel.org/project/linux-mediatek/list/?series=684959
> >>> - Fix compilation failure due to use of undeclared identifier in file "mtk-mdp3-cmdq.c"
> >>>
> >>> Hello,
> >>>
> >>> This patch is used to add support for MDP3 on the MT8195 platform that
> >>> contains more picture quality components, and can arrange more pipelines
> >>> through two sets of MMSYS and MUTEX respectively.
> >>>
> >>> Moudy Ho (14):
> >>>     arm64: dts: mediatek: mt8183: correct MDP3 DMA-related nodes
> >>>     arm64: dts: mediatek: mt8195: add MDP3 nodes
> >>
> >> Please send the DTS patches separately, those go through a different maintainer.
> >
> > I thought most people prefer the _full_ view in a patchset?
> >
>
> Yeah but those going through a different maintainer makes it more straightforward
> to pick; besides, essentially, you can also get a full view with dt-bindings
> patches instead of devicetrees, as the latter are "constructed from" bindings
> anyway.

Sure, but testing, especially by people not in the recipients or CC list,
is a bit painful when the full set of patches isn't bundled together.
Having them bundled together shows what the submitter tested and makes
it easier for others to reproduce.

AFAIK other ARM platforms have been sending patches all grouped together.
It's MediaTek that has been different, as they normally have (for Chromebooks)
a system integration engineer handling the device tree stuff, while component
driver owners just handle the drivers, and by extension, the DT bindings.

> Moreover, it would be definitely nice to add a link to the devicetree series
> in the cover letter of this series, so that people *do* get a full overview
> by checking both series :-)

Most maintainers seem to know what to do: apply the subset destined for
their tree. At least the subsystems that frequently deal with DT-based
platforms anyway.


ChenYu

> Cheers!
>
> >> P.S.: The dt-bindings patch can be sent inside of this series, please do that.
> >>
> >> Thanks!
> >> Angelo
> >>
> >>
>