Enable the multi-bank functions for infra-iommu. We put PCIE in bank0
and USB in the last bank(bank4). and we don't use the other banks
currently, disable them.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers
Each bank has some independent registers. thus backup/restore them for
each a bank when suspend and resume.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 39 +++
drivers/iommu/mtk_iommu.h | 14 +++---
2 files changed, 38 insertions(+), 15 dele
The registers for each bank of the IOMMU base are in order, delta is
0x1000. Initialise the base for each bank.
For all the previous SoC, we only have bank0. thus use "do {} while()"
to allow bank0 always go.
When removing the device, Not always all the banks are initialised, it
depend on if ther
We preassign some ports in a special bank via the new defined
bank_portmsk. Put it in the plat_data means it is not expected to be
adjusted dynamically.
If the iommu id in the iommu consumer's dtsi node is inside this
bank_portmsk, then we switch it to this special iommu bank, and initialise
the I
Prepare for adding bankid, also no functional change.
In the previous SoC, each a iova_region is a domain; In the multi-banks
case, each a bank is a domain; then the original function name
"mtk_iommu_get_domain_id" is not proper. the name "iova_region_id"
should be proper. this patch only rename t
Prepare for supporting multi banks, Adds two variables in the plat_data:
bank_nr: the bank number that this SoC support;
bank_enable: list if the banks is enabled.
Add them for all the current SoC, bank_nr always is 1 and only
bank_enable[0] is enabled.
Signed-off-by: Yong Wu
---
drivers/iommu/
The mt8195 IOMMU HW max support 5 banks, and regarding the banks'
registers, it looks like:
|bank0 | bank1 | bank2 | bank3 | bank4|
|global |
|control| null
|regs |
-
Prepare for supporting multi-banks for the IOMMU HW, No functional change.
Add a new structure(mtk_iommu_bank_data) for each a bank. Each a bank have
the independent HW base/IRQ, and each a bank has its special iommu-domain
(independent pgtable), thus, also move the domain information and tlb_lock
No functional change too. mt8195 IOMMU support bank functions.
some global control settings are in bank0. and the other banks have
their bank independent setting. Here only move the global control
settings and the independent registers together.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu
No functional change. Use "base" instead of the data->base. This is
avoid to touch too many lines in the next patches.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 45 +--
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/iommu/
mt8195 has 3 IOMMU, containing 2 MM IOMMUs, one is for vdo, the other
is for vpp. and 1 INFRA IOMMU.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 42 +++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 43 insertions(+)
diff --git a/drivers/iommu/
Currently the code for of_iommu_configure_dev_id is like this:
static int of_iommu_configure_dev_id(struct device_node *master_np,
struct device *dev,
const u32 *id)
{
struct of_phandle_args iommu_spec = { .args_count
The infra iommu enable bits in mt8195 is in the pericfg register segment,
use regmap to update it.
If infra iommu master translation fault, It don't have the larbid/portid,
thus print out the whole register value.
Since regmap_update_bits may fail, add return value for mtk_iommu_config.
Signed-o
For MM IOMMU, We always add device link between smi-common and IOMMU HW.
In mt8195, we add smi-sub-common. Thus, if the node is sub-common, we still
need find again to get smi-common, then do device link.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 11 +++
1 file changed, 11 i
Prepare for supporting INFRA_IOMMU, and APU_IOMMU later.
For Infra IOMMU/APU IOMMU, it doesn't have the "larb""port". thus, Use
the MM flag contain the MM_IOMMU special flow, Also, it moves a big
chunk code about parsing the mediatek,larbs into a function, this is
only needed for MM IOMMU. and all
Add IOMMU_TYPE definition. In the mt8195, we have another IOMMU_TYPE:
infra iommu, also there will be another APU_IOMMU, thus, use 2bits for the
IOMMU_TYPE.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/driv
In prevous SoC, the sub common id occupy 2 bits. the mt8195's sub common
id has 3bits. Add a new flag for this. and rename the prevous flag to
_2BITS. For readable, I put these two flags together, then move the
other flags. no functional change.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu
Currently the output PA[32:33] is contained by the flag IOVA_34.
This is not right. the iova_34 has no relation with pa[32:33], the 32bits
iova still could map to pa[32:33]. Move it out from the flag.
No need fix tag since currently only mt8192 use the calulation and it
always has this IOVA_34 fla
Prepare for 2 HWs that sharing pgtable in different power-domains.
The previous SoC don't have PM. Only mt8192 has power-domain,
and it is display's power-domain which nearly always is enabled.
When there are 2 M4U HWs, it may has problem.
In this function, we get the pm_status via the m4u dev, b
The MediaTek IOMMU don't care about granule when tlb flushing.
Remove this variable.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d64139ab59d0..add23a36a5
The tlb_flush_all also touches the registers about tlb operations.
Add spinlock in it to protect the tlb registers. If flush_all is called
from tlb_flush_range, then no need this spinlock as tlb_flush_range
already hold the tlb_lock.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 19
The tlb_sync_all is called from these three functions:
a) flush_iotlb_all: it will be called for each a iommu HW.
b) tlb_flush_range_sync: it already has for_each_m4u.
c) in irq: some IOMMU HW translation fault, Only need flush itself.
Thus, No need for_each_m4u in this tlb_sync_all. Remove it.
S
Add a new flag NON_STD_AXI, All the previous SoC support this flag.
Prepare for adding infra and apu iommu which don't support this.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.
In the infra iommu, we should disable DCM. add a new flag for this.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 259ff7b90ff3..bd50f3020bc1 100644
--- a
In mt8192, we preassign 0-4G; 4G-8G; 8G-12G for different multimedia
engines. This depends on the "dma-ranges=" in the iommu consumer's dtsi
node.
Adds 12G-16G region here. and reword the previous comment. we don't limit
which master locate in which region.
CCU still is 8G-12G. Don't change it he
In previous mt2712, Both IOMMUs are MM IOMMU, and they will share pgtable.
However in the latest SoC, another is infra IOMMU, there is no reason to
share pgtable between MM with INFRA IOMMU. This patch manage to
implement the two case(sharing and non-sharing pgtable).
Currently we use for_each_m4u
In the commit 4f956c97d26b ("iommu/mediatek: Move domain_finalise into
attach_device"), I overlooked the sharing pgtable case.
After that commit, the "data" in the mtk_iommu_domain_finalise always is
the data of the current IOMMU HW. Fix this for the sharing pgtable case.
Only affect mt2712 which
In mt8195, we have a new IOMMU that is for INFRA IOMMU. its masters
mainly are PCIe and USB. Different with MM IOMMU, all these masters
connect with IOMMU directly, there is no mediatek,larbs property for
infra IOMMU.
Another thing is about PCIe ports. currently the function
"of_iommu_configure_de
This patch adds descriptions for mt8195 IOMMU which also use ARM
Short-Descriptor translation table format.
In mt8195, there are two smi-common HW and IOMMU, one is for vdo(video
output), the other is for vpp(video processing pipe). They connects
with different smi-larbs, then some setting(larbid_
This patchset add mt8195 iommu support.
mt8195 have 3 IOMMU HWs. 2 IOMMU HW is for multimedia, and 1 IOMMU HW is
for infra-master, like PCIe/USB.
About the 2 MM IOMMU HW, something like this:
IOMMU(VDO) IOMMU(VPP)
| |
SMI_COMMON(VDO) SMI_C
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
> Subject: [PATCH V3 04/13] HV: Mark vmbus ring buffer visible to host in
> Isolation VM
>
Use tag "Drivers: hv: vmbus:" in the Subject line.
> Mark vmbus ring buffer visible with set_memory_decrypted() when
> establish gpadl handle.
>
>
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
[snip]
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index ad8a5c586a35..1e4a0882820a 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -29,6 +29,8 @@
> #include
> #includ
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
> Subject: [PATCH V3 03/13] x86/HV: Add new hvcall guest address host
> visibility support
Use "x86/hyperv:" tag in the Subject line.
>
> From: Tianyu Lan
>
> Add new hvcall guest address host visibility support to mark
> memory visible
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
> Subject: [PATCH V3 02/13] x86/HV: Initialize shared memory boundary in the
> Isolation VM.
As with Patch 1, use the "x86/hyperv:" tag in the Subject line.
>
> From: Tianyu Lan
>
> Hyper-V exposes shared memory boundary via cpuid
> HYPE
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
> Subject: [PATCH V3 01/13] x86/HV: Initialize GHCB page in Isolation VM
The subject line tag on patches under arch/x86/hyperv is generally
"x86/hyperv:".
There's some variation in the spelling of "hyperv", but let's go with the all
lowercas
On 8/12/2021 8:26 PM, Christoph Hellwig wrote:
On Mon, Aug 09, 2021 at 01:56:13PM -0400, Tianyu Lan wrote:
From: Tianyu Lan
In Hyper-V Isolation VM with AMD SEV, swiotlb boucne buffer
needs to be mapped into address space above vTOM and so
introduce dma_map_decrypted/dma_unmap_encrypted() t
On 2021-08-12 7:00 a.m., Christoph Hellwig wrote:
> These can only return 0 for failure or the number of entries, so turn
> the return value into an unsigned int.
>
> Signed-off-by: Christoph Hellwig
Makes sense to me.
Reviewed-by: Logan Gunthorpe
__
On Wed, Jul 28, 2021 at 10:20:34AM -0500, Brian Cain wrote:
> > this series adds support for using the global coherent (aka uncached)
> > pool to the generic dma-direct code and then switches arm-nommu and
> > hexagon over to it, together with a bunch of cleanups.
>
> Christoph,
>
> Thanks for se
These can only return 0 for failure or the number of entries, so turn
the return value into an unsigned int.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 9 +
kernel/dma/mapping.c| 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/
On 2021-08-11 21:18, Sven Peter wrote:
On Tue, Aug 10, 2021, at 11:51, Robin Murphy wrote:
On 2021-08-09 21:45, Sven Peter wrote:
On Mon, Aug 9, 2021, at 19:41, Robin Murphy wrote:
On 2021-08-07 12:47, Sven Peter via iommu wrote:
On Fri, Aug 6, 2021, at 20:04, Robin Murphy wrote:
On 20
This is still broken. You need to make sure the actual DMA allocations
do have struct page backing.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Aug 09, 2021 at 01:56:13PM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> In Hyper-V Isolation VM with AMD SEV, swiotlb boucne buffer
> needs to be mapped into address space above vTOM and so
> introduce dma_map_decrypted/dma_unmap_encrypted() to map/unmap
> bounce buffer memory. The pla
Hi Sven,
On Tue, Aug 10, 2021 at 08:09:53AM +0200, Sven Peter wrote:
> This happens because apple/dart is missing the "Optimizing iommu_[map/unmap]
> performance"
> series which is already in the core branch [1].
> The same commit works fine in iommu/next since that branch merges both
> iommu/co
On Tue, Aug 10, 2021 at 03:47:19PM +0200, Geert Uytterhoeven wrote:
> The Apple DART (Device Address Resolution Table) IOMMU is only present
> on Apple ARM SoCs like the M1. Hence add a dependency on ARCH_APPLE, to
> prevent asking the user about this driver when configuring a kernel
> without sup
On 2021-08-12 10:21, David Stevens wrote:
On Thu, Aug 12, 2021 at 3:47 AM Robin Murphy wrote:
On 2021-08-11 03:42, David Stevens wrote:
From: David Stevens
When calling arch_sync_dma, we need to pass it the memory that's
actually being used for dma. When using swiotlb bounce buffers, this i
On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote:
> On 8/11/21 7:19 AM, Kirill A. Shutemov wrote:
> > On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
> >> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
> >>>
> >>>
> >>> On 7/27/21 3:26 PM, Tom Lendacky wrote:
> >>>
On 2021-08-12 02:45, David Stevens wrote:
On Thu, Aug 12, 2021 at 4:12 AM Robin Murphy wrote:
On 2021-08-11 03:42, David Stevens wrote:
From: David Stevens
For devices which set min_align_mask, swiotlb preserves the offset of
the original physical address within that mask. Since __iommu_dma
On Thu, Aug 12, 2021 at 3:47 AM Robin Murphy wrote:
>
> On 2021-08-11 03:42, David Stevens wrote:
> > From: David Stevens
> >
> > When calling arch_sync_dma, we need to pass it the memory that's
> > actually being used for dma. When using swiotlb bounce buffers, this is
> > the bounce buffer. Mov
48 matches
Mail list logo
