Il 08/05/24 09:19, CK Hu (胡俊光) ha scritto:
On Tue, 2024-05-07 at 16:07 +0200, AngeloGioacchino Del Regno wrote:
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@xxxxxxxxxxxxx>
---
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23
+++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mms
ys.y
aml
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mms
ys.y
aml
index b3c6888c1457..4e9acd966aa5 100644
---
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mms
ys.y
aml
+++
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mms
ys.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>;
};
};
I'm not sure how do you define this port from OVL to vdosys. If this
port means 'master relationship', others could add port in COLOR to
point to vdosys because COLOR and vdosys has the 'master relationship'
and I could not reject this. So we need more specific definition of
this port.
Only the 'first' device in pipeline could have this port?
Correct. Only the first device in a pipeline - and this is actually a restriction
that the generic binding definition of port already gives, in a way.
In mt8173, one pipeline is
ovl -> color -> aal -> od -> rdma -> ufo -> dsi
But rdma has an option to read data from od or directly from DRAM. If
from DRAM, the pipeline would be changed to
rdma -> ufo -> dsi
So it's confused which one is 'first'.
That's why the pipeline is *board-specific* and not soc-generic!
And what you described is *exactly* the reason why I'm adding support for the
OF graphs in mediatek-drm: specifying the correct pipeline for each board as per
what each board wants to use (said differently: for each board's *capabilities*).
So, if on a certain board you want to skip OD, you can hook RDMA up directly to
MMSYS/VDOSYS.
In MT8173, one pipeline for one board uses endpoints IN/OUT like this:
MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
and for another board, endpoints will be like
MMSYS -> RDMA -> UFO -> DSI
...which is the exact same as you described, and I think that your confusion comes
from the fact that you didn't put MMSYS at the beginning of the pipeline :-)
In case you need any *temporary override* on any board that defines a pipeline like
MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
so that the pipeline *temporarily* becomes (for power management, or for any other
reason) RDMA -> UFO -> DSI .... that's not a concern: the graph is present, and it
is used to tell to the driver what is the regular pipeline to use.
Eventual temporary overrides can be managed transparently inside of the driver with
C code and no changes to the devicetree are required.
I don't know how to decide which device could point to mmsys/vdosys. So
please give a specific definition.
Nothing points TO mmsys/vdosys. It is mmsys/vdosys pointing to a device.
So, mmsys/vdosys must point to the *first device in the pipeline*.
Any other doubt?
Cheers,
Angelo
Regards,
CK
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
