Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint defines the starting point for one of the (currently three)
possible hardware paths.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index b3c6888c1457..90758bb5bcb1 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
On Thu, Apr 4, 2024 at 4:16 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths > per HW instance (so potentially up to six displays for multi-vdo SoCs). > > The MMSYS or VDOSYS is always the first component in the DDP pipeline, > so it only supports an output port with multiple endpoints - where each > endpoint defines the starting point for one of the (currently three) > possible hardware paths. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > index b3c6888c1457..90758bb5bcb1 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 > + Technically the mmsys device serves as an glue layer for the display pipeline, providing things like clock control and signal routing; the device itself is not part of the pipeline, and probably shouldn't be part of the graph? ChenYu > required: > - compatible > - reg > -- > 2.44.0 >
Il 08/04/24 05:20, Chen-Yu Tsai ha scritto: > On Thu, Apr 4, 2024 at 4:16 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> wrote: >> >> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths >> per HW instance (so potentially up to six displays for multi-vdo SoCs). >> >> The MMSYS or VDOSYS is always the first component in the DDP pipeline, >> so it only supports an output port with multiple endpoints - where each >> endpoint defines the starting point for one of the (currently three) >> possible hardware paths. >> >> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >> --- >> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++ >> 1 file changed, 23 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml >> index b3c6888c1457..90758bb5bcb1 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 >> + > > Technically the mmsys device serves as an glue layer for the display > pipeline, providing things like clock control and signal routing; the > device itself is not part of the pipeline, and probably shouldn't be > part of the graph? > That is (only) partially true: in the case of older SoCs, the MMSYS can only connect to a single first IP of the pipeline, but in the case of newer ones, and especially (but not limited to) MT8195 onwards having multiple instances of VDOSYS, that really becomes part of the pipeline. This is not because of the possible different first IP in the pipeline, but because of support for dual-interface (DSI and DP) that, in even newer SoCs, can be done with cross-mmsys (cross-vdosys, actually...) as some of those do have the two in different VDOs. So yes, this can be done without the graph in MMSYS *in this precise moment in time*, but we'll anyway end up adding it sooner than later - and I'm doing this right now, instead of later, because it's also simplifying the implementation so like that I'm "catching two birds with one stone" :-) Cheers, Angelo > ChenYu > >> required: >> - compatible >> - reg >> -- >> 2.44.0 >>
On Mon, Apr 8, 2024 at 6:16 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 08/04/24 05:20, Chen-Yu Tsai ha scritto: > > On Thu, Apr 4, 2024 at 4:16 PM AngeloGioacchino Del Regno > > <angelogioacchino.delregno@collabora.com> wrote: > >> > >> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths > >> per HW instance (so potentially up to six displays for multi-vdo SoCs). > >> > >> The MMSYS or VDOSYS is always the first component in the DDP pipeline, > >> so it only supports an output port with multiple endpoints - where each > >> endpoint defines the starting point for one of the (currently three) > >> possible hardware paths. > >> > >> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > >> --- > >> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++ > >> 1 file changed, 23 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > >> index b3c6888c1457..90758bb5bcb1 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 > >> + > > > > Technically the mmsys device serves as an glue layer for the display > > pipeline, providing things like clock control and signal routing; the > > device itself is not part of the pipeline, and probably shouldn't be > > part of the graph? > > > > That is (only) partially true: in the case of older SoCs, the MMSYS can only > connect to a single first IP of the pipeline, but in the case of newer ones, > and especially (but not limited to) MT8195 onwards having multiple instances > of VDOSYS, that really becomes part of the pipeline. > > This is not because of the possible different first IP in the pipeline, but > because of support for dual-interface (DSI and DP) that, in even newer SoCs, > can be done with cross-mmsys (cross-vdosys, actually...) as some of those do > have the two in different VDOs. > > So yes, this can be done without the graph in MMSYS *in this precise moment in > time*, but we'll anyway end up adding it sooner than later - and I'm doing this > right now, instead of later, because it's also simplifying the implementation > so like that I'm "catching two birds with one stone" :-) I see. Thanks for sorting it out. We had something similar on Allwinner platforms but it was never as complex or flexible as this. ChenYu > Cheers, > Angelo > > > ChenYu > > > >> required: > >> - compatible > >> - reg > >> -- > >> 2.44.0 > >> > >
Hi AngeloGioacchino,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on robh/for-next pza/reset/next linus/master v6.9-rc2 next-20240404]
[cannot apply to pza/imx-drm/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/AngeloGioacchino-Del-Regno/dt-bindings-display-mediatek-Add-OF-graph-support-for-board-path/20240404-161930
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/20240404081635.91412-3-angelogioacchino.delregno%40collabora.com
patch subject: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240405/202404050315.7WBDW2E8-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404050315.7WBDW2E8-lkp@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties: 'required' should not be valid under {'$ref': '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
--
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/net/snps,dwmac.yaml: mac-mode: missing type definition
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Thu, 04 Apr 2024 10:16:34 +0200, AngeloGioacchino Del Regno wrote:
> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
> per HW instance (so potentially up to six displays for multi-vdo SoCs).
>
> The MMSYS or VDOSYS is always the first component in the DDP pipeline,
> so it only supports an output port with multiple endpoints - where each
> endpoint defines the starting point for one of the (currently three)
> possible hardware paths.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties: 'required' should not be valid under {'$ref': '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.example.dtb: /example-0/syscon@14000000: failed to match any schema with compatible: ['mediatek,mt8173-mmsys', 'syscon']
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240404081635.91412-3-angelogioacchino.delregno@collabora.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
© 2016 - 2026 Red Hat, Inc.