| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <bf72f620071c3bfe7c3dea3eec6464afce3e7f4f.camel@mediatek.com>
Date: Tue, 16 Nov 2021 20:05:03 +0800
From: "yunfei.dong@...iatek.com" <yunfei.dong@...iatek.com>
To: Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
CC: Alexandre Courbot <acourbot@...omium.org>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Tzung-Bi Shih <tzungbi@...omium.org>,
"Tiffany Lin" <tiffany.lin@...iatek.com>,
Andrew-CT Chen <andrew-ct.chen@...iatek.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Tomasz Figa <tfiga@...gle.com>,
Irui Wang <irui.wang@...iatek.com>,
"Benjamin Gaignard" <benjamin.gaignard@...labora.com>,
srv_heupstream <srv_heupstream@...iatek.com>,
devicetree <devicetree@...r.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@...iatek.com>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>,
"Hsin-Yi Wang" <hsinyi@...omium.org>,
Fritz Koenig <frkoenig@...omium.org>,
"Dafna Hirschfeld" <dafna.hirschfeld@...labora.com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-media <linux-media@...r.kernel.org>
Subject: Re: [PATCH v10, 15/19] dt-bindings: media: mtk-vcodec: Adds decoder
dt-bindings for mt8192
Hi Ezequiel,
Thanks for your suggestion.
On Sun, 2021-11-14 at 18:56 -0300, Ezequiel Garcia wrote:
> Yunfei,
>
> On Thu, 11 Nov 2021 at 01:15, Yunfei Dong <yunfei.dong@...iatek.com>
> wrote:
> >
> > Adds decoder dt-bindings for mt8192.
> >
> > Signed-off-by: Yunfei Dong <yunfei.dong@...iatek.com>
> > ---
> > .../media/mediatek,vcodec-subdev-decoder.yaml | 261
> > ++++++++++++++++++
> > 1 file changed, 261 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-
> > decoder.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-
> > decoder.yaml
> > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-
> > decoder.yaml
> > new file mode 100644
> > index 000000000000..1886fae6e39d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-
> > subdev-decoder.yaml
> > @@ -0,0 +1,261 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +
> > +%YAML 1.2
> > +---
> > +$id: "
> > http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#
> > "
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> > +
> > +title: Mediatek Video Decode Accelerator With Multi Hardware
> > +
> > +maintainers:
> > + - Yunfei Dong <yunfei.dong@...iatek.com>
> > +
> > +description: |
> > + Mediatek Video Decode is the video decode hardware present in
> > Mediatek
> > + SoCs which supports high resolution decoding functionalities.
> > Required
> > + main and subdev device node.
> > +
> > + About the Decoder Hardware Block Diagram, please check below:
> > +
> > + +---------------------------------+---------------------------
> > ---------+
> > + | |
> > |
> > + | input -> lat HW -> lat buffer --|--> lat buffer -> core HW
> > -> output
>
> |
>
> To be completely honest, I can't really understand what is the
> meaning
> of the blocks
> with input -> lat hw -> lat buffer, and how this means lat- and core-
> are children of some parent.
>
I will add more detail information as below:
The block diagram is data flow, need two or more hardwares to decode
for each picture. input is input bitstream, lat hardware need input
bitstream and lat buffer to decode, will write temp information to lat
buffer when lat decode done. lat buffer is used to share lat buffer
information for lat hardware and core hardware. core hardware need
frame buffer and lat buffer to decode, will write decode result to
frame buffer.
> > + | || | ||
> > |
> > + +------------||-------------------+---------------------||--
> > -----------+
> > + || lat thread | core
> > thread || <parent>
> > + -------------||-----------------------------------------||--
> > --------------
> > + || ||
> > <child>
> > + \/ <----------------HW index-------------->\/
> > + +----------------------------------------------------
> > --+
> > + | enable/disable
> > |
> > + | clk power irq iommu
> > port |
> > + | (lat/lat
> > soc/core0/core1) |
> > + +----------------------------------------------------
> > --+
> > +
> > + As above, <parent> mean in main device, <child> mean in subdev
> > device. The information
> > + of each hardware will be stored in subdev device. There are two
> > workqueues in main device:
> > + lat and core. Enable/disable the lat clk/power/irq when lat need
> > to work through hardware
> > + index, core is the same.
> > +
> > + Normally the smi common may not the same for each hardware,
> > can't combine all hardware in
> > + one node, or leading to iommu fault when access dram data.
> > +
>
There are one parent node, regards it as main device, each child node
as subdevices, one child node mean one hardware.
There are two work queues in main device used for lat and core hardware
to decode.
The information of each hardware will be stored in subdevices.
Enable/disable the lat clk/power/irq when hardware need to work.
> To what extent the lat- and core- devices are really "children"
> or "subdevices" of the video-codec@...00000 device?
>
> I.e. what resources do they share? What are the details of
> their bus topology?
>
The hardware is really very simple, just enable it to work when needed.
But each hardware isn't independent, need lat and core to decode for
every picture. No complex bus topology.
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + #include <dt-bindings/memory/mt8192-larb-port.h>
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/clock/mt8192-clk.h>
> > + #include <dt-bindings/power/mt8192-power.h>
> > +
> > + video-codec@...00000 {
> > + compatible = "mediatek,mt8192-vcodec-dec";
> > + reg = <0x16000000 0x1000>; /* VDEC_SYS */
> > + mediatek,scp = <&scp>;
> > + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>;
> > + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > + vcodec-lat@...10000 {
> > + compatible = "mediatek,mtk-vcodec-lat";
> > + reg = <0x16010000 0x800>;
> > + interrupts = <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH 0>;
> > + iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>,
> > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>,
> > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>,
> > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>,
> > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>,
> > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>,
> > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>,
> > + <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>;
> > + clocks = <&topckgen CLK_TOP_VDEC_SEL>,
> > + <&vdecsys_soc CLK_VDEC_SOC_VDEC>,
> > + <&vdecsys_soc CLK_VDEC_SOC_LAT>,
> > + <&vdecsys_soc CLK_VDEC_SOC_LARB1>,
> > + <&topckgen CLK_TOP_MAINPLL_D4>;
> > + clock-names = "sel", "soc-vdec", "soc-lat", "vdec",
> > "top";
> > + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>;
> > + assigned-clock-parents = <&topckgen
> > CLK_TOP_MAINPLL_D4>;
> > + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>;
> > + };
> > +
> > + vcodec-core@...25000 {
> > + compatible = "mediatek,mtk-vcodec-core";
> > + reg = <0x16025000 0x1000>;
>
> The children address space might need some thinking.
> In other words,
>
> video-codec@...00000 {
>
> vcodec-lat@...10000 {
> }
>
> vcodec-core@...25000 {
> }
> }
>
> Your proposal has vcodec-lat as children of video-codec, but its
> address space
> are really on the same level, instead of children being contained in
> the parent address space:
>
> video-codec@...00000 {
>
> vcodec-lat@...00 {
> }
>
> vcodec-core@...00 {
> }
> }
>
yes, I will try to fix the dtsi as: vcodec-lat@...00, if it looks much
more reasonable.
> I think this last tree makes more sense from a device-tree point of
> view.
> The ranges property allows you to put the right translation
> information,
> so the device driver itself will get the correct address 0x16000000 +
> 0x25000.
>
> You might find that the ranges property is tricky to understand at
> first.
>
> Thanks,
> Ezequiel
>
Hope to get your feedback.
Thanks,
Yunfei Dong
>
> > + interrupts = <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH 0>;
> > + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>,
> > + <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>;
> > + clocks = <&topckgen CLK_TOP_VDEC_SEL>,
> > + <&vdecsys CLK_VDEC_VDEC>,
> > + <&vdecsys CLK_VDEC_LAT>,
> > + <&vdecsys CLK_VDEC_LARB1>,
> > + <&topckgen CLK_TOP_MAINPLL_D4>;
> > + clock-names = "sel", "soc-vdec", "soc-lat", "vdec",
> > "top";
> > + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>;
> > + assigned-clock-parents = <&topckgen
> > CLK_TOP_MAINPLL_D4>;
> > + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC2>;
> > + };
> > + };
> > --
> > 2.25.1
> >
Powered by blists - more mailing lists