diff for duplicates of <ee0209dac731b36ffe2ee20a2ff537ce7758b01f.camel@mediatek.com> diff --git a/a/1.txt b/N1/1.txt index 3c4b000..e153e11 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -216,4 +216,8 @@ CK > > > > > > > -> +> +_______________________________________________ +linux-arm-kernel mailing list +linux-arm-kernel@lists.infradead.org +http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/a/content_digest b/N1/content_digest index 078ba02..556427d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -250,6 +250,10 @@ "> > > \n" "> > > \n" "> \n" - > + "> \n" + "_______________________________________________\n" + "linux-arm-kernel mailing list\n" + "linux-arm-kernel@lists.infradead.org\n" + http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -2e5a2d0ef14bafc5844a0607a28b13750c4fbb643b00400ab0e218e0e549f415 +f0414ce85cae61b6ebfdb2c0c2ea3b4da0dc94f44f00599c0bc7608b094bc403
diff --git a/N2/2.bin b/N2/2.bin new file mode 100644 index 0000000..fb48f95 --- /dev/null +++ b/N2/2.bin @@ -0,0 +1,238 @@ +<html><body><p> +<pre> +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. +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/N2/2.hdr b/N2/2.hdr new file mode 100644 index 0000000..da1f671 --- /dev/null +++ b/N2/2.hdr @@ -0,0 +1,3 @@ +Content-Type: text/html; + charset="utf-8" +Content-Transfer-Encoding: base64 diff --git a/a/content_digest b/N2/content_digest index 078ba02..ddb361e 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -30,7 +30,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 Mon, 2024-06-10 at 10:28 +0200, AngeloGioacchino Del Regno wrote:\n" "> Il 06/06/24 07:29, CK Hu (\350\203\241\344\277\212\345\205\211) ha scritto:\n" @@ -251,5 +251,245 @@ "> > > \n" "> \n" > + "\01:2\0" + "b\0" + "<html><body><p>\r\n" + "<pre>\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" + "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" + "</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><!--}--> -2e5a2d0ef14bafc5844a0607a28b13750c4fbb643b00400ab0e218e0e549f415 +7ab1442bb4fe31b9964f2c0418ebf6c9617d2ed0bca65d04e0d1cf7b8c3b7169
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.