Changes in v2:
- Fixed wrong `required` block indentation in commit [2/3]
The display IPs in MediaTek SoCs are *VERY* flexible and those support
being interconnected with different instances of DDP IPs (for example,
merge0 or merge1) and/or with different DDP IPs (for example, rdma can
be connected with either color, dpi, dsi, merge, etc), forming a full
Display Data Path that ends with an actual display.
This series was born because of an issue that I've found while enabling
support for MT8195/MT8395 boards with DSI output as main display: the
current mtk_drm_route variations would not work as currently, the driver
hardcodes a display path for Chromebooks, which have a DisplayPort panel
with DSC support, instead of a DSI panel without DSC support.
There are other reasons for which I wrote this series, and I find that
hardcoding those paths - when a HW path is clearly board-specific - is
highly suboptimal. Also, let's not forget about keeping this driver from
becoming a huge list of paths for each combination of SoC->board->disp
and... this and that.
For more information, please look at the commit description for each of
the commits included in this series.
Please don't mind about the missing OVL_ADAPTOR support for OF graphs
in this series: that needs a bit more thinking and a bit more work, and
will come in a second series that will go on top of this a bit later,
as the OF graph support for *at least* the primary display is essential
*right now* to enable support for the MT8195/8395 EVK, Kontron SoM,
Radxa NIO-12L and all of the other non-Chromebook boards to co-exist
with Chromebooks.
Besides, this is also a valid option for MT8188 Chromebooks which might
have different DSI-or-eDP displays depending on the model (as far as I
can see from the mtk_drm_route attempt for this SoC that is already
present in this driver).
This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths (meaning main display through OF graph and external
display hardcoded, because of OVL_ADAPTOR).
AngeloGioacchino Del Regno (3):
dt-bindings: display: mediatek: Add OF graph support for board path
dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
drm/mediatek: Implement OF graphs support for display paths
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 ++
.../display/mediatek/mediatek,aal.yaml | 40 +++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++
.../display/mediatek/mediatek,color.yaml | 22 ++
.../display/mediatek/mediatek,dither.yaml | 22 ++
.../display/mediatek/mediatek,dpi.yaml | 25 +-
.../display/mediatek/mediatek,dsc.yaml | 24 ++
.../display/mediatek/mediatek,dsi.yaml | 27 +-
.../display/mediatek/mediatek,ethdr.yaml | 22 ++
.../display/mediatek/mediatek,gamma.yaml | 19 ++
.../display/mediatek/mediatek,merge.yaml | 23 ++
.../display/mediatek/mediatek,od.yaml | 22 ++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
.../display/mediatek/mediatek,ovl.yaml | 22 ++
.../display/mediatek/mediatek,postmask.yaml | 21 ++
.../display/mediatek/mediatek,rdma.yaml | 22 ++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
21 files changed, 645 insertions(+), 36 deletions(-)
--
2.44.0
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 <[email protected]>
---
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index b3c6888c1457..4e9acd966aa5 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -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
+
required:
- compatible
- reg
--
2.44.0
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is anyway not enough for all final routes as the
DSI cannot be connected to MERGE if it's not a dual-DSI, or enabling
DSC preventively doesn't work if the display doesn't support it, or
others.
Since practically all display IPs in MediaTek SoCs support being
interconnected with different instances of other, or the same, IPs
or with different IPs and in different combinations, the final DDP
pipeline is effectively a board specific configuration.
Implement OF graphs support to the mediatek-drm drivers, allowing to
stop hardcoding the paths, and preventing this driver to get a huge
amount of arrays for each board and SoC combination, also paving the
way to share the same mtk_mmsys_driver_data between multiple SoCs,
making it more straightforward to add support for new chips.
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++++++++++++++++++++++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
4 files changed, 250 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index beb7d9d08e97..c47648d244fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -705,6 +705,15 @@ static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node, 1, -1);
+ if (IS_ERR(dpi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node, 0, 0);
+ if (IS_ERR(dpi->next_bridge))
+ return dev_err_probe(dpi->dev, PTR_ERR(dpi->next_bridge),
+ "Failed to get bridge\n");
+ }
+
return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
&dpi->bridge, flags);
}
@@ -1055,13 +1064,6 @@ static int mtk_dpi_probe(struct platform_device *pdev)
if (dpi->irq < 0)
return dpi->irq;
- dpi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dpi->next_bridge))
- return dev_err_probe(dev, PTR_ERR(dpi->next_bridge),
- "Failed to get bridge\n");
-
- dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
-
platform_set_drvdata(pdev, dpi);
dpi->bridge.funcs = &mtk_dpi_bridge_funcs;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 74832c213092..2baefa06ad16 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -796,12 +796,200 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ }
};
+static int mtk_drm_of_get_ddp_comp_type(struct device_node *node, enum mtk_ddp_comp_type *ctype)
+{
+ const struct of_device_id *of_id = of_match_node(mtk_ddp_comp_dt_ids, node);
+
+ if (!of_id)
+ return -EINVAL;
+
+ *ctype = (enum mtk_ddp_comp_type)((uintptr_t)of_id->data);
+
+ return 0;
+}
+
+static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
+ int output_port, enum mtk_drm_crtc_path crtc_path,
+ struct device_node **next, unsigned int *cid)
+{
+ struct device_node *ep_dev_node, *ep_out;
+ enum mtk_ddp_comp_type comp_type;
+ int ret;
+
+ ep_out = of_graph_get_endpoint_by_regs(node, output_port, crtc_path);
+ if (!ep_out)
+ return -ENOENT;
+
+ ep_dev_node = of_graph_get_remote_port_parent(ep_out);
+ if (!ep_dev_node)
+ return -EINVAL;
+
+ /*
+ * Pass the next node pointer regardless of failures in the later code
+ * so that if this function is called in a loop it will walk through all
+ * of the subsequent endpoints anyway.
+ */
+ *next = ep_dev_node;
+
+ if (!of_device_is_available(ep_dev_node))
+ return -ENODEV;
+
+ ret = mtk_drm_of_get_ddp_comp_type(ep_dev_node, &comp_type);
+ if (ret)
+ return ret;
+
+ ret = mtk_ddp_comp_get_id(ep_dev_node, comp_type);
+ if (ret < 0)
+ return ret;
+
+ /* All ok! Pass the Component ID to the caller. */
+ *cid = (unsigned int)ret;
+
+ return 0;
+}
+
+/**
+ * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC Path
+ * @dev: The mediatek-drm device
+ * @cpath: CRTC Path relative to a VDO or MMSYS
+ * @out_path: Pointer to an array that will contain the new pipeline
+ * @out_path_len: Number of entries in the pipeline array
+ *
+ * MediaTek SoCs can use different DDP hardware pipelines (or paths) depending
+ * on the board-specific desired display configuration; this function walks
+ * through all of the output endpoints starting from a VDO or MMSYS hardware
+ * instance and builds the right pipeline as specified in device trees.
+ *
+ * Return:
+ * * %0 - Display HW Pipeline successfully built and validated
+ * * %-ENOENT - Display pipeline was not specified in device tree
+ * * %-EINVAL - Display pipeline built but validation failed
+ * * %-ENOMEM - Failure to allocate pipeline array to pass to the caller
+ */
+static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum mtk_drm_crtc_path cpath,
+ const unsigned int **out_path,
+ unsigned int *out_path_len)
+{
+ struct device_node *next, *prev, *vdo = dev->parent->of_node;
+ unsigned int temp_path[DDP_COMPONENT_DRM_ID_MAX] = { 0 };
+ unsigned int *final_ddp_path;
+ unsigned short int idx = 0;
+ int ret;
+
+ /* Get the first entry for the temp_path array */
+ ret = mtk_drm_of_get_ddp_ep_cid(vdo, 0, cpath, &next, &temp_path[idx++]);
+ if (ret) {
+ if (next)
+ dev_err(dev, "Invalid component %pOF\n", next);
+ else
+ dev_err(dev, "Cannot find first endpoint for path %d\n", cpath);
+
+ return ret;
+ }
+
+ /*
+ * Walk through port outputs until we reach the last valid mediatek-drm component.
+ * To be valid, this must end with an "invalid" component that is a display node.
+ */
+ do {
+ prev = next;
+ ret = mtk_drm_of_get_ddp_ep_cid(next, 1, cpath, &next, &temp_path[idx]);
+ of_node_put(prev);
+ if (ret) {
+ of_node_put(next);
+ break;
+ }
+ } while (++idx < DDP_COMPONENT_DRM_ID_MAX);
+
+ /* If the last entry is not a final display output, the configuration is wrong */
+ switch (temp_path[idx - 1]) {
+ case DDP_COMPONENT_DP_INTF0:
+ case DDP_COMPONENT_DP_INTF1:
+ case DDP_COMPONENT_DPI0:
+ case DDP_COMPONENT_DPI1:
+ case DDP_COMPONENT_DSI0:
+ case DDP_COMPONENT_DSI1:
+ case DDP_COMPONENT_DSI2:
+ case DDP_COMPONENT_DSI3:
+ break;
+ default:
+ dev_err(dev, "Invalid display hw pipeline. Last component: %d (ret=%d)\n",
+ temp_path[idx - 1], ret);
+ return -EINVAL;
+ }
+
+ final_ddp_path = devm_kmemdup(dev, temp_path, idx * sizeof(temp_path[0]), GFP_KERNEL);
+ if (!final_ddp_path)
+ return -ENOMEM;
+
+ dev_dbg(dev, "Display HW Pipeline built with %d components.\n", idx);
+
+ /* Pipeline built! */
+ *out_path = final_ddp_path;
+ *out_path_len = idx;
+
+ return 0;
+}
+
+static int mtk_drm_of_ddp_path_build(struct device *dev, struct device_node *node,
+ struct mtk_mmsys_driver_data *data)
+{
+ struct device_node *ep_node;
+ struct of_endpoint of_ep;
+ bool output_present[MAX_CRTC] = { false };
+ int ret;
+
+ for_each_endpoint_of_node(node, ep_node) {
+ ret = of_graph_parse_endpoint(ep_node, &of_ep);
+ of_node_put(ep_node);
+ if (ret) {
+ dev_err_probe(dev, ret, "Cannot parse endpoint\n");
+ break;
+ }
+
+ if (of_ep.port >= MAX_CRTC) {
+ ret = dev_err_probe(dev, -EINVAL,
+ "Invalid endpoint%u number\n", of_ep.port);
+ break;
+ }
+
+ output_present[of_ep.port] = true;
+ }
+
+ if (ret)
+ return ret;
+
+ if (output_present[CRTC_MAIN]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_MAIN,
+ &data->main_path, &data->main_len);
+ if (ret)
+ return ret;
+ }
+
+ if (output_present[CRTC_EXT]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_EXT,
+ &data->ext_path, &data->ext_len);
+ if (ret)
+ return ret;
+ }
+
+ if (output_present[CRTC_THIRD]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_THIRD,
+ &data->third_path, &data->third_len);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *phandle = dev->parent->of_node;
const struct of_device_id *of_id;
struct mtk_drm_private *private;
+ struct mtk_mmsys_driver_data *mtk_drm_data;
struct device_node *node;
struct component_match *match = NULL;
struct platform_device *ovl_adaptor;
@@ -822,7 +1010,31 @@ static int mtk_drm_probe(struct platform_device *pdev)
if (!of_id)
return -ENODEV;
- private->data = of_id->data;
+ mtk_drm_data = (struct mtk_mmsys_driver_data *)of_id->data;
+ if (!mtk_drm_data)
+ return -EINVAL;
+
+ private->data = kmemdup(mtk_drm_data, sizeof(*mtk_drm_data), GFP_KERNEL);
+ if (!private->data)
+ return -ENOMEM;
+
+ /* Try to build the display pipeline from devicetree graphs */
+ if (of_graph_is_present(phandle)) {
+ dev_dbg(dev, "Building display pipeline for MMSYS %u\n",
+ mtk_drm_data->mmsys_id);
+ private->data = devm_kmemdup(dev, mtk_drm_data,
+ sizeof(*mtk_drm_data), GFP_KERNEL);
+ if (!private->data)
+ return -ENOMEM;
+
+ ret = mtk_drm_of_ddp_path_build(dev, phandle, private->data);
+ if (ret)
+ return ret;
+ } else {
+ /* No devicetree graphs support: go with hardcoded paths if present */
+ dev_dbg(dev, "Using hardcoded paths for MMSYS %u\n", mtk_drm_data->mmsys_id);
+ private->data = mtk_drm_data;
+ };
private->all_drm_private = devm_kmalloc_array(dev, private->data->mmsys_dev_num,
sizeof(*private->all_drm_private),
@@ -844,12 +1056,11 @@ static int mtk_drm_probe(struct platform_device *pdev)
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(phandle->parent, node) {
- const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
- of_id = of_match_node(mtk_ddp_comp_dt_ids, node);
- if (!of_id)
+ ret = mtk_drm_of_get_ddp_comp_type(node, &comp_type);
+ if (ret)
continue;
if (!of_device_is_available(node)) {
@@ -858,8 +1069,6 @@ static int mtk_drm_probe(struct platform_device *pdev)
continue;
}
- comp_type = (enum mtk_ddp_comp_type)(uintptr_t)of_id->data;
-
if (comp_type == MTK_DISP_MUTEX) {
int id;
@@ -888,22 +1097,24 @@ static int mtk_drm_probe(struct platform_device *pdev)
* blocks have separate component platform drivers and initialize their own
* DDP component structure. The others are initialized here.
*/
- if (comp_type == MTK_DISP_AAL ||
- comp_type == MTK_DISP_CCORR ||
- comp_type == MTK_DISP_COLOR ||
- comp_type == MTK_DISP_GAMMA ||
- comp_type == MTK_DISP_MERGE ||
- comp_type == MTK_DISP_OVL ||
- comp_type == MTK_DISP_OVL_2L ||
- comp_type == MTK_DISP_OVL_ADAPTOR ||
- comp_type == MTK_DISP_RDMA ||
- comp_type == MTK_DP_INTF ||
- comp_type == MTK_DPI ||
- comp_type == MTK_DSI) {
- dev_info(dev, "Adding component match for %pOF\n",
- node);
- drm_of_component_match_add(dev, &match, component_compare_of,
- node);
+ switch (comp_type) {
+ default:
+ break;
+ case MTK_DISP_AAL:
+ case MTK_DISP_CCORR:
+ case MTK_DISP_COLOR:
+ case MTK_DISP_GAMMA:
+ case MTK_DISP_MERGE:
+ case MTK_DISP_OVL:
+ case MTK_DISP_OVL_2L:
+ case MTK_DISP_OVL_ADAPTOR:
+ case MTK_DISP_RDMA:
+ case MTK_DP_INTF:
+ case MTK_DPI:
+ case MTK_DSI:
+ dev_info(dev, "Adding component match for %pOF\n", node);
+ drm_of_component_match_add(dev, &match, component_compare_of, node);
+ break;
}
ret = mtk_ddp_comp_init(node, &private->ddp_comp[comp_id], comp_id);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 33fadb08dc1c..9b2a7045e69d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -59,7 +59,7 @@ struct mtk_drm_private {
struct device *mmsys_dev;
struct device_node *comp_node[DDP_COMPONENT_DRM_ID_MAX];
struct mtk_ddp_comp ddp_comp[DDP_COMPONENT_DRM_ID_MAX];
- const struct mtk_mmsys_driver_data *data;
+ struct mtk_mmsys_driver_data *data;
struct drm_atomic_state *suspend_state;
unsigned int mbox_index;
struct mtk_drm_private **all_drm_private;
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 9501f4019199..1bdbe43e3888 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -903,9 +903,13 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dsi->next_bridge))
- return PTR_ERR(dsi->next_bridge);
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+ if (IS_ERR(dsi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
+ if (IS_ERR(dsi->next_bridge))
+ return PTR_ERR(dsi->next_bridge);
+ }
drm_bridge_add(&dsi->bridge);
--
2.44.0
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual display.
The final display pipeline is effectively board specific, as it does
depend on the display that is attached to it, and eventually on the
sensors supported by the board (for example, Adaptive Ambient Light
would need an Ambient Light Sensor, otherwise it's pointless!), other
than the output type.
Add support for OF graphs to most of the MediaTek DDP (display) bindings
to add flexibility to build custom hardware paths, hence enabling board
specific configuration of the display pipeline and allowing to finally
migrate away from using hardcoded paths.
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
---
.../display/mediatek/mediatek,aal.yaml | 40 +++++++++++++++++++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++++++++++
.../display/mediatek/mediatek,color.yaml | 22 ++++++++++
.../display/mediatek/mediatek,dither.yaml | 22 ++++++++++
.../display/mediatek/mediatek,dpi.yaml | 25 +++++++++++-
.../display/mediatek/mediatek,dsc.yaml | 24 +++++++++++
.../display/mediatek/mediatek,dsi.yaml | 27 ++++++++++++-
.../display/mediatek/mediatek,ethdr.yaml | 22 ++++++++++
.../display/mediatek/mediatek,gamma.yaml | 19 +++++++++
.../display/mediatek/mediatek,merge.yaml | 23 +++++++++++
.../display/mediatek/mediatek,od.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ovl.yaml | 22 ++++++++++
.../display/mediatek/mediatek,postmask.yaml | 21 ++++++++++
.../display/mediatek/mediatek,rdma.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++++++++++
16 files changed, 372 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index b4c28e96dd55..623cf7e37fe3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -61,6 +61,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: AAL input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ AAL output to the next component's input, for example could be one
+ of many gamma, overdrive or other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -88,5 +109,24 @@ examples:
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_AAL>;
mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal0_in: endpoint {
+ remote-endpoint = <&ccorr0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal0_out: endpoint {
+ remote-endpoint = <&gamma0_in>;
+ };
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 8c2a737237f2..71ea277a5d8e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -54,6 +54,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: CCORR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ CCORR output to the input of the next desired component in the
+ display pipeline, usually only one of the available AAL blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index b886ca0d89ea..61d040a10c08 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -64,6 +64,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: COLOR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ COLOR output to the input of the next desired component in the
+ display pipeline, for example one of the available CCORR or AAL
+ blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 1588b3f7cec7..3d4ab3f86294 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -55,6 +55,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DITHER input, usually from a POSTMASK or GAMMA block.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DITHER output to the input of the next desired component in the
+ display pipeline, for example one of the available DSC compressors,
+ DP_INTF, DSI, LVDS or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 803c00f26206..6607cb1c6e0a 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -64,13 +64,34 @@ properties:
Output port node. This port should be connected to the input port of an
attached HDMI, LVDS or DisplayPort encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI output to an HDMI, LVDS or DisplayPort encoder input
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
additionalProperties: false
@@ -79,7 +100,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/mt8173-clk.h>
- dpi0: dpi@1401d000 {
+ dpi: dpi@1401d000 {
compatible = "mediatek,mt8173-dpi";
reg = <0x1401d000 0x1000>;
interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
index 2cbdd9ee449d..846de6c17d93 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
@@ -49,6 +49,30 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression input, usually from one of the DITHER
+ or MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression output to the input of the next desired
+ component in the display pipeline, for example to MERGE, DP_INTF,
+ DPI or DSI.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index 8611319bed2e..2e9d3d23cbc1 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -76,6 +76,26 @@ properties:
Output port node. This port should be connected to the input
port of an attached DSI panel or DSI-to-eDP encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input ports can have multiple endpoints, each of those connects
+ to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DSI input port, usually from DITHER, DSC or MERGE
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DSI output to an attached DSI panel, or a DSI-to-X encoder chip
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -85,7 +105,12 @@ required:
- clock-names
- phys
- phy-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
index 677882348ede..98db47894eeb 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
@@ -110,6 +110,28 @@ properties:
include/dt-bindings/gce/<chip>-gce.h, mapping to the register of display
function block.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: ETHDR input, usually from one of the MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ ETHDR output to the input of the next desired component in the
+ display pipeline, for example one of the available MERGE blocks,
+ or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index c6641acd75d6..e24287ec364e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -59,6 +59,25 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GAMMA input, usually from one of the AAL blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ GAMMA output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER or
+ POSTMASK blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index dae839279950..0de9f64f3f84 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -77,6 +77,29 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE input port, usually from DITHER, DPI, DSC, DSI, MDP_RDMA,
+ ETHDR or even from a different MERGE block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE output to a DSC, DPI, DP_INTF, DSI, ETHDR, Write DMA, or
+ a different MERGE block, or others.
+
+ required:
+ - port@0
+ - port@1
+
resets:
description: reset controller
See Documentation/devicetree/bindings/reset/reset.txt for details.
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
index 831c653caffd..71534febd49c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
@@ -38,6 +38,28 @@ properties:
items:
- description: OD Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OD input port, usually from an AAL block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OD output to the input of the next desired component in the
+ display pipeline, for example one of the available RDMA or
+ other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
index c7dd0ef02dcf..bacdfe7d08a6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
@@ -57,6 +57,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS, VDOSYS or other OVLs
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index c471a181d125..e93f0247bdcc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -74,6 +74,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS or one of multiple VDOSYS
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
index 11fe32e50a59..fb6fe4742624 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
@@ -52,6 +52,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: POSTMASK input port, usually from GAMMA
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ POSTMASK output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 39dbb5c8bcf8..edb8d3b67025 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -86,6 +86,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: RDMA input port, usually from MMSYS, OD or OVL
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ RDMA output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, DPI,
+ DSI, MERGE or UFOE blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
index 39e3e2d4a0db..61a5e22effbf 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
@@ -43,6 +43,27 @@ properties:
items:
- description: UFOe Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: UFOE input, usually from one of the RDMA blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ UFOE output to the input of the next desired component in the
+ display pipeline, usually one of the available DSI blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
--
2.44.0
On Tue, 9 Apr 2024 at 18:41, AngeloGioacchino Del Regno
<[email protected]> wrote:
>
> Il 09/04/24 17:20, Dmitry Baryshkov ha scritto:
> > On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> >> The display IPs in MediaTek SoCs support being interconnected with
> >> different instances of DDP IPs (for example, merge0 or merge1) and/or
> >> with different DDP IPs (for example, rdma can be connected with either
> >> color, dpi, dsi, merge, etc), forming a full Display Data Path that
> >> ends with an actual display.
> >>
> >> The final display pipeline is effectively board specific, as it does
> >> depend on the display that is attached to it, and eventually on the
> >> sensors supported by the board (for example, Adaptive Ambient Light
> >> would need an Ambient Light Sensor, otherwise it's pointless!), other
> >> than the output type.
> >
> > With the color and gamma being in play, should the configuration be
> > board-driver or rather use-case driven with the driver being able to
> > reroute some of the blocks at runtime?
> >
>
> The driver can already set some blocks to "BYPASS MODE" at runtime, meaning
> that those will work as simple pass-through, performing *no* processing at
> all, so that's addressed from the very beginning.
>
> This doesn't mean that a specific pipeline must always support the "DISP_GAMMA"
> or the "DISP_CCOLOR" block(s) alone, or together, or in combination with another
> specific block.
I was thinking about slightly different case: do you have enough
colour blocks to drive all outputs or do you have to select them for
the particular output only?
(excuse me, I didn't check the platform details).
> For any other question, clarification, etc, I'm here :-)
>
> Cheers!
>
> >>
> >> Add support for OF graphs to most of the MediaTek DDP (display) bindings
> >> to add flexibility to build custom hardware paths, hence enabling board
> >> specific configuration of the display pipeline and allowing to finally
> >> migrate away from using hardcoded paths.
> >>
> >> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
> >
>
--
With best wishes
Dmitry
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color, dpi, dsi, merge, etc), forming a full Display Data Path that
> ends with an actual display.
>
> The final display pipeline is effectively board specific, as it does
> depend on the display that is attached to it, and eventually on the
> sensors supported by the board (for example, Adaptive Ambient Light
> would need an Ambient Light Sensor, otherwise it's pointless!), other
> than the output type.
With the color and gamma being in play, should the configuration be
board-driver or rather use-case driven with the driver being able to
reroute some of the blocks at runtime?
>
> Add support for OF graphs to most of the MediaTek DDP (display) bindings
> to add flexibility to build custom hardware paths, hence enabling board
> specific configuration of the display pipeline and allowing to finally
> migrate away from using hardcoded paths.
>
> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
--
With best wishes
Dmitry
Il 09/04/24 17:20, Dmitry Baryshkov ha scritto:
> On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
>> The display IPs in MediaTek SoCs support being interconnected with
>> different instances of DDP IPs (for example, merge0 or merge1) and/or
>> with different DDP IPs (for example, rdma can be connected with either
>> color, dpi, dsi, merge, etc), forming a full Display Data Path that
>> ends with an actual display.
>>
>> The final display pipeline is effectively board specific, as it does
>> depend on the display that is attached to it, and eventually on the
>> sensors supported by the board (for example, Adaptive Ambient Light
>> would need an Ambient Light Sensor, otherwise it's pointless!), other
>> than the output type.
>
> With the color and gamma being in play, should the configuration be
> board-driver or rather use-case driven with the driver being able to
> reroute some of the blocks at runtime?
>
The driver can already set some blocks to "BYPASS MODE" at runtime, meaning
that those will work as simple pass-through, performing *no* processing at
all, so that's addressed from the very beginning.
This doesn't mean that a specific pipeline must always support the "DISP_GAMMA"
or the "DISP_CCOLOR" block(s) alone, or together, or in combination with another
specific block.
For any other question, clarification, etc, I'm here :-)
Cheers!
>>
>> Add support for OF graphs to most of the MediaTek DDP (display) bindings
>> to add flexibility to build custom hardware paths, hence enabling board
>> specific configuration of the display pipeline and allowing to finally
>> migrate away from using hardcoded paths.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
>
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color, dpi, dsi, merge, etc), forming a full Display Data Path that
> ends with an actual display.
>
> The final display pipeline is effectively board specific, as it does
> depend on the display that is attached to it, and eventually on the
> sensors supported by the board (for example, Adaptive Ambient Light
> would need an Ambient Light Sensor, otherwise it's pointless!), other
> than the output type.
>
> Add support for OF graphs to most of the MediaTek DDP (display) bindings
> to add flexibility to build custom hardware paths, hence enabling board
> specific configuration of the display pipeline and allowing to finally
> migrate away from using hardcoded paths.
>
> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
> ---
> .../display/mediatek/mediatek,aal.yaml | 40 +++++++++++++++++++
> .../display/mediatek/mediatek,ccorr.yaml | 21 ++++++++++
> .../display/mediatek/mediatek,color.yaml | 22 ++++++++++
> .../display/mediatek/mediatek,dither.yaml | 22 ++++++++++
> .../display/mediatek/mediatek,dpi.yaml | 25 +++++++++++-
> .../display/mediatek/mediatek,dsc.yaml | 24 +++++++++++
> .../display/mediatek/mediatek,dsi.yaml | 27 ++++++++++++-
> .../display/mediatek/mediatek,ethdr.yaml | 22 ++++++++++
> .../display/mediatek/mediatek,gamma.yaml | 19 +++++++++
> .../display/mediatek/mediatek,merge.yaml | 23 +++++++++++
> .../display/mediatek/mediatek,od.yaml | 22 ++++++++++
> .../display/mediatek/mediatek,ovl-2l.yaml | 22 ++++++++++
> .../display/mediatek/mediatek,ovl.yaml | 22 ++++++++++
> .../display/mediatek/mediatek,postmask.yaml | 21 ++++++++++
> .../display/mediatek/mediatek,rdma.yaml | 22 ++++++++++
> .../display/mediatek/mediatek,ufoe.yaml | 21 ++++++++++
> 16 files changed, 372 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index b4c28e96dd55..623cf7e37fe3 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -61,6 +61,27 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> + description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: AAL input port
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + AAL output to the next component's input, for example could be one
> + of many gamma, overdrive or other blocks.
> +
> + required:
> + - port@0
> + - port@1
> +
> required:
> - compatible
> - reg
> @@ -88,5 +109,24 @@ examples:
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> clocks = <&mmsys CLK_MM_DISP_AAL>;
> mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + aal0_in: endpoint {
> + remote-endpoint = <&ccorr0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + aal0_out: endpoint {
> + remote-endpoint = <&gamma0_in>;
> + };
> + };
> + };
> };
> };
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index 8c2a737237f2..71ea277a5d8e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -54,6 +54,27 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> + description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: CCORR input port
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + CCORR output to the input of the next desired component in the
> + display pipeline, usually only one of the available AAL blocks.
> +
> + required:
> + - port@0
> + - port@1
> +
> required:
> - compatible
> - reg
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> index b886ca0d89ea..61d040a10c08 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> @@ -64,6 +64,28 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> + description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: COLOR input port
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + COLOR output to the input of the next desired component in the
> + display pipeline, for example one of the available CCORR or AAL
> + blocks.
> +
> + required:
> + - port@0
> + - port@1
> +
> required:
> - compatible
> - reg
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> index 1588b3f7cec7..3d4ab3f86294 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> @@ -55,6 +55,28 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> + description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: DITHER input, usually from a POSTMASK or GAMMA block.
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + DITHER output to the input of the next desired component in the
> + display pipeline, for example one of the available DSC compressors,
> + DP_INTF, DSI, LVDS or others.
> +
> + required:
> + - port@0
> + - port@1
> +
> required:
> - compatible
> - reg
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> index 803c00f26206..6607cb1c6e0a 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> @@ -64,13 +64,34 @@ properties:
> Output port node. This port should be connected to the input port of an
> attached HDMI, LVDS or DisplayPort encoder chip.
>
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: DPI input port
Strictly speaking, 'port' is equivalent to 'port@0', so it is already
defined to be the output path. It is a little odd for the input to be
port@1, but that is why we define the numbering.
Same comment applies to DSI.
Rob
On Tue, Apr 09, 2024 at 02:02:10PM +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 <[email protected]>
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> index b3c6888c1457..4e9acd966aa5 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> @@ -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.
I'm have a hard time understanding this, but is it 3 outputs
simultaneously or connect mmsys to 1 of 3. Generally it's multiple ports
for the former and endpoints for the latter.
> + 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
> +
> required:
> - compatible
> - reg
> --
> 2.44.0
>
Il 09/04/24 17:45, Dmitry Baryshkov ha scritto:
> On Tue, 9 Apr 2024 at 18:41, AngeloGioacchino Del Regno
> <[email protected]> wrote:
>>
>> Il 09/04/24 17:20, Dmitry Baryshkov ha scritto:
>>> On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
>>>> The display IPs in MediaTek SoCs support being interconnected with
>>>> different instances of DDP IPs (for example, merge0 or merge1) and/or
>>>> with different DDP IPs (for example, rdma can be connected with either
>>>> color, dpi, dsi, merge, etc), forming a full Display Data Path that
>>>> ends with an actual display.
>>>>
>>>> The final display pipeline is effectively board specific, as it does
>>>> depend on the display that is attached to it, and eventually on the
>>>> sensors supported by the board (for example, Adaptive Ambient Light
>>>> would need an Ambient Light Sensor, otherwise it's pointless!), other
>>>> than the output type.
>>>
>>> With the color and gamma being in play, should the configuration be
>>> board-driver or rather use-case driven with the driver being able to
>>> reroute some of the blocks at runtime?
>>>
>>
>> The driver can already set some blocks to "BYPASS MODE" at runtime, meaning
>> that those will work as simple pass-through, performing *no* processing at
>> all, so that's addressed from the very beginning.
>>
>> This doesn't mean that a specific pipeline must always support the "DISP_GAMMA"
>> or the "DISP_CCOLOR" block(s) alone, or together, or in combination with another
>> specific block.
>
> I was thinking about slightly different case: do you have enough
> colour blocks to drive all outputs or do you have to select them for
> the particular output only?
Sorry for the very very very very .. very late reply, your email slipped through
the cracks and I just noticed it.
That depends on the SoC, but generally... no, you have to select them for the
particular output.
There is a restricted set of outputs that support this block, but between this
set, there are still not enough blocks for all of them.
>
> (excuse me, I didn't check the platform details).
You (and me, and everyone else) can't really invest hours of time to check on
how each and every SoC on the planet works - that's normal.
No worries ;-)
Cheers,
Angelo
>
>> For any other question, clarification, etc, I'm here :-)
>>
>> Cheers!
>>
>>>>
>>>> Add support for OF graphs to most of the MediaTek DDP (display) bindings
>>>> to add flexibility to build custom hardware paths, hence enabling board
>>>> specific configuration of the display pipeline and allowing to finally
>>>> migrate away from using hardcoded paths.
>>>>
>>>> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
>>>
>>
>
>
Il 10/04/24 21:03, Rob Herring ha scritto:
> On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
>> The display IPs in MediaTek SoCs support being interconnected with
>> different instances of DDP IPs (for example, merge0 or merge1) and/or
>> with different DDP IPs (for example, rdma can be connected with either
>> color, dpi, dsi, merge, etc), forming a full Display Data Path that
>> ends with an actual display.
>>
>> The final display pipeline is effectively board specific, as it does
>> depend on the display that is attached to it, and eventually on the
>> sensors supported by the board (for example, Adaptive Ambient Light
>> would need an Ambient Light Sensor, otherwise it's pointless!), other
>> than the output type.
>>
>> Add support for OF graphs to most of the MediaTek DDP (display) bindings
>> to add flexibility to build custom hardware paths, hence enabling board
>> specific configuration of the display pipeline and allowing to finally
>> migrate away from using hardcoded paths.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
>> ---
>> .../display/mediatek/mediatek,aal.yaml | 40 +++++++++++++++++++
>> .../display/mediatek/mediatek,ccorr.yaml | 21 ++++++++++
>> .../display/mediatek/mediatek,color.yaml | 22 ++++++++++
>> .../display/mediatek/mediatek,dither.yaml | 22 ++++++++++
>> .../display/mediatek/mediatek,dpi.yaml | 25 +++++++++++-
>> .../display/mediatek/mediatek,dsc.yaml | 24 +++++++++++
>> .../display/mediatek/mediatek,dsi.yaml | 27 ++++++++++++-
>> .../display/mediatek/mediatek,ethdr.yaml | 22 ++++++++++
>> .../display/mediatek/mediatek,gamma.yaml | 19 +++++++++
>> .../display/mediatek/mediatek,merge.yaml | 23 +++++++++++
>> .../display/mediatek/mediatek,od.yaml | 22 ++++++++++
>> .../display/mediatek/mediatek,ovl-2l.yaml | 22 ++++++++++
>> .../display/mediatek/mediatek,ovl.yaml | 22 ++++++++++
>> .../display/mediatek/mediatek,postmask.yaml | 21 ++++++++++
>> .../display/mediatek/mediatek,rdma.yaml | 22 ++++++++++
>> .../display/mediatek/mediatek,ufoe.yaml | 21 ++++++++++
>> 16 files changed, 372 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
>> index b4c28e96dd55..623cf7e37fe3 100644
>> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
>> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
>> @@ -61,6 +61,27 @@ properties:
>> $ref: /schemas/types.yaml#/definitions/phandle-array
>> maxItems: 1
>>
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> + description:
>> + Input and output ports can have multiple endpoints, each of those
>> + connects to either the primary, secondary, etc, display pipeline.
>> +
>> + properties:
>> + port@0:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description: AAL input port
>> +
>> + port@1:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description:
>> + AAL output to the next component's input, for example could be one
>> + of many gamma, overdrive or other blocks.
>> +
>> + required:
>> + - port@0
>> + - port@1
>> +
>> required:
>> - compatible
>> - reg
>> @@ -88,5 +109,24 @@ examples:
>> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
>> clocks = <&mmsys CLK_MM_DISP_AAL>;
>> mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + aal0_in: endpoint {
>> + remote-endpoint = <&ccorr0_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + aal0_out: endpoint {
>> + remote-endpoint = <&gamma0_in>;
>> + };
>> + };
>> + };
>> };
>> };
>> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
>> index 8c2a737237f2..71ea277a5d8e 100644
>> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
>> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
>> @@ -54,6 +54,27 @@ properties:
>> $ref: /schemas/types.yaml#/definitions/phandle-array
>> maxItems: 1
>>
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> + description:
>> + Input and output ports can have multiple endpoints, each of those
>> + connects to either the primary, secondary, etc, display pipeline.
>> +
>> + properties:
>> + port@0:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description: CCORR input port
>> +
>> + port@1:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description:
>> + CCORR output to the input of the next desired component in the
>> + display pipeline, usually only one of the available AAL blocks.
>> +
>> + required:
>> + - port@0
>> + - port@1
>> +
>> required:
>> - compatible
>> - reg
>> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
>> index b886ca0d89ea..61d040a10c08 100644
>> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
>> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
>> @@ -64,6 +64,28 @@ properties:
>> $ref: /schemas/types.yaml#/definitions/phandle-array
>> maxItems: 1
>>
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> + description:
>> + Input and output ports can have multiple endpoints, each of those
>> + connects to either the primary, secondary, etc, display pipeline.
>> +
>> + properties:
>> + port@0:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description: COLOR input port
>> +
>> + port@1:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description:
>> + COLOR output to the input of the next desired component in the
>> + display pipeline, for example one of the available CCORR or AAL
>> + blocks.
>> +
>> + required:
>> + - port@0
>> + - port@1
>> +
>> required:
>> - compatible
>> - reg
>> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
>> index 1588b3f7cec7..3d4ab3f86294 100644
>> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
>> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
>> @@ -55,6 +55,28 @@ properties:
>> $ref: /schemas/types.yaml#/definitions/phandle-array
>> maxItems: 1
>>
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> + description:
>> + Input and output ports can have multiple endpoints, each of those
>> + connects to either the primary, secondary, etc, display pipeline.
>> +
>> + properties:
>> + port@0:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description: DITHER input, usually from a POSTMASK or GAMMA block.
>> +
>> + port@1:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description:
>> + DITHER output to the input of the next desired component in the
>> + display pipeline, for example one of the available DSC compressors,
>> + DP_INTF, DSI, LVDS or others.
>> +
>> + required:
>> + - port@0
>> + - port@1
>> +
>> required:
>> - compatible
>> - reg
>> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
>> index 803c00f26206..6607cb1c6e0a 100644
>> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
>> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
>> @@ -64,13 +64,34 @@ properties:
>> Output port node. This port should be connected to the input port of an
>> attached HDMI, LVDS or DisplayPort encoder chip.
>>
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> +
>> + properties:
>> + port@0:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description: DPI input port
>
> Strictly speaking, 'port' is equivalent to 'port@0', so it is already
> defined to be the output path. It is a little odd for the input to be
> port@1, but that is why we define the numbering.
>
> Same comment applies to DSI.
>
> Rob
Sorry Rob, but I think I didn't understand your comment here.. because the
input is port@0, not port@1...
DPI/DSI/other components IN -> port@0
DPI/DSI/other components OUT -> port@1
Cheers,
Angelo
Il 10/04/24 21:15, Rob Herring ha scritto:
> On Tue, Apr 09, 2024 at 02:02:10PM +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 <[email protected]>
>> ---
>> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> index b3c6888c1457..4e9acd966aa5 100644
>> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> @@ -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.
>
> I'm have a hard time understanding this, but is it 3 outputs
> simultaneously or connect mmsys to 1 of 3. Generally it's multiple ports
> for the former and endpoints for the latter.
>
Yes I feel you, MediaTek SoCs are a bit strange, but I do have a reason to
use one port and multiple endpoints, instead of multiple ports and one endpoint.
On MediaTek SoCs, there are multiple ports: those multiple ports are represented
by multiple MMSYS or multiple VDOSYS (depending on the SoC), which do then have
multiple endpoints.
However, the multiple ports, at least for now, are represented by multiple MMSYS
and/or multiple VDOSYS nodes instead of one MM/VDO node with multiple iostart for
the multiple blocks in `reg`.
The multiple iostart "thing" was the initial design by MediaTek, but there was no
way to get them really connected the right way unless adding an iostart restriction
in the driver itself (so that the mmsys driver would check an iostart to probe the
mediatek-drm components for the right IP number), so, after quite many reviews and
many series versions, they had to resort to use multiple nodes for each VDO.
I think that, after this series, we could also clean that mess up (sorry for the
strong words) and make it right - assigning the MMIO for all VDOSYS blocks to one
node, and adding the multiple ports - however, that will require a bit of work that
is simply too much for this series alone.
Summarizing, so that you don't have to carefully proof-read all this wall of text:
- MediaTek SoCs have got multiple `port` for MMSYS and VDOSYS
- Currently the driver implementation doesn't allow that
- MediaTek had to work around no OF graph support!
- Multiple ports are the multiple MMSYS/VDOSYS
- One MMSYS / One VDOSYS have multiple `endpoints`
That's how the HW is.
Hope that's clear now?
Cheers,
Angelo
>> + 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
>> +
>> required:
>> - compatible
>> - reg
>> --
>> 2.44.0
>>
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 <
> [email protected]>
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23
> +++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> index b3c6888c1457..4e9acd966aa5 100644
> ---
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> +++
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> @@ -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?
Regards,
CK
> required:
> - compatible
> - reg
Hi Angelo,
On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:
> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
> NIO-12L with both hardcoded paths, OF graph support and partially
> hardcoded paths (meaning main display through OF graph and external
> display hardcoded, because of OVL_ADAPTOR).
Is that make sense for you to add the DTS changes of these boards into this serie ?
I asked because, IMHO, that could help to understand the serie.
--
Regards,
Alexandre
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 <
>> [email protected]>
>> ---
>> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23
>> +++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> index b3c6888c1457..4e9acd966aa5 100644
>> ---
>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> +++
>> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> @@ -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.
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.
Cheers,
Angelo
> Regards,
> CK
>
>
>> required:
>> - compatible
>> - reg
On 30/04/2024 13:33, AngeloGioacchino Del Regno wrote:
> Il 30/04/24 12:17, Alexandre Mergnat ha scritto:
>> Hi Angelo,
>>
>> On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:
>>> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
>>> NIO-12L with both hardcoded paths, OF graph support and partially
>>> hardcoded paths (meaning main display through OF graph and external
>>> display hardcoded, because of OVL_ADAPTOR).
>>
>> Is that make sense for you to add the DTS changes of these boards into this serie ?
>> I asked because, IMHO, that could help to understand the serie.
>>
>
> Yes and no... but I imagine that you're asking this because you're trying to
> prepare something with a different SoC+board(s) combination :-)
>
> In that case, I'm preventively sorry because what follows here is not 100%
> perfectly tidy yet as I didn't mean to send the devicetree commits upstream
> before this series got picked....
>
> ... but there you go - I'm sure that you won't mind and that the example will
> be more than good enough for you.
>
> Please note that one of the reasons why I didn't want to add this to the series
> is that the following changes show only a mere 50% of the reasons why we want OF
> graph support on mediatek-drm (but mainly, it's because I didn't have time to
> actually rebase etc :-P )
Thanks for the explanations and examples.
Unfortunately, I have 2 display but only one is working (the main: DSI0) when I use the dts method.
I've probably missed something but I don't know what.
In my "mmsys" node, if I swap display (the ext endpoint with the main endpoint), the DPI0 is
working, but not the DSI0. I conclude my both paths are good.
Then, I've put some trace into "mtk_drm_of_ddp_path_build" to check if it parse the two endpoint of
the node. Both are parsed, but "of_ep.port" is always = 0. According to "of_graph_parse_endpoint"
function, "port" is the value of the parent "reg", whereas "id" is the value of the endpoint "reg".
So I replaced "of_ep.port" by "of_ep.id". Now I've of_ep.id = 0 for main and of_ep.id = 1 for EXT.
Now I've the good CRTC path, I get this error:
mediatek-drm mediatek-drm.1.auto: Invalid display hw pipeline. Last component: 54 (ret=-2)
mediatek-drm mediatek-drm.1.auto: probe with driver mediatek-drm failed with error -22
After quick look, the "cpath" into "mtk_drm_of_ddp_path_build_one" (or deeper functions) seems not
be used as it should, due to the previous "of_ep.port" => "of_ep.id" change of course.
But I probably have to fix "of_ep.port" because I've mis-coded something. Just in case, I share you
my diff:
diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
index 1aa3426f561b..f660481d3fe8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
@@ -109,15 +109,51 @@ vsys_lcm_reg: regulator-vsys-lcm {
};
};
+&cpu0 {
+ proc-supply = <&mt6357_vproc_reg>;
+ sram-supply = <&mt6357_vsram_proc_reg>;
+};
+
+&cpu1 {
+ proc-supply = <&mt6357_vproc_reg>;
+ sram-supply = <&mt6357_vsram_proc_reg>;
+};
+
+&cpu2 {
+ proc-supply = <&mt6357_vproc_reg>;
+ sram-supply = <&mt6357_vsram_proc_reg>;
+};
+
+&cpu3 {
+ proc-supply = <&mt6357_vproc_reg>;
+ sram-supply = <&mt6357_vsram_proc_reg>;
+};
+
+&dither0_out {
+ remote-endpoint = <&dsi0_in>;
+};
+
&dpi0 {
pinctrl-0 = <&dpi_default_pins>;
pinctrl-1 = <&dpi_idle_pins>;
pinctrl-names = "default", "sleep";
status = "okay";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
- port {
- dpi_out: endpoint {
- remote-endpoint = <&it66121_in>;
+ port@0 {
+ reg = <0>;
+ dpi0_in: endpoint {
+ remote-endpoint = <&rdma1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpi0_out: endpoint {
+ remote-endpoint = <&it66121_in>;
+ };
};
};
};
@@ -137,36 +173,28 @@ panel@0 {
port {
panel_in: endpoint {
- remote-endpoint = <&dsi_out>;
+ remote-endpoint = <&dsi0_out>;
};
};
};
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
- port {
- dsi_out: endpoint {
- remote-endpoint = <&panel_in>;
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dither0_out>;
+ };
};
- };
-};
-&cpu0 {
- proc-supply = <&mt6357_vproc_reg>;
- sram-supply = <&mt6357_vsram_proc_reg>;
-};
-
-&cpu1 {
- proc-supply = <&mt6357_vproc_reg>;
- sram-supply = <&mt6357_vsram_proc_reg>;
-};
-
-&cpu2 {
- proc-supply = <&mt6357_vproc_reg>;
- sram-supply = <&mt6357_vsram_proc_reg>;
-};
-
-&cpu3 {
- proc-supply = <&mt6357_vproc_reg>;
- sram-supply = <&mt6357_vsram_proc_reg>;
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
};
ðernet {
@@ -229,7 +257,7 @@ port@0 {
reg = <0>;
it66121_in: endpoint {
bus-width = <12>;
- remote-endpoint = <&dpi_out>;
+ remote-endpoint = <&dpi0_out>;
};
};
@@ -557,6 +585,10 @@ &pwm {
status = "okay";
};
+&rdma1_out {
+ remote-endpoint = <&dpi0_in>;
+};
+
&ssusb {
dr_mode = "otg";
maximum-speed = "high-speed";
diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
index d34519a33c90..dbb559959a9d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
@@ -762,6 +762,19 @@ mmsys: syscon@14000000 {
compatible = "mediatek,mt8365-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
#clock-cells = <1>;
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mmsys_main: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&ovl0_in>;
+ };
+ mmsys_ext: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&rdma1_in>;
+ };
+ };
};
mutex: mutex@14001000 {
@@ -801,6 +814,24 @@ ovl0: ovl@1400b000 {
interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_LOW>;
iommus = <&iommu M4U_PORT_DISP_OVL0>;
power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ovl0_in: endpoint {
+ remote-endpoint = <&mmsys_main>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ ovl0_out: endpoint {
+ remote-endpoint = <&rdma0_in>;
+ };
+ };
+ };
};
rdma0: rdma@1400d000 {
@@ -811,6 +842,24 @@ rdma0: rdma@1400d000 {
iommus = <&iommu M4U_PORT_DISP_RDMA0>;
mediatek,rdma-fifo-size = <5120>;
power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ rdma0_in: endpoint {
+ remote-endpoint = <&ovl0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ rdma0_out: endpoint {
+ remote-endpoint = <&color0_in>;
+ };
+ };
+ };
};
color0: color@1400f000 {
@@ -819,6 +868,24 @@ color0: color@1400f000 {
clocks = <&mmsys CLK_MM_MM_DISP_COLOR0>;
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ color0_in: endpoint {
+ remote-endpoint = <&rdma0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ color0_out: endpoint {
+ remote-endpoint = <&ccorr0_in>;
+ };
+ };
+ };
};
ccorr0: ccorr@14010000 {
@@ -827,6 +894,24 @@ ccorr0: ccorr@14010000 {
clocks = <&mmsys CLK_MM_MM_DISP_CCORR0>;
interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ccorr0_in: endpoint {
+ remote-endpoint = <&color0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ ccorr0_out: endpoint {
+ remote-endpoint = <&aal0_in>;
+ };
+ };
+ };
};
aal0: aal@14011000 {
@@ -835,6 +920,24 @@ aal0: aal@14011000 {
clocks = <&mmsys CLK_MM_MM_DISP_AAL0>;
interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal0_in: endpoint {
+ remote-endpoint = <&ccorr0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal0_out: endpoint {
+ remote-endpoint = <&gamma0_in>;
+ };
+ };
+ };
};
gamma0: gamma@14012000 {
@@ -843,6 +946,24 @@ gamma0: gamma@14012000 {
clocks = <&mmsys CLK_MM_MM_DISP_GAMMA0>;
interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ gamma0_in: endpoint {
+ remote-endpoint = <&aal0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ gamma0_out: endpoint {
+ remote-endpoint = <&dither0_in>;
+ };
+ };
+ };
};
dither0: dither@14013000 {
@@ -851,6 +972,23 @@ dither0: dither@14013000 {
clocks = <&mmsys CLK_MM_MM_DISP_DITHER0>;
interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dither0_in: endpoint {
+ remote-endpoint = <&gamma0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dither0_out: endpoint {
+ };
+ };
+ };
};
dsi0: dsi@14014000 {
@@ -874,6 +1012,23 @@ rdma1: rdma@14016000 {
iommus = <&iommu M4U_PORT_DISP_RDMA1>;
mediatek,rdma-fifo-size = <2048>;
power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ rdma1_in: endpoint {
+ remote-endpoint = <&mmsys_ext>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ rdma1_out: endpoint {
+ };
+ };
+ };
};
dpi0: dpi@14018000 {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index dacf4eaa3457..5992b7865310 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -230,22 +230,6 @@ static const unsigned int mt8195_mtk_ddp_ext[] = {
DDP_COMPONENT_DP_INTF1,
};
-static const unsigned int mt8365_mtk_ddp_main[] = {
- DDP_COMPONENT_OVL0,
- DDP_COMPONENT_RDMA0,
- DDP_COMPONENT_COLOR0,
- DDP_COMPONENT_CCORR,
- DDP_COMPONENT_AAL0,
- DDP_COMPONENT_GAMMA,
- DDP_COMPONENT_DITHER0,
- DDP_COMPONENT_DSI0,
-};
-
-static const unsigned int mt8365_mtk_ddp_ext[] = {
- DDP_COMPONENT_RDMA1,
- DDP_COMPONENT_DPI0,
-};
-
static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.main_path = mt2701_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
@@ -334,10 +318,6 @@ static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
};
static const struct mtk_mmsys_driver_data mt8365_mmsys_driver_data = {
- .main_path = mt8365_mtk_ddp_main,
- .main_len = ARRAY_SIZE(mt8365_mtk_ddp_main),
- .ext_path = mt8365_mtk_ddp_ext,
- .ext_len = ARRAY_SIZE(mt8365_mtk_ddp_ext),
.mmsys_dev_num = 1,
};
--
Regards,
Alexandre
Hi Angelo,
On Tue Apr 9, 2024 at 2:02 PM CEST, AngeloGioacchino Del Regno wrote:
> +static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
> + int output_port, enum mtk_drm_crtc_path crtc_path,
Not sure what's your base branch is, but "enum mtk_drm_crtc_path"
was renamed to "enum mtk_crtc_path" in commit 9e149879038f5
('drm/mediatek: Rename "mtk_drm_crtc" to "mtk_crtc"').
> +/**
> + * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC Path
> + * @dev: The mediatek-drm device
> + * @cpath: CRTC Path relative to a VDO or MMSYS
> + * @out_path: Pointer to an array that will contain the new pipeline
> + * @out_path_len: Number of entries in the pipeline array
> + *
> + * MediaTek SoCs can use different DDP hardware pipelines (or paths) depending
> + * on the board-specific desired display configuration; this function walks
> + * through all of the output endpoints starting from a VDO or MMSYS hardware
> + * instance and builds the right pipeline as specified in device trees.
> + *
> + * Return:
> + * * %0 - Display HW Pipeline successfully built and validated
> + * * %-ENOENT - Display pipeline was not specified in device tree
> + * * %-EINVAL - Display pipeline built but validation failed
> + * * %-ENOMEM - Failure to allocate pipeline array to pass to the caller
> + */
> +static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum mtk_drm_crtc_path cpath,
likewise
> + const unsigned int **out_path,
> + unsigned int *out_path_len)
-michael
Hi Angelo,
On Tue Apr 30, 2024 at 1:33 PM CEST, AngeloGioacchino Del Regno wrote:
> >> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
> >> NIO-12L with both hardcoded paths, OF graph support and partially
> >> hardcoded paths (meaning main display through OF graph and external
> >> display hardcoded, because of OVL_ADAPTOR).
> >
> > Is that make sense for you to add the DTS changes of these boards into this serie ?
> > I asked because, IMHO, that could help to understand the serie.
> >
>
> Yes and no... but I imagine that you're asking this because you're trying to
> prepare something with a different SoC+board(s) combination :-)
>
> In that case, I'm preventively sorry because what follows here is not 100%
> perfectly tidy yet as I didn't mean to send the devicetree commits upstream
> before this series got picked....
>
> ... but there you go - I'm sure that you won't mind and that the example will
> be more than good enough for you.
I've tested this series with the DSI0 output and it works. Nice! No
need for my DSI0 patch for the MT8395 anymore.
But I can't get it to work with the DisplayPort output, that is the
dp_intf1/dp_tx interface. I don' know how the pipeline have to look
like. The functional spec seems to be ambiguous on this. The text
seem to refer to the second vdosys but there is also a diagram where
you can use the first vdosys and dsc0. If you have any pointers for
me, I'm all ears :)
-michael
Il 06/05/24 12:02, Michael Walle ha scritto:
> Hi Angelo,
>
> On Tue Apr 30, 2024 at 1:33 PM CEST, AngeloGioacchino Del Regno wrote:
>>>> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
>>>> NIO-12L with both hardcoded paths, OF graph support and partially
>>>> hardcoded paths (meaning main display through OF graph and external
>>>> display hardcoded, because of OVL_ADAPTOR).
>>>
>>> Is that make sense for you to add the DTS changes of these boards into this serie ?
>>> I asked because, IMHO, that could help to understand the serie.
>>>
>>
>> Yes and no... but I imagine that you're asking this because you're trying to
>> prepare something with a different SoC+board(s) combination :-)
>>
>> In that case, I'm preventively sorry because what follows here is not 100%
>> perfectly tidy yet as I didn't mean to send the devicetree commits upstream
>> before this series got picked....
>>
>> ... but there you go - I'm sure that you won't mind and that the example will
>> be more than good enough for you.
>
> I've tested this series with the DSI0 output and it works. Nice! No
> need for my DSI0 patch for the MT8395 anymore.
>
> But I can't get it to work with the DisplayPort output, that is the
> dp_intf1/dp_tx interface. I don' know how the pipeline have to look
> like. The functional spec seems to be ambiguous on this. The text
> seem to refer to the second vdosys but there is also a diagram where
> you can use the first vdosys and dsc0. If you have any pointers for
> me, I'm all ears :)
>
The problem with this is that you need DDP_COMPONENT_DRM_OVL_ADAPTOR... which is
a software thing and not HW, so that can't be described in devicetree.
The only thing this series won't deal with is exactly that.
It's relatively easy, though, to add support for the OVL_ADAPTOR... as it would
be just a matter of checking if any of the components in the pipeline contain a
compatible that is in the OVL_ADAPTOR compatible list.
I'll try to add that up today, let's see what I can do.
Cheers,
Angelo
Il 06/05/24 12:56, AngeloGioacchino Del Regno ha scritto:
> Il 06/05/24 12:02, Michael Walle ha scritto:
>> Hi Angelo,
>>
>> On Tue Apr 30, 2024 at 1:33 PM CEST, AngeloGioacchino Del Regno wrote:
>>>>> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
>>>>> NIO-12L with both hardcoded paths, OF graph support and partially
>>>>> hardcoded paths (meaning main display through OF graph and external
>>>>> display hardcoded, because of OVL_ADAPTOR).
>>>>
>>>> Is that make sense for you to add the DTS changes of these boards into this
>>>> serie ?
>>>> I asked because, IMHO, that could help to understand the serie.
>>>>
>>>
>>> Yes and no... but I imagine that you're asking this because you're trying to
>>> prepare something with a different SoC+board(s) combination :-)
>>>
>>> In that case, I'm preventively sorry because what follows here is not 100%
>>> perfectly tidy yet as I didn't mean to send the devicetree commits upstream
>>> before this series got picked....
>>>
>>> ... but there you go - I'm sure that you won't mind and that the example will
>>> be more than good enough for you.
>>
>> I've tested this series with the DSI0 output and it works. Nice! No
>> need for my DSI0 patch for the MT8395 anymore.
>>
>> But I can't get it to work with the DisplayPort output, that is the
>> dp_intf1/dp_tx interface. I don' know how the pipeline have to look
>> like. The functional spec seems to be ambiguous on this. The text
>> seem to refer to the second vdosys but there is also a diagram where
>> you can use the first vdosys and dsc0. If you have any pointers for
>> me, I'm all ears :)
>>
>
>
> The problem with this is that you need DDP_COMPONENT_DRM_OVL_ADAPTOR... which is
> a software thing and not HW, so that can't be described in devicetree.
>
> The only thing this series won't deal with is exactly that.
Sorry, no, I got confused.
The series *does* already deal with that, as the pipeline is built before the check
for OVL_ADAPTOR components, so that will get probed.
What I got confused about is the fact that I promised myself to cleanup the support
for that OVL_ADAPTOR thing (which is unrelated to this series, even...), but again,
this series will still get that probed anyway.
Anyway.
The pipeline for DP1 should be simply
VDOSYS 1 -> MERGE 5 -> DP_INTF 1 -> DP
(eDP on VDOSYS 0 -> MERGE 0 --- DP on VDOSYS 1 -> MERGE 5)
Cheers,
Angelo
>
> It's relatively easy, though, to add support for the OVL_ADAPTOR... as it would
> be just a matter of checking if any of the components in the pipeline contain a
> compatible that is in the OVL_ADAPTOR compatible list.
>
> I'll try to add that up today, let's see what I can do.
>
Il 06/05/24 11:11, Michael Walle ha scritto:
> Hi Angelo,
>
> On Tue Apr 9, 2024 at 2:02 PM CEST, AngeloGioacchino Del Regno wrote:
>> +static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
>> + int output_port, enum mtk_drm_crtc_path crtc_path,
>
> Not sure what's your base branch is, but "enum mtk_drm_crtc_path"
> was renamed to "enum mtk_crtc_path" in commit 9e149879038f5
> ('drm/mediatek: Rename "mtk_drm_crtc" to "mtk_crtc"').
>
>> +/**
>> + * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC Path
>> + * @dev: The mediatek-drm device
>> + * @cpath: CRTC Path relative to a VDO or MMSYS
>> + * @out_path: Pointer to an array that will contain the new pipeline
>> + * @out_path_len: Number of entries in the pipeline array
>> + *
>> + * MediaTek SoCs can use different DDP hardware pipelines (or paths) depending
>> + * on the board-specific desired display configuration; this function walks
>> + * through all of the output endpoints starting from a VDO or MMSYS hardware
>> + * instance and builds the right pipeline as specified in device trees.
>> + *
>> + * Return:
>> + * * %0 - Display HW Pipeline successfully built and validated
>> + * * %-ENOENT - Display pipeline was not specified in device tree
>> + * * %-EINVAL - Display pipeline built but validation failed
>> + * * %-ENOMEM - Failure to allocate pipeline array to pass to the caller
>> + */
>> +static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum mtk_drm_crtc_path cpath,
>
> likewise
>
>> + const unsigned int **out_path,
>> + unsigned int *out_path_len)
>
> -michael
Yeah, thanks for noticing that, I'll send a new version soon.
Cheers
Hi Angelo,
On Mon May 6, 2024 at 1:22 PM CEST, AngeloGioacchino Del Regno wrote:
> > The problem with this is that you need DDP_COMPONENT_DRM_OVL_ADAPTOR... which is
> > a software thing and not HW, so that can't be described in devicetree.
> >
> > The only thing this series won't deal with is exactly that.
>
> Sorry, no, I got confused.
>
> The series *does* already deal with that, as the pipeline is built before the check
> for OVL_ADAPTOR components, so that will get probed.
Are you sure? Because who is actually adding the OVL_ADAPTOR to the
path? It looks like your patch will walk the graph and add all the
components according to their compatible string. And since the
OVL_ADAPTOR is virtual and doesn't have a node..
-michael
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 <
> > > [email protected]>
> > > ---
> > > .../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,
...>;
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?
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
>
>
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 <
> > > > > [email protected]>
> > > > > ---
> > > > > .../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? 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'.
I don't know how to decide which device could point to mmsys/vdosys. So
please give a specific definition.
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
> > >
> > >
>
>
>
On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno wrote:
> 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 <
> > > > > > > [email protected]>
> > > > > > > ---
> > > > > > > .../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 one board, both OVL and RDMA could switch dynamically. Because each
one could be the first in one board, mmsys point to both ovl and rdma?
Regards,
CK
>
>
>
>
> 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
> > > > >
> > > > >
> > >
> > >
> > >
>
>
On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno wrote:
> Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto:
> > On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno
> > wrote:
> > > 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 <
> > > > > > > > > [email protected]>
> > > > > > > > > ---
> > > > > > > > > .../bindings/arm/mediatek/mediatek,mmsys.yaml |
> > > > > > > > > 23
> > > > > > > > > +++++++++++++++++++
> > > > > > > > > 1 file changed, 23 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/Documentation/devicetree/bindings/arm/mediatek/medi
> > > > > > > > > atek
> > > > > > > > > ,mms
> > > > > > > > > ys.y
> > > > > > > > > aml
> > > > > > > > > b/Documentation/devicetree/bindings/arm/mediatek/medi
> > > > > > > > > atek
> > > > > > > > > ,mms
> > > > > > > > > ys.y
> > > > > > > > > aml
> > > > > > > > > index b3c6888c1457..4e9acd966aa5 100644
> > > > > > > > > ---
> > > > > > > > > a/Documentation/devicetree/bindings/arm/mediatek/medi
> > > > > > > > > atek
> > > > > > > > > ,mms
> > > > > > > > > ys.y
> > > > > > > > > aml
> > > > > > > > > +++
> > > > > > > > > b/Documentation/devicetree/bindings/arm/mediatek/medi
> > > > > > > > > atek
> > > > > > > > > ,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 one board, both OVL and RDMA could switch dynamically. Because
> > each
> > one could be the first in one board, mmsys point to both ovl and
> > rdma?
> >
>
> No.
>
> MMSYS would still point ONLY to OVL, because OVL is the "earliest
> point"
> of the pipeline that this one board does support.
>
> In that case, RDMA being present at a later point in the pipeline
> does not
> matter and does not prevent us from *temporarily* skipping OVL-COLOR-
> AAL-OD
> and going MMSYS->RDMA *directly*.
>
> Switching dynamically is a driver duty and will be 100% possible (as
> much
> as it is right now) to dynamically switch OVL and RDMA as long as
> both are
> present in the pipeline.
>
> With this exact pipeline:
>
> MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
>
> the driver _can switch dynamically_ between MMSYS->OVL->...->RDMA and
> MMSYS->RDMA as the driver itself *is allowed to* temporarily ignore
> part
> of the pipeline.
>
> Please note that, in case it is needed (trust me on this: it's not
> needed)
> a custom property in the endpoint node can always be introduced
> later, so
> that you can declare a node like
>
> endpoint@0 {
> remote-endpoint = <&ovl0_in>;
> mediatek,short-path = <&rdma0_in>;
> };
>
> ...but again, that's never going to be needed, as the driver already
> does
> have knowledge of the fact that RDMA is in the pipeline, so it is
> possible
> to simply do a temporary override in the driver.
>
> What the OF Graph support does is to build the same arrays, that we
> currently
> have hardcoded in mediatek-drm, by reading from device tree.
>
> Nothing else and nothing more - for now.
>
> Having the OF Graph support makes us able to also add new dual-path
> support
> with more complicated connections than the current ones, without any
> problem
> and, in many cases, without even modifying the bindings from what I
> provided
> in this series.
OK, please add the information we discussed into binding document to
prevent anyone misusing this binding.
Regards,
CK
>
> Cheers,
> Angelo
>
> > Regards,
> > CK
> >
> > >
> > >
> > >
> > >
> > > 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
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>
>
Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto:
> On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno wrote:
>> Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto:
>>> On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno
>>> wrote:
>>>> 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 <
>>>>>>>>>> [email protected]>
>>>>>>>>>> ---
>>>>>>>>>> .../bindings/arm/mediatek/mediatek,mmsys.yaml |
>>>>>>>>>> 23
>>>>>>>>>> +++++++++++++++++++
>>>>>>>>>> 1 file changed, 23 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git
>>>>>>>>>> a/Documentation/devicetree/bindings/arm/mediatek/medi
>>>>>>>>>> atek
>>>>>>>>>> ,mms
>>>>>>>>>> ys.y
>>>>>>>>>> aml
>>>>>>>>>> b/Documentation/devicetree/bindings/arm/mediatek/medi
>>>>>>>>>> atek
>>>>>>>>>> ,mms
>>>>>>>>>> ys.y
>>>>>>>>>> aml
>>>>>>>>>> index b3c6888c1457..4e9acd966aa5 100644
>>>>>>>>>> ---
>>>>>>>>>> a/Documentation/devicetree/bindings/arm/mediatek/medi
>>>>>>>>>> atek
>>>>>>>>>> ,mms
>>>>>>>>>> ys.y
>>>>>>>>>> aml
>>>>>>>>>> +++
>>>>>>>>>> b/Documentation/devicetree/bindings/arm/mediatek/medi
>>>>>>>>>> atek
>>>>>>>>>> ,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 one board, both OVL and RDMA could switch dynamically. Because
>>> each
>>> one could be the first in one board, mmsys point to both ovl and
>>> rdma?
>>>
>>
>> No.
>>
>> MMSYS would still point ONLY to OVL, because OVL is the "earliest
>> point"
>> of the pipeline that this one board does support.
>>
>> In that case, RDMA being present at a later point in the pipeline
>> does not
>> matter and does not prevent us from *temporarily* skipping OVL-COLOR-
>> AAL-OD
>> and going MMSYS->RDMA *directly*.
>>
>> Switching dynamically is a driver duty and will be 100% possible (as
>> much
>> as it is right now) to dynamically switch OVL and RDMA as long as
>> both are
>> present in the pipeline.
>>
>> With this exact pipeline:
>>
>> MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
>>
>> the driver _can switch dynamically_ between MMSYS->OVL->...->RDMA and
>> MMSYS->RDMA as the driver itself *is allowed to* temporarily ignore
>> part
>> of the pipeline.
>>
>> Please note that, in case it is needed (trust me on this: it's not
>> needed)
>> a custom property in the endpoint node can always be introduced
>> later, so
>> that you can declare a node like
>>
>> endpoint@0 {
>> remote-endpoint = <&ovl0_in>;
>> mediatek,short-path = <&rdma0_in>;
>> };
>>
>> ...but again, that's never going to be needed, as the driver already
>> does
>> have knowledge of the fact that RDMA is in the pipeline, so it is
>> possible
>> to simply do a temporary override in the driver.
>>
>> What the OF Graph support does is to build the same arrays, that we
>> currently
>> have hardcoded in mediatek-drm, by reading from device tree.
>>
>> Nothing else and nothing more - for now.
>>
>> Having the OF Graph support makes us able to also add new dual-path
>> support
>> with more complicated connections than the current ones, without any
>> problem
>> and, in many cases, without even modifying the bindings from what I
>> provided
>> in this series.
>
> OK, please add the information we discussed into binding document to
> prevent anyone misusing this binding.
>
Sorry CK, but the binding *does* already have this information inside - not
in terms of "phrases", but in terms of restrictions of the binding...
If you want, though, I can add this information in the description of the
commit that is adding this binding, is that okay for you?
Thanks,
Angelo
> Regards,
> CK
>
>>
>> Cheers,
>> Angelo
>>
>>> Regards,
>>> CK
>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>>
On Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote:
> Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto:
> > On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno
> > wrote:
> > > Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto:
> > > > On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno
> > > > wrote:
> > > > > 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 <
> > > > > > > > > > > [email protected]>
> > > > > > > > > > > ---
> > > > > > > > > > > .../bindings/arm/mediatek/mediatek,mmsys.ya
> > > > > > > > > > > ml |
> > > > > > > > > > > 23
> > > > > > > > > > > +++++++++++++++++++
> > > > > > > > > > > 1 file changed, 23 insertions(+)
> > > > > > > > > > >
> > > > > > > > > > > diff --git
> > > > > > > > > > > a/Documentation/devicetree/bindings/arm/mediatek/
> > > > > > > > > > > medi
> > > > > > > > > > > atek
> > > > > > > > > > > ,mms
> > > > > > > > > > > ys.y
> > > > > > > > > > > aml
> > > > > > > > > > > b/Documentation/devicetree/bindings/arm/mediatek/
> > > > > > > > > > > medi
> > > > > > > > > > > atek
> > > > > > > > > > > ,mms
> > > > > > > > > > > ys.y
> > > > > > > > > > > aml
> > > > > > > > > > > index b3c6888c1457..4e9acd966aa5 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/Documentation/devicetree/bindings/arm/mediatek/
> > > > > > > > > > > medi
> > > > > > > > > > > atek
> > > > > > > > > > > ,mms
> > > > > > > > > > > ys.y
> > > > > > > > > > > aml
> > > > > > > > > > > +++
> > > > > > > > > > > b/Documentation/devicetree/bindings/arm/mediatek/
> > > > > > > > > > > medi
> > > > > > > > > > > atek
> > > > > > > > > > > ,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 one board, both OVL and RDMA could switch dynamically.
> > > > Because
> > > > each
> > > > one could be the first in one board, mmsys point to both ovl
> > > > and
> > > > rdma?
> > > >
> > >
> > > No.
> > >
> > > MMSYS would still point ONLY to OVL, because OVL is the "earliest
> > > point"
> > > of the pipeline that this one board does support.
> > >
> > > In that case, RDMA being present at a later point in the pipeline
> > > does not
> > > matter and does not prevent us from *temporarily* skipping OVL-
> > > COLOR-
> > > AAL-OD
> > > and going MMSYS->RDMA *directly*.
> > >
> > > Switching dynamically is a driver duty and will be 100% possible
> > > (as
> > > much
> > > as it is right now) to dynamically switch OVL and RDMA as long as
> > > both are
> > > present in the pipeline.
> > >
> > > With this exact pipeline:
> > >
> > > MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
> > >
> > > the driver _can switch dynamically_ between MMSYS->OVL->...->RDMA
> > > and
> > > MMSYS->RDMA as the driver itself *is allowed to* temporarily
> > > ignore
> > > part
> > > of the pipeline.
> > >
> > > Please note that, in case it is needed (trust me on this: it's
> > > not
> > > needed)
> > > a custom property in the endpoint node can always be introduced
> > > later, so
> > > that you can declare a node like
> > >
> > > endpoint@0 {
> > > remote-endpoint = <&ovl0_in>;
> > > mediatek,short-path = <&rdma0_in>;
> > > };
> > >
> > > ...but again, that's never going to be needed, as the driver
> > > already
> > > does
> > > have knowledge of the fact that RDMA is in the pipeline, so it is
> > > possible
> > > to simply do a temporary override in the driver.
> > >
> > > What the OF Graph support does is to build the same arrays, that
> > > we
> > > currently
> > > have hardcoded in mediatek-drm, by reading from device tree.
> > >
> > > Nothing else and nothing more - for now.
> > >
> > > Having the OF Graph support makes us able to also add new dual-
> > > path
> > > support
> > > with more complicated connections than the current ones, without
> > > any
> > > problem
> > > and, in many cases, without even modifying the bindings from what
> > > I
> > > provided
> > > in this series.
> >
> > OK, please add the information we discussed into binding document
> > to
> > prevent anyone misusing this binding.
> >
>
> Sorry CK, but the binding *does* already have this information inside
> - not
> in terms of "phrases", but in terms of restrictions of the binding...
>
> If you want, though, I can add this information in the description of
> the
> commit that is adding this binding, is that okay for you?
I think what we discuss could be translated to restrictions. This is a
restriction description:
If one component has option to be first component or middle component
of one pipeline, it's treated as middle component not first component.
In mt8195, there are 8 vdo1_rdma. So each one is the first component of
display pipeline. So the maximum display pipe number is not 3, maybe 8
or more.
Regards,
CK
>
> Thanks,
> Angelo
>
> > Regards,
> > CK
> >
> > >
> > > Cheers,
> > > Angelo
> > >
> > > > Regards,
> > > > CK
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
Il 13/05/24 08:15, CK Hu (胡俊光) ha scritto:
> On Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote:
>> Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto:
>>> On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno
>>> wrote:
>>>> Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto:
>>>>> On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno
>>>>> wrote:
>>>>>> 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 <
>>>>>>>>>>>> [email protected]>
>>>>>>>>>>>> ---
>>>>>>>>>>>> .../bindings/arm/mediatek/mediatek,mmsys.ya
>>>>>>>>>>>> ml |
>>>>>>>>>>>> 23
>>>>>>>>>>>> +++++++++++++++++++
>>>>>>>>>>>> 1 file changed, 23 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git
>>>>>>>>>>>> a/Documentation/devicetree/bindings/arm/mediatek/
>>>>>>>>>>>> medi
>>>>>>>>>>>> atek
>>>>>>>>>>>> ,mms
>>>>>>>>>>>> ys.y
>>>>>>>>>>>> aml
>>>>>>>>>>>> b/Documentation/devicetree/bindings/arm/mediatek/
>>>>>>>>>>>> medi
>>>>>>>>>>>> atek
>>>>>>>>>>>> ,mms
>>>>>>>>>>>> ys.y
>>>>>>>>>>>> aml
>>>>>>>>>>>> index b3c6888c1457..4e9acd966aa5 100644
>>>>>>>>>>>> ---
>>>>>>>>>>>> a/Documentation/devicetree/bindings/arm/mediatek/
>>>>>>>>>>>> medi
>>>>>>>>>>>> atek
>>>>>>>>>>>> ,mms
>>>>>>>>>>>> ys.y
>>>>>>>>>>>> aml
>>>>>>>>>>>> +++
>>>>>>>>>>>> b/Documentation/devicetree/bindings/arm/mediatek/
>>>>>>>>>>>> medi
>>>>>>>>>>>> atek
>>>>>>>>>>>> ,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 one board, both OVL and RDMA could switch dynamically.
>>>>> Because
>>>>> each
>>>>> one could be the first in one board, mmsys point to both ovl
>>>>> and
>>>>> rdma?
>>>>>
>>>>
>>>> No.
>>>>
>>>> MMSYS would still point ONLY to OVL, because OVL is the "earliest
>>>> point"
>>>> of the pipeline that this one board does support.
>>>>
>>>> In that case, RDMA being present at a later point in the pipeline
>>>> does not
>>>> matter and does not prevent us from *temporarily* skipping OVL-
>>>> COLOR-
>>>> AAL-OD
>>>> and going MMSYS->RDMA *directly*.
>>>>
>>>> Switching dynamically is a driver duty and will be 100% possible
>>>> (as
>>>> much
>>>> as it is right now) to dynamically switch OVL and RDMA as long as
>>>> both are
>>>> present in the pipeline.
>>>>
>>>> With this exact pipeline:
>>>>
>>>> MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
>>>>
>>>> the driver _can switch dynamically_ between MMSYS->OVL->...->RDMA
>>>> and
>>>> MMSYS->RDMA as the driver itself *is allowed to* temporarily
>>>> ignore
>>>> part
>>>> of the pipeline.
>>>>
>>>> Please note that, in case it is needed (trust me on this: it's
>>>> not
>>>> needed)
>>>> a custom property in the endpoint node can always be introduced
>>>> later, so
>>>> that you can declare a node like
>>>>
>>>> endpoint@0 {
>>>> remote-endpoint = <&ovl0_in>;
>>>> mediatek,short-path = <&rdma0_in>;
>>>> };
>>>>
>>>> ...but again, that's never going to be needed, as the driver
>>>> already
>>>> does
>>>> have knowledge of the fact that RDMA is in the pipeline, so it is
>>>> possible
>>>> to simply do a temporary override in the driver.
>>>>
>>>> What the OF Graph support does is to build the same arrays, that
>>>> we
>>>> currently
>>>> have hardcoded in mediatek-drm, by reading from device tree.
>>>>
>>>> Nothing else and nothing more - for now.
>>>>
>>>> Having the OF Graph support makes us able to also add new dual-
>>>> path
>>>> support
>>>> with more complicated connections than the current ones, without
>>>> any
>>>> problem
>>>> and, in many cases, without even modifying the bindings from what
>>>> I
>>>> provided
>>>> in this series.
>>>
>>> OK, please add the information we discussed into binding document
>>> to
>>> prevent anyone misusing this binding.
>>>
>>
>> Sorry CK, but the binding *does* already have this information inside
>> - not
>> in terms of "phrases", but in terms of restrictions of the binding...
>>
>> If you want, though, I can add this information in the description of
>> the
>> commit that is adding this binding, is that okay for you?
>
> I think what we discuss could be translated to restrictions. This is a
> restriction description:
>
> If one component has option to be first component or middle component
> of one pipeline, it's treated as middle component not first component.
>
> In mt8195, there are 8 vdo1_rdma. So each one is the first component of
> display pipeline. So the maximum display pipe number is not 3, maybe 8
> or more.
>
I will add the information in the commit description for the next version
of this series.
Thanks,
Angelo
> Regards,
> CK
>
>
>>
>> Thanks,
>> Angelo
>>
>>> Regards,
>>> CK
>>>
>>>>
>>>> Cheers,
>>>> Angelo
>>>>
>>>>> Regards,
>>>>> CK
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
On Mon, May 13, 2024 at 03:44:00PM +0200, AngeloGioacchino Del Regno wrote:
> Il 13/05/24 08:15, CK Hu (胡俊光) ha scritto:
> > On Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote:
> > > Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto:
> > > > On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno
> > > > wrote:
> > > > > Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto:
> > > > > > On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno
> > > > > > wrote:
> > > > > > > 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 <
> > > > > > > > > > > > > [email protected]>
One of you guys, probably 胡俊光, has a mail client that is completely
mangling these quotes. Can you try to fix that please? It makes reading
the thread unfun :/
Hi Angelo,
Gentle ping because I'm stuck if I rebase my serie on top of yours.
On 02/05/2024 18:53, Alexandre Mergnat wrote:
>
>
> On 30/04/2024 13:33, AngeloGioacchino Del Regno wrote:
>> Il 30/04/24 12:17, Alexandre Mergnat ha scritto:
>>> Hi Angelo,
>>>
>>> On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:
>>>> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
>>>> NIO-12L with both hardcoded paths, OF graph support and partially
>>>> hardcoded paths (meaning main display through OF graph and external
>>>> display hardcoded, because of OVL_ADAPTOR).
>>>
>>> Is that make sense for you to add the DTS changes of these boards into this serie ?
>>> I asked because, IMHO, that could help to understand the serie.
>>>
>>
>> Yes and no... but I imagine that you're asking this because you're trying to
>> prepare something with a different SoC+board(s) combination :-)
>>
>> In that case, I'm preventively sorry because what follows here is not 100%
>> perfectly tidy yet as I didn't mean to send the devicetree commits upstream
>> before this series got picked....
>>
>> ... but there you go - I'm sure that you won't mind and that the example will
>> be more than good enough for you.
>>
>> Please note that one of the reasons why I didn't want to add this to the series
>> is that the following changes show only a mere 50% of the reasons why we want OF
>> graph support on mediatek-drm (but mainly, it's because I didn't have time to
>> actually rebase etc :-P )
>
> Thanks for the explanations and examples.
> Unfortunately, I have 2 display but only one is working (the main: DSI0) when I use the dts method.
> I've probably missed something but I don't know what.
>
> In my "mmsys" node, if I swap display (the ext endpoint with the main endpoint), the DPI0 is
> working, but not the DSI0. I conclude my both paths are good.
>
> Then, I've put some trace into "mtk_drm_of_ddp_path_build" to check if it parse the two endpoint of
> the node. Both are parsed, but "of_ep.port" is always = 0. According to "of_graph_parse_endpoint"
> function, "port" is the value of the parent "reg", whereas "id" is the value of the endpoint "reg".
> So I replaced "of_ep.port" by "of_ep.id". Now I've of_ep.id = 0 for main and of_ep.id = 1 for EXT.
>
> Now I've the good CRTC path, I get this error:
> mediatek-drm mediatek-drm.1.auto: Invalid display hw pipeline. Last component: 54 (ret=-2)
> mediatek-drm mediatek-drm.1.auto: probe with driver mediatek-drm failed with error -22
>
> After quick look, the "cpath" into "mtk_drm_of_ddp_path_build_one" (or deeper functions) seems not
> be used as it should, due to the previous "of_ep.port" => "of_ep.id" change of course.
>
> But I probably have to fix "of_ep.port" because I've mis-coded something. Just in case, I share you
> my diff:
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
> index 1aa3426f561b..f660481d3fe8 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
> @@ -109,15 +109,51 @@ vsys_lcm_reg: regulator-vsys-lcm {
> };
> };
>
> +&cpu0 {
> + proc-supply = <&mt6357_vproc_reg>;
> + sram-supply = <&mt6357_vsram_proc_reg>;
> +};
> +
> +&cpu1 {
> + proc-supply = <&mt6357_vproc_reg>;
> + sram-supply = <&mt6357_vsram_proc_reg>;
> +};
> +
> +&cpu2 {
> + proc-supply = <&mt6357_vproc_reg>;
> + sram-supply = <&mt6357_vsram_proc_reg>;
> +};
> +
> +&cpu3 {
> + proc-supply = <&mt6357_vproc_reg>;
> + sram-supply = <&mt6357_vsram_proc_reg>;
> +};
> +
> +&dither0_out {
> + remote-endpoint = <&dsi0_in>;
> +};
> +
> &dpi0 {
> pinctrl-0 = <&dpi_default_pins>;
> pinctrl-1 = <&dpi_idle_pins>;
> pinctrl-names = "default", "sleep";
> status = "okay";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
>
> - port {
> - dpi_out: endpoint {
> - remote-endpoint = <&it66121_in>;
> + port@0 {
> + reg = <0>;
> + dpi0_in: endpoint {
> + remote-endpoint = <&rdma1_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dpi0_out: endpoint {
> + remote-endpoint = <&it66121_in>;
> + };
> };
> };
> };
> @@ -137,36 +173,28 @@ panel@0 {
>
> port {
> panel_in: endpoint {
> - remote-endpoint = <&dsi_out>;
> + remote-endpoint = <&dsi0_out>;
> };
> };
> };
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
>
> - port {
> - dsi_out: endpoint {
> - remote-endpoint = <&panel_in>;
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <&dither0_out>;
> + };
> };
> - };
> -};
>
> -&cpu0 {
> - proc-supply = <&mt6357_vproc_reg>;
> - sram-supply = <&mt6357_vsram_proc_reg>;
> -};
> -
> -&cpu1 {
> - proc-supply = <&mt6357_vproc_reg>;
> - sram-supply = <&mt6357_vsram_proc_reg>;
> -};
> -
> -&cpu2 {
> - proc-supply = <&mt6357_vproc_reg>;
> - sram-supply = <&mt6357_vsram_proc_reg>;
> -};
> -
> -&cpu3 {
> - proc-supply = <&mt6357_vproc_reg>;
> - sram-supply = <&mt6357_vsram_proc_reg>;
> + port@1 {
> + reg = <1>;
> + dsi0_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> };
>
> ðernet {
> @@ -229,7 +257,7 @@ port@0 {
> reg = <0>;
> it66121_in: endpoint {
> bus-width = <12>;
> - remote-endpoint = <&dpi_out>;
> + remote-endpoint = <&dpi0_out>;
> };
> };
>
> @@ -557,6 +585,10 @@ &pwm {
> status = "okay";
> };
>
> +&rdma1_out {
> + remote-endpoint = <&dpi0_in>;
> +};
> +
> &ssusb {
> dr_mode = "otg";
> maximum-speed = "high-speed";
> diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
> index d34519a33c90..dbb559959a9d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
> @@ -762,6 +762,19 @@ mmsys: syscon@14000000 {
> compatible = "mediatek,mt8365-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
> #clock-cells = <1>;
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mmsys_main: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&ovl0_in>;
> + };
> + mmsys_ext: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&rdma1_in>;
> + };
> + };
> };
>
> mutex: mutex@14001000 {
> @@ -801,6 +814,24 @@ ovl0: ovl@1400b000 {
> interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_LOW>;
> iommus = <&iommu M4U_PORT_DISP_OVL0>;
> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + ovl0_in: endpoint {
> + remote-endpoint = <&mmsys_main>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + ovl0_out: endpoint {
> + remote-endpoint = <&rdma0_in>;
> + };
> + };
> + };
> };
>
> rdma0: rdma@1400d000 {
> @@ -811,6 +842,24 @@ rdma0: rdma@1400d000 {
> iommus = <&iommu M4U_PORT_DISP_RDMA0>;
> mediatek,rdma-fifo-size = <5120>;
> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + rdma0_in: endpoint {
> + remote-endpoint = <&ovl0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + rdma0_out: endpoint {
> + remote-endpoint = <&color0_in>;
> + };
> + };
> + };
> };
>
> color0: color@1400f000 {
> @@ -819,6 +868,24 @@ color0: color@1400f000 {
> clocks = <&mmsys CLK_MM_MM_DISP_COLOR0>;
> interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + color0_in: endpoint {
> + remote-endpoint = <&rdma0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + color0_out: endpoint {
> + remote-endpoint = <&ccorr0_in>;
> + };
> + };
> + };
> };
>
> ccorr0: ccorr@14010000 {
> @@ -827,6 +894,24 @@ ccorr0: ccorr@14010000 {
> clocks = <&mmsys CLK_MM_MM_DISP_CCORR0>;
> interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_LOW>;
> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + ccorr0_in: endpoint {
> + remote-endpoint = <&color0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + ccorr0_out: endpoint {
> + remote-endpoint = <&aal0_in>;
> + };
> + };
> + };
> };
>
> aal0: aal@14011000 {
> @@ -835,6 +920,24 @@ aal0: aal@14011000 {
> clocks = <&mmsys CLK_MM_MM_DISP_AAL0>;
> interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_LOW>;
> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + aal0_in: endpoint {
> + remote-endpoint = <&ccorr0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + aal0_out: endpoint {
> + remote-endpoint = <&gamma0_in>;
> + };
> + };
> + };
> };
>
> gamma0: gamma@14012000 {
> @@ -843,6 +946,24 @@ gamma0: gamma@14012000 {
> clocks = <&mmsys CLK_MM_MM_DISP_GAMMA0>;
> interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + gamma0_in: endpoint {
> + remote-endpoint = <&aal0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + gamma0_out: endpoint {
> + remote-endpoint = <&dither0_in>;
> + };
> + };
> + };
> };
>
> dither0: dither@14013000 {
> @@ -851,6 +972,23 @@ dither0: dither@14013000 {
> clocks = <&mmsys CLK_MM_MM_DISP_DITHER0>;
> interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dither0_in: endpoint {
> + remote-endpoint = <&gamma0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dither0_out: endpoint {
> + };
> + };
> + };
> };
>
> dsi0: dsi@14014000 {
> @@ -874,6 +1012,23 @@ rdma1: rdma@14016000 {
> iommus = <&iommu M4U_PORT_DISP_RDMA1>;
> mediatek,rdma-fifo-size = <2048>;
> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + rdma1_in: endpoint {
> + remote-endpoint = <&mmsys_ext>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + rdma1_out: endpoint {
> + };
> + };
> + };
> };
>
> dpi0: dpi@14018000 {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index dacf4eaa3457..5992b7865310 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -230,22 +230,6 @@ static const unsigned int mt8195_mtk_ddp_ext[] = {
> DDP_COMPONENT_DP_INTF1,
> };
>
> -static const unsigned int mt8365_mtk_ddp_main[] = {
> - DDP_COMPONENT_OVL0,
> - DDP_COMPONENT_RDMA0,
> - DDP_COMPONENT_COLOR0,
> - DDP_COMPONENT_CCORR,
> - DDP_COMPONENT_AAL0,
> - DDP_COMPONENT_GAMMA,
> - DDP_COMPONENT_DITHER0,
> - DDP_COMPONENT_DSI0,
> -};
> -
> -static const unsigned int mt8365_mtk_ddp_ext[] = {
> - DDP_COMPONENT_RDMA1,
> - DDP_COMPONENT_DPI0,
> -};
> -
> static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .main_path = mt2701_mtk_ddp_main,
> .main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
> @@ -334,10 +318,6 @@ static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
> };
>
> static const struct mtk_mmsys_driver_data mt8365_mmsys_driver_data = {
> - .main_path = mt8365_mtk_ddp_main,
> - .main_len = ARRAY_SIZE(mt8365_mtk_ddp_main),
> - .ext_path = mt8365_mtk_ddp_ext,
> - .ext_len = ARRAY_SIZE(mt8365_mtk_ddp_ext),
> .mmsys_dev_num = 1,
> };
>
>
>
> --
> Regards,
> Alexandre
--
Regards,
Alexandre
Il 14/05/24 11:46, Alexandre Mergnat ha scritto:
> Hi Angelo,
>
> Gentle ping because I'm stuck if I rebase my serie on top of yours.
>
Sorry, I was unable to find time to get back to this... I plan to look at it
between today and tomorrow.
In the meanwhile - does your platform use OVL_ADAPTOR?
If it does, that's the actual issue; otherwise, there may be some mistake on
your side, because the EPs' ports<->ids relationship was verified before sending
this to the lists.
Cheers,
Angelo
> On 02/05/2024 18:53, Alexandre Mergnat wrote:
>>
>>
>> On 30/04/2024 13:33, AngeloGioacchino Del Regno wrote:
>>> Il 30/04/24 12:17, Alexandre Mergnat ha scritto:
>>>> Hi Angelo,
>>>>
>>>> On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:
>>>>> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
>>>>> NIO-12L with both hardcoded paths, OF graph support and partially
>>>>> hardcoded paths (meaning main display through OF graph and external
>>>>> display hardcoded, because of OVL_ADAPTOR).
>>>>
>>>> Is that make sense for you to add the DTS changes of these boards into this
>>>> serie ?
>>>> I asked because, IMHO, that could help to understand the serie.
>>>>
>>>
>>> Yes and no... but I imagine that you're asking this because you're trying to
>>> prepare something with a different SoC+board(s) combination :-)
>>>
>>> In that case, I'm preventively sorry because what follows here is not 100%
>>> perfectly tidy yet as I didn't mean to send the devicetree commits upstream
>>> before this series got picked....
>>>
>>> ... but there you go - I'm sure that you won't mind and that the example will
>>> be more than good enough for you.
>>>
>>> Please note that one of the reasons why I didn't want to add this to the series
>>> is that the following changes show only a mere 50% of the reasons why we want OF
>>> graph support on mediatek-drm (but mainly, it's because I didn't have time to
>>> actually rebase etc :-P )
>>
>> Thanks for the explanations and examples.
>> Unfortunately, I have 2 display but only one is working (the main: DSI0) when I
>> use the dts method.
>> I've probably missed something but I don't know what.
>>
>> In my "mmsys" node, if I swap display (the ext endpoint with the main endpoint),
>> the DPI0 is working, but not the DSI0. I conclude my both paths are good.
>>
>> Then, I've put some trace into "mtk_drm_of_ddp_path_build" to check if it parse
>> the two endpoint of the node. Both are parsed, but "of_ep.port" is always = 0.
>> According to "of_graph_parse_endpoint" function, "port" is the value of the
>> parent "reg", whereas "id" is the value of the endpoint "reg".
>> So I replaced "of_ep.port" by "of_ep.id". Now I've of_ep.id = 0 for main and
>> of_ep.id = 1 for EXT.
>>
>> Now I've the good CRTC path, I get this error:
>> mediatek-drm mediatek-drm.1.auto: Invalid display hw pipeline. Last component:
>> 54 (ret=-2)
>> mediatek-drm mediatek-drm.1.auto: probe with driver mediatek-drm failed with
>> error -22
>>
>> After quick look, the "cpath" into "mtk_drm_of_ddp_path_build_one" (or deeper
>> functions) seems not be used as it should, due to the previous "of_ep.port" =>
>> "of_ep.id" change of course.
>>
>> But I probably have to fix "of_ep.port" because I've mis-coded something. Just in
>> case, I share you my diff:
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
>> b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
>> index 1aa3426f561b..f660481d3fe8 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
>> @@ -109,15 +109,51 @@ vsys_lcm_reg: regulator-vsys-lcm {
>> };
>> };
>>
>> +&cpu0 {
>> + proc-supply = <&mt6357_vproc_reg>;
>> + sram-supply = <&mt6357_vsram_proc_reg>;
>> +};
>> +
>> +&cpu1 {
>> + proc-supply = <&mt6357_vproc_reg>;
>> + sram-supply = <&mt6357_vsram_proc_reg>;
>> +};
>> +
>> +&cpu2 {
>> + proc-supply = <&mt6357_vproc_reg>;
>> + sram-supply = <&mt6357_vsram_proc_reg>;
>> +};
>> +
>> +&cpu3 {
>> + proc-supply = <&mt6357_vproc_reg>;
>> + sram-supply = <&mt6357_vsram_proc_reg>;
>> +};
>> +
>> +&dither0_out {
>> + remote-endpoint = <&dsi0_in>;
>> +};
>> +
>> &dpi0 {
>> pinctrl-0 = <&dpi_default_pins>;
>> pinctrl-1 = <&dpi_idle_pins>;
>> pinctrl-names = "default", "sleep";
>> status = "okay";
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>>
>> - port {
>> - dpi_out: endpoint {
>> - remote-endpoint = <&it66121_in>;
>> + port@0 {
>> + reg = <0>;
>> + dpi0_in: endpoint {
>> + remote-endpoint = <&rdma1_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + dpi0_out: endpoint {
>> + remote-endpoint = <&it66121_in>;
>> + };
>> };
>> };
>> };
>> @@ -137,36 +173,28 @@ panel@0 {
>>
>> port {
>> panel_in: endpoint {
>> - remote-endpoint = <&dsi_out>;
>> + remote-endpoint = <&dsi0_out>;
>> };
>> };
>> };
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>>
>> - port {
>> - dsi_out: endpoint {
>> - remote-endpoint = <&panel_in>;
>> + port@0 {
>> + reg = <0>;
>> + dsi0_in: endpoint {
>> + remote-endpoint = <&dither0_out>;
>> + };
>> };
>> - };
>> -};
>>
>> -&cpu0 {
>> - proc-supply = <&mt6357_vproc_reg>;
>> - sram-supply = <&mt6357_vsram_proc_reg>;
>> -};
>> -
>> -&cpu1 {
>> - proc-supply = <&mt6357_vproc_reg>;
>> - sram-supply = <&mt6357_vsram_proc_reg>;
>> -};
>> -
>> -&cpu2 {
>> - proc-supply = <&mt6357_vproc_reg>;
>> - sram-supply = <&mt6357_vsram_proc_reg>;
>> -};
>> -
>> -&cpu3 {
>> - proc-supply = <&mt6357_vproc_reg>;
>> - sram-supply = <&mt6357_vsram_proc_reg>;
>> + port@1 {
>> + reg = <1>;
>> + dsi0_out: endpoint {
>> + remote-endpoint = <&panel_in>;
>> + };
>> + };
>> + };
>> };
>>
>> ðernet {
>> @@ -229,7 +257,7 @@ port@0 {
>> reg = <0>;
>> it66121_in: endpoint {
>> bus-width = <12>;
>> - remote-endpoint = <&dpi_out>;
>> + remote-endpoint = <&dpi0_out>;
>> };
>> };
>>
>> @@ -557,6 +585,10 @@ &pwm {
>> status = "okay";
>> };
>>
>> +&rdma1_out {
>> + remote-endpoint = <&dpi0_in>;
>> +};
>> +
>> &ssusb {
>> dr_mode = "otg";
>> maximum-speed = "high-speed";
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
>> index d34519a33c90..dbb559959a9d 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
>> @@ -762,6 +762,19 @@ mmsys: syscon@14000000 {
>> compatible = "mediatek,mt8365-mmsys", "syscon";
>> reg = <0 0x14000000 0 0x1000>;
>> #clock-cells = <1>;
>> + port {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + mmsys_main: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint = <&ovl0_in>;
>> + };
>> + mmsys_ext: endpoint@1 {
>> + reg = <1>;
>> + remote-endpoint = <&rdma1_in>;
>> + };
>> + };
>> };
>>
>> mutex: mutex@14001000 {
>> @@ -801,6 +814,24 @@ ovl0: ovl@1400b000 {
>> interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_LOW>;
>> iommus = <&iommu M4U_PORT_DISP_OVL0>;
>> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + ovl0_in: endpoint {
>> + remote-endpoint = <&mmsys_main>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + ovl0_out: endpoint {
>> + remote-endpoint = <&rdma0_in>;
>> + };
>> + };
>> + };
>> };
>>
>> rdma0: rdma@1400d000 {
>> @@ -811,6 +842,24 @@ rdma0: rdma@1400d000 {
>> iommus = <&iommu M4U_PORT_DISP_RDMA0>;
>> mediatek,rdma-fifo-size = <5120>;
>> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + rdma0_in: endpoint {
>> + remote-endpoint = <&ovl0_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + rdma0_out: endpoint {
>> + remote-endpoint = <&color0_in>;
>> + };
>> + };
>> + };
>> };
>>
>> color0: color@1400f000 {
>> @@ -819,6 +868,24 @@ color0: color@1400f000 {
>> clocks = <&mmsys CLK_MM_MM_DISP_COLOR0>;
>> interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + color0_in: endpoint {
>> + remote-endpoint = <&rdma0_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + color0_out: endpoint {
>> + remote-endpoint = <&ccorr0_in>;
>> + };
>> + };
>> + };
>> };
>>
>> ccorr0: ccorr@14010000 {
>> @@ -827,6 +894,24 @@ ccorr0: ccorr@14010000 {
>> clocks = <&mmsys CLK_MM_MM_DISP_CCORR0>;
>> interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + ccorr0_in: endpoint {
>> + remote-endpoint = <&color0_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + ccorr0_out: endpoint {
>> + remote-endpoint = <&aal0_in>;
>> + };
>> + };
>> + };
>> };
>>
>> aal0: aal@14011000 {
>> @@ -835,6 +920,24 @@ aal0: aal@14011000 {
>> clocks = <&mmsys CLK_MM_MM_DISP_AAL0>;
>> interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + aal0_in: endpoint {
>> + remote-endpoint = <&ccorr0_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + aal0_out: endpoint {
>> + remote-endpoint = <&gamma0_in>;
>> + };
>> + };
>> + };
>> };
>>
>> gamma0: gamma@14012000 {
>> @@ -843,6 +946,24 @@ gamma0: gamma@14012000 {
>> clocks = <&mmsys CLK_MM_MM_DISP_GAMMA0>;
>> interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + gamma0_in: endpoint {
>> + remote-endpoint = <&aal0_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + gamma0_out: endpoint {
>> + remote-endpoint = <&dither0_in>;
>> + };
>> + };
>> + };
>> };
>>
>> dither0: dither@14013000 {
>> @@ -851,6 +972,23 @@ dither0: dither@14013000 {
>> clocks = <&mmsys CLK_MM_MM_DISP_DITHER0>;
>> interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
>> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + dither0_in: endpoint {
>> + remote-endpoint = <&gamma0_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + dither0_out: endpoint {
>> + };
>> + };
>> + };
>> };
>>
>> dsi0: dsi@14014000 {
>> @@ -874,6 +1012,23 @@ rdma1: rdma@14016000 {
>> iommus = <&iommu M4U_PORT_DISP_RDMA1>;
>> mediatek,rdma-fifo-size = <2048>;
>> power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + rdma1_in: endpoint {
>> + remote-endpoint = <&mmsys_ext>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + rdma1_out: endpoint {
>> + };
>> + };
>> + };
>> };
>>
>> dpi0: dpi@14018000 {
>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> index dacf4eaa3457..5992b7865310 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> @@ -230,22 +230,6 @@ static const unsigned int mt8195_mtk_ddp_ext[] = {
>> DDP_COMPONENT_DP_INTF1,
>> };
>>
>> -static const unsigned int mt8365_mtk_ddp_main[] = {
>> - DDP_COMPONENT_OVL0,
>> - DDP_COMPONENT_RDMA0,
>> - DDP_COMPONENT_COLOR0,
>> - DDP_COMPONENT_CCORR,
>> - DDP_COMPONENT_AAL0,
>> - DDP_COMPONENT_GAMMA,
>> - DDP_COMPONENT_DITHER0,
>> - DDP_COMPONENT_DSI0,
>> -};
>> -
>> -static const unsigned int mt8365_mtk_ddp_ext[] = {
>> - DDP_COMPONENT_RDMA1,
>> - DDP_COMPONENT_DPI0,
>> -};
>> -
>> static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
>> .main_path = mt2701_mtk_ddp_main,
>> .main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
>> @@ -334,10 +318,6 @@ static const struct mtk_mmsys_driver_data
>> mt8195_vdosys1_driver_data = {
>> };
>>
>> static const struct mtk_mmsys_driver_data mt8365_mmsys_driver_data = {
>> - .main_path = mt8365_mtk_ddp_main,
>> - .main_len = ARRAY_SIZE(mt8365_mtk_ddp_main),
>> - .ext_path = mt8365_mtk_ddp_ext,
>> - .ext_len = ARRAY_SIZE(mt8365_mtk_ddp_ext),
>> .mmsys_dev_num = 1,
>> };
>>
>>
>>
>> --
>> Regards,
>> Alexandre
>
Il 13/05/24 08:15, CK Hu (胡俊光) ha scritto:
> On Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote:
>> Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto:
>>> On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno
>>> wrote:
>>>> Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto:
>>>>> On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno
>>>>> wrote:
>>>>>> 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 <
>>>>>>>>>>>> [email protected]>
>>>>>>>>>>>> ---
>>>>>>>>>>>> .../bindings/arm/mediatek/mediatek,mmsys.ya
>>>>>>>>>>>> ml |
>>>>>>>>>>>> 23
>>>>>>>>>>>> +++++++++++++++++++
>>>>>>>>>>>> 1 file changed, 23 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git
>>>>>>>>>>>> a/Documentation/devicetree/bindings/arm/mediatek/
>>>>>>>>>>>> medi
>>>>>>>>>>>> atek
>>>>>>>>>>>> ,mms
>>>>>>>>>>>> ys.y
>>>>>>>>>>>> aml
>>>>>>>>>>>> b/Documentation/devicetree/bindings/arm/mediatek/
>>>>>>>>>>>> medi
>>>>>>>>>>>> atek
>>>>>>>>>>>> ,mms
>>>>>>>>>>>> ys.y
>>>>>>>>>>>> aml
>>>>>>>>>>>> index b3c6888c1457..4e9acd966aa5 100644
>>>>>>>>>>>> ---
>>>>>>>>>>>> a/Documentation/devicetree/bindings/arm/mediatek/
>>>>>>>>>>>> medi
>>>>>>>>>>>> atek
>>>>>>>>>>>> ,mms
>>>>>>>>>>>> ys.y
>>>>>>>>>>>> aml
>>>>>>>>>>>> +++
>>>>>>>>>>>> b/Documentation/devicetree/bindings/arm/mediatek/
>>>>>>>>>>>> medi
>>>>>>>>>>>> atek
>>>>>>>>>>>> ,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 one board, both OVL and RDMA could switch dynamically.
>>>>> Because
>>>>> each
>>>>> one could be the first in one board, mmsys point to both ovl
>>>>> and
>>>>> rdma?
>>>>>
>>>>
>>>> No.
>>>>
>>>> MMSYS would still point ONLY to OVL, because OVL is the "earliest
>>>> point"
>>>> of the pipeline that this one board does support.
>>>>
>>>> In that case, RDMA being present at a later point in the pipeline
>>>> does not
>>>> matter and does not prevent us from *temporarily* skipping OVL-
>>>> COLOR-
>>>> AAL-OD
>>>> and going MMSYS->RDMA *directly*.
>>>>
>>>> Switching dynamically is a driver duty and will be 100% possible
>>>> (as
>>>> much
>>>> as it is right now) to dynamically switch OVL and RDMA as long as
>>>> both are
>>>> present in the pipeline.
>>>>
>>>> With this exact pipeline:
>>>>
>>>> MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
>>>>
>>>> the driver _can switch dynamically_ between MMSYS->OVL->...->RDMA
>>>> and
>>>> MMSYS->RDMA as the driver itself *is allowed to* temporarily
>>>> ignore
>>>> part
>>>> of the pipeline.
>>>>
>>>> Please note that, in case it is needed (trust me on this: it's
>>>> not
>>>> needed)
>>>> a custom property in the endpoint node can always be introduced
>>>> later, so
>>>> that you can declare a node like
>>>>
>>>> endpoint@0 {
>>>> remote-endpoint = <&ovl0_in>;
>>>> mediatek,short-path = <&rdma0_in>;
>>>> };
>>>>
>>>> ...but again, that's never going to be needed, as the driver
>>>> already
>>>> does
>>>> have knowledge of the fact that RDMA is in the pipeline, so it is
>>>> possible
>>>> to simply do a temporary override in the driver.
>>>>
>>>> What the OF Graph support does is to build the same arrays, that
>>>> we
>>>> currently
>>>> have hardcoded in mediatek-drm, by reading from device tree.
>>>>
>>>> Nothing else and nothing more - for now.
>>>>
>>>> Having the OF Graph support makes us able to also add new dual-
>>>> path
>>>> support
>>>> with more complicated connections than the current ones, without
>>>> any
>>>> problem
>>>> and, in many cases, without even modifying the bindings from what
>>>> I
>>>> provided
>>>> in this series.
>>>
>>> OK, please add the information we discussed into binding document
>>> to
>>> prevent anyone misusing this binding.
>>>
>>
>> Sorry CK, but the binding *does* already have this information inside
>> - not
>> in terms of "phrases", but in terms of restrictions of the binding...
>>
>> If you want, though, I can add this information in the description of
>> the
>> commit that is adding this binding, is that okay for you?
>
> I think what we discuss could be translated to restrictions. This is a
> restriction description:
>
> If one component has option to be first component or middle component
> of one pipeline, it's treated as middle component not first component.
>
This cannot be added to the binding description, as the binding describes
hardware, and what we're talking about here is a *driver* behavior detail,
not suitable for describing a binding by itself.
Also, that's not true: if a component has option to be first or middle,
it is going to be treated as per what you describe in the graph - if you
place it as first, it's going to be first (unless temporary overrides are
used in the driver which are, again, transparent to all this) otherwise,
if you place it as middle, it's going to normally be treated as middle.
Besides - to address your concern about misusing the graph... that's not
possible because of multiple reasons:
1. The bindings won't pass validation - dtbs_check will give errors and/or
warnings upon misuse of bindings in device trees
2. The driver simply won't work, as it's going to refuse probing if it
detects an invalid graph (which corresponds to any binding misuse).
> In mt8195, there are 8 vdo1_rdma. So each one is the first component of
> display pipeline. So the maximum display pipe number is not 3, maybe 8
> or more.
Yes but we currently only support three paths - adding more to the bindings
later is trivial anyway, so I prefer to describe what is currently supported
and what can currently be tested on the real (and commonly availlable) hardware,
and not what might be, one day, maybe supported.
Whenever any commonly available hardware supporting more than three paths will
appear, I'll change the binding to do that, and it's going to be a 10 minutes job.
Besides, I'm about to send a v4 of this series, containing some fixes for the
multi-path support on all SoCs.
Regards,
Angelo
> > Regards,
> CK
>
>
>>
>> Thanks,
>> Angelo
>>
>>> Regards,
>>> CK
>>>
>>>>
>>>> Cheers,
>>>> Angelo
>>>>
>>>>> Regards,
>>>>> CK
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>