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
Acked-by: Will Deacon
---
drivers/iommu
MediaTek extend the arm v7s descriptor to support up to 34 bits PA where
the bit32 and bit33 are encoded in the bit9 and bit4 of the PTE
respectively. Meanwhile the iova still is 32bits.
Regarding whether the pagetable address could be over 4GB, the mt8183
support it while the previous mt8173 don'
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
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-
There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
mmu0 or mmu1 to balance the bandwidth via the smi-common register
SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
In mt8183, For better performance, we switch larb1/2/5/7 to enter
mmu1 while the others still keep enter mmu0.
In m
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
Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk
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
Reviewed-by: Matthias Brugger
Reviewed-by: Evan Green
---
drivers/iommu/mtk_iommu.c | 24
drivers/iommu/mtk_iommu.h |
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
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
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c| 4 ++--
drivers/iommu/mtk_iommu.h| 6 +++---
drivers/iommu/mtk_iommu_v1.c | 4 ++--
drivers/memory/mtk-s
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:
=
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
Use a struct as the platform special data instead of the enumeration.
Also there is a minor change that moving the position of
"enum mtk_smi_gen" definition, this is because we expect define
"struct mtk_smi_common_plat" before it is referred.
This is a preparing patch for mt8183.
Signed-off-by:
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
This patch only move the clk_prepare_enable and config_port into the
runtime suspend/resume callback. It doesn't change the code content
and sequence.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
(SMI_BUS_SEL need to be restored after smi-common resume every time.)
Also it gives
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
Reviewed-by: Evan Green
Reviewed-b
In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module
which can help synchronize for the modules in different clock frequency.
It can be seen as a "asynchronous fifo". This is a example diagram:
M4U
|
--
||
gals0-rx
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_ 0x1_4000_ (Add bit32)
0x8000_ 0x1_8000_ ...
0xc000_ 0x1
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
Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 3 ++-
drivers/iommu/mtk_iommu.h | 1 +
2 files c
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
Reviewe
The config_port of mt2712 and mt8183 are the same. Use a general
config_port interface instead.
In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which
are not the normal larb, their register space are different from the
normal one. thus, we can not call the general config_port. In mt81
Use ias/oas to check the valid iova/pa. Synchronize this checking with
io-pgtable-arm.c.
Signed-off-by: Yong Wu
Acked-by: Will Deacon
---
drivers/iommu/io-pgtable-arm-v7s.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/
Add two helper functions: paddr_to_iopte and iopte_to_paddr.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
Reviewed-by: Evan Green
---
drivers/iommu/io-pgtable-arm-v7s.c | 45 --
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/iomm
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
|
This patchset mainly adds support 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
|
Hi Joerg,
On 8/23/19 4:39 PM, Joerg Roedel wrote:
On Fri, Aug 23, 2019 at 03:17:29PM +0800, Lu Baolu wrote:
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4569,9 +4569,6 @@ static int __init platform_optin_force_iommu(void)
iommu_identity_mapping |= IDEN
The cookie is dereferenced before null checking in the function
iommu_dma_init_domain.
This patch moves the dereferencing after the null checking.
Fixes: fdbe574eb693 ("iommu/dma: Allow MSI-only cookies")
Signed-off-by: Yunsheng Lin
---
drivers/iommu/dma-iommu.c | 4 +++-
1 file changed, 3 inse
On 2019-08-20 2:53 a.m., Nadav Amit wrote:
> set_msi_sid_cb() is used to determine whether device aliases share the
> same bus, but it can provide false indications that aliases use the same
> bus when in fact they do not. The reason is that set_msi_sid_cb()
> assumes that pdev is fixed, while a
On Fri, Aug 23, 2019 at 09:49:46PM +0900, Masahiro Yamada wrote:
> On Tue, May 7, 2019 at 7:36 AM Nicolin Chen wrote:
> >
> > The addresses within a single page are always contiguous, so it's
> > not so necessary to always allocate one single page from CMA area.
> > Since the CMA area has a limite
Hi Christoph,
On Fri, Aug 16, 2019 at 09:07:48AM +0200, Christoph Hellwig wrote:
> I'd still like to hear a confirmation from the mips folks how
> the write combibe attribute can or can't work with the KSEG1
> uncached segment.
Quoting section 4.8 "Cacheability and Coherency Attributes and Access
On Tue, 23 Jul 2019 17:06:31 +0100
Shameer Kolothum wrote:
> This is to revive this series which almost made to 4.18 but got dropped
> as Alex found an issue[1] with IGD and USB devices RMRR region being
> reported as reserved regions.
>
> Thanks to Eric for his work here[2]. It provides a way t
Hi Joerg,
Please pull these ARM SMMU updates for 5.4. The branch is based on the
for-joerg/batched-unmap branch that you pulled into iommu/core already
because I didn't want to rebase everything onto -rc3. The pull request
was generated against iommu/core.
There's a lot of code here, but the head
+ linux-mmc, Ulf Hansson, Adrian Hunter,
ADMA of SDHCI is not working
since bd2e75633c8012fc8a7431c82fda66237133bf7e
Did anybody see the same problem?
Masahiro
On Fri, Aug 23, 2019 at 9:49 PM Masahiro Yamada
wrote:
>
> On Tue, May 7, 2019 at 7:36 AM Nicolin Chen wrote:
> >
> > The addre
On 2019/8/23 16:37, Will Deacon wrote:
> On Fri, Aug 23, 2019 at 04:06:52PM +0800, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2019/8/23 15:50, Will Deacon wrote:
>>> On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote:
v2 --> v3:
As Will Deacon's suggestion, I changed the lock type
Hi Alex,
A gentle ping on this. Please let me know.
Thanks,
Shameer
> -Original Message-
> From: Shameerali Kolothum Thodi
> Sent: 23 July 2019 17:07
> To: alex.william...@redhat.com; eric.au...@redhat.com
> Cc: k...@vger.kernel.org; linux-ker...@vger.kernel.org;
> iommu@lists.linux-foun
On Fri, Aug 23, 2019 at 03:17:29PM +0800, Lu Baolu wrote:
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -4569,9 +4569,6 @@ static int __init platform_optin_force_iommu(void)
> iommu_identity_mapping |= IDENTMAP_ALL;
>
> dmar_disabled = 0;
> -#if
On Fri, Aug 23, 2019 at 04:06:52PM +0800, Leizhen (ThunderTown) wrote:
>
>
> On 2019/8/23 15:50, Will Deacon wrote:
> > On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote:
> >> v2 --> v3:
> >> As Will Deacon's suggestion, I changed the lock type of
> >> arm_smmu_domain.devices_lock from spi
On Wed, Aug 21, 2019 at 01:10:04PM +0800, Kai-Heng Feng wrote:
> drivers/iommu/Makefile | 2 +-
> drivers/iommu/amd_iommu.h| 14 +
> drivers/iommu/amd_iommu_init.c | 5 +-
> drivers/iommu/amd_iommu_quirks.c | 92
> 4 files changed, 111 ins
Hi Jacob,
On Tue, Aug 20, 2019 at 02:21:08PM -0700, Jacob Pan wrote:
> Global pages support is removed from VT-d spec 3.0. Since global pages G
> flag only affects first-level paging structures and because DMA request
> with PASID are only supported by VT-d spec. 3.0 and onward, we can
> safely re
Hi all,
Can anyone help review it?
On 2019/8/15 20:11, Zhen Lei wrote:
> v1 --> v2
> 1. I did not chagne the patches but added this cover-letter.
> 2. Add a batch of reviewers base on
>9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova allocation")
> 3. I described the problem I m
On Mon, Aug 19, 2019 at 03:22:45PM +0200, Joerg Roedel wrote:
> Joerg Roedel (11):
> iommu: Remember when default domain type was set on kernel command line
> iommu: Add helpers to set/get default domain type
> iommu: Use Functions to set default domain type in
> iommu_set_def_domain_type()
On 2019/8/23 15:50, Will Deacon wrote:
> On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote:
>> v2 --> v3:
>> As Will Deacon's suggestion, I changed the lock type of
>> arm_smmu_domain.devices_lock from spinlock_t to rwlock_t, and I saw that the
>> performance is all right. And further use
On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote:
> v2 --> v3:
> As Will Deacon's suggestion, I changed the lock type of
> arm_smmu_domain.devices_lock from spinlock_t to rwlock_t, and I saw that the
> performance is all right. And further use nr_ats_masters to quickly check have
> no obvio
Hi,
On 8/22/19 10:29 PM, Janusz Krzysztofik wrote:
When a perfectly working i915 device is hot unplugged (via sysfs) and
hot re-plugged again, its dev->archdata.iommu field is not populated
again with an IOMMU pointer. As a result, the device probe fails on
DMA mapping error during scratch page
This splits the size parameter to swiotlb_tbl_map_single() and
swiotlb_tbl_unmap_single() into an alloc_size and a mapping_size
parameter, where the latter one is rounded up to the iommu page
size.
Suggested-by: Christoph Hellwig
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
---
drive
This adds a helper to check whether a device needs to
use bounce buffer. It also provides a boot time option
to disable the bounce buffer. Users can use this to
prevent the iommu driver from using the bounce buffer
for performance gain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by:
This adds trace support for the Intel IOMMU driver. It
also declares some events which could be used to trace
the events when an IOVA is being mapped or unmapped in
a domain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Mika Westerberg
Signed-off-by: Lu Baolu
Reviewed-by: Steven
This is necessary to avoid exposing valid kernel data to any
malicious device.
Suggested-by: Christoph Hellwig
Signed-off-by: Lu Baolu
---
kernel/dma/swiotlb.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index
The Intel VT-d hardware uses paging for DMA remapping.
The minimum mapped window is a page size. The device
drivers may map buffers not filling the whole IOMMU
window. This allows the device to access to possibly
unrelated memory and a malicious device could exploit
this to perform DMA attacks. To
There are several places in the kernel where it is necessary to
check whether a device is a pci untrusted device. Add a helper
to simplify the callers.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
---
include/linux/pci.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/li
The direct dma implementation depends on swiotlb. Hence, don't
switch off swiotlb since direct dma interfaces are used in this
driver.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-
The Thunderbolt vulnerabilities are public and have a nice
name as Thunderclap [1] [3] nowadays. This patch series aims
to mitigate those concerns.
An external PCI device is a PCI peripheral device connected
to the system through an external bus, such as Thunderbolt.
What makes it different is tha
51 matches
Mail list logo