mbox series

[v6,00/16] introduce more MDP3 components in MT8195

Message ID 20230922072116.11009-1-moudy.ho@mediatek.com
Headers show
Series introduce more MDP3 components in MT8195 | expand

Message

Moudy Ho Sept. 22, 2023, 7:21 a.m. UTC
Changes since v5:
- Rebase on v6.6-rc2.
- Dependent dtsi files:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=786511
- Depends on:
  Message ID = 20230911074233.31556-5-shawn.sung@mediatek.com
- Split out common propertis for RDMA.
- Split each component into independent patches.

Changes since v4:
- Rebase on v6.6-rc1
- Organize identical hardware components into their respective files.

Hi,

The purpose of this patch is to separate the MDP3-related bindings from
the original mailing list mentioned below:
https://lore.kernel.org/all/20230208092209.19472-1-moudy.ho@mediatek.com/
Those binding files describe additional components that
are present in the mt8195.

Moudy Ho (16):
  dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with
    generic names
  dt-bindings: media: mediatek: mdp3: split out general properties
  dt-bindings: media: mediatek: mdp3: include common properties
  dt-bindings: media: mediatek: mdp3: rename to MT8183 RDMA
  dt-bindings: media: mediatek: mdp3: add support MT8195 RDMA
  dt-bindings: media: mediatek: mdp3: add component FG for MT8195
  dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
  dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
  dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
  dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
  dt-bindings: display: mediatek: aal: add compatible for MT8195
  dt-bindings: display: mediatek: color: add compatible for MT8195
  dt-bindings: display: mediatek: merge: add compatible for MT8195
  dt-bindings: display: mediatek: ovl: add compatible for MT8195
  dt-bindings: display: mediatek: split: add compatible for MT8195
  dt-bindings: display: mediatek: padding: add compatible for MT8195

 .../display/mediatek/mediatek,aal.yaml        |  1 +
 .../display/mediatek/mediatek,color.yaml      |  1 +
 .../display/mediatek/mediatek,merge.yaml      |  1 +
 .../display/mediatek/mediatek,ovl.yaml        |  1 +
 .../display/mediatek/mediatek,padding.yaml    |  4 +-
 .../display/mediatek/mediatek,split.yaml      |  1 +
 .../bindings/media/mediatek,mdp3-fg.yaml      | 61 +++++++++++++++++
 .../bindings/media/mediatek,mdp3-hdr.yaml     | 60 +++++++++++++++++
 .../media/mediatek,mdp3-rdma-8183.yaml        | 65 +++++++++++++++++++
 .../media/mediatek,mdp3-rdma-8195.yaml        | 64 ++++++++++++++++++
 ...ma.yaml => mediatek,mdp3-rdma-common.yaml} | 49 ++++----------
 .../bindings/media/mediatek,mdp3-stitch.yaml  | 61 +++++++++++++++++
 .../bindings/media/mediatek,mdp3-tcc.yaml     | 60 +++++++++++++++++
 .../bindings/media/mediatek,mdp3-tdshp.yaml   | 61 +++++++++++++++++
 .../bindings/media/mediatek,mdp3-wrot.yaml    | 23 ++++---
 15 files changed, 467 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8183.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
 rename Documentation/devicetree/bindings/media/{mediatek,mdp3-rdma.yaml => mediatek,mdp3-rdma-common.yaml} (57%)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml

Comments

Conor Dooley Sept. 22, 2023, 3:48 p.m. UTC | #1
On Fri, Sep 22, 2023 at 03:21:11PM +0800, Moudy Ho wrote:
> Add a compatible string for the AAL block in MediaTek MT8195 that
> is controlled by MDP3.
> 
> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

> ---
>  .../devicetree/bindings/display/mediatek/mediatek,aal.yaml       | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index 7fd42c8fdc32..b4c28e96dd55 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -24,6 +24,7 @@ properties:
>        - enum:
>            - mediatek,mt8173-disp-aal
>            - mediatek,mt8183-disp-aal
> +          - mediatek,mt8195-mdp3-aal
>        - items:
>            - enum:
>                - mediatek,mt2712-disp-aal
> -- 
> 2.18.0
>
Conor Dooley Sept. 22, 2023, 3:51 p.m. UTC | #2
On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote:
> On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote:
> > Add a compatible string for the COLOR block in MediaTek MT8195 that
> > is controlled by MDP3.
> > 
> > Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> > ---
> >  .../devicetree/bindings/display/mediatek/mediatek,color.yaml     | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> > index f21e44092043..b886ca0d89ea 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> > @@ -26,6 +26,7 @@ properties:
> >            - mediatek,mt2701-disp-color
> >            - mediatek,mt8167-disp-color
> >            - mediatek,mt8173-disp-color
> > +          - mediatek,mt8195-mdp3-color
> 
> How come this one is a "mdp3" not a "disp"?

I don't know what mdp3 means & googling gives me no answers. What's the
"disp" one controlled by, since it isn't controlled by mdp3?

> 
> >        - items:
> >            - enum:
> >                - mediatek,mt7623-disp-color
> > -- 
> > 2.18.0
> >
Krzysztof Kozlowski Sept. 23, 2023, 5:34 p.m. UTC | #3
On 22/09/2023 09:21, Moudy Ho wrote:
> Add the fundamental hardware configuration of component TDSHP,
> which is controlled by MDP3 on MT8195.
> 
> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> ---
>  .../bindings/media/mediatek,mdp3-tdshp.yaml   | 61 +++++++++++++++++++
>  1 file changed, 61 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
> new file mode 100644
> index 000000000000..0ac904cbc2c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
> @@ -0,0 +1,61 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/mediatek,mdp3-tdshp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Media Data Path 3 TDSHP
> +
> +maintainers:
> +  - Matthias Brugger <matthias.bgg@gmail.com>
> +  - Moudy Ho <moudy.ho@mediatek.com>
> +
> +description:
> +  One of Media Data Path 3 (MDP3) components used to improve image
> +  sharpness and contrast.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - mediatek,mt8195-mdp3-tdshp
> +
> +  reg:
> +    maxItems: 1
> +
> +  mediatek,gce-client-reg:
> +    description:
> +      The register of display function block to be set by gce. There are 4 arguments,
> +      such as gce node, subsys id, offset and register size. The subsys id that is
> +      mapping to the register of display function blocks is defined in the gce header
> +      include/dt-bindings/gce/<chip>-gce.h of each chips.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    items:
> +      items:
> +        - description: phandle of GCE
> +        - description: GCE subsys id
> +        - description: register offset
> +        - description: register size
> +    maxItems: 1
> +
> +  clocks:
> +    minItems: 1

NAK. So you ignored all the review. Brilliant.

I am getting fed up with Mediatek's approach. It's not the first time.

Best regards,
Krzysztof
Moudy Ho Sept. 27, 2023, 6:50 a.m. UTC | #4
On Sat, 2023-09-23 at 19:36 +0200, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 22/09/2023 09:21, Moudy Ho wrote:
> > Changes since v5:
> > - Rebase on v6.6-rc2.
> > - Dependent dtsi files:
> >   
> https://patchwork.kernel.org/project/linux-mediatek/list/?series=786511
> > - Depends on:
> >   Message ID = 20230911074233.31556-5-shawn.sung@mediatek.com
> > - Split out common propertis for RDMA.
> > - Split each component into independent patches.
> 
> And ignored previously given feedback. That's not the way you should
> work with upstream community. It feels like a waste of my time and it
> is
> not fair that Mediatek is doing it :(
> 
> Best regards,
> Krzysztof
> 
Hi Krzysztof,

While splitting the bindings, I was so focused that I accidentally
missed correcting the properties that needed to be fixed.
I sincerely apologize for this oversight.
Moving forward, I will handle such matters with greater care.

Sincerely,
Moudy
Moudy Ho Sept. 28, 2023, 2:52 a.m. UTC | #5
On Wed, 2023-09-27 at 10:47 +0100, Conor Dooley wrote:
> On Wed, Sep 27, 2023 at 07:19:28AM +0000, Moudy Ho (何宗原) wrote:
> > On Fri, 2023-09-22 at 16:51 +0100, Conor Dooley wrote:
> > > On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote:
> > > > On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote:
> > > > > Add a compatible string for the COLOR block in MediaTek
> > > > > MT8195
> > > > > that
> > > > > is controlled by MDP3.
> > > > > 
> > > > > Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> > > > > ---
> > > > >  .../devicetree/bindings/display/mediatek/mediatek,color.yaml
> > > > >     
> > > > >  | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > ,col
> > > > > or.yaml
> > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > ,col
> > > > > or.yaml
> > > > > index f21e44092043..b886ca0d89ea 100644
> > > > > ---
> > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > ,col
> > > > > or.yaml
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > ,col
> > > > > or.yaml
> > > > > @@ -26,6 +26,7 @@ properties:
> > > > >            - mediatek,mt2701-disp-color
> > > > >            - mediatek,mt8167-disp-color
> > > > >            - mediatek,mt8173-disp-color
> > > > > +          - mediatek,mt8195-mdp3-color
> > > > 
> > > > How come this one is a "mdp3" not a "disp"?
> > > 
> > > I don't know what mdp3 means & googling gives me no answers.
> > > What's
> > > the
> > > "disp" one controlled by, since it isn't controlled by mdp3?
> > > 
> > 
> > Hi Conor,
> > 
> > Mediatek's Media Data Path ver.3 (MDP3) is associated with MMSYS
> > and
> > acts as an independent driver that operates between VDEC and DISP.
> > By controlling multiple components, it carries out tasks like
> > converting color formats, resizing, and applying specific Picture
> > Quality (PQ) effects.
> > The driver can be found at "driver/media/platform/mediatek/mdp3".
> > Since the same hardware components are configured in both MDP3 and
> > DISP, considering previous discussions, I attemped to integrate
> > into a
> > single binding, named after the controlling user.
> 
> I'm still kinda struggling to understand this. Do you mean that the
> hardware can be controlled by either of the disp and mdp3 drivers,
> and
> a compatible containing "disp" would use one driver, and one
> containing
> "mdp3" would use another?
> 

Hi Conor,

Sorry for any confusion caused by the software information. In the
video pipeline, after decoding, the data flows sequentially through two
subsystems: MDP and DISP. Each subsystems has multiple IPs, with some
serving the same functionality as COLOR mentioned here. However, these
IPs cannot be controlled by different subsystems. Therefore, I included
the name of the subsystem after SoC to identify the configuration's
location. Is this approach feasible?

Sincerely,
Moudy
Conor Dooley Sept. 28, 2023, 4:49 p.m. UTC | #6
On Thu, Sep 28, 2023 at 02:52:23AM +0000, Moudy Ho (何宗原) wrote:
> On Wed, 2023-09-27 at 10:47 +0100, Conor Dooley wrote:
> > On Wed, Sep 27, 2023 at 07:19:28AM +0000, Moudy Ho (何宗原) wrote:
> > > On Fri, 2023-09-22 at 16:51 +0100, Conor Dooley wrote:
> > > > On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote:
> > > > > On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote:
> > > > > > Add a compatible string for the COLOR block in MediaTek
> > > > > > MT8195
> > > > > > that
> > > > > > is controlled by MDP3.
> > > > > > 
> > > > > > Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/display/mediatek/mediatek,color.yaml
> > > > > >     
> > > > > >  | 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > > ,col
> > > > > > or.yaml
> > > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > > ,col
> > > > > > or.yaml
> > > > > > index f21e44092043..b886ca0d89ea 100644
> > > > > > ---
> > > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > > ,col
> > > > > > or.yaml
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > > ,col
> > > > > > or.yaml
> > > > > > @@ -26,6 +26,7 @@ properties:
> > > > > >            - mediatek,mt2701-disp-color
> > > > > >            - mediatek,mt8167-disp-color
> > > > > >            - mediatek,mt8173-disp-color
> > > > > > +          - mediatek,mt8195-mdp3-color
> > > > > 
> > > > > How come this one is a "mdp3" not a "disp"?
> > > > 
> > > > I don't know what mdp3 means & googling gives me no answers.
> > > > What's
> > > > the
> > > > "disp" one controlled by, since it isn't controlled by mdp3?
> > > > 

> > > Mediatek's Media Data Path ver.3 (MDP3) is associated with MMSYS
> > > and
> > > acts as an independent driver that operates between VDEC and DISP.
> > > By controlling multiple components, it carries out tasks like
> > > converting color formats, resizing, and applying specific Picture
> > > Quality (PQ) effects.
> > > The driver can be found at "driver/media/platform/mediatek/mdp3".
> > > Since the same hardware components are configured in both MDP3 and
> > > DISP, considering previous discussions, I attemped to integrate
> > > into a
> > > single binding, named after the controlling user.
> > 
> > I'm still kinda struggling to understand this. Do you mean that the
> > hardware can be controlled by either of the disp and mdp3 drivers,
> > and
> > a compatible containing "disp" would use one driver, and one
> > containing
> > "mdp3" would use another?
> > 

> Sorry for any confusion caused by the software information. In the
> video pipeline, after decoding, the data flows sequentially through two
> subsystems: MDP and DISP. Each subsystems has multiple IPs, with some
> serving the same functionality as COLOR mentioned here. However, these
> IPs cannot be controlled by different subsystems. Therefore, I included
> the name of the subsystem after SoC to identify the configuration's
> location. Is this approach feasible?

I'll have to leave things to the likes of Laurent to comment here I
think. I don't understand this hardware well enough to have a useful
opinion. It would seem like a different part of the datapath is a
different device that should be documented separately, but I don't know
enough to say for sure, sorry.
AngeloGioacchino Del Regno Sept. 29, 2023, 8:42 a.m. UTC | #7
Il 28/09/23 18:49, Conor Dooley ha scritto:
> On Thu, Sep 28, 2023 at 02:52:23AM +0000, Moudy Ho (何宗原) wrote:
>> On Wed, 2023-09-27 at 10:47 +0100, Conor Dooley wrote:
>>> On Wed, Sep 27, 2023 at 07:19:28AM +0000, Moudy Ho (何宗原) wrote:
>>>> On Fri, 2023-09-22 at 16:51 +0100, Conor Dooley wrote:
>>>>> On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote:
>>>>>> On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote:
>>>>>>> Add a compatible string for the COLOR block in MediaTek
>>>>>>> MT8195
>>>>>>> that
>>>>>>> is controlled by MDP3.
>>>>>>>
>>>>>>> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
>>>>>>> ---
>>>>>>>   .../devicetree/bindings/display/mediatek/mediatek,color.yaml
>>>>>>>      
>>>>>>>   | 1 +
>>>>>>>   1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/display/mediatek/mediatek
>>>>>>> ,col
>>>>>>> or.yaml
>>>>>>> b/Documentation/devicetree/bindings/display/mediatek/mediatek
>>>>>>> ,col
>>>>>>> or.yaml
>>>>>>> index f21e44092043..b886ca0d89ea 100644
>>>>>>> ---
>>>>>>> a/Documentation/devicetree/bindings/display/mediatek/mediatek
>>>>>>> ,col
>>>>>>> or.yaml
>>>>>>> +++
>>>>>>> b/Documentation/devicetree/bindings/display/mediatek/mediatek
>>>>>>> ,col
>>>>>>> or.yaml
>>>>>>> @@ -26,6 +26,7 @@ properties:
>>>>>>>             - mediatek,mt2701-disp-color
>>>>>>>             - mediatek,mt8167-disp-color
>>>>>>>             - mediatek,mt8173-disp-color
>>>>>>> +          - mediatek,mt8195-mdp3-color
>>>>>>
>>>>>> How come this one is a "mdp3" not a "disp"?
>>>>>
>>>>> I don't know what mdp3 means & googling gives me no answers.
>>>>> What's
>>>>> the
>>>>> "disp" one controlled by, since it isn't controlled by mdp3?
>>>>>
> 
>>>> Mediatek's Media Data Path ver.3 (MDP3) is associated with MMSYS
>>>> and
>>>> acts as an independent driver that operates between VDEC and DISP.
>>>> By controlling multiple components, it carries out tasks like
>>>> converting color formats, resizing, and applying specific Picture
>>>> Quality (PQ) effects.
>>>> The driver can be found at "driver/media/platform/mediatek/mdp3".
>>>> Since the same hardware components are configured in both MDP3 and
>>>> DISP, considering previous discussions, I attemped to integrate
>>>> into a
>>>> single binding, named after the controlling user.
>>>
>>> I'm still kinda struggling to understand this. Do you mean that the
>>> hardware can be controlled by either of the disp and mdp3 drivers,
>>> and
>>> a compatible containing "disp" would use one driver, and one
>>> containing
>>> "mdp3" would use another?
>>>
> 
>> Sorry for any confusion caused by the software information. In the
>> video pipeline, after decoding, the data flows sequentially through two
>> subsystems: MDP and DISP. Each subsystems has multiple IPs, with some
>> serving the same functionality as COLOR mentioned here. However, these
>> IPs cannot be controlled by different subsystems. Therefore, I included
>> the name of the subsystem after SoC to identify the configuration's
>> location. Is this approach feasible?
> 
> I'll have to leave things to the likes of Laurent to comment here I
> think. I don't understand this hardware well enough to have a useful
> opinion. It would seem like a different part of the datapath is a
> different device that should be documented separately, but I don't know
> enough to say for sure, sorry.

Hardware speaking, it's not a different device: those all reside in the
same block, except they are configured to route their I/O *either* to the
display pipeline, *or* to the MDP3 pipeline.

I would agree though in that this could be more flexible, as in, not
having a requirement to say "mdp3" or "disp", and managing the COLOR
blocks generically and letting the drivers to choose the actual path
transparently from what the devicetree compatible is, but there's no
practical point in doing this in the end, because there is an enough
number of (for example, COLOR) blocks such that one can be completely
reserved to MDP3 and one completely reserved to DISP.

So, we don't *need* this flexibility, but would be nice to have for
different (unexistant, basically) usecases...

The thing is, if we go for the maximum flexibility, the drawback is
that we'd see a number of nodes like

shared_block: something@somewhere {
	compatible = "mediatek,something";
}

mdp3: dma-controller@14001000 {
	......
	mediatek,color = <&color0>;
	mediatek,stitch = <&stitch0>;
	mediatek,hdr = <&hdr0>;
	mediatek,aal = <&aal0>;
	....
	long list of another 10 components
}

display: something@somewhere {
	......
	an even longer list than the MDP3 one
}

...or perhaps even a graph, which is even longer in the end.

I'm not against this kind of structure, but I wonder if it's worth it.

Cheers,
Angelo
Conor Dooley Sept. 29, 2023, 1:58 p.m. UTC | #8
On Fri, Sep 29, 2023 at 10:42:58AM +0200, AngeloGioacchino Del Regno wrote:
> Il 28/09/23 18:49, Conor Dooley ha scritto:
> > On Thu, Sep 28, 2023 at 02:52:23AM +0000, Moudy Ho (何宗原) wrote:
> > > On Wed, 2023-09-27 at 10:47 +0100, Conor Dooley wrote:
> > > > On Wed, Sep 27, 2023 at 07:19:28AM +0000, Moudy Ho (何宗原) wrote:
> > > > > On Fri, 2023-09-22 at 16:51 +0100, Conor Dooley wrote:
> > > > > > On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote:
> > > > > > > > Add a compatible string for the COLOR block in MediaTek
> > > > > > > > MT8195
> > > > > > > > that
> > > > > > > > is controlled by MDP3.
> > > > > > > > 
> > > > > > > > Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> > > > > > > > ---
> > > > > > > >   .../devicetree/bindings/display/mediatek/mediatek,color.yaml
> > > > > > > >   | 1 +
> > > > > > > >   1 file changed, 1 insertion(+)
> > > > > > > > 
> > > > > > > > diff --git
> > > > > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > > > > ,col
> > > > > > > > or.yaml
> > > > > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > > > > ,col
> > > > > > > > or.yaml
> > > > > > > > index f21e44092043..b886ca0d89ea 100644
> > > > > > > > ---
> > > > > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > > > > ,col
> > > > > > > > or.yaml
> > > > > > > > +++
> > > > > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek
> > > > > > > > ,col
> > > > > > > > or.yaml
> > > > > > > > @@ -26,6 +26,7 @@ properties:
> > > > > > > >             - mediatek,mt2701-disp-color
> > > > > > > >             - mediatek,mt8167-disp-color
> > > > > > > >             - mediatek,mt8173-disp-color
> > > > > > > > +          - mediatek,mt8195-mdp3-color
> > > > > > > 
> > > > > > > How come this one is a "mdp3" not a "disp"?
> > > > > > 
> > > > > > I don't know what mdp3 means & googling gives me no answers.
> > > > > > What's
> > > > > > the
> > > > > > "disp" one controlled by, since it isn't controlled by mdp3?
> > > > > > 
> > 
> > > > > Mediatek's Media Data Path ver.3 (MDP3) is associated with MMSYS
> > > > > and
> > > > > acts as an independent driver that operates between VDEC and DISP.
> > > > > By controlling multiple components, it carries out tasks like
> > > > > converting color formats, resizing, and applying specific Picture
> > > > > Quality (PQ) effects.
> > > > > The driver can be found at "driver/media/platform/mediatek/mdp3".
> > > > > Since the same hardware components are configured in both MDP3 and
> > > > > DISP, considering previous discussions, I attemped to integrate
> > > > > into a
> > > > > single binding, named after the controlling user.
> > > > 
> > > > I'm still kinda struggling to understand this. Do you mean that the
> > > > hardware can be controlled by either of the disp and mdp3 drivers,
> > > > and
> > > > a compatible containing "disp" would use one driver, and one
> > > > containing
> > > > "mdp3" would use another?
> > > > 
> > 
> > > Sorry for any confusion caused by the software information. In the
> > > video pipeline, after decoding, the data flows sequentially through two
> > > subsystems: MDP and DISP. Each subsystems has multiple IPs, with some
> > > serving the same functionality as COLOR mentioned here. However, these
> > > IPs cannot be controlled by different subsystems. Therefore, I included
> > > the name of the subsystem after SoC to identify the configuration's
> > > location. Is this approach feasible?
> > 
> > I'll have to leave things to the likes of Laurent to comment here I
> > think. I don't understand this hardware well enough to have a useful
> > opinion. It would seem like a different part of the datapath is a
> > different device that should be documented separately, but I don't know
> > enough to say for sure, sorry.
> 
> Hardware speaking, it's not a different device: those all reside in the
> same block, except they are configured to route their I/O *either* to the
> display pipeline, *or* to the MDP3 pipeline.

Is it runtime configurable?

> I would agree though in that this could be more flexible, as in, not
> having a requirement to say "mdp3" or "disp", and managing the COLOR
> blocks generically and letting the drivers to choose the actual path
> transparently from what the devicetree compatible is, but there's no
> practical point in doing this in the end, because there is an enough
> number of (for example, COLOR) blocks such that one can be completely
> reserved to MDP3 and one completely reserved to DISP.
> 
> So, we don't *need* this flexibility, but would be nice to have for
> different (unexistant, basically) usecases...
> 
> The thing is, if we go for the maximum flexibility, the drawback is
> that we'd see a number of nodes like
> 
> shared_block: something@somewhere {
> 	compatible = "mediatek,something";
> }
> 
> mdp3: dma-controller@14001000 {
> 	......
> 	mediatek,color = <&color0>;
> 	mediatek,stitch = <&stitch0>;
> 	mediatek,hdr = <&hdr0>;
> 	mediatek,aal = <&aal0>;
> 	....
> 	long list of another 10 components
> }
> 
> display: something@somewhere {
> 	......
> 	an even longer list than the MDP3 one
> }
> 
> ...or perhaps even a graph, which is even longer in the end.
> 
> I'm not against this kind of structure, but I wonder if it's worth it.

I have no idea, but it sounds like it isn't. Really what happened here,
is not me having a particular thing I want to see, is getting a response
that implied that there were two different compatibles for the same
hardware, controlled by different drivers.
It does seem to be that way at present, and this is not something I am
willing to ack etc. That's not to say that I am _nacking_ it, just that
I don't understand this enough to ack something that we usually tell
people not to do.