Changes in v4:
- Fixed a typo that caused pure OF graphs pipelines multiple
concurrent outputs to not get correctly parsed (port->id);
- Added OVL_ADAPTOR support for OF graph specified pipelines;
- Now tested with fully OF Graph specified pipelines on MT8195
Chromebooks and MT8395 boards;
- Rebased on next-20240516
Changes in v3:
- Rebased on next-20240502 because of renames in mediatek-drm
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.
This series is essential to enable support for the MT8195/MT8395 EVK,
Kontron i1200, Radxa NIO-12L and, mainly, for non-Chromebook boards
and Chromebooks to co-exist without conflicts.
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, and pure OF graph support including pipelines that
require OVL_ADAPTOR support.
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 | 28 ++
.../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_disp_drv.h | 1 +
.../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 40 ++-
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 282 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
23 files changed, 713 insertions(+), 41 deletions(-)
--
2.45.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.
Reviewed-by: Rob Herring (Arm) <[email protected]>
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 b8b8e83ebc3f..17f299abda11 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -64,6 +64,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.45.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.
Reviewed-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
---
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index b3c6888c1457..0ef67ca4122b 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -93,6 +93,34 @@ 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 multiple 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
+
+ oneOf:
+ - required:
+ - endpoint@0
+ - required:
+ - endpoint@1
+ - required:
+ - endpoint@2
+
required:
- compatible
- reg
--
2.45.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_disp_drv.h | 1 +
.../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 40 ++-
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 282 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
6 files changed, 313 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 082ac18fe04a..94843974851f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -108,6 +108,7 @@ size_t mtk_ovl_get_num_formats(struct device *dev);
void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex);
void mtk_ovl_adaptor_remove_comp(struct device *dev, struct mtk_mutex *mutex);
+bool mtk_ovl_adaptor_is_comp_present(struct device_node *node);
void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev,
unsigned int next);
void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 02dd7dcdfedb..400519d1ca1f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -491,6 +491,38 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
}
+static int ovl_adaptor_of_get_ddp_comp_type(struct device_node *node,
+ enum mtk_ovl_adaptor_comp_type *ctype)
+{
+ const struct of_device_id *of_id = of_match_node(mtk_ovl_adaptor_comp_dt_ids, node);
+
+ if (!of_id)
+ return -EINVAL;
+
+ *ctype = (enum mtk_ovl_adaptor_comp_type)((uintptr_t)of_id->data);
+
+ return 0;
+}
+
+bool mtk_ovl_adaptor_is_comp_present(struct device_node *node)
+{
+ enum mtk_ovl_adaptor_comp_type type;
+ int ret;
+
+ ret = ovl_adaptor_of_get_ddp_comp_type(node, &type);
+ if (ret)
+ return false;
+
+ if (type >= OVL_ADAPTOR_TYPE_NUM)
+ return false;
+
+ /*
+ * ETHDR and Padding are used exclusively in OVL Adaptor: if this
+ * component is not one of those, it's likely not an OVL Adaptor path.
+ */
+ return type == OVL_ADAPTOR_TYPE_ETHDR || type == OVL_ADAPTOR_TYPE_PADDING;
+}
+
static int ovl_adaptor_comp_init(struct device *dev, struct component_match **match)
{
struct mtk_disp_ovl_adaptor *priv = dev_get_drvdata(dev);
@@ -500,12 +532,11 @@ static int ovl_adaptor_comp_init(struct device *dev, struct component_match **ma
parent = dev->parent->parent->of_node->parent;
for_each_child_of_node(parent, node) {
- const struct of_device_id *of_id;
enum mtk_ovl_adaptor_comp_type type;
- int id;
+ int id, ret;
- of_id = of_match_node(mtk_ovl_adaptor_comp_dt_ids, node);
- if (!of_id)
+ ret = ovl_adaptor_of_get_ddp_comp_type(node, &type);
+ if (ret)
continue;
if (!of_device_is_available(node)) {
@@ -514,7 +545,6 @@ static int ovl_adaptor_comp_init(struct device *dev, struct component_match **ma
continue;
}
- type = (enum mtk_ovl_adaptor_comp_type)(uintptr_t)of_id->data;
id = ovl_adaptor_comp_get_id(dev, node, type);
if (id < 0) {
dev_warn(dev, "Skipping unknown component %pOF\n",
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index bfe8653005db..5c86aa0b75b2 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 b5f605751b0a..ce8f3cc6e853 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -26,6 +26,7 @@
#include "mtk_crtc.h"
#include "mtk_ddp_comp.h"
+#include "mtk_disp_drv.h"
#include "mtk_drm_drv.h"
#include "mtk_gem.h"
@@ -798,12 +799,226 @@ 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_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) {
+ if (mtk_ovl_adaptor_is_comp_present(ep_dev_node)) {
+ *cid = (unsigned int)DDP_COMPONENT_DRM_OVL_ADAPTOR;
+ return 0;
+ }
+ 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_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;
+ bool ovl_adaptor_comp_added = false;
+ 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 && temp_path[idx] == DDP_COMPONENT_DRM_OVL_ADAPTOR) {
+ dev_err(dev, "Adding OVL Adaptor for %pOF\n", next);
+ ovl_adaptor_comp_added = true;
+ } else {
+ 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;
+ }
+ }
+ idx++;
+
+ /*
+ * 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;
+ }
+
+ /*
+ * If this is an OVL adaptor exclusive component and one of those
+ * was already added, don't add another instance of the generic
+ * DDP_COMPONENT_OVL_ADAPTOR, as this is used only to decide whether
+ * to probe that component master driver of which only one instance
+ * is needed and possible.
+ */
+ if (temp_path[idx] == DDP_COMPONENT_DRM_OVL_ADAPTOR) {
+ if (!ovl_adaptor_comp_added)
+ ovl_adaptor_comp_added = true;
+ else
+ idx--;
+ }
+ } 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.id >= MAX_CRTC) {
+ ret = dev_err_probe(dev, -EINVAL,
+ "Invalid endpoint%u number\n", of_ep.port);
+ break;
+ }
+
+ output_present[of_ep.id] = 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;
@@ -824,7 +1039,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),
@@ -846,12 +1085,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)) {
@@ -860,8 +1098,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;
@@ -890,22 +1126,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 78d698ede1bf..7e54d86e25a3 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 c255559cc56e..e036d9394c23 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -904,9 +904,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.45.0
Hi, Angelo:
On Thu, 2024-05-16 at 10:11 +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.
>
> Reviewed-by: Rob Herring (Arm) <[email protected]>
> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 28 +++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> index b3c6888c1457..0ef67ca4122b 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> @@ -93,6 +93,34 @@ 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 multiple display outputs per MMSYS.
The display pipeline number usually depend on how many display interface. Display interface is in the end of pipeline.
In below case, two RDMA is merged into one pipeline and output to one display interface DP_INTF. This is usually ONE display.
RDMA -+
Merge -> ... -> DP_INTF
RDMA -+
In below case, one RDMA data output to two display interface DSI and DPI. This is usually TWO display with the same content.
+-> DSI
RDMA -> ... -> +
+-> DPI
So the display pipeline number does not depend on the number of first component. It usually depend on the number of display interface.
Regards,
CK
> + 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
> +
> + oneOf:
> + - required:
> + - endpoint@0
> + - required:
> + - endpoint@1
> + - required:
> + - endpoint@2
> +
> required:
> - compatible
> - reg
Il 16/05/24 11:23, CK Hu (胡俊光) ha scritto:
> Hi, Angelo:
>
> On Thu, 2024-05-16 at 10:11 +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.
>>
>> Reviewed-by: Rob Herring (Arm) <[email protected]>
>> Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
>> ---
>> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 28 +++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> index b3c6888c1457..0ef67ca4122b 100644
>> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> @@ -93,6 +93,34 @@ 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 multiple display outputs per MMSYS.
>
> The display pipeline number usually depend on how many display interface. Display interface is in the end of pipeline.
>
I have never stated that the display pipeline number depends on that.
Plus, the display interface is not described in the mmsys binding: this document
is only saying that mmsys' endpoint is to be connected to a (supported) component
of your choice. Nothing else.
> In below case, two RDMA is merged into one pipeline and output to one display interface DP_INTF. This is usually ONE display.
>
> RDMA -+
> Merge -> ... -> DP_INTF
> RDMA -+
>
> In below case, one RDMA data output to two display interface DSI and DPI. This is usually TWO display with the same content.
>
> +-> DSI
> RDMA -> ... -> +
> +-> DPI
>
The actual content of a display is a software capability - if the hardware supports
that, and some MediaTek SoCs do, the connection does not happen at the endpoint of
mmsys, but later.
> So the display pipeline number does not depend on the number of first component. It usually depend on the number of display interface.
>
I sure agree with that, but again, I have *never stated* that the display pipeline
number depends on the number of the first component.
> Regards,
> CK
>
>
>> + 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
>> +
>> + oneOf:
>> + - required:
>> + - endpoint@0
>> + - required:
>> + - endpoint@1
>> + - required:
>> + - endpoint@2
>> +
>> required:
>> - compatible
>> - reg
Hi Angelo,
On Thu May 16, 2024 at 10:11 AM CEST, AngeloGioacchino Del Regno wrote:
> 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.
paths might be optional, see comment in mtk_drm_kms_init(). But with
this patch, you'll get an -EINVAL with a disabled path. See my
proposals how to fix that below.
With these changes and the following two patches I was able to get
DisplayPort working on vdosys1. vdosys0 wasn't used at all.
https://lore.kernel.org/r/[email protected]/
https://lore.kernel.org/r/[email protected]/
I've already successfully tested a former version with DSI output on
vdosys0.
Thanks for working on this!
> +/**
> + * 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_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;
> + bool ovl_adaptor_comp_added = false;
> + 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 && temp_path[idx] == DDP_COMPONENT_DRM_OVL_ADAPTOR) {
> + dev_err(dev, "Adding OVL Adaptor for %pOF\n", next);
> + ovl_adaptor_comp_added = true;
> + } else {
> + 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;
> + }
> + }
> + idx++;
> +
> + /*
> + * 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;
> + }
> +
> + /*
> + * If this is an OVL adaptor exclusive component and one of those
> + * was already added, don't add another instance of the generic
> + * DDP_COMPONENT_OVL_ADAPTOR, as this is used only to decide whether
> + * to probe that component master driver of which only one instance
> + * is needed and possible.
> + */
> + if (temp_path[idx] == DDP_COMPONENT_DRM_OVL_ADAPTOR) {
> + if (!ovl_adaptor_comp_added)
> + ovl_adaptor_comp_added = true;
> + else
> + idx--;
> + }
> + } while (++idx < DDP_COMPONENT_DRM_ID_MAX);
/* The device might not be disabled. In that case, don't check the last
* entry but just report the missing device. */
if (ret == -ENODEV)
return ret;
> +
> + /* 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.id >= MAX_CRTC) {
> + ret = dev_err_probe(dev, -EINVAL,
> + "Invalid endpoint%u number\n", of_ep.port);
> + break;
> + }
> +
> + output_present[of_ep.id] = 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)
if (ret && ret != -ENODEV)
> + 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)
likewise
> + 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)
likewise
> + return ret;
> + }
> +
> + return 0;
> +}
-michael
Hi Angelo,
On 16/05/2024 10:11, AngeloGioacchino Del Regno wrote:
> + oneOf:
> + - required:
> + - endpoint@0
> + - required:
> + - endpoint@1
> + - required:
> + - endpoint@2
I'm not sure this is what you expect because I must remove this part to pass the dt-validate.
I have 2 possible display at the same time (DSI and DPI), then I add this in my DTSI:
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>;
};
};
};
But the DTS check returns me an error:
dt-validate -s Documentation/devicetree/bindings arch/arm64/boot/dts/mediatek/mt8365-evk.dtb
/home/*******/linux-upstream/arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: syscon@14000000: port:
More than one condition true in oneOf schema:
{'$ref': '/schemas/graph.yaml#/properties/port',
'oneOf': [{'required': ['endpoint@0']},
{'required': ['endpoint@1']},
{'required': ['endpoint@2']}],
'properties': {'endpoint@0': {'$ref': '/schemas/graph.yaml#/properties/endpoint'},
'endpoint@1': {'$ref': '/schemas/graph.yaml#/properties/endpoint'},
'endpoint@2': {'$ref': '/schemas/graph.yaml#/properties/endpoint'}}}
from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#
In other hand, if I use "ports" to keep only one endpoint for each port:
mmsys: syscon@14000000 {
compatible = "mediatek,mt8365-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
#clock-cells = <1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
mmsys_main: endpoint@0 {
reg = <0>;
remote-endpoint = <&ovl0_in>;
};
};
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
mmsys_ext: endpoint@1 {
reg = <1>;
remote-endpoint = <&rdma1_in>;
};
};
};
};
The DTS check returns another error:
dt-validate -s Documentation/devicetree/bindings arch/arm64/boot/dts/mediatek/mt8365-evk.dtb
/home/*******/linux-upstream/arch/arm64/boot/dts/mediatek/mt8365-evk.dtb: syscon@14000000: 'ports'
does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#
Additionally, with the last DTS example, displays aren't working, probably because "ports" isn't
well parsed.
So, I don't know how you want to manage multiple display, but IMHO there are 2 ways:
- removing the current "oneOf".
- adding the "ports" support in the documentation and driver (to be parsed).
Still possible I missed something and I doing shit :)
--
Regards,
Alexandre
Il 17/05/24 11:49, Michael Walle ha scritto:
> Hi Angelo,
>
> On Thu May 16, 2024 at 10:11 AM CEST, AngeloGioacchino Del Regno wrote:
>> 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.
>
> paths might be optional, see comment in mtk_drm_kms_init(). But with
> this patch, you'll get an -EINVAL with a disabled path. See my
> proposals how to fix that below.
I might not be understanding the reason behind allowing that but, per my logic, if
a board does have a path, then it's written in devicetree and enabled - otherwise,
it should not be there at all, in principle.
Can you explain a bit more extensively the reason(s) why we need to account
for disabled paths?
>
> With these changes and the following two patches I was able to get
> DisplayPort working on vdosys1. vdosys0 wasn't used at all.
> https://lore.kernel.org/r/[email protected]/
> https://lore.kernel.org/r/[email protected]/
>
> I've already successfully tested a former version with DSI output on
> vdosys0.
>
> Thanks for working on this!
>
Thank you for helping with the testing! :-)
Cheers,
Angelo
>> +/**
>> + * 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_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;
>> + bool ovl_adaptor_comp_added = false;
>> + 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 && temp_path[idx] == DDP_COMPONENT_DRM_OVL_ADAPTOR) {
>> + dev_err(dev, "Adding OVL Adaptor for %pOF\n", next);
>> + ovl_adaptor_comp_added = true;
>> + } else {
>> + 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;
>> + }
>> + }
>> + idx++;
>> +
>> + /*
>> + * 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;
>> + }
>> +
>> + /*
>> + * If this is an OVL adaptor exclusive component and one of those
>> + * was already added, don't add another instance of the generic
>> + * DDP_COMPONENT_OVL_ADAPTOR, as this is used only to decide whether
>> + * to probe that component master driver of which only one instance
>> + * is needed and possible.
>> + */
>> + if (temp_path[idx] == DDP_COMPONENT_DRM_OVL_ADAPTOR) {
>> + if (!ovl_adaptor_comp_added)
>> + ovl_adaptor_comp_added = true;
>> + else
>> + idx--;
>> + }
>> + } while (++idx < DDP_COMPONENT_DRM_ID_MAX);
>
> /* The device might not be disabled. In that case, don't check the last
> * entry but just report the missing device. */
> if (ret == -ENODEV)
> return ret;
>
>> +
>> + /* 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.id >= MAX_CRTC) {
>> + ret = dev_err_probe(dev, -EINVAL,
>> + "Invalid endpoint%u number\n", of_ep.port);
>> + break;
>> + }
>> +
>> + output_present[of_ep.id] = 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)
> if (ret && ret != -ENODEV)
>
>> + 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)
> likewise
>
>> + 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)
> likewise
>
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>
> -michael
On 20/05/2024 12:53, AngeloGioacchino Del Regno wrote:
>> So, I don't know how you want to manage multiple display, but IMHO there are 2 ways:
>> - removing the current "oneOf".
>
> ...eh I think this should be anyOf instead :-)
>
> I'll check later and send a v5.
"anyOf" behavior works as expected on my side, dt-validate pass ;)
--
Regards,
Alexandre
Il 20/05/24 13:49, Alexandre Mergnat ha scritto:
>
>
> On 20/05/2024 12:53, AngeloGioacchino Del Regno wrote:
>>> So, I don't know how you want to manage multiple display, but IMHO there are 2
>>> ways:
>>> - removing the current "oneOf".
>>
>> ...eh I think this should be anyOf instead :-)
>>
>> I'll check later and send a v5.
>
> "anyOf" behavior works as expected on my side, dt-validate pass ;)
>
Hey, thanks for the test, buys me some important time.
Cheers!
Angelo
On 20/05/2024 13:55, AngeloGioacchino Del Regno wrote:
> Il 20/05/24 13:49, Alexandre Mergnat ha scritto:
>>
>>
>> On 20/05/2024 12:53, AngeloGioacchino Del Regno wrote:
>>>> So, I don't know how you want to manage multiple display, but IMHO there are 2 ways:
>>>> - removing the current "oneOf".
>>>
>>> ...eh I think this should be anyOf instead :-)
>>>
>>> I'll check later and send a v5.
>>
>> "anyOf" behavior works as expected on my side, dt-validate pass ;)
>>
>
> Hey, thanks for the test, buys me some important time.
You're welcome, after that:
Reviewed-by: Alexandre Mergnat <[email protected]>
Tested-by: Alexandre Mergnat <[email protected]>
--
Regards,
Alexandre
Reviewed-by: Alexandre Mergnat <[email protected]>
Tested-by: Alexandre Mergnat <[email protected]>
On 16/05/2024 10:11, 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.
>
> Reviewed-by: Rob Herring (Arm)<[email protected]>
> Signed-off-by: AngeloGioacchino Del Regno<[email protected]>
--
Regards,
Alexandre
Reviewed-by: Alexandre Mergnat <[email protected]>
Tested-by: Alexandre Mergnat <[email protected]>
On 16/05/2024 10:11, AngeloGioacchino Del Regno wrote:
> 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.
--
Regards,
Alexandre
Hi Angelo,
> >> 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.
> >
> > paths might be optional, see comment in mtk_drm_kms_init(). But with
> > this patch, you'll get an -EINVAL with a disabled path. See my
> > proposals how to fix that below.
>
> I might not be understanding the reason behind allowing that but, per my logic, if
> a board does have a path, then it's written in devicetree and enabled - otherwise,
> it should not be there at all, in principle.
>
>
> Can you explain a bit more extensively the reason(s) why we need to account
> for disabled paths?
Paths should be (and this was already supported before this patch
with the hardcoded paths) disabled with the status property. This
way you can have a common board configuration where all the paths
are already described but are disabled. An overlay (or maybe another
dts variant) can then just enable the pipeline/output port by
overwriting the status property.
Also, this is the usual DT usage, as a node with status = "disabled"
should just be skipped. Without handling this, the current code will
return -EINVAL during probe (IIRC, my vacation might have reset my
memory :o).
-michael
On Thu, May 16, 2024 at 10:11:01AM +0200, AngeloGioacchino Del Regno wrote:
> Changes in v4:
> - Fixed a typo that caused pure OF graphs pipelines multiple
> concurrent outputs to not get correctly parsed (port->id);
> - Added OVL_ADAPTOR support for OF graph specified pipelines;
> - Now tested with fully OF Graph specified pipelines on MT8195
> Chromebooks and MT8395 boards;
> - Rebased on next-20240516
>
> Changes in v3:
> - Rebased on next-20240502 because of renames in mediatek-drm
>
> 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.
>
> This series is essential to enable support for the MT8195/MT8395 EVK,
> Kontron i1200, Radxa NIO-12L and, mainly, for non-Chromebook boards
> and Chromebooks to co-exist without conflicts.
>
> 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, and pure OF graph support including pipelines that
> require OVL_ADAPTOR support.
>
> 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 | 28 ++
> .../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_disp_drv.h | 1 +
> .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 40 ++-
> drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 282 ++++++++++++++++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
> drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
> 23 files changed, 713 insertions(+), 41 deletions(-)
>
> --
> 2.45.0
>
Hi Angelo,
I'm seeing issues with this series on MT8195-Tomato running on next-20240606:
[ 4.770965] refcount_t: addition on 0; use-after-free.
[ 4.770975] WARNING: CPU: 5 PID: 171 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144
[ 4.770983] Modules linked in: videobuf2_common rfkill(+) kfifo_buf onboard_usb_dev(+) mc hid_multitouch(+) cros_ec_chardev cros_kbd_led_backlight snd_sof_mt8195 elan_i2c mtk_adsp_common sbs_battery snd_soc_mt8195_afe snd_sof_xtensa_dsp pwm_bl lvts_thermal(+) mt6577_auxadc pcie_mediatek_gen3(+) snd_sof_of coreboot_table backlight mtk_scp mtk_rpmsg snd_sof mtk_svs snd_sof_utils mtk_scp_ipi mt8195_mt6359 ramoops reed_solomon
[ 4.771000] CPU: 5 PID: 171 Comm: (udev-worker) Not tainted 6.10.0-rc2-next-20240606-00005-gf8e90366fe4b #472
[ 4.771002] Hardware name: Acer Tomato (rev2) board (DT)
[ 4.771003] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4.771005] pc : refcount_warn_saturate+0xa0/0x144
[ 4.771007] lr : refcount_warn_saturate+0xa0/0x144
[ 4.771008] sp : ffff800080ce3950
[ 4.771009] x29: ffff800080ce3950 x28: ffff800080ce3c70 x27: ffff800080ce3c70
[ 4.771011] x26: 0000000000000000 x25: ffffaec95d6b53f0 x24: ffff5054d9468368
[ 4.771012] x23: ffff5054c0a81968 x22: 0000000000000000 x21: 0000000000000000
[ 4.771014] x20: ffff800080ce39d8 x19: ffff5054c0a81c68 x18: 0000000000000038
[ 4.771015] x17: ffffa18b9ed32000 x16: ffff800080028000 x15: fffffffffffeab58
[ 4.771017] x14: ffffaec95d181f48 x13: 00000000000006c6 x12: 0000000000000242
[ 4.771018] x11: fffffffffffeab58 x10: ffffaec95d1d9f48 x9 : 00000000fffff000
[ 4.771020] x8 : ffffaec95d181f48 x7 : ffffaec95d1d9f48 x6 : 0000000000000000
[ 4.771021] x5 : 80000000fffff000 x4 : 000000000000aff5 x3 : 00000000ffffffff
[ 4.771023] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff5054d8af33c0
[ 4.771024] Call trace:
[ 4.771025] refcount_warn_saturate+0xa0/0x144
[ 4.771027] klist_next+0x184/0x1a8
[ 4.771030] bus_for_each_dev+0x60/0xd4
[ 4.771033] driver_attach+0x24/0x30
[ 4.771035] bus_add_driver+0xe4/0x208
[ 4.771037] driver_register+0x60/0x128
[ 4.771039] __platform_driver_register+0x28/0x34
[ 4.771041] lvts_driver_init+0x20/0x1000 [lvts_thermal]
[ 4.771046] do_one_initcall+0x6c/0x1b0
[ 4.771048] do_init_module+0x60/0x1f0
[ 4.771050] load_module+0x191c/0x1b04
[ 4.771052] init_module_from_file+0x84/0xc0
[ 4.771054] __arm64_sys_finit_module+0x1b8/0x27c
[ 4.771056] invoke_syscall+0x48/0x118
[ 4.771059] el0_svc_common.constprop.0+0x40/0xe0
[ 4.771061] do_el0_svc+0x1c/0x28
[ 4.771063] el0_svc+0x34/0xdc
[ 4.771065] el0t_64_sync_handler+0xc0/0xc4
[ 4.771067] el0t_64_sync+0x190/0x194
[ 4.837189] refcount_t: saturated; leaking memory.
[ 4.837197] WARNING: CPU: 7 PID: 170 at lib/refcount.c:22 refcount_warn_saturate+0x74/0x144
[ 4.837205] Modules linked in: phy_mtk_dp(+) videodev videobuf2_common rfkill kfifo_buf onboard_usb_dev(+) mc hid_multitouch(+) cros_ec_chardev cros_kbd_led_backlight snd_sof_mt8195 elan_i2c mtk_adsp_common sbs_battery snd_soc_mt8195_afe snd_sof_xtensa_dsp pwm_bl lvts_thermal mt6577_auxadc pcie_mediatek_gen3(+) snd_sof_of coreboot_table backlight mtk_scp mtk_rpmsg snd_sof mtk_svs snd_sof_utils mtk_scp_ipi mt8195_mt6359 ramoops reed_solomon
[ 4.837221] CPU: 7 PID: 170 Comm: (udev-worker) Tainted: G W 6.10.0-rc2-next-20240606-00005-gf8e90366fe4b #472
[ 4.837224] Tainted: [W]=WARN
[ 4.837224] Hardware name: Acer Tomato (rev2) board (DT)
[ 4.837225] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4.837227] pc : refcount_warn_saturate+0x74/0x144
[ 4.837229] lr : refcount_warn_saturate+0x74/0x144
[ 4.837230] sp : ffff800080cdb950
[ 4.837231] x29: ffff800080cdb950 x28: ffff800080cdbc70 x27: ffff800080cdbc70
[ 4.837232] x26: 0000000000000000 x25: ffffaec95d6b53f0 x24: ffff5054d66544e8
[ 4.837234] x23: ffff5054c0a81968 x22: 0000000000000000 x21: 0000000000000000
[ 4.837235] x20: ffff800080cdb9d8 x19: ffff5054c0a81c68 x18: 0000000000000030
[ 4.837236] x17: 0000000000000000 x16: ffffaec95b03d998 x15: fffffffffffecb70
[ 4.837238] x14: ffffaec95d181f48 x13: 0000000000000825 x12: 00000000000002b7
[ 4.837239] x11: fffffffffffecb70 x10: ffffaec95d1d9f48 x9 : 00000000fffff000
[ 4.837240] x8 : ffffaec95d181f48 x7 : ffffaec95d1d9f48 x6 : 0000000000000000
[ 4.837242] x5 : 80000000fffff000 x4 : 000000000000aff5 x3 : 00000000ffffffff
[ 4.837243] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff5054d8af4500
[ 4.837245] Call trace:
[ 4.837246] refcount_warn_saturate+0x74/0x144
[ 4.837247] klist_next+0x178/0x1a8
[ 4.837250] bus_for_each_dev+0x60/0xd4
[ 4.837253] driver_attach+0x24/0x30
[ 4.837255] bus_add_driver+0xe4/0x208
[ 4.837257] driver_register+0x60/0x128
[ 4.837259] __platform_driver_register+0x28/0x34
[ 4.837260] mtk_dp_phy_driver_init+0x20/0x1000 [phy_mtk_dp]
[ 4.837263] do_one_initcall+0x6c/0x1b0
[ 4.837265] do_init_module+0x60/0x1f0
[ 4.837268] load_module+0x191c/0x1b04
[ 4.837269] init_module_from_file+0x84/0xc0
[ 4.837271] __arm64_sys_finit_module+0x1b8/0x27c
[ 4.837273] invoke_syscall+0x48/0x118
[ 4.837276] el0_svc_common.constprop.0+0x40/0xe0
[ 4.837277] do_el0_svc+0x1c/0x28
[ 4.837279] el0_svc+0x34/0xdc
[ 4.837282] el0t_64_sync_handler+0xc0/0xc4
[ 4.837284] el0t_64_sync+0x190/0x194
and many more occurrences.
Config: http://0x0.st/XbqI.txt
Full kernel logs: http://0x0.st/Xbq6.txt
Thanks,
N?colas
Il 07/06/24 01:25, Nícolas F. R. A. Prado ha scritto:
> On Thu, May 16, 2024 at 10:11:01AM +0200, AngeloGioacchino Del Regno wrote:
>> Changes in v4:
>> - Fixed a typo that caused pure OF graphs pipelines multiple
>> concurrent outputs to not get correctly parsed (port->id);
>> - Added OVL_ADAPTOR support for OF graph specified pipelines;
>> - Now tested with fully OF Graph specified pipelines on MT8195
>> Chromebooks and MT8395 boards;
>> - Rebased on next-20240516
>>
>> Changes in v3:
>> - Rebased on next-20240502 because of renames in mediatek-drm
>>
>> 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.
>>
>> This series is essential to enable support for the MT8195/MT8395 EVK,
>> Kontron i1200, Radxa NIO-12L and, mainly, for non-Chromebook boards
>> and Chromebooks to co-exist without conflicts.
>>
>> 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, and pure OF graph support including pipelines that
>> require OVL_ADAPTOR support.
>>
>> 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 | 28 ++
>> .../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_disp_drv.h | 1 +
>> .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 40 ++-
>> drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 282 ++++++++++++++++--
>> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
>> drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
>> 23 files changed, 713 insertions(+), 41 deletions(-)
>>
>> --
>> 2.45.0
>>
>
> Hi Angelo,
>
> I'm seeing issues with this series on MT8195-Tomato running on next-20240606:
Thanks Nicolas - yes I've recently seen that too, I also had feedback for that
something like 3 weeks ago.
I wanted to fix that but had no time to do the job as I had to care about some
other stuff....
Anyway, I should be able to send a v5 with a fix for that issue tomorrow.
Thanks again!
Angelo
>
> [ 4.770965] refcount_t: addition on 0; use-after-free.
> [ 4.770975] WARNING: CPU: 5 PID: 171 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144
> [ 4.770983] Modules linked in: videobuf2_common rfkill(+) kfifo_buf onboard_usb_dev(+) mc hid_multitouch(+) cros_ec_chardev cros_kbd_led_backlight snd_sof_mt8195 elan_i2c mtk_adsp_common sbs_battery snd_soc_mt8195_afe snd_sof_xtensa_dsp pwm_bl lvts_thermal(+) mt6577_auxadc pcie_mediatek_gen3(+) snd_sof_of coreboot_table backlight mtk_scp mtk_rpmsg snd_sof mtk_svs snd_sof_utils mtk_scp_ipi mt8195_mt6359 ramoops reed_solomon
> [ 4.771000] CPU: 5 PID: 171 Comm: (udev-worker) Not tainted 6.10.0-rc2-next-20240606-00005-gf8e90366fe4b #472
> [ 4.771002] Hardware name: Acer Tomato (rev2) board (DT)
> [ 4.771003] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 4.771005] pc : refcount_warn_saturate+0xa0/0x144
> [ 4.771007] lr : refcount_warn_saturate+0xa0/0x144
> [ 4.771008] sp : ffff800080ce3950
> [ 4.771009] x29: ffff800080ce3950 x28: ffff800080ce3c70 x27: ffff800080ce3c70
> [ 4.771011] x26: 0000000000000000 x25: ffffaec95d6b53f0 x24: ffff5054d9468368
> [ 4.771012] x23: ffff5054c0a81968 x22: 0000000000000000 x21: 0000000000000000
> [ 4.771014] x20: ffff800080ce39d8 x19: ffff5054c0a81c68 x18: 0000000000000038
> [ 4.771015] x17: ffffa18b9ed32000 x16: ffff800080028000 x15: fffffffffffeab58
> [ 4.771017] x14: ffffaec95d181f48 x13: 00000000000006c6 x12: 0000000000000242
> [ 4.771018] x11: fffffffffffeab58 x10: ffffaec95d1d9f48 x9 : 00000000fffff000
> [ 4.771020] x8 : ffffaec95d181f48 x7 : ffffaec95d1d9f48 x6 : 0000000000000000
> [ 4.771021] x5 : 80000000fffff000 x4 : 000000000000aff5 x3 : 00000000ffffffff
> [ 4.771023] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff5054d8af33c0
> [ 4.771024] Call trace:
> [ 4.771025] refcount_warn_saturate+0xa0/0x144
> [ 4.771027] klist_next+0x184/0x1a8
> [ 4.771030] bus_for_each_dev+0x60/0xd4
> [ 4.771033] driver_attach+0x24/0x30
> [ 4.771035] bus_add_driver+0xe4/0x208
> [ 4.771037] driver_register+0x60/0x128
> [ 4.771039] __platform_driver_register+0x28/0x34
> [ 4.771041] lvts_driver_init+0x20/0x1000 [lvts_thermal]
> [ 4.771046] do_one_initcall+0x6c/0x1b0
> [ 4.771048] do_init_module+0x60/0x1f0
> [ 4.771050] load_module+0x191c/0x1b04
> [ 4.771052] init_module_from_file+0x84/0xc0
> [ 4.771054] __arm64_sys_finit_module+0x1b8/0x27c
> [ 4.771056] invoke_syscall+0x48/0x118
> [ 4.771059] el0_svc_common.constprop.0+0x40/0xe0
> [ 4.771061] do_el0_svc+0x1c/0x28
> [ 4.771063] el0_svc+0x34/0xdc
> [ 4.771065] el0t_64_sync_handler+0xc0/0xc4
> [ 4.771067] el0t_64_sync+0x190/0x194
>
>
> [ 4.837189] refcount_t: saturated; leaking memory.
> [ 4.837197] WARNING: CPU: 7 PID: 170 at lib/refcount.c:22 refcount_warn_saturate+0x74/0x144
> [ 4.837205] Modules linked in: phy_mtk_dp(+) videodev videobuf2_common rfkill kfifo_buf onboard_usb_dev(+) mc hid_multitouch(+) cros_ec_chardev cros_kbd_led_backlight snd_sof_mt8195 elan_i2c mtk_adsp_common sbs_battery snd_soc_mt8195_afe snd_sof_xtensa_dsp pwm_bl lvts_thermal mt6577_auxadc pcie_mediatek_gen3(+) snd_sof_of coreboot_table backlight mtk_scp mtk_rpmsg snd_sof mtk_svs snd_sof_utils mtk_scp_ipi mt8195_mt6359 ramoops reed_solomon
> [ 4.837221] CPU: 7 PID: 170 Comm: (udev-worker) Tainted: G W 6.10.0-rc2-next-20240606-00005-gf8e90366fe4b #472
> [ 4.837224] Tainted: [W]=WARN
> [ 4.837224] Hardware name: Acer Tomato (rev2) board (DT)
> [ 4.837225] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 4.837227] pc : refcount_warn_saturate+0x74/0x144
> [ 4.837229] lr : refcount_warn_saturate+0x74/0x144
> [ 4.837230] sp : ffff800080cdb950
> [ 4.837231] x29: ffff800080cdb950 x28: ffff800080cdbc70 x27: ffff800080cdbc70
> [ 4.837232] x26: 0000000000000000 x25: ffffaec95d6b53f0 x24: ffff5054d66544e8
> [ 4.837234] x23: ffff5054c0a81968 x22: 0000000000000000 x21: 0000000000000000
> [ 4.837235] x20: ffff800080cdb9d8 x19: ffff5054c0a81c68 x18: 0000000000000030
> [ 4.837236] x17: 0000000000000000 x16: ffffaec95b03d998 x15: fffffffffffecb70
> [ 4.837238] x14: ffffaec95d181f48 x13: 0000000000000825 x12: 00000000000002b7
> [ 4.837239] x11: fffffffffffecb70 x10: ffffaec95d1d9f48 x9 : 00000000fffff000
> [ 4.837240] x8 : ffffaec95d181f48 x7 : ffffaec95d1d9f48 x6 : 0000000000000000
> [ 4.837242] x5 : 80000000fffff000 x4 : 000000000000aff5 x3 : 00000000ffffffff
> [ 4.837243] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff5054d8af4500
> [ 4.837245] Call trace:
> [ 4.837246] refcount_warn_saturate+0x74/0x144
> [ 4.837247] klist_next+0x178/0x1a8
> [ 4.837250] bus_for_each_dev+0x60/0xd4
> [ 4.837253] driver_attach+0x24/0x30
> [ 4.837255] bus_add_driver+0xe4/0x208
> [ 4.837257] driver_register+0x60/0x128
> [ 4.837259] __platform_driver_register+0x28/0x34
> [ 4.837260] mtk_dp_phy_driver_init+0x20/0x1000 [phy_mtk_dp]
> [ 4.837263] do_one_initcall+0x6c/0x1b0
> [ 4.837265] do_init_module+0x60/0x1f0
> [ 4.837268] load_module+0x191c/0x1b04
> [ 4.837269] init_module_from_file+0x84/0xc0
> [ 4.837271] __arm64_sys_finit_module+0x1b8/0x27c
> [ 4.837273] invoke_syscall+0x48/0x118
> [ 4.837276] el0_svc_common.constprop.0+0x40/0xe0
> [ 4.837277] do_el0_svc+0x1c/0x28
> [ 4.837279] el0_svc+0x34/0xdc
> [ 4.837282] el0t_64_sync_handler+0xc0/0xc4
> [ 4.837284] el0t_64_sync+0x190/0x194
>
>
> and many more occurrences.
>
> Config: http://0x0.st/XbqI.txt
> Full kernel logs: http://0x0.st/Xbq6.txt
>
> Thanks,
> Nícolas