diff for duplicates of <fbb00e4cc81d8e1e47fac01c3c9146148747fa55.camel@mediatek.com> diff --git a/N1/2.bin b/N1/2.bin new file mode 100644 index 0000000..36066a7 --- /dev/null +++ b/N1/2.bin @@ -0,0 +1,263 @@ +<html><body><p> +<pre> +On Tue, 2024-06-11 at 08:54 +0200, AngeloGioacchino Del Regno wrote: +> Il 11/06/24 08:48, CK Hu (胡俊光) ha scritto: +> > On Mon, 2024-06-10 at 10:28 +0200, AngeloGioacchino Del Regno wrote: +> > > Il 06/06/24 07:29, CK Hu (胡俊光) ha scritto: +> > > > Hi, Angelo: +> > > >  +> > > > On Wed, 2024-06-05 at 13:15 +0200, AngeloGioacchino Del Regno wrote: +> > > > > Il 05/06/24 03:38, CK Hu (胡俊光) ha scritto: +> > > > > > Hi, Angelo: +> > > > > >  +> > > > > > On Tue, 2024-05-21 at 09:57 +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) <robh@kernel.org> +> > > > > > > Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> +> > > > > > > Tested-by: Alexandre Mergnat <amergnat@baylibre.com> +> > > > > > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> +> > > > > > > --- +> > > > > > >     .../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. +> > > > > >  +> > > > > > This patch looks good to me. Just want to share another information for you. +> > > > > > Here is an example that mmsys/vdosys could point to the display interface node. +> > > > > >  +> > > > > > vdosys0: syscon@1c01a000 { +> > > > > >              mmsys-display-interface = <&dsi0>, <&dsi1>, <&dp_intf0>; +> > > > > > }; +> > > > > >      +> > > > > > vdosys1: syscon@1c100000 { +> > > > > >              mmsys-display-interface = <&dp_intf1>; +> > > > > > }; +> > > > > >  +> > > > > > There is no conflict that mmsys/vdosys point to first component of one display pipeline or point to display interface. +> > > > > > Both could co-exist. +> > > > > >  +> > > > >  +> > > > > Hey CK, +> > > > >  +> > > > > yes, this could be an alternative to the OF graphs, and I'm sure that it'd work, +> > > > > even though this kind of solution would still require partial hardcoding of the +> > > > > display paths up until mmsys-display-interface (so, up until DSI0, or DSI1, etc). +> > > > >  +> > > > > The problem with a solution like this is that, well, even though it would work, +> > > > > even if we ignore the suboptimal partial hardcoding, OF graphs are something +> > > > > generic, while the mmsys-display-interface would be a MediaTek specific/custom +> > > > > property. +> > > > >  +> > > > > In the end, reusing generic kernel apis/interfaces/etc is always preferred +> > > > > compared to custom solutions, especially in this case, in which the generic +> > > > > stuff is on-par (or actually, depending purely on personal opinions, superior). +> > > > >  +> > > > > As for the two to co-exist, I'm not sure that this is actually needed, as the +> > > > > OF graphs are already (at the end of the graph) pointing to the display interface. +> > > > >  +> > > > > In any case, just as a reminder: if there will be any need to add any custom +> > > > > MediaTek specific properties later, it's ok and we can do that at any time. +> > > >  +> > > > The alternative solution is using OF graphs to point display interface and use MediaTek specific property to first component: +> > > >  +> > > > vdosys0: syscon@1c01a000 { +> > > >             ports { +> > > >                      port@0 { +> > > >                                endpoint { +> > > >                                         remote-endpoint = <&dsi0_endpoint>; +> > > >                                }; +> > > >                      }; +> > > >     +> > > >                      port@1 { +> > > >                                endpoint { +> > > >                                         remote-endpoint = <&dsi1_endpoint>; +> > > >                                }; +> > > >                      }; +> > > >     +> > > >                      port@2 { +> > > >                                endpoint { +> > > >                                         remote-endpoint = <&dp_intf0_endpoint>; +> > > >                                }; +> > > >                      }; +> > > >             }; +> > > >     +> > > >             display-first-component = <&ovl0>; +> > > > }; +> > > >  +> > > > And I agree to it's better to keep only OF graphs property, so it would be +> > > >  +> > > > vdosys0: syscon@1c01a000 { +> > > >             ports { +> > > >                      port@0 { +> > > >                                endpoint { +> > > >                                         remote-endpoint = <&dsi0_endpoint>; +> > > >                      +> > > >              }; +> > > >                      }; +> > > >     +> > > >                      port@1 { +> > > >                                endpoint { +> > > >                                         remote-endpoint = <&dsi1_endpoint>; +> > > >                              +> > > >      }; +> > > >                      }; +> > > >     +> > > >                      port@2 { +> > > >                                endpoint { +> > > >                                         remote-endpoint = <&dp_intf0_endpoint>; +> > > >                                } +> > > > ; +> > > >                      }; +> > > >             }; +> > > > }; +> > > >  +> > > > Maybe we could use OF graphs for both first component and display interface and drop using MediaTek specific property. +> > > >  +> > >  +> > > We could, or we can simply walk through the OF Graph in the driver and get the +> > > display interface like that, as it's board-specific ;-) +> > >  +> > > ...but anyway, let's see that later: after getting this series upstreamed, I will +> > > convert all MediaTek boards (including Chromebooks) to use the graphs instead, and +> > > you'll see that, at least for the currently supported boards, there's no need for +> > > any custom property. +> > >  +> > > Also, setting the DSI0/1/dpintf endpoint to VDO0 is technically wrong, as that is +> > > supposed to be the last one, and a graph is conceptually supposed to go from the +> > > first to the last in sequence. +> > >  +> > > *if* we will ever need (probably not) to get the VDO0 node to point directly to +> > > the last node for whatever reason, the right way would be the first one you said, +> > > so, mediatek,mmsys-display-interface = <&dsi0>, <&dsi1>, etc etc +> > >  +> > > ...or mediatek,mmsys-possible-displays = < ... phandles > +> > >  +> > > ...or anyway, many other solutions are possible - but again, I think this is not +> > > the right time to think about that. Knowing that there are eventual solutions for +> > > any need that might arise in the future is enough, IMO :-) +> >  +> > This is one routing of display pipeline and the relation of VDOSYS0 with display pipeline. +> >  +> >                 +-- VDOSYS0 ---------------------------------------------+ +> >                 |                                                        | +> >                 |                                                        | +> > DRAM -> IOMMU ---> OVL0 -> RDMA0 -> ... -> DSC0 -> MERGE0 -> DP_INTF0 ----> +> >                 |                                                        | +> >                 |                                                        | +> >                 +--------------------------------------------------------+ +> >  +> > Video data is read by IOMMU from DRAM and send to display pipeline. Then video data travel through first component to display interface. +> > VDOSYS0 manage each component in the pipeline include first component and display interface. +> > The management include clock gating, reset, video data input/output routing. +> > The relationship of VDOSYTS0 with first component is the same as the relationship of VDOSYS0 with display interface. +> > If VDOSYS0 is not suitable using OF graph point to display interface, VDOSYS0 is also not suitable using OF graph point to first component. +>  +> In the cases in which VDO goes directly to the display, it *is* possible to make it +> point directly to the display. +>  +> In the cases in which the pipeline is larger, VDO still points to the display, but +> only later in the pipeline. + +I mean VDOSYS0 is not suitable 'using OF graph' to point to both display interface and first component. +So VDOSYS0 should use specific property to point to both display interface and first component. +Maybe + +vdosys0 { +dma-device = <ovl0>; +display-interface = <&dsi0>, <&dsi1>, <&dp_intf0>; +}; + +Regards, +CK + +>  +> > The job of the component in display pipeline is to process the video data, +> > but the job of VDOSYS0 is to manage (clock gating, reset, routing) the pipeline. +> > If the OF graph is to show the video data travel path, VDOSYS0 should not exist in the OF graph. +> >  +> > Regards, +> > CK +> >  +> > >  +> > > Cheers, +> > > Angelo +> > >  +> > > > Regards, +> > > > CK +> > > >  +> > > > >  +> > > > > Cheers! +> > > > > Angelo +> > > > >  +> > > > > > 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 +> > > > > > > + +> > > > > > > +    anyOf: +> > > > > > > +      - required: +> > > > > > > +          - endpoint@0 +> > > > > > > +      - required: +> > > > > > > +          - endpoint@1 +> > > > > > > +      - required: +> > > > > > > +          - endpoint@2 +> > > > > > > + +> > > > > > >     required: +> > > > > > >       - compatible +> > > > > > >       - reg +> > > > >  +> > > > >  +> > >  +> > >  +>  +>  +>  + +</pre> +</p></body></html><!--type:text--><!--{--><pre>************* MEDIATEK Confidentiality Notice + ******************** +The information contained in this e-mail message (including any +attachments) may be confidential, proprietary, privileged, or otherwise +exempt from disclosure under applicable laws. It is intended to be +conveyed only to the designated recipient(s). Any use, dissemination, +distribution, printing, retaining or copying of this e-mail (including its +attachments) by unintended recipient(s) is strictly prohibited and may +be unlawful. If you are not an intended recipient of this e-mail, or believe + +that you have received this e-mail in error, please notify the sender +immediately (by replying to this e-mail), delete any and all copies of +this e-mail (including any attachments) from your system, and do not +disclose the content of this e-mail to any other person. Thank you! +</pre><!--}--> diff --git a/N1/2.hdr b/N1/2.hdr new file mode 100644 index 0000000..da1f671 --- /dev/null +++ b/N1/2.hdr @@ -0,0 +1,3 @@ +Content-Type: text/html; + charset="utf-8" +Content-Transfer-Encoding: base64 diff --git a/a/content_digest b/N1/content_digest index 5824b9f..d9d62ac 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -32,7 +32,7 @@ " Yu-chang Lee (\346\235\216\347\246\271\347\222\213) <Yu-chang.Lee@mediatek.com>" linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> " amergnat@baylibre.com <amergnat@baylibre.com>\0" - "\00:1\0" + "\01:1\0" "b\0" "On Tue, 2024-06-11 at 08:54 +0200, AngeloGioacchino Del Regno wrote:\n" "> Il 11/06/24 08:48, CK Hu (\350\203\241\344\277\212\345\205\211) ha scritto:\n" @@ -278,5 +278,270 @@ "> \n" "> \n" > + "\01:2\0" + "b\0" + "<html><body><p>\r\n" + "<pre>\r\n" + "On Tue, 2024-06-11 at 08:54 +0200, AngeloGioacchino Del Regno wrote:\r\n" + "> Il 11/06/24 08:48, CK Hu (胡俊光) ha scritto:\r\n" + "> > On Mon, 2024-06-10 at 10:28 +0200, AngeloGioacchino Del Regno wrote:\r\n" + "> > > Il 06/06/24 07:29, CK Hu (胡俊光) ha scritto:\r\n" + "> > > > Hi, Angelo:\r\n" + "> > > > \r\n" + "> > > > On Wed, 2024-06-05 at 13:15 +0200, AngeloGioacchino Del Regno wrote:\r\n" + "> > > > > Il 05/06/24 03:38, CK Hu (胡俊光) ha scritto:\r\n" + "> > > > > > Hi, Angelo:\r\n" + "> > > > > > \r\n" + "> > > > > > On Tue, 2024-05-21 at 09:57 +0200, AngeloGioacchino Del Regno wrote:\r\n" + "> > > > > > > Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths\r\n" + "> > > > > > > per HW instance (so potentially up to six displays for multi-vdo SoCs).\r\n" + "> > > > > > > \r\n" + "> > > > > > > The MMSYS or VDOSYS is always the first component in the DDP pipeline,\r\n" + "> > > > > > > so it only supports an output port with multiple endpoints - where each\r\n" + "> > > > > > > endpoint defines the starting point for one of the (currently three)\r\n" + "> > > > > > > possible hardware paths.\r\n" + "> > > > > > > \r\n" + "> > > > > > > Reviewed-by: Rob Herring (Arm) <robh@kernel.org>\r\n" + "> > > > > > > Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>\r\n" + "> > > > > > > Tested-by: Alexandre Mergnat <amergnat@baylibre.com>\r\n" + "> > > > > > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>\r\n" + "> > > > > > > ---\r\n" + "> > > > > > >     .../bindings/arm/mediatek/mediatek,mmsys.yaml | 28 +++++++++++++++++++\r\n" + "> > > > > > >     1 file changed, 28 insertions(+)\r\n" + "> > > > > > > \r\n" + "> > > > > > > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml\r\n" + "> > > > > > > index b3c6888c1457..0ef67ca4122b 100644\r\n" + "> > > > > > > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml\r\n" + "> > > > > > > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml\r\n" + "> > > > > > > @@ -93,6 +93,34 @@ properties:\r\n" + "> > > > > > >       '#reset-cells':\r\n" + "> > > > > > >         const: 1\r\n" + "> > > > > > >     \r\n" + "> > > > > > > +  port:\r\n" + "> > > > > > > +    $ref: /schemas/graph.yaml#/properties/port\r\n" + "> > > > > > > +    description:\r\n" + "> > > > > > > +      Output port node. This port connects the MMSYS/VDOSYS output to\r\n" + "> > > > > > > +      the first component of one display pipeline, for example one of\r\n" + "> > > > > > > +      the available OVL or RDMA blocks.\r\n" + "> > > > > > > +      Some MediaTek SoCs support multiple display outputs per MMSYS.\r\n" + "> > > > > > \r\n" + "> > > > > > This patch looks good to me. Just want to share another information for you.\r\n" + "> > > > > > Here is an example that mmsys/vdosys could point to the display interface node.\r\n" + "> > > > > > \r\n" + "> > > > > > vdosys0: syscon@1c01a000 {\r\n" + "> > > > > >              mmsys-display-interface = <&dsi0>, <&dsi1>, <&dp_intf0>;\r\n" + "> > > > > > };\r\n" + "> > > > > >     \r\n" + "> > > > > > vdosys1: syscon@1c100000 {\r\n" + "> > > > > >              mmsys-display-interface = <&dp_intf1>;\r\n" + "> > > > > > };\r\n" + "> > > > > > \r\n" + "> > > > > > There is no conflict that mmsys/vdosys point to first component of one display pipeline or point to display interface.\r\n" + "> > > > > > Both could co-exist.\r\n" + "> > > > > > \r\n" + "> > > > > \r\n" + "> > > > > Hey CK,\r\n" + "> > > > > \r\n" + "> > > > > yes, this could be an alternative to the OF graphs, and I'm sure that it'd work,\r\n" + "> > > > > even though this kind of solution would still require partial hardcoding of the\r\n" + "> > > > > display paths up until mmsys-display-interface (so, up until DSI0, or DSI1, etc).\r\n" + "> > > > > \r\n" + "> > > > > The problem with a solution like this is that, well, even though it would work,\r\n" + "> > > > > even if we ignore the suboptimal partial hardcoding, OF graphs are something\r\n" + "> > > > > generic, while the mmsys-display-interface would be a MediaTek specific/custom\r\n" + "> > > > > property.\r\n" + "> > > > > \r\n" + "> > > > > In the end, reusing generic kernel apis/interfaces/etc is always preferred\r\n" + "> > > > > compared to custom solutions, especially in this case, in which the generic\r\n" + "> > > > > stuff is on-par (or actually, depending purely on personal opinions, superior).\r\n" + "> > > > > \r\n" + "> > > > > As for the two to co-exist, I'm not sure that this is actually needed, as the\r\n" + "> > > > > OF graphs are already (at the end of the graph) pointing to the display interface.\r\n" + "> > > > > \r\n" + "> > > > > In any case, just as a reminder: if there will be any need to add any custom\r\n" + "> > > > > MediaTek specific properties later, it's ok and we can do that at any time.\r\n" + "> > > > \r\n" + "> > > > The alternative solution is using OF graphs to point display interface and use MediaTek specific property to first component:\r\n" + "> > > > \r\n" + "> > > > vdosys0: syscon@1c01a000 {\r\n" + "> > > >             ports {\r\n" + "> > > >                      port@0 {\r\n" + "> > > >                                endpoint {\r\n" + "> > > >                                         remote-endpoint = <&dsi0_endpoint>;\r\n" + "> > > >                                };\r\n" + "> > > >                      };\r\n" + "> > > >    \r\n" + "> > > >                      port@1 {\r\n" + "> > > >                                endpoint {\r\n" + "> > > >                                         remote-endpoint = <&dsi1_endpoint>;\r\n" + "> > > >                                };\r\n" + "> > > >                      };\r\n" + "> > > >    \r\n" + "> > > >                      port@2 {\r\n" + "> > > >                                endpoint {\r\n" + "> > > >                                         remote-endpoint = <&dp_intf0_endpoint>;\r\n" + "> > > >                                };\r\n" + "> > > >                      };\r\n" + "> > > >             };\r\n" + "> > > >    \r\n" + "> > > >             display-first-component = <&ovl0>;\r\n" + "> > > > };\r\n" + "> > > > \r\n" + "> > > > And I agree to it's better to keep only OF graphs property, so it would be\r\n" + "> > > > \r\n" + "> > > > vdosys0: syscon@1c01a000 {\r\n" + "> > > >             ports {\r\n" + "> > > >                      port@0 {\r\n" + "> > > >                                endpoint {\r\n" + "> > > >                                         remote-endpoint = <&dsi0_endpoint>;\r\n" + "> > > >                     \r\n" + "> > > >              };\r\n" + "> > > >                      };\r\n" + "> > > >    \r\n" + "> > > >                      port@1 {\r\n" + "> > > >                                endpoint {\r\n" + "> > > >                                         remote-endpoint = <&dsi1_endpoint>;\r\n" + "> > > >                             \r\n" + "> > > >      };\r\n" + "> > > >                      };\r\n" + "> > > >    \r\n" + "> > > >                      port@2 {\r\n" + "> > > >                                endpoint {\r\n" + "> > > >                                         remote-endpoint = <&dp_intf0_endpoint>;\r\n" + "> > > >                                }\r\n" + "> > > > ;\r\n" + "> > > >                      };\r\n" + "> > > >             };\r\n" + "> > > > };\r\n" + "> > > > \r\n" + "> > > > Maybe we could use OF graphs for both first component and display interface and drop using MediaTek specific property.\r\n" + "> > > > \r\n" + "> > > \r\n" + "> > > We could, or we can simply walk through the OF Graph in the driver and get the\r\n" + "> > > display interface like that, as it's board-specific ;-)\r\n" + "> > > \r\n" + "> > > ...but anyway, let's see that later: after getting this series upstreamed, I will\r\n" + "> > > convert all MediaTek boards (including Chromebooks) to use the graphs instead, and\r\n" + "> > > you'll see that, at least for the currently supported boards, there's no need for\r\n" + "> > > any custom property.\r\n" + "> > > \r\n" + "> > > Also, setting the DSI0/1/dpintf endpoint to VDO0 is technically wrong, as that is\r\n" + "> > > supposed to be the last one, and a graph is conceptually supposed to go from the\r\n" + "> > > first to the last in sequence.\r\n" + "> > > \r\n" + "> > > *if* we will ever need (probably not) to get the VDO0 node to point directly to\r\n" + "> > > the last node for whatever reason, the right way would be the first one you said,\r\n" + "> > > so, mediatek,mmsys-display-interface = <&dsi0>, <&dsi1>, etc etc\r\n" + "> > > \r\n" + "> > > ...or mediatek,mmsys-possible-displays = < ... phandles >\r\n" + "> > > \r\n" + "> > > ...or anyway, many other solutions are possible - but again, I think this is not\r\n" + "> > > the right time to think about that. Knowing that there are eventual solutions for\r\n" + "> > > any need that might arise in the future is enough, IMO :-)\r\n" + "> > \r\n" + "> > This is one routing of display pipeline and the relation of VDOSYS0 with display pipeline.\r\n" + "> > \r\n" + "> >                 +-- VDOSYS0 ---------------------------------------------+\r\n" + "> >                 |                                                        |\r\n" + "> >                 |                                                        |\r\n" + "> > DRAM -> IOMMU ---> OVL0 -> RDMA0 -> ... -> DSC0 -> MERGE0 -> DP_INTF0 ---->\r\n" + "> >                 |                                                        |\r\n" + "> >                 |                                                        |\r\n" + "> >                 +--------------------------------------------------------+\r\n" + "> > \r\n" + "> > Video data is read by IOMMU from DRAM and send to display pipeline. Then video data travel through first component to display interface.\r\n" + "> > VDOSYS0 manage each component in the pipeline include first component and display interface.\r\n" + "> > The management include clock gating, reset, video data input/output routing.\r\n" + "> > The relationship of VDOSYTS0 with first component is the same as the relationship of VDOSYS0 with display interface.\r\n" + "> > If VDOSYS0 is not suitable using OF graph point to display interface, VDOSYS0 is also not suitable using OF graph point to first component.\r\n" + "> \r\n" + "> In the cases in which VDO goes directly to the display, it *is* possible to make it\r\n" + "> point directly to the display.\r\n" + "> \r\n" + "> In the cases in which the pipeline is larger, VDO still points to the display, but\r\n" + "> only later in the pipeline.\r\n" + "\r\n" + "I mean VDOSYS0 is not suitable 'using OF graph' to point to both display interface and first component.\r\n" + "So VDOSYS0 should use specific property to point to both display interface and first component.\r\n" + "Maybe\r\n" + "\r\n" + "vdosys0 {\r\n" + "dma-device = <ovl0>;\r\n" + "display-interface = <&dsi0>, <&dsi1>, <&dp_intf0>;\r\n" + "};\r\n" + "\r\n" + "Regards,\r\n" + "CK\r\n" + "\r\n" + "> \r\n" + "> > The job of the component in display pipeline is to process the video data,\r\n" + "> > but the job of VDOSYS0 is to manage (clock gating, reset, routing) the pipeline.\r\n" + "> > If the OF graph is to show the video data travel path, VDOSYS0 should not exist in the OF graph.\r\n" + "> > \r\n" + "> > Regards,\r\n" + "> > CK\r\n" + "> > \r\n" + "> > > \r\n" + "> > > Cheers,\r\n" + "> > > Angelo\r\n" + "> > > \r\n" + "> > > > Regards,\r\n" + "> > > > CK\r\n" + "> > > > \r\n" + "> > > > > \r\n" + "> > > > > Cheers!\r\n" + "> > > > > Angelo\r\n" + "> > > > > \r\n" + "> > > > > > Regards,\r\n" + "> > > > > > CK\r\n" + "> > > > > > \r\n" + "> > > > > > > +    properties:\r\n" + "> > > > > > > +      endpoint@0:\r\n" + "> > > > > > > +        $ref: /schemas/graph.yaml#/properties/endpoint\r\n" + "> > > > > > > +        description: Output to the primary display pipeline\r\n" + "> > > > > > > +\r\n" + "> > > > > > > +      endpoint@1:\r\n" + "> > > > > > > +        $ref: /schemas/graph.yaml#/properties/endpoint\r\n" + "> > > > > > > +        description: Output to the secondary display pipeline\r\n" + "> > > > > > > +\r\n" + "> > > > > > > +      endpoint@2:\r\n" + "> > > > > > > +        $ref: /schemas/graph.yaml#/properties/endpoint\r\n" + "> > > > > > > +        description: Output to the tertiary display pipeline\r\n" + "> > > > > > > +\r\n" + "> > > > > > > +    anyOf:\r\n" + "> > > > > > > +      - required:\r\n" + "> > > > > > > +          - endpoint@0\r\n" + "> > > > > > > +      - required:\r\n" + "> > > > > > > +          - endpoint@1\r\n" + "> > > > > > > +      - required:\r\n" + "> > > > > > > +          - endpoint@2\r\n" + "> > > > > > > +\r\n" + "> > > > > > >     required:\r\n" + "> > > > > > >       - compatible\r\n" + "> > > > > > >       - reg\r\n" + "> > > > > \r\n" + "> > > > > \r\n" + "> > > \r\n" + "> > > \r\n" + "> \r\n" + "> \r\n" + "> \r\n" + "\r\n" + "</pre>\r\n" + "</p></body></html><!--type:text--><!--{--><pre>************* MEDIATEK Confidentiality Notice\r\n" + " ********************\r\n" + "The information contained in this e-mail message (including any \r\n" + "attachments) may be confidential, proprietary, privileged, or otherwise\r\n" + "exempt from disclosure under applicable laws. It is intended to be \r\n" + "conveyed only to the designated recipient(s). Any use, dissemination, \r\n" + "distribution, printing, retaining or copying of this e-mail (including its \r\n" + "attachments) by unintended recipient(s) is strictly prohibited and may \r\n" + "be unlawful. If you are not an intended recipient of this e-mail, or believe\r\n" + " \r\n" + "that you have received this e-mail in error, please notify the sender \r\n" + "immediately (by replying to this e-mail), delete any and all copies of \r\n" + "this e-mail (including any attachments) from your system, and do not\r\n" + "disclose the content of this e-mail to any other person. Thank you!\r\n" + </pre><!--}--> -a6175b1572fb86a4d0f001878dc797b4ff2933905af7e381aebc927db84c7a4d +e38a9d93ae98406a15bc9bceb139b79abdeb931bbe9848c96157e7a458ec5ce0
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.