[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201002105826.GA6888@pi3>
Date: Fri, 2 Oct 2020 12:58:26 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Yong Wu <yong.wu@...iatek.com>
Cc: Joerg Roedel <joro@...tes.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Will Deacon <will@...nel.org>,
Evan Green <evgreen@...omium.org>,
Tomasz Figa <tfiga@...gle.com>,
linux-mediatek@...ts.infradead.org, srv_heupstream@...iatek.com,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
iommu@...ts.linux-foundation.org, youlin.pei@...iatek.com,
Nicolas Boichat <drinkcat@...omium.org>, anan.sun@...iatek.com,
chao.hao@...iatek.com, ming-fan.chen@...iatek.com,
Greg Kroah-Hartman <gregkh@...gle.com>, kernel-team@...roid.com
Subject: Re: [PATCH v3 01/24] dt-bindings: iommu: mediatek: Convert IOMMU to
DT schema
On Wed, Sep 30, 2020 at 03:06:24PM +0800, Yong Wu wrote:
> Convert MediaTek IOMMU to DT schema.
>
> Signed-off-by: Yong Wu <yong.wu@...iatek.com>
> ---
> .../bindings/iommu/mediatek,iommu.txt | 103 ------------
> .../bindings/iommu/mediatek,iommu.yaml | 154 ++++++++++++++++++
> 2 files changed, 154 insertions(+), 103 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> deleted file mode 100644
> index c1ccd8582eb2..000000000000
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -* Mediatek IOMMU Architecture Implementation
> -
> - Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and
> -this M4U have two generations of HW architecture. Generation one uses flat
> -pagetable, and only supports 4K size page mapping. Generation two uses the
> -ARM Short-Descriptor translation table format for address translation.
> -
> - About the M4U Hardware Block Diagram, please check below:
> -
> - EMI (External Memory Interface)
> - |
> - m4u (Multimedia Memory Management Unit)
> - |
> - +--------+
> - | |
> - gals0-rx gals1-rx (Global Async Local Sync rx)
> - | |
> - | |
> - gals0-tx gals1-tx (Global Async Local Sync tx)
> - | | Some SoCs may have GALS.
> - +--------+
> - |
> - SMI Common(Smart Multimedia Interface Common)
> - |
> - +----------------+-------
> - | |
> - | gals-rx There may be GALS in some larbs.
> - | |
> - | |
> - | gals-tx
> - | |
> - SMI larb0 SMI larb1 ... SoCs have several SMI local arbiter(larb).
> - (display) (vdec)
> - | |
> - | |
> - +-----+-----+ +----+----+
> - | | | | | |
> - | | |... | | | ... There are different ports in each larb.
> - | | | | | |
> -OVL0 RDMA0 WDMA0 MC PP VLD
> -
> - As above, The Multimedia HW will go through SMI and M4U while it
> -access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
> -smi local arbiter and smi common. It will control whether the Multimedia
> -HW should go though the m4u for translation or bypass it and talk
> -directly with EMI. And also SMI help control the power domain and clocks for
> -each local arbiter.
> - Normally we specify a local arbiter(larb) for each multimedia HW
> -like display, video decode, and camera. And there are different ports
> -in each larb. Take a example, There are many ports like MC, PP, VLD in the
> -video decode local arbiter, all these ports are according to the video HW.
> - In some SoCs, there may be a GALS(Global Async Local Sync) module between
> -smi-common and m4u, and additional GALS module between smi-larb and
> -smi-common. GALS can been seen as a "asynchronous fifo" which could help
> -synchronize for the modules in different clock frequency.
> -
> -Required properties:
> -- compatible : must be one of the following string:
> - "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW.
> - "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW.
> - "mediatek,mt6779-m4u" for mt6779 which uses generation two m4u HW.
> - "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses
> - generation one m4u HW.
> - "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
> - "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW.
> -- reg : m4u register base and size.
> -- interrupts : the interrupt of m4u.
> -- clocks : must contain one entry for each clock-names.
> -- clock-names : Only 1 optional clock:
> - - "bclk": the block clock of m4u.
> - Here is the list which require this "bclk":
> - - mt2701, mt2712, mt7623 and mt8173.
> - Note that m4u use the EMI clock which always has been enabled before kernel
> - if there is no this "bclk".
> -- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
> - Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
> - according to the local arbiter index, like larb0, larb1, larb2...
> -- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
> - Specifies the mtk_m4u_id as defined in
> - dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623
> - dt-binding/memory/mt2712-larb-port.h for mt2712,
> - dt-binding/memory/mt6779-larb-port.h for mt6779,
> - dt-binding/memory/mt8173-larb-port.h for mt8173, and
> - dt-binding/memory/mt8183-larb-port.h for mt8183.
> -
> -Example:
> - iommu: iommu@...05000 {
> - compatible = "mediatek,mt8173-m4u";
> - reg = <0 0x10205000 0 0x1000>;
> - interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
> - clocks = <&infracfg CLK_INFRA_M4U>;
> - clock-names = "bclk";
> - mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
> - #iommu-cells = <1>;
> - };
> -
> -Example for a client device:
> - display {
> - compatible = "mediatek,mt8173-disp";
> - iommus = <&iommu M4U_PORT_DISP_OVL0>,
> - <&iommu M4U_PORT_DISP_RDMA0>;
> - ...
> - };
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> new file mode 100644
> index 000000000000..eae773ad53a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> @@ -0,0 +1,154 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
You relicense GPLv2 content so you need acks/signed-offs from every
author:
- Fabien Parent <fparent@...libre.com>
- Chao Hao <chao.hao@...iatek.com>
- Matthias Brugger <matthias.bgg@...il.com>
- Honghui Zhang <honghui.zhang@...iatek.com>
(assuming yours is implicit).
Please resend CC-ing all the people.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/mediatek,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek IOMMU Architecture Implementation
> +
> +maintainers:
> + - Yong Wu <yong.wu@...iatek.com>
> +
> +description: |+
> + Some MediaTek SOCs contain a Multimedia Memory Management Unit (M4U), and
> + this M4U have two generations of HW architecture. Generation one uses flat
> + pagetable, and only supports 4K size page mapping. Generation two uses the
> + ARM Short-Descriptor translation table format for address translation.
> +
> + About the M4U Hardware Block Diagram, please check below:
> +
> + EMI (External Memory Interface)
> + |
> + m4u (Multimedia Memory Management Unit)
> + |
> + +--------+
> + | |
> + gals0-rx gals1-rx (Global Async Local Sync rx)
> + | |
> + | |
> + gals0-tx gals1-tx (Global Async Local Sync tx)
> + | | Some SoCs may have GALS.
> + +--------+
> + |
> + SMI Common(Smart Multimedia Interface Common)
> + |
> + +----------------+-------
> + | |
> + | gals-rx There may be GALS in some larbs.
> + | |
> + | |
> + | gals-tx
> + | |
> + SMI larb0 SMI larb1 ... SoCs have several SMI local arbiter(larb).
> + (display) (vdec)
> + | |
> + | |
> + +-----+-----+ +----+----+
> + | | | | | |
> + | | |... | | | ... There are different ports in each larb.
> + | | | | | |
> + OVL0 RDMA0 WDMA0 MC PP VLD
> +
> + As above, The Multimedia HW will go through SMI and M4U while it
> + access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
> + smi local arbiter and smi common. It will control whether the Multimedia
> + HW should go though the m4u for translation or bypass it and talk
> + directly with EMI. And also SMI help control the power domain and clocks for
> + each local arbiter.
> +
> + Normally we specify a local arbiter(larb) for each multimedia HW
> + like display, video decode, and camera. And there are different ports
> + in each larb. Take a example, There are many ports like MC, PP, VLD in the
> + video decode local arbiter, all these ports are according to the video HW.
> +
> + In some SoCs, there may be a GALS(Global Async Local Sync) module between
> + smi-common and m4u, and additional GALS module between smi-larb and
> + smi-common. GALS can been seen as a "asynchronous fifo" which could help
> + synchronize for the modules in different clock frequency.
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - mediatek,mt2701-m4u # mt2701 generation one HW
> + - mediatek,mt2712-m4u # mt2712 generation two HW
> + - mediatek,mt6779-m4u # mt6779 generation two HW
> + - mediatek,mt8173-m4u # mt8173 generation two HW
> + - mediatek,mt8183-m4u # mt8183 generation two HW
> +
> + - description: mt7623 generation one HW
> + items:
> + - const: mediatek,mt7623-m4u
> + - const: mediatek,mt2701-m4u
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + description: |
> + bclk is optional. here is the list which require this bclk:
> + mt2701, mt2712, mt7623 and mt8173.
> + M4U will use the EMI clock which always has been enabled before
> + kernel if there is no this bclk.
> + items:
> + - description: bclk is the block clock.
> +
> + clock-names:
> + items:
> + - const: bclk
> +
> + mediatek,larbs:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description: |
> + List of phandle to the local arbiters in the current Socs.
> + Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort
> + according to the local arbiter index, like larb0, larb1, larb2...
How many items?
Best regards,
Krzysztof
Powered by blists - more mailing lists