summaryrefslogtreecommitdiffstats
path: root/drivers/iommu/mtk_iommu.h
Commit message (Collapse)AuthorAgeFilesLines
* iommu/mediatek: Add support for MT8167Fabien Parent2020-09-181-0/+1
| | | | | | | | | Add support for the IOMMU on MT8167 Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20200907101649.1573134-3-fparent@baylibre.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
*-. Merge branches 'arm/renesas', 'arm/qcom', 'arm/mediatek', 'arm/omap', ↵Joerg Roedel2020-07-291-8/+15
|\ \ | | | | | | | | | 'arm/exynos', 'arm/smmu', 'ppc/pamu', 'x86/vt-d', 'x86/amd' and 'core' into next
| | * iommu/mediatek: Do no use dev->archdata.iommuJoerg Roedel2020-06-301-0/+2
| |/ |/| | | | | | | | | | | | | | | | | The iommu private pointer is already used in the Mediatek IOMMU v1 driver, so move the dma_iommu_mapping pointer into 'struct mtk_iommu_data' and do not use dev->archdata.iommu anymore. Signed-off-by: Joerg Roedel <jroedel@suse.de> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20200625130836.1916-9-joro@8bytes.org
| * iommu/mediatek: Include liunx/dma-mapping.hJoerg Roedel2020-07-131-0/+1
| | | | | | | | | | | | | | | | This fixes a compile error when cross-compiling the driver on x86-32. Signed-off-by: Joerg Roedel <jroedel@suse.de> Link: https://lore.kernel.org/r/20200713101648.32056-1-joro@8bytes.org
| * iommu/mediatek: Add mt6779 basic supportChao Hao2020-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it. 2. Add mt6779_data to support mm_iommu HW init. Signed-off-by: Chao Hao <chao.hao@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Cc: Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20200703044127.27438-11-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/mediatek: Add REG_MMU_WR_LEN_CTRL register definitionChao Hao2020-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some platforms(ex: mt6779) need to improve performance by setting REG_MMU_WR_LEN_CTRL register. And we can use WR_THROT_EN macro to control whether we need to set the register. If the register uses default value, iommu will send command to EMI without restriction, when the number of commands become more and more, it will drop the EMI performance. So when more than ten_commands(default value) don't be handled for EMI, iommu will stop send command to EMI for keeping EMI's performace by enabling write throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register. Signed-off-by: Chao Hao <chao.hao@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20200703044127.27438-8-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/mediatek: Add sub_comm id in translation faultChao Hao2020-07-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The max larb number that a iommu HW support is 8(larb0~larb7 in the below diagram). If the larb's number is over 8, we use a sub_common for merging several larbs into one larb. At this case, we will extend larb_id: bit[11:9] means common-id; bit[8:7] means subcommon-id; >From these two variables, we could get the real larb number when translation fault happen. The diagram is as below: EMI | IOMMU | ----------------- | | common1 common0 | | ----------------- | smi common | ------------------------------------ | | | | | | 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8) | | | | | | Larb0 Larb1 | Larb3 ... Larb7 | smi sub common | -------------------------- | | | | 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4) | | | | Larb8 Larb9 Larb10 Larb11 In this patch we extend larb_remap[] to larb_remap[8][4] for this. larb_remap[x][y]: x means common-id above, y means subcommon_id above. We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM macro. Signed-off-by: Chao Hao <chao.hao@mediatek.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20200703044127.27438-7-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/mediatek: Move inv_sel_reg into the plat_dataChao Hao2020-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For mt6779, MMU_INV_SEL register's offset is changed from 0x38 to 0x2c, so we can put inv_sel_reg in the plat_data to use it. In addition, we renamed it to REG_MMU_INV_SEL_GEN1 and use it before mt6779. Signed-off-by: Chao Hao <chao.hao@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Cc: Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20200703044127.27438-6-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/mediatek: Use a u32 flags to describe different HW featuresChao Hao2020-07-101-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the fact that we are adding more and more plat_data bool values, it would make sense to use a u32 flags register and add the appropriate macro definitions to set and check for a flag present. No functional change. Suggested-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Chao Hao <chao.hao@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Cc: Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20200703044127.27438-4-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRLChao Hao2020-07-101-1/+4
|/ | | | | | | | | | | | | | | For iommu offset=0x48 register, only the previous mt8173/mt8183 use the name STANDARD_AXI_MODE, all the latest SoC extend the register more feature by different bits, for example: axi_mode, in_order_en, coherent_en and so on. So rename REG_MMU_MISC_CTRL may be more proper. This patch only rename the register name, no functional change. Signed-off-by: Chao Hao <chao.hao@mediatek.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20200703044127.27438-3-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Move the tlb_sync into tlb_flushYong Wu2019-11-111-1/+0
| | | | | | | | | | Right now, the tlb_add_flush_nosync and tlb_sync always appear together. we merge the two functions into one(also move the tlb_lock into the new function). No functional change. Signed-off-by: Chao Hao <chao.hao@mediatek.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Add a new tlb_lock for tlb_flushYong Wu2019-11-111-0/+1
| | | | | | | | | | | | | | | | | | The commit 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API TLB sync") help move the tlb_sync of unmap from v7s into the iommu framework. It helps add a new function "mtk_iommu_iotlb_sync", But it lacked the lock, then it will cause the variable "tlb_flush_active" may be changed unexpectedly, we could see this warning log randomly: mtk-iommu 10205000.iommu: Partial TLB flush timed out, falling back to full flush The HW requires tlb_flush/tlb_sync in pairs strictly, this patch adds a new tlb_lock for tlb operations to fix this issue. Fixes: 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API TLB sync") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Clean up struct mtk_smi_iommuYong Wu2019-08-301-3/+3
| | | | | | | | | Remove the "struct mtk_smi_iommu" to simplify the code since it has only one item in it right now. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Fix VLD_PA_RNG register backup when suspendYong Wu2019-08-301-0/+1
| | | | | | | | | | | | The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB mode support for mt2712. this patch add it. Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Add mt8183 IOMMU supportYong Wu2019-08-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use the ARM Short-descriptor like mt8173, and most of the HW registers are the same. Here list main differences between mt8183 and mt8173/mt2712: 1) mt8183 has only one M4U HW like mt8173 while mt2712 has two. 2) mt8183 don't have the "bclk" clock, it use the EMI clock instead. 3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB mode". 4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent the bit[33:32] in the physical address of the pgtable base, But the standard ttbr0[1] means the S bit which is enabled defaultly, Hence, we add a mask. 5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support. 6) mt8183 need reset_axi like mt8173. 7) the larb-id in smi-common is remapped. M4U should add its larbid_remap. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Move vld_pa_rng into plat_dataYong Wu2019-08-301-0/+1
| | | | | | | | | | Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address range) register while mt2712 have. Move it into the plat_data. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Move reset_axi into plat_dataYong Wu2019-08-301-1/+1
| | | | | | | | | | | | | | | In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while it is REG_MMU_CTRL in the other SoCs, and the bits meaning is completely different with the REG_MMU_STANDARD_AXI_MODE. This patch moves this property to plat_data, it's also a preparing patch for mt8183. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Add larb-id remapped supportYong Wu2019-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The larb-id may be remapped in the smi-common, this means the larb-id reported in the mtk_iommu_isr isn't the real larb-id, Take mt8183 as a example: M4U | --------------------------------------------- | SMI common | -0-----7-----5-----6-----1-----2------3-----4- <- Id remapped | | | | | | | | larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU disp vdec img cam venc img cam As above, larb0 connects with the id 0 in smi-common. larb1 connects with the id 7 in smi-common. ... If the larb-id reported in the isr is 7, actually it's larb1(vdec). In order to output the right larb-id in the isr, we add a larb-id remapping relationship in this patch. If there is no this larb-id remapping in some SoCs, use the linear mapping array instead. This also is a preparing patch for mt8183. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Add bclk can be supported optionallyYong Wu2019-08-301-0/+3
| | | | | | | | | | | | | | In some SoCs, M4U doesn't have its "bclk", it will use the EMI clock instead which has always been enabled when entering kernel. Currently mt2712 and mt8173 have this bclk while mt8183 doesn't. This also is a preparing patch for mt8183. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Adjust the PA for the 4GB ModeYong Wu2019-08-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | After extending the v7s support PA[33:32] for MediaTek, we have to adjust the PA ourself for the 4GB mode. In the 4GB Mode, the PA will remap like this: CPU PA -> M4U output PA 0x4000_0000 0x1_4000_0000 (Add bit32) 0x8000_0000 0x1_8000_0000 ... 0xc000_0000 0x1_c000_0000 ... 0x1_0000_0000 0x1_0000_0000 (No change) 1) Always add bit32 for CPU PA in ->map. 2) Discard the bit32 in iova_to_phys if PA > 0x1_4000_0000 since the iommu consumer always use the CPU PA. Besides, the "oas" always is set to 34 since v7s has already supported our case. Both mt2712 and mt8173 support this "4GB mode" while the mt8183 don't. The PA in mt8183 won't remap. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Use a struct as the platform dataYong Wu2019-08-301-1/+5
| | | | | | | | | | Use a struct as the platform special data instead of the enumeration. This is a prepare patch for adding mt8183 iommu support. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174Thomas Gleixner2019-05-301-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iommu: Allow io-pgtable to be used outside of drivers/iommu/Rob Herring2019-02-111-2/+1
| | | | | | | | | | | | | | | | | | | Move io-pgtable.h to include/linux/ and export alloc_io_pgtable_ops and free_io_pgtable_ops. This enables drivers outside drivers/iommu/ to use the page table library. Specifically, some ARM Mali GPUs use the ARM page table formats. Cc: Will Deacon <will.deacon@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: iommu@lists.linux-foundation.org Cc: linux-mediatek@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Fix protect memory settingYong Wu2018-03-211-0/+1
| | | | | | | | | | | | | | | | | | | | In MediaTek's IOMMU design, When a iommu translation fault occurs (HW can NOT translate the destination address to a valid physical address), the IOMMU HW output the dirty data into a special memory to avoid corrupting the main memory, this is called "protect memory". the register(0x114) for protect memory is a little different between mt8173 and mt2712. In the mt8173, bit[30:6] in the register represents [31:7] of the physical address. In the 4GB mode, the register bit[31] should be 1. While in the mt2712, the bits don't shift. bit[31:7] in the register represents [31:7] in the physical address, and bit[1:0] in the register represents bit[33:32] of the physical address if it has. Fixes: e6dec9230862 ("iommu/mediatek: Add mt2712 IOMMU support") Reported-by: Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Merge 2 M4U HWs into one iommu domainYong Wu2017-08-221-0/+2
| | | | | | | | | | | | | In theory, If there are 2 M4U HWs, there should be 2 IOMMU domains. But one IOMMU domain(4GB iova range) is enough for us currently, It's unnecessary to maintain 2 pagetables. Besides, This patch can simplify our consumer code largely. They don't need map a iova range from one domain into another, They can share the iova address easily. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Add mt2712 IOMMU supportYong Wu2017-08-221-0/+7
| | | | | | | | | | | | | | | | The M4U IP blocks in mt2712 is MTK's generation2 M4U which use the ARM Short-descriptor like mt8173, and most of the HW registers are the same. The difference is that there are 2 M4U HWs in mt2712 while there's only one in mt8173. The purpose of 2 M4U HWs is for balance the bandwidth. Normally if there are 2 M4U HWs, there should be 2 iommu domains, each M4U has a iommu domain. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mtk: Avoid redundant TLB syncs locallyRobin Murphy2017-07-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | Under certain circumstances, the io-pgtable code may end up issuing two TLB sync operations without any intervening invalidations. This goes badly for the M4U hardware, since it means the second sync ends up polling for a non-existent operation to finish, and as a result times out and warns. The io_pgtable_tlb_* helpers implement a high-level optimisation to avoid issuing the second sync at all in such cases, but in order to work correctly that requires all pagetable operations to be serialised under a lock, thus is no longer applicable to all io-pgtable users. Since we're the only user actually relying on this flag for correctness, let's reimplement it locally to avoid the headache of trying to make the high-level version concurrency-safe for other users. CC: Yong Wu <yong.wu@mediatek.com> CC: Matthias Brugger <matthias.bgg@gmail.com> Tested-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
* iommu/mediatek: Make use of iommu_device_register interfaceJoerg Roedel2017-02-101-0/+2
| | | | | | | | | | Register individual Mediatek IOMMUs to the iommu core and add sysfs entries. Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Convert DT component matching to component_match_add_release()Russell King2016-11-101-0/+5
| | | | | | | Convert DT component matching to use component_match_add_release(). Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Convert M4Uv1 to iommu_fwspecRobin Murphy2016-11-101-6/+0
| | | | | | | | | | | | | | Our per-device data consists of the M4U instance and firmware-provided list of LARB IDs, which is a perfect fit for the generic iommu_fwspec machinery. Use that directly instead of the custom archdata code - while we can't rely on the of_xlate() mechanism to initialise things until the 32-bit ARM DMA code learns about groups and default domains, it still results in a reasonable simplification overall. CC: Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Mark static functions in headers inlineJoerg Roedel2016-08-091-3/+3
| | | | | | | | This was an oversight while merging these functions. Fix it. Cc: Honghui Zhang <honghui.zhang@mediatek.com> Fixes: 9ca340c98c0d ('iommu/mediatek: move the common struct into header file') Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: move the common struct into header fileHonghui Zhang2016-06-211-0/+77
Move the struct defines of mtk iommu into a new header files for common use. Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-14 09:05:17 +0000