From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: "CK Hu (胡俊光)" <ck.hu@mediatek.com>,
"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"wenst@chromium.org" <wenst@chromium.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"tzimmermann@suse.de" <tzimmermann@suse.de>,
"Shawn Sung (宋孝謙)" <Shawn.Sung@mediatek.com>,
"mripard@kernel.org" <mripard@kernel.org>,
"Jitao Shi (石记涛)" <jitao.shi@mediatek.com>,
"daniel@ffwll.ch" <daniel@ffwll.ch>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"maarten.lankhorst@linux.intel.com"
<maarten.lankhorst@linux.intel.com>,
"robh@kernel.org" <robh@kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"airlied@gmail.com" <airlied@gmail.com>,
"krzysztof.kozlowski+dt@linaro.org"
<krzysztof.kozlowski+dt@linaro.org>,
"kernel@collabora.com" <kernel@collabora.com>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"Yu-chang Lee (李禹璋)" <Yu-chang.Lee@mediatek.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Date: Tue, 7 May 2024 16:07:05 +0200 [thread overview]
Message-ID: <46347f5d-e09b-4e83-a5a2-e12407f442a4@collabora.com> (raw)
In-Reply-To: <4dfb09b9c437ab2baa0898eca13a43fd7475047a.camel@mediatek.com>
Il 07/05/24 08:59, CK Hu (胡俊光) ha scritto:
> On Thu, 2024-05-02 at 10:50 +0200, AngeloGioacchino Del Regno wrote:
>> Il 25/04/24 04:23, CK Hu (胡俊光) ha scritto:
>>> Hi, Angelo:
>>>
>>> On Tue, 2024-04-09 at 14:02 +0200, AngeloGioacchino Del Regno
>>> wrote:
>>>> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP
>>>> paths
>>>> per HW instance (so potentially up to six displays for multi-vdo
>>>> SoCs).
>>>>
>>>> The MMSYS or VDOSYS is always the first component in the DDP
>>>> pipeline,
>>>> so it only supports an output port with multiple endpoints -
>>>> where
>>>> each
>>>> endpoint defines the starting point for one of the (currently
>>>> three)
>>>> possible hardware paths.
>>>>
>>>> Signed-off-by: AngeloGioacchino Del Regno <
>>>> angelogioacchino.delregno@collabora.com>
>>>> ---
>>>> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23
>>>> +++++++++++++++++++
>>>> 1 file changed, 23 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.y
>>>> aml
>>>> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.y
>>>> aml
>>>> index b3c6888c1457..4e9acd966aa5 100644
>>>> ---
>>>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.y
>>>> aml
>>>> +++
>>>> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.y
>>>> aml
>>>> @@ -93,6 +93,29 @@ properties:
>>>> '#reset-cells':
>>>> const: 1
>>>>
>>>> + port:
>>>> + $ref: /schemas/graph.yaml#/properties/port
>>>> + description:
>>>> + Output port node. This port connects the MMSYS/VDOSYS
>>>> output
>>>> to
>>>> + the first component of one display pipeline, for example
>>>> one
>>>> of
>>>> + the available OVL or RDMA blocks.
>>>> + Some MediaTek SoCs support up to three display outputs per
>>>> MMSYS.
>>>> + properties:
>>>> + endpoint@0:
>>>> + $ref: /schemas/graph.yaml#/properties/endpoint
>>>> + description: Output to the primary display pipeline
>>>> +
>>>> + endpoint@1:
>>>> + $ref: /schemas/graph.yaml#/properties/endpoint
>>>> + description: Output to the secondary display pipeline
>>>> +
>>>> + endpoint@2:
>>>> + $ref: /schemas/graph.yaml#/properties/endpoint
>>>> + description: Output to the tertiary display pipeline
>>>> +
>>>> + required:
>>>> + - endpoint@0
>>>> +
>>>
>>> mmsys/vdosys does not output data to the first component of display
>>> pipeline, so this connection looks 'virtual'. Shall we add
>>> something
>>> virtual in device tree? You add this in order to decide which
>>> pipeline
>>> is 1st, 2nd, 3rd, but for device it don't care which one is first.
>>> In
>>> computer, software could change which display is the primary
>>> display.
>>> I'm not sure it's good to decide display order in device tree?
>>>
>>
>> Devicetree describes hardware, so nothing virtual can be present -
>> and in any case,
>> the primary/secondary/tertiary pipeline is in relation to MM/VDO SYS,
>> not referred
>> to software.
>>
>> Better explaining, the primary pipeline is not necessarily the
>> primary display in
>> DRM terms: that's a concept that is completely detached from the
>> scope of this
>> series and this graph - and it's something that shall be managed
>> solely by the
>> driver (mediatek-drm in this case).
>>
>> Coming back to the connection looking, but *not* being virtual: the
>> sense here is
>> that the MM/VDOSYS blocks are used in the display pipeline to
>> "stitch" together
>> the various display pipeline hardware blocks, or, said differently,
>> setting up the
>> routing between all of those (P.S.: mmsys_mtxxxx_routing_table!)
>> through the VDO
>> Input Selection (VDOx_SEL_IN) or Output Selection (VDOx_SEL_OUT) and
>> with the
>> assistance of the VDO Multiple Output Mask (VDOx_MOUT) for the
>> multiple outputs
>> usecase, both of which, are described by this graph.
>
> I agree this part, but this is related to display device OF graph.
> These display device would output video data from one device and input
> to another video device. These video device would not input or output
> video data to mmsys/vdosys.
>
>>
>> This means that the VDOSYS is really the "master" of the display
>> pipeline since
>> everything gets enabled, mixed and matched from there - and that's in
>> the sense
>> of hardware operation, so we are *really* (and not virtually!)
>> flipping switches.
>
> I agree mmsys/vdosys is master of video pipeline, so let's define what
> the port in mmsys/vdosys is. If the port means the master relationship,
> mmsys/vdosys should output port to every display device. Or use a
> simply way to show the master relation ship
>
> mmsys-subdev = <&ovl0, &rdma0, &color0, ...>, <&ovl1, &rdma1, &color1,
> ...>;
>
There's no need to list all of the VDO0/VDO1/mmsys devices in one big array
property, because the actual possible devices can be defined:
1. In the bindings; and
2. In the actual OF graph that we write for each SoC+board combination.
A graph cannot contain a connection to a device that cannot be connected to
the previous, so, your "mmsys-subdev" list can be retrieved by looking at the
graph:
- Start from VDO0/1 or MMSYS
- Walk through (visually, even) OUTPUT ports
- VDO0 (read output ep) -> ovl0 (read output ep) -> rdma0 (read output ep) ->
color0 (...) -> etc
- Nothing more - it's all defined there.
>
> Another problem is how to group display device? If two pipeline could
> be route to the same display interface, such as
>
> rdma0 -> dsi
> rdma1 -> dsi
>
> Would this be single group?
There are multiple ways of doing this, but one that comes to my mind right now and
that looks clean as well is the following:
ovl0@ef01 {
.....
ports {
port@0 {
reg = <0>;
ovl0_in: endpoint {
remote-endpoint = <&vdosys0_out>;
};
};
port@1 {
reg = <1>;
ovl0_out0: endpoint@0 {
remote-endpoint = <&rdma0_in>;
};
ovl0_out1: endpoint@1 {
remote-endpoint = <&rdma1_in>;
};
};
};
};
rdma0@1234 {
.....
ports {
port@0 {
reg = <0>;
rdma0_in: endpoint {
remote-endpoint = <&ovl0_out0>; /* assuming ovl0 outputs to rdma0...*/
};
};
port@1 {
reg = <1>;
rdma0_out: endpoint@1 {
remote-endpoint = <&dsi_dual_intf0_in>;
};
};
};
};
rdma1@5678 {
.....
ports {
port@0 {
reg = <0>;
rdma1_in: endpoint {
/* assuming ovl0 outputs to rdma1 as well... can be something else. */
remote-endpoint = <&ovl0_out1>;
};
};
port@1 {
reg = <1>;
rdma1_out: endpoint {
remote-endpoint = <&dsi_dual_intf1_in>;
};
};
};
};
dsi@9abcd {
.....
ports {
port@0 {
reg = <0>;
/* Where endpoint@0 could be always DSI LEFT CTRL */
dsi_dual_intf0_in: endpoint@0 {
remote-endpoint = <&rdma0_out>;
};
/* ...and @1 could be always DSI RIGHT CTRL */
dsi_dual_intf1_in: endpoint@1 {
remote-endpoint = <&rdma1_out>;
};
};
port@1 {
reg = <1>;
dsi0_out: endpoint {
remote-endpoint = <&dsi_panel_in>;
};
};
};
};
...for a dual-dsi panel, it'd be a similar graph.
Cheers,
Angelo
>
> mmsys-subdev = <&rdma0, &rdma1, &dsi>;
>
> Or two group?
>
> mmsys-subdev = <&rdma0, &dsi>, <&rdma1, &dsi>;
>
> I think we should clearly define this.
>
> Regards,
> CK
>
>>
>>
>> Cheers,
>> Angelo
>>
>>> Regards,
>>> CK
>>>
>>>
>>>> required:
>>>> - compatible
>>>> - reg
>>
>>
next prev parent reply other threads:[~2024-05-07 14:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 12:02 [PATCH v2 0/3] drm/mediatek: Add support for OF graphs AngeloGioacchino Del Regno
2024-04-09 12:02 ` [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path AngeloGioacchino Del Regno
2024-04-09 15:20 ` Dmitry Baryshkov
2024-04-09 15:41 ` AngeloGioacchino Del Regno
2024-04-09 15:45 ` Dmitry Baryshkov
2024-04-19 7:40 ` AngeloGioacchino Del Regno
2024-04-10 19:03 ` Rob Herring
2024-04-19 7:44 ` AngeloGioacchino Del Regno
2024-04-09 12:02 ` [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: " AngeloGioacchino Del Regno
2024-04-10 19:15 ` Rob Herring
2024-04-19 7:54 ` AngeloGioacchino Del Regno
2024-04-25 2:23 ` CK Hu (胡俊光)
2024-05-02 8:50 ` AngeloGioacchino Del Regno
2024-05-07 6:59 ` CK Hu (胡俊光)
2024-05-07 14:07 ` AngeloGioacchino Del Regno [this message]
2024-05-08 7:19 ` CK Hu (胡俊光)
2024-05-08 13:03 ` AngeloGioacchino Del Regno
2024-05-09 5:42 ` CK Hu (胡俊光)
2024-05-09 9:27 ` AngeloGioacchino Del Regno
2024-05-10 9:34 ` CK Hu (胡俊光)
2024-05-10 10:14 ` AngeloGioacchino Del Regno
2024-05-13 6:15 ` CK Hu (胡俊光)
2024-05-13 13:44 ` AngeloGioacchino Del Regno
2024-05-13 16:28 ` Conor Dooley
2024-05-16 7:27 ` AngeloGioacchino Del Regno
2024-04-09 12:02 ` [PATCH v2 3/3] drm/mediatek: Implement OF graphs support for display paths AngeloGioacchino Del Regno
2024-05-06 9:11 ` Michael Walle
2024-05-06 12:58 ` AngeloGioacchino Del Regno
2024-04-30 10:17 ` [PATCH v2 0/3] drm/mediatek: Add support for OF graphs Alexandre Mergnat
2024-04-30 11:33 ` AngeloGioacchino Del Regno
2024-05-02 16:53 ` Alexandre Mergnat
2024-05-14 9:46 ` Alexandre Mergnat
2024-05-14 12:00 ` AngeloGioacchino Del Regno
2024-05-06 10:02 ` Michael Walle
2024-05-06 10:56 ` AngeloGioacchino Del Regno
2024-05-06 11:22 ` AngeloGioacchino Del Regno
2024-05-06 13:17 ` Michael Walle
2024-05-06 14:18 ` AngeloGioacchino Del Regno
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=46347f5d-e09b-4e83-a5a2-e12407f442a4@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=Shawn.Sung@mediatek.com \
--cc=Yu-chang.Lee@mediatek.com \
--cc=airlied@gmail.com \
--cc=chunkuang.hu@kernel.org \
--cc=ck.hu@mediatek.com \
--cc=conor+dt@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jitao.shi@mediatek.com \
--cc=kernel@collabora.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=tzimmermann@suse.de \
--cc=wenst@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).