summaryrefslogtreecommitdiff
path: root/drivers/iommu/mtk_iommu.c
AgeCommit message (Collapse)Author
2021-02-01iommu/mediatek: Add get_domain_id from dev->dma_range_mapYong Wu
Add a new interface _get_domain_id from dev->dma_range_map, The iommu consumer device will use dma-ranges in dtsi node to indicate its dma address region requirement. In this iommu driver, we will get the requirement and decide which iova domain it should locate. In the lastest SoC, there will be several iova-regions(domains), we will compare and calculate which domain is right. If the start/end of device requirement equal some region. it is best fit of course. If it is inside some region, it is also ok. the iova requirement of a device should not be inside two or more regions. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-28-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Add iova_region structureYong Wu
Add a new structure for the iova_region. Each a region will be a independent iommu domain. For the previous SoC, there is single iova region(0~4G). For the SoC that need support multi-domains, there will be several regions. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-27-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Move geometry.aperture updating into domain_finaliseYong Wu
Move the domain geometry.aperture updating into domain_finalise. This is a preparing patch for updating the domain region. We know the detailed iova region in the attach_device. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-26-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Move domain_finalise into attach_deviceYong Wu
Currently domain_alloc only has a parameter(type), We have no chance to input some special data. This patch moves the domain_finalise into attach_device which has the device information, then could update the domain's geometry.aperture ranges for each a device. Strictly, I should use the data from mtk_iommu_get_m4u_data as the parameter of mtk_iommu_domain_finalise in this patch. but dom->data only is used in tlb ops in which the data is get from the m4u_list, thus it is ok here. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-25-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Adjust the structureYong Wu
Add "struct mtk_iommu_data *" in the "struct mtk_iommu_domain", reduce the call mtk_iommu_get_m4u_data(). No functional change. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-24-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Support report iova 34bit translation fault in ISRYong Wu
If the iova is over 32bit, the fault status register bit is a little different. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-23-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Support up to 34bit iova in tlb flushYong Wu
If the iova is 34bit, the iova[32][33] is the bit0/1 in the tlb flush register. Add a new macro for this. In the macro, since (iova + size - 1) may be end with 0xfff, then the bit0/1 always is 1, thus add a mask. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-22-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Add power-domain operationYong Wu
In the previous SoC, the M4U HW is in the EMI power domain which is always on. the latest M4U is in the display power domain which may be turned on/off, thus we have to add pm_runtime interface for it. When the engine work, the engine always enable the power and clocks for smi-larb/smi-common, then the M4U's power will always be powered on automatically via the device link with smi-common. Note: we don't enable the M4U power in iommu_map/unmap for tlb flush. If its power already is on, of course it is ok. if the power is off, the main tlb will be reset while M4U power on, thus the tlb flush while m4u power off is unnecessary, just skip it. Therefore, we increase the ref_count for pm when pm status is ACTIVE, otherwise, skip it. Meanwhile, the tlb_flush_range is called so often, thus, update pm ref_count while the SoC has power-domain to avoid touch the dev->power.lock. and the tlb_flush_all only is called when boot, so no need check if the SoC has power-domain to keep code clean. There will be one case that pm runctime status is not expected when tlb flush. After boot, the display may call dma_alloc_attrs before it call pm_runtime_get(disp-dev), then the m4u's pm status is not active inside the dma_alloc_attrs. Since it only happens after boot, the tlb is clean at that time, I also think this is ok. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-21-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Add pm runtime callbackYong Wu
In pm runtime case, all the registers backup/restore and bclk are controlled in the pm_runtime callback, Rename the original suspend/resume to the runtime_suspend/resume. Use pm_runtime_force_suspend/resume as the normal suspend/resume. iommu should suspend after iommu consumer devices, thus use _LATE_. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-20-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Add device link for smi-common and m4uYong Wu
In the lastest SoC, M4U has its special power domain. thus, If the engine begin to work, it should help enable the power for M4U firstly. Currently if the engine work, it always enable the power/clocks for smi-larbs/smi-common. This patch adds device_link for smi-common and M4U. then, if smi-common power is enabled, the M4U power also is powered on automatically. Normally M4U connect with several smi-larbs and their smi-common always are the same, In this patch it get smi-common dev from the last smi-larb device, then add the device_link. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-19-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Add error handle for mtk_iommu_probeYong Wu
In the original code, we lack the error handle. This patch adds them. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-18-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Move hw_init into attach_deviceYong Wu
In attach device, it will update the pagetable base address register. Move the hw_init function also here. Then it only need call pm_runtime_get/put one time here if m4u has power domain. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-17-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Update oas for v7sYong Wu
This patch only updates oas in different SoCs. If the SoC supports 4GB-mode and current dram size is 4GB, the oas is 33. otherwise, it's still 32. In the lastest SoC, the oas is 35bits. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-16-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Add a flag for iova 34bits caseYong Wu
Add a HW flag for if the HW support 34bit IOVA. the previous SoC still use 32bit. normally the lvl1 pgtable size is 16KB when ias == 32. if ias == 34, lvl1 pgtable size is 16KB * 4. The purpose of this patch is to save 16KB*3 continuous memory for the previous SoC. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-15-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTekYong Wu
MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-11-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-02-01iommu/mediatek: Use the common mtk-memory-port.hYong Wu
Use the common memory header(larb-port) in the source code. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://lore.kernel.org/r/20210111111914.22211-9-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-27iommu/mediatek: Remove the tlb-ops for v7sYong Wu
Until now, we have already used the tlb operations from iommu framework, then the tlb operations for v7s can be removed. Correspondingly, Switch the paramenter "cookie" to the internal structure. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210107122909.16317-8-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-27iommu/mediatek: Gather iova in iommu_unmap to achieve tlb sync onceYong Wu
In current iommu_unmap, this code is: iommu_iotlb_gather_init(&iotlb_gather); ret = __iommu_unmap(domain, iova, size, &iotlb_gather); iommu_iotlb_sync(domain, &iotlb_gather); We could gather the whole iova range in __iommu_unmap, and then do tlb synchronization in the iommu_iotlb_sync. This patch implement this, Gather the range in mtk_iommu_unmap. then iommu_iotlb_sync call tlb synchronization for the gathered iova range. we don't call iommu_iotlb_gather_add_page since our tlb synchronization could be regardless of granule size. In this way, gather->start is impossible ULONG_MAX, remove the checking. This patch aims to do tlb synchronization *once* in the iommu_unmap. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210107122909.16317-7-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-27iommu: Switch gather->end to the inclusive endYong Wu
Currently gather->end is "unsigned long" which may be overflow in arch32 in the corner case: 0xfff00000 + 0x100000(iova + size). Although it doesn't affect the size(end - start), it affects the checking "gather->end < end" This patch changes this "end" to the real end address (end = start + size - 1). Correspondingly, update the length to "end - start + 1". Fixes: a7d20dc19d9e ("iommu: Introduce struct iommu_iotlb_gather for batching TLB flushes") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210107122909.16317-5-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-27iommu/mediatek: Add iotlb_sync_map to sync whole the iova rangeYong Wu
Remove IO_PGTABLE_QUIRK_TLBI_ON_MAP to avoid tlb sync for each a small chunk memory, Use the new iotlb_sync_map to tlb_sync once for whole the iova range of iommu_map. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210107122909.16317-4-yong.wu@mediatek.com Signed-off-by: Will Deacon <will@kernel.org>
2020-12-08iommu/io-pgtable: Remove tlb_flush_leafRobin Murphy
The only user of tlb_flush_leaf is a particularly hairy corner of the Arm short-descriptor code, which wants a synchronous invalidation to minimise the races inherent in trying to split a large page mapping. This is already far enough into "here be dragons" territory that no sensible caller should ever hit it, and thus it really doesn't need optimising. Although using tlb_flush_walk there may technically be more heavyweight than needed, it does the job and saves everyone else having to carry around useless baggage. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/9844ab0c5cb3da8b2f89c6c2da16941910702b41.1606324115.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-09-18iommu/mediatek: Add support for MT8167Fabien Parent
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>
2020-09-18iommu/mediatek: Add flag for legacy ivrp paddrFabien Parent
Add a new flag in order to select which IVRP_PADDR format is used by an SoC. Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20200907101649.1573134-2-fparent@baylibre.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-09-04iommu/mediatek: Check 4GB mode by reading infracfgMiles Chen
In previous discussion [1] and [2], we found that it is risky to use max_pfn or totalram_pages to tell if 4GB mode is enabled. Check 4GB mode by reading infracfg register, remove the usage of the un-exported symbol max_pfn. This is a step towards building mtk_iommu as a kernel module. [1] https://lore.kernel.org/lkml/20200603161132.2441-1-miles.chen@mediatek.com/ [2] https://lore.kernel.org/lkml/20200604080120.2628-1-miles.chen@mediatek.com/ [3] https://lore.kernel.org/lkml/20200715205120.GA778876@bogus/ Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: David Hildenbrand <david@redhat.com> Cc: Yong Wu <yong.wu@mediatek.com> Cc: Yingjoe Chen <yingjoe.chen@mediatek.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Rob Herring <robh@kernel.org> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Joerg Roedel <joro@8bytes.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Miles Chen <miles.chen@mediatek.com> Link: https://lore.kernel.org/r/20200904104038.4979-1-miles.chen@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-09-04iommu/mediatek: Drop of_match_ptr to fix -Wunused-const-variableKrzysztof Kozlowski
The of_device_id is included unconditionally by of.h header and used in the driver as well. Remove of_match_ptr to fix W=1 compile test warning with !CONFIG_OF: drivers/iommu/mtk_iommu.c:833:34: warning: 'mtk_iommu_of_ids' defined but not used [-Wunused-const-variable=] 833 | static const struct of_device_id mtk_iommu_of_ids[] = { Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200727181842.8441-1-krzk@kernel.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-29Merge branches 'arm/renesas', 'arm/qcom', 'arm/mediatek', 'arm/omap', ↵Joerg Roedel
'arm/exynos', 'arm/smmu', 'ppc/pamu', 'x86/vt-d', 'x86/amd' and 'core' into next
2020-07-24iommu: Add gfp parameter to io_pgtable_ops->map()Baolin Wang
Now the ARM page tables are always allocated by GFP_ATOMIC parameter, but the iommu_ops->map() function has been added a gfp_t parameter by commit 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map"), thus io_pgtable_ops->map() should use the gfp parameter passed from iommu_ops->map() to allocate page pages, which can avoid wasting the memory allocators atomic pools for some non-atomic contexts. Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/3093df4cb95497aaf713fca623ce4ecebb197c2e.1591930156.git.baolin.wang@linux.alibaba.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-10iommu/mediatek: Add mt6779 basic supportChao Hao
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>
2020-07-10iommu/mediatek: Modify MMU_CTRL register settingChao Hao
The MMU_CTRL register of MT8173 is different from other SoCs. The in_order_wr_en is bit[9] which is zero by default. Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to one by default. We need to preserve the bit when setting F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU performance will drop. Signed-off-by: Chao Hao <chao.hao@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20200703044127.27438-10-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-10iommu/mediatek: Extend protect pa alignment valueChao Hao
Starting with mt6779, iommu needs to extend to 256 bytes from 128 bytes which can send the max number of data for memory protection pa alignment. So we can use a separate patch to modify it. Signed-off-by: Chao Hao <chao.hao@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20200703044127.27438-9-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-10iommu/mediatek: Add REG_MMU_WR_LEN_CTRL register definitionChao Hao
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>
2020-07-10iommu/mediatek: Add sub_comm id in translation faultChao Hao
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>
2020-07-10iommu/mediatek: Move inv_sel_reg into the plat_dataChao Hao
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>
2020-07-10iommu/mediatek: Setting MISC_CTRL registerChao Hao
Add F_MMU_IN_ORDER_WR_EN_MASK and F_MMU_STANDARD_AXI_MODE_EN_MASK definitions in MISC_CTRL register. F_MMU_STANDARD_AXI_MODE_EN_MASK: If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard AXI protocol), the iommu will priorize sending of urgent read command over a normal read command. This improves the performance. F_MMU_IN_ORDER_WR_EN_MASK: If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the iommu will re-order write commands and send the write commands with higher priority. Otherwise the sending of write commands will be done in order. The feature is controlled by OUT_ORDER_WR_EN platform data flag. Suggested-by: Yong Wu <yong.wu@mediatek.com> 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-5-chao.hao@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-07-10iommu/mediatek: Use a u32 flags to describe different HW featuresChao Hao
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>
2020-07-10iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRLChao Hao
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>
2020-05-05iommu/mediatek: Convert to probe/release_device() call-backsJoerg Roedel
Convert the Mediatek IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by: Joerg Roedel <jroedel@suse.de> Link: https://lore.kernel.org/r/20200429133712.31431-23-joro@8bytes.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-03-27iommu/mediatek: Use accessor functions for iommu private dataJoerg Roedel
Make use of dev_iommu_priv_set/get() functions. Signed-off-by: Joerg Roedel <jroedel@suse.de> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Link: https://lore.kernel.org/r/20200326150841.10083-14-joro@8bytes.org
2020-01-10iommu/io-pgtable-arm: Rationalise TTBRn handlingRobin Murphy
TTBR1 values have so far been redundant since no users implement any support for split address spaces. Crucially, though, one of the main reasons for wanting to do so is to be able to manage each half entirely independently, e.g. context-switching one set of mappings without disturbing the other. Thus it seems unlikely that tying two tables together in a single io_pgtable_cfg would ever be particularly desirable or useful. Streamline the configs to just a single conceptual TTBR value representing the allocated table. This paves the way for future users to support split address spaces by simply allocating a table and dealing with the detailed TTBRn logistics themselves. Tested-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> [will: Drop change to ttbr value] Signed-off-by: Will Deacon <will@kernel.org>
2019-11-12Merge branches 'iommu/fixes', 'arm/qcom', 'arm/renesas', 'arm/rockchip', ↵Joerg Roedel
'arm/mediatek', 'arm/tegra', 'arm/smmu', 'x86/amd', 'x86/vt-d', 'virtio' and 'core' into next
2019-11-11iommu/mediatek: Reduce the tlb flush timeout valueYong Wu
Reduce the tlb timeout value from 100000us to 1000us. The original value would make the kernel stuck for 100 ms with interrupts disabled, which could have other side effects. The flush is expected to always take much less than 1 ms, so use that instead. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-11-11iommu/mediatek: Get rid of the pgtlockYong Wu
Now we have tlb_lock for the HW tlb flush, then pgtable code hasn't needed the external "pgtlock" for a while. this patch remove the "pgtlock". Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-11-11iommu/mediatek: Move the tlb_sync into tlb_flushYong Wu
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>
2019-11-11iommu/mediatek: Delete the leaf in the tlb_flushYong Wu
In our tlb range flush, we don't care the "leaf". Remove it to simplify the code. no functional change. "granule" also is unnecessary for us, Keep it satisfy the format of tlb_flush_walk. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-11-11iommu/mediatek: Use gather to achieve the tlb range flushYong Wu
Use the iommu_gather mechanism to achieve the tlb range flush. Gather the iova range in the "tlb_add_page", then flush the merged iova range in iotlb_sync. Suggested-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-11-11iommu/mediatek: Add a new tlb_lock for tlb_flushYong Wu
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>
2019-11-11iommu/mediatek: Correct the flush_iotlb_all callbackYong Wu
Use the correct tlb_flush_all instead of the original one. Fixes: 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API TLB sync") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-10-15iommu: Add gfp parameter to iommu_ops::mapTom Murphy
Add a gfp_t parameter to the iommu_ops::map function. Remove the needless locking in the AMD iommu driver. The iommu_ops::map function (or the iommu_map function which calls it) was always supposed to be sleepable (according to Joerg's comment in this thread: https://lore.kernel.org/patchwork/patch/977520/ ) and so should probably have had a "might_sleep()" since it was written. However currently the dma-iommu api can call iommu_map in an atomic context, which it shouldn't do. This doesn't cause any problems because any iommu driver which uses the dma-iommu api uses gfp_atomic in it's iommu_ops::map function. But doing this wastes the memory allocators atomic pools. Signed-off-by: Tom Murphy <murphyt7@tcd.ie> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30Merge branch 'arm/smmu' into arm/mediatekJoerg Roedel
2019-08-30iommu/mediatek: Clean up struct mtk_smi_iommuYong Wu
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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-03 14:48:16 +0000