summaryrefslogtreecommitdiffstats
path: root/drivers/iommu/mtk_iommu.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'arm/smmu' into arm/mediatekJoerg Roedel2019-08-301-8/+37
|\
| * iommu/io-pgtable: Pass struct iommu_iotlb_gather to ->tlb_add_page()Will Deacon2019-07-291-1/+2
| | | | | | | | | | | | | | | | | | With all the pieces in place, we can finally propagate the iommu_iotlb_gather structure from the call to unmap() down to the IOMMU drivers' implementation of ->tlb_add_page(). Currently everybody ignores it, but the machinery is now there to defer invalidation. Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/io-pgtable: Pass struct iommu_iotlb_gather to ->unmap()Will Deacon2019-07-291-1/+1
| | | | | | | | | | | | | | Update the io-pgtable ->unmap() function to take an iommu_iotlb_gather pointer as an argument, and update the callers as appropriate. Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/io-pgtable: Remove unused ->tlb_sync() callbackWill Deacon2019-07-291-1/+0
| | | | | | | | | | | | The ->tlb_sync() callback is no longer used, so it can be removed. Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/io-pgtable: Replace ->tlb_add_flush() with ->tlb_add_page()Will Deacon2019-07-291-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The ->tlb_add_flush() callback in the io-pgtable API now looks a bit silly: - It takes a size and a granule, which are always the same - It takes a 'bool leaf', which is always true - It only ever flushes a single page With that in mind, replace it with an optional ->tlb_add_page() callback that drops the useless parameters. Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/io-pgtable: Hook up ->tlb_flush_walk() and ->tlb_flush_leaf() in driversWill Deacon2019-07-291-0/+16
| | | | | | | | | | | | | | | | | | Hook up ->tlb_flush_walk() and ->tlb_flush_leaf() in drivers using the io-pgtable API so that we can start making use of them in the page-table code. For now, they can just wrap the implementations of ->tlb_add_flush and ->tlb_sync pending future optimisation in each driver. Signed-off-by: Will Deacon <will@kernel.org>
| * iommu: Pass struct iommu_iotlb_gather to ->unmap() and ->iotlb_sync()Will Deacon2019-07-291-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | To allow IOMMU drivers to batch up TLB flushing operations and postpone them until ->iotlb_sync() is called, extend the prototypes for the ->unmap() and ->iotlb_sync() IOMMU ops callbacks to take a pointer to the current iommu_iotlb_gather structure. All affected IOMMU drivers are updated, but there should be no functional change since the extra parameter is ignored for now. Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/io-pgtable: Rename iommu_gather_ops to iommu_flush_opsWill Deacon2019-07-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | In preparation for TLB flush gathering in the IOMMU API, rename the iommu_gather_ops structure in io-pgtable to iommu_flush_ops, which better describes its purpose and avoids the potential for confusion between different levels of the API. $ find linux/ -type f -name '*.[ch]' | xargs sed -i 's/gather_ops/flush_ops/g' Signed-off-by: Will Deacon <will@kernel.org>
* | iommu/mediatek: Clean up struct mtk_smi_iommuYong Wu2019-08-301-2/+2
| | | | | | | | | | | | | | | | | | 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>
* | memory: mtk-smi: Get rid of need_larbidYong Wu2019-08-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "mediatek,larb-id" has already been parsed in MTK IOMMU driver. It's no need to parse it again in SMI driver. Only clean some codes. This patch is fit for all the current mt2701, mt2712, mt7623, mt8173 and mt8183. After this patch, the "mediatek,larb-id" only be needed for mt2712 which have 2 M4Us. In the other SoCs, we can get the larb-id from M4U in which the larbs in the "mediatek,larbs" always are ordered. Correspondingly, the larb_nr in the "struct mtk_smi_iommu" could also be deleted. CC: Matthias Brugger <matthias.bgg@gmail.com> 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: Fix VLD_PA_RNG register backup when suspendYong Wu2019-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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 mmu1 supportYong Wu2019-08-301-17/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally the M4U HW connect EMI with smi. the diagram is like below: EMI | M4U | smi-common | ----------------- | | | | ... larb0 larb1 larb2 larb3 Actually there are 2 mmu cells in the M4U HW, like this diagram: EMI --------- | | mmu0 mmu1 <- M4U | | --------- | smi-common | ----------------- | | | | ... larb0 larb1 larb2 larb3 This patch add support for mmu1. In order to get better performance, we could adjust some larbs go to mmu1 while the others still go to mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220). mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default value of that register is 0 which means all the larbs go to mmu0 defaultly. This is a preparing patch for adjusting SMI_BUS_SEL 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: Add mt8183 IOMMU supportYong Wu2019-08-301-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Refine protect memory definitionYong Wu2019-08-301-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The protect memory setting is a little different in the different SoCs. In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault protect) shift bit is normally 4 while it shift 5 bits only in the mt8173. This patch delete the complex MACRO and use a common if-else instead. 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 larb-id remapped supportYong Wu2019-08-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/io-pgtable-arm-v7s: Rename the quirk from MTK_4GB to MTK_EXTYong Wu2019-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | In previous mt2712/mt8173, MediaTek extend the v7s to support 4GB dram. But in the latest mt8183, We extend it to support the PA up to 34bit. Then the "MTK_4GB" name is not so fit, This patch only change the quirk name to "MTK_EXT". Signed-off-by: Yong Wu <yong.wu@mediatek.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* | iommu/mediatek: Fix iova_to_phys PA start for 4GB modeYong Wu2019-08-301-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In M4U 4GB mode, the physical address is remapped as below: CPU Physical address: ==================== 0 1G 2G 3G 4G 5G |---A---|---B---|---C---|---D---|---E---| +--I/O--+------------Memory-------------+ IOMMU output physical address: ============================= 4G 5G 6G 7G 8G |---E---|---B---|---C---|---D---| +------------Memory-------------+ The Region 'A'(I/O) can not be mapped by M4U; For Region 'B'/'C'/'D', the bit32 of the CPU physical address always is needed to set, and for Region 'E', the CPU physical address keep as is. something looks 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) Additionally, the iommu consumers always use the CPU phyiscal address. The PA in the iova_to_phys that is got from v7s always is u32, But from the CPU point of view, PA only need add BIT(32) when PA < 0x4000_0000. Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") 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-8/+16
|/ | | | | | | | | | 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/mediatek: Fix leaked of_node referencesWen Yang2019-04-261-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. 581 static int mtk_iommu_probe(struct platform_device *pdev) 582 { ... 626 for (i = 0; i < larb_nr; i++) { 627 struct device_node *larbnode; ... 631 larbnode = of_parse_phandle(...); 632 if (!larbnode) 633 return -EINVAL; 634 635 if (!of_device_is_available(larbnode)) 636 continue; ---> leaked here 637 ... 643 if (!plarbdev) 644 return -EPROBE_DEFER; ---> leaked here ... 647 component_match_add_release(dev, &match, release_of, 648 compare_of, larbnode); ---> release_of will call of_node_put 649 } ... 650 Detected by coccinelle with the following warnings: ./drivers/iommu/mtk_iommu.c:644:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 631, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Cc: Joerg Roedel <joro@8bytes.org> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: iommu@lists.linux-foundation.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
*-. Merge branches 'iommu/fixes', 'arm/renesas', 'arm/mediatek', 'arm/tegra', ↵Joerg Roedel2018-12-201-11/+14
|\ \ | | | | | | | | | 'arm/omap', 'arm/smmu', 'x86/vt-d', 'x86/amd' and 'core' into next
| | * iommu/mediatek: Use helper functions to access dev->iommu_fwspecJoerg Roedel2018-12-171-9/+12
| |/ |/| | | | | | | | | | | | | | | | | Use the new helpers dev_iommu_fwspec_get()/set() to access the dev->iommu_fwspec pointer. This makes it easier to move that pointer later into another struct. Cc: Matthias Brugger <matthias.bgg@gmail.com> Tested-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/mediatek: Constify iommu_opsArvind Yadav2018-11-061-2/+2
|/ | | | | | | | | | | | iommu_ops are not supposed to change at runtime. Functions 'iommu_device_set_ops' and 'bus_set_iommu' working with const iommu_ops provided by <linux/iommu.h>. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> (Change the title to iommu/mediatek: xx) Signed-off-by: Joerg Roedel <jroedel@suse.de>
* mm: remove include/linux/bootmem.hMike Rapoport2018-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move remaining definitions and declarations from include/linux/bootmem.h into include/linux/memblock.h and remove the redundant header. The includes were replaced with the semantic patch below and then semi-automated removal of duplicated '#include <linux/memblock.h> @@ @@ - #include <linux/bootmem.h> + #include <linux/memblock.h> [sfr@canb.auug.org.au: dma-direct: fix up for the removal of linux/bootmem.h] Link: http://lkml.kernel.org/r/20181002185342.133d1680@canb.auug.org.au [sfr@canb.auug.org.au: powerpc: fix up for removal of linux/bootmem.h] Link: http://lkml.kernel.org/r/20181005161406.73ef8727@canb.auug.org.au [sfr@canb.auug.org.au: x86/kaslr, ACPI/NUMA: fix for linux/bootmem.h removal] Link: http://lkml.kernel.org/r/20181008190341.5e396491@canb.auug.org.au Link: http://lkml.kernel.org/r/1536927045-23536-30-git-send-email-rppt@linux.vnet.ibm.com Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Chris Zankel <chris@zankel.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greentime Hu <green.hu@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Ingo Molnar <mingo@redhat.com> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Jonas Bonn <jonas@southpole.se> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ley Foon Tan <lftan@altera.com> Cc: Mark Salter <msalter@redhat.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Matt Turner <mattst88@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Simek <monstr@monstr.eu> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Paul Burton <paul.burton@mips.com> Cc: Richard Kuo <rkuo@codeaurora.org> Cc: Richard Weinberger <richard@nod.at> Cc: Rich Felker <dalias@libc.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Serge Semin <fancer.lancer@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* iommu: Remove the ->map_sg indirectionChristoph Hellwig2018-08-081-1/+0
| | | | | | | | | | All iommu drivers use the default_iommu_map_sg implementation, and there is no good reason to ever override it. Just expose it as iommu_map_sg directly and remove the indirection, specially in our post-spectre world where indirect calls are horribly expensive. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Fix protect memory settingYong Wu2018-03-211-5/+10
| | | | | | | | | | | | | | | | | | | | 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>
*-. Merge branches 'iommu/fixes', 'arm/omap', 'arm/exynos', 'x86/amd', ↵Joerg Roedel2017-10-131-0/+7
|\ \ | | | | | | | | | 'x86/vt-d' and 'core' into next
| | * iommu/io-pgtable-arm-v7s: Convert to IOMMU API TLB syncRobin Murphy2017-10-021-0/+7
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the core API issues its own post-unmap TLB sync call, push that operation out from the io-pgtable-arm-v7s internals into the users. For now, we leave the invalidation implicit in the unmap operation, since none of the current users would benefit much from any change to that. Note that the conversion of msm_iommu is implicit, since that apparently has no specific TLB sync operation anyway. CC: Yong Wu <yong.wu@mediatek.com> CC: Rob Clark <robdclark@gmail.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* / iommu/mediatek: Limit the physical address in 32bit for v7sYong Wu2017-09-271-1/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ARM short descriptor has already limited the physical address to 32bit after the commit <76557391433c> ("iommu/io-pgtable: Sanitise map/unmap addresses"). But in MediaTek 4GB mode, the physical address is from 0x1_0000_0000 to 0x1_ffff_ffff. this will cause: WARNING: CPU: 4 PID: 3900 at xxx/drivers/iommu/io-pgtable-arm-v7s.c:482 arm_v7s_map+0x40/0xf8 Modules linked in: CPU: 4 PID: 3900 Comm: weston Tainted: G S W 4.9.44 #1 Hardware name: MediaTek MT2712m1v1 board (DT) task: ffffffc0eaa5b280 task.stack: ffffffc0e9858000 PC is at arm_v7s_map+0x40/0xf8 LR is at mtk_iommu_map+0x64/0x90 pc : [<ffffff80085b09e8>] lr : [<ffffff80085b29fc>] pstate: 000001c5 sp : ffffffc0e985b920 x29: ffffffc0e985b920 x28: 0000000127d00000 x27: 0000000000100000 x26: ffffff8008f9e000 x25: 0000000000000003 x24: 0000000000100000 x23: 0000000127d00000 x22: 00000000ff800000 x21: ffffffc0f7ec8ce0 x20: 0000000000000003 x19: 0000000000000003 x18: 0000000000000002 x17: 0000007f7e5d72c0 x16: ffffff80082b0f08 x15: 0000000000000001 x14: 000000000000003f x13: 0000000000000000 x12: 0000000000000028 x11: 0088000000000000 x10: 0000000000000000 x9 : ffffff80092fa000 x8 : ffffffc0e9858000 x7 : ffffff80085b29d8 x6 : 0000000000000000 x5 : ffffff80085b09a8 x4 : 0000000000000003 x3 : 0000000000100000 x2 : 0000000127d00000 x1 : 00000000ff800000 x0 : 0000000000000001 ... Call trace: [<ffffff80085b09e8>] arm_v7s_map+0x40/0xf8 [<ffffff80085b29fc>] mtk_iommu_map+0x64/0x90 [<ffffff80085ab5f8>] iommu_map+0x100/0x3a0 [<ffffff80085ab99c>] default_iommu_map_sg+0x104/0x168 [<ffffff80085aead8>] iommu_dma_alloc+0x238/0x3f8 [<ffffff8008098b30>] __iommu_alloc_attrs+0xa8/0x260 [<ffffff80085f364c>] mtk_drm_gem_create+0xac/0x180 [<ffffff80085f3894>] mtk_drm_gem_dumb_create+0x54/0xc8 [<ffffff80085d576c>] drm_mode_create_dumb_ioctl+0xa4/0xd8 [<ffffff80085cb2a0>] drm_ioctl+0x1c0/0x490 In order to satify this, Limit the physical address to 32bit. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Fix a build warning of BIT(32) in ARMYong Wu2017-08-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The commit ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") introduce the following build warning while ARCH=arm: drivers/iommu/mtk_iommu.c: In function 'mtk_iommu_iova_to_phys': include/linux/bitops.h:6:24: warning: left shift count >= width of type [-Wshift-count-overflow] #define BIT(nr) (1UL << (nr)) ^ >> drivers/iommu/mtk_iommu.c:407:9: note: in expansion of macro 'BIT' pa |= BIT(32); drivers/iommu/mtk_iommu.c: In function 'mtk_iommu_probe': include/linux/bitops.h:6:24: warning: left shift count >= width of type [-Wshift-count-overflow] #define BIT(nr) (1UL << (nr)) ^ drivers/iommu/mtk_iommu.c:589:35: note: in expansion of macro 'BIT' data->enable_4GB = !!(max_pfn > (BIT(32) >> PAGE_SHIFT)); Use BIT_ULL instead of BIT. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Fix a build fail of m4u_typeYong Wu2017-08-281-1/+1
| | | | | | | | | | | | | | | | The commit ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") introduce the following build error: drivers/iommu/mtk_iommu.c: In function 'mtk_iommu_hw_init': >> drivers/iommu/mtk_iommu.c:536:30: error: 'const struct mtk_iommu_data' has no member named 'm4u_type'; did you mean 'm4u_dom'? if (data->enable_4GB && data->m4u_type != M4U_MT8173) { This patch fix it, use "m4u_plat" instead of "m4u_type". Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Enlarge the validate PA range for 4GB modeYong Wu2017-08-221-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | This patch is for 4GB mode, mainly for 4 issues: 1) Fix a 4GB bug: if the dram base is 0x4000_0000, the dram size is 0xc000_0000. then the code just meet a corner case because max_pfn is 0x10_0000. data->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT)); It's true at the case above. That is unexpected. 2) In mt2712, there is a new register for the 4GB PA range(0x118) we should enlarge the max PA range, or the HW will report error. The dram range is from 0x1_0000_0000 to 0x1_ffff_ffff in the 4GB mode, we cut out the bit[32:30] of the SA(Start address) and EA(End address) into this REG_MMU_VLD_PA_RNG(0x118). 3) In mt2712, the register(0x13c) is extended for 4GB mode. bit[7:6] indicate the valid PA[32:33]. Thus, we don't mask the value and print it directly for debug. 4) if 4GB is enabled, the dram PA range is from 0x1_0000_0000 to 0x1_ffff_ffff. Thus, the PA from iova_to_pa should also '|' BIT(32) Signed-off-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: Disable iommu clock when system suspendYong Wu2017-08-221-1/+8
| | | | | | | | | | When system suspend, infra power domain may be off, and the iommu's clock must be disabled when system off, or the iommu's bclk clock maybe disabled after system resume. Signed-off-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: Move pgtable allocation into domain_allocYong Wu2017-08-221-30/+22
| | | | | | | | | | | | After adding the global list for M4U HW, We get a chance to move the pagetable allocation into the mtk_iommu_domain_alloc. Let the domain_alloc do the right thing. This patch is for fixing this problem[1]. [1]: https://patchwork.codeaurora.org/patch/53987/ 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-24/+68
| | | | | | | | | | | | | 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-37/+34
| | | | | | | | | | | | | | | | 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/mediatek: Move MTK_M4U_TO_LARB/PORT into mtk_iommu.cYong Wu2017-08-221-1/+7
| | | | | | | | | | The definition of MTK_M4U_TO_LARB and MTK_M4U_TO_PORT are shared by all the gen2 M4U HWs. Thus, Move them out from mt8173-larb-port.h, and put them into the c file. Suggested-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/mtk: Avoid redundant TLB syncs locallyRobin Murphy2017-07-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | 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: Remove iommu_register_instance interfaceJoerg Roedel2017-02-101-1/+0
| | | | | | | | | | | | | And also move its remaining functionality to iommu_device_register() and 'struct iommu_device'. Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: Make use of iommu_device_register interfaceJoerg Roedel2017-02-101-0/+26
| | | | | | | | | | 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>
*-. Merge branches 'arm/mediatek', 'arm/smmu', 'x86/amd', 's390', 'core' and ↵Joerg Roedel2016-12-061-60/+25
|\ \ | | | | | | | | | 'arm/exynos' into next
| | * iommu/mediatek: Fix M4Uv2 group refcountingRobin Murphy2016-11-151-0/+2
| |/ |/| | | | | | | | | | | | | | | | | | | For each subsequent device assigned to the m4u_group after its initial allocation, we need to take an additional reference. Otherwise, the caller of iommu_group_get_for_dev() will inadvertently remove the reference taken by iommu_group_add_device(), and the group will be freed prematurely if any device is removed. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/mediatek: Convert DT component matching to component_match_add_release()Russell King2016-11-101-3/+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 M4Uv2 to iommu_fwspecRobin Murphy2016-11-101-57/+18
|/ | | | | | | | | | | | 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 as a simpler alternative to the custom archdata code. CC: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/mediatek: move the common struct into header fileHonghui Zhang2016-06-211-47/+1
| | | | | | | | 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>
* iommu/mediatek: Do not call of_node_put in mtk_iommu_of_xlateHonghui Zhang2016-06-211-1/+0
| | | | | | | | The device_node will be released in of_iommu_configure, it may be double released if call of_node_put in mtk_iommu_of_xlate. Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
OpenPOWER on IntegriCloud