On 12/09/2023 12:28, Chen-Yu Tsai wrote: > On Tue, Sep 12, 2023 at 5:43 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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. Most, but not all. Some maintainers take entire set - including DTS - which is not what we want, because *DTS, as a hardware description, must be independent of driver changes*. Most notably Greg and netdev folks grab everything. Keeping it together with driver changes brings confusion and feeling that there are dependency. Please don't do this. Best regards, Krzysztof
