18 Sep, 2020

1 commit


10 Jul, 2020

1 commit

  • This patch adds description for MT6779 IOMMU.

    MT6779 has two iommus, they are mm_iommu and apu_iommu which
    both use ARM Short-Descriptor translation format.

    In addition, mm_iommu and apu_iommu are two independent HW instance
    , we need to set them separately.

    The MT6779 IOMMU hardware diagram is as below, it is only a brief
    diagram about iommu, it don't focus on the part of smi_larb, so
    I don't describe the smi_larb detailedly.

    EMI
    |
    --------------------------------------
    | |
    MM_IOMMU APU_IOMMU
    | |
    SMI_COMMOM----------- APU_BUS
    | | |
    SMI_LARB(0~11) | |
    | | |
    | | --------------
    | | | | |
    Multimedia engine CCU VPU MDLA EMDA

    All the connections are hardware fixed, software can not adjust it.

    Signed-off-by: Chao Hao
    Reviewed-by: Rob Herring
    Link: https://lore.kernel.org/r/20200703044127.27438-2-chao.hao@mediatek.com
    Signed-off-by: Joerg Roedel

    Chao Hao
     

10 Jan, 2020

2 commits


30 Aug, 2019

1 commit

  • This patch adds decriptions for mt8183 IOMMU and SMI.

    mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
    uses ARM Short-Descriptor translation table format.

    The mt8183 M4U-SMI HW diagram is as below:

    EMI
    |
    M4U
    |
    ----------
    | |
    gals0-rx gals1-rx
    | |
    | |
    gals0-tx gals1-tx
    | |
    ------------
    SMI Common
    ------------
    |
    +-----+-----+--------+-----+-----+-------+-------+
    | | | | | | | |
    | | gals-rx gals-rx | gals-rx gals-rx gals-rx
    | | | | | | | |
    | | | | | | | |
    | | gals-tx gals-tx | gals-tx gals-tx gals-tx
    | | | | | | | |
    larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
    disp vdec img cam venc img cam

    All the connections are HW fixed, SW can NOT adjust it.

    Compared with mt8173, we add a GALS(Global Async Local Sync) module
    between SMI-common and M4U, and additional GALS between larb2/3/5/6
    and SMI-common. GALS can help synchronize for the modules in different
    clock frequency, it can be seen as a "asynchronous fifo".

    GALS can only help transfer the command/data while it doesn't have
    the configuring register, thus it has the special "smi" clock and it
    doesn't have the "apb" clock. From the diagram above, we add "gals0"
    and "gals1" clocks for smi-common and add a "gals" clock for smi-larb.

    >From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera
    Control Unit) is connected with smi-common directly, we can take them
    as "larb2", "larb3" and "larb7", and their register spaces are
    different with the normal larb.

    Signed-off-by: Yong Wu
    Reviewed-by: Rob Herring
    Reviewed-by: Evan Green
    Signed-off-by: Joerg Roedel

    Yong Wu
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation this program is
    distributed in the hope that it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose see the gnu general public license
    for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 655 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Kate Stewart
    Reviewed-by: Richard Fontana
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

18 Jul, 2018

1 commit

  • This patch adds decriptions for mt2712 IOMMU and SMI.

    In order to balance the bandwidth, mt2712 has two M4Us, two
    smi-commons, 10 smi-larbs. and mt2712 is also MTK IOMMU gen2 which
    uses ARM Short-Descriptor translation table format.

    The mt2712 M4U-SMI HW diagram is as below:

    EMI
    |
    ------------------------------------
    | |
    M4U0 M4U1
    | |
    smi-common0 smi-common1
    | |
    ------------------------- --------------------------------
    | | | | | | | | | |
    | | | | | | | | | |
    larb0 larb1 larb2 larb3 larb6 larb4 larb5 larb7 larb8 larb9
    disp0 vdec cam venc jpg mdp1/disp1 mdp2/disp2 mdp3 vdo/nr tvd

    All the connections are HW fixed, SW can NOT adjust it.

    Signed-off-by: Yong Wu
    Acked-by: Rob Herring
    Signed-off-by: Matthias Brugger

    Yong Wu
     

19 May, 2018

1 commit


27 Apr, 2018

1 commit


13 Dec, 2017

1 commit

  • As opposed to earlier incarnations, the memory controller on Tegra186 no
    longer implements an SMMU. Instead the SMMU is a regular ARM SMMU and in
    a separate IP block.

    However, the memory controller programs the SMMU stream IDs for each of
    the memory clients. Add a header file with definitions for each of these
    stream IDs and mark the #iommu-cells property as required on Tegra30 to
    Tegra210 in the device tree bindings.

    Signed-off-by: Thierry Reding

    Thierry Reding
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

22 Aug, 2017

1 commit


22 Aug, 2016

1 commit


21 Jun, 2016

1 commit


25 Feb, 2016

1 commit


13 Aug, 2015

1 commit


04 Dec, 2014

1 commit

  • The memory controller on NVIDIA Tegra exposes various knobs that can be
    used to tune the behaviour of the clients attached to it.

    Currently this driver sets up the latency allowance registers to the HW
    defaults. Eventually an API should be exported by this driver (via a
    custom API or a generic subsystem) to allow clients to register latency
    requirements.

    This driver also registers an IOMMU (SMMU) that's implemented by the
    memory controller. It is supported on Tegra30, Tegra114 and Tegra124
    currently. Tegra20 has a GART instead.

    The Tegra SMMU operates on memory clients and SWGROUPs. A memory client
    is a unidirectional, special-purpose DMA master. A SWGROUP represents a
    set of memory clients that form a logical functional unit corresponding
    to a single device. Typically a device has two clients: one client for
    read transactions and one client for write transactions, but there are
    also devices that have only read clients, but many of them (such as the
    display controllers).

    Because there is no 1:1 relationship between memory clients and devices
    the driver keeps a table of memory clients and the SWGROUPs that they
    belong to per SoC. Note that this is an exception and due to the fact
    that the SMMU is tightly integrated with the rest of the Tegra SoC. The
    use of these tables is discouraged in drivers for generic IOMMU devices
    such as the ARM SMMU because the same IOMMU could be used in any number
    of SoCs and keeping such tables for each SoC would not scale.

    Acked-by: Joerg Roedel
    Signed-off-by: Thierry Reding

    Thierry Reding