On Fri, Jan 8, 2021 at 1:59 AM Florian Fainelli wrote:
>
> On 1/7/21 9:42 AM, Claire Chang wrote:
>
> >> Can you explain how ATF gets involved and to what extent it does help,
> >> besides enforcing a secure region from the ARM CPU's perpsective? Does
> >> the PCIe root complex not have an IOMMU
On Fri, Jan 8, 2021 at 2:15 AM Florian Fainelli wrote:
>
> On 1/7/21 10:00 AM, Konrad Rzeszutek Wilk wrote:
> >>>
> >>>
> >>> - Nothing stops the physical device from bypassing the SWIOTLB buffer.
> >>>That is if an errant device screwed up the length or DMA address, the
> >>>SWIOTLB
Hi, Bjorn
On 2020/12/18 上午4:38, Bjorn Helgaas wrote:
The principles are:
- I don't want to have to update a quirk for every new Device ID
that needs this.
Hi Bjorn and Zhangfei,
We plan to use ATS/PRI to support SVA in future PCI devices. However, for
current devices, we need to
Hi Yi,
On Thu, Sep 10, 2020 at 4:13 PM Liu Yi L wrote:
>
> This patch is added as instead of returning a boolean for DOMAIN_ATTR_NESTING,
> iommu_domain_get_attr() should return an iommu_nesting_info handle. For
> now, return an empty nesting info struct for now as true nesting is not
> yet
Hi Jean,
On 1/8/21 10:52 PM, Jean-Philippe Brucker wrote:
Some devices manage I/O Page Faults (IOPF) themselves instead of relying
on PCIe PRI or Arm SMMU stall. Allow their drivers to enable SVA without
mandating IOMMU-managed IOPF. The other device drivers now need to first
enable
On Thu, 7 Jan 2021 17:29:00 +0800
Keqian Zhu wrote:
> If we detach group during dirty page tracking, we shouldn't remove
> vfio_dma, because dirty log will lose.
>
> But we don't prevent unmap_unpin_all in vfio_iommu_release, because
> under normal procedure, dirty tracking has been stopped.
> >>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> >>> index 0a4881e59aa7..3d9b17fe5771 100644
> >>> --- a/kernel/dma/direct.c
> >>> +++ b/kernel/dma/direct.c
> >>> @@ -374,9 +374,11 @@ void dma_direct_unmap_sg(struct device *dev, struct
> >>> scatterlist *sgl,
> >>>struct
On 2021-01-11 18:03, Marc Orr wrote:
On 2021-01-11 15:43, Marc Orr wrote:
minus sta...@vger.kernel.org, per gregkh@'s email.
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 0a4881e59aa7..3d9b17fe5771 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -374,9 +374,11 @@
On 2021-01-07 02:45, chenxiang (M) wrote:
Hi Will, Robin or other guys,
When debugging SMMU/SVA issue on huawei ARM64 board, we find that it
lacks of enough debugfs for ARM SMMU driver (such as
the value of STE/CD which we need to check sometimes). Currently it
creates top-level iommu
On 2021-01-07 13:03, Will Deacon wrote:
On Thu, Jan 07, 2021 at 03:03:40PM +0530, Ajay Kumar wrote:
When PCI function drivers(ex:pci-endpoint-test) are probed for already
initialized PCIe-RC(Root Complex), and PCIe-RC is already bound to SMMU,
then we encounter a situation where the function
> On 2021-01-11 15:43, Marc Orr wrote:
minus sta...@vger.kernel.org, per gregkh@'s email.
> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> > index 0a4881e59aa7..3d9b17fe5771 100644
> > --- a/kernel/dma/direct.c
> > +++ b/kernel/dma/direct.c
> > @@ -374,9 +374,11 @@ void
This patch updates dma_direct_unmap_sg() to mark each scatter/gather
entry invalid, after it's unmapped. This fixes two issues:
1. It makes the unmapping code able to tolerate a double unmap.
2. It prevents the NVMe driver from erroneously treating an unmapped DMA
address as mapped.
The bug that
On Mon, Jan 11, 2021 at 07:43:35AM -0800, Marc Orr wrote:
> This patch updates dma_direct_unmap_sg() to mark each scatter/gather
> entry invalid, after it's unmapped. This fixes two issues:
>
> 1. It makes the unmapping code able to tolerate a double unmap.
> 2. It prevents the NVMe driver from
On 2021-01-11 15:43, Marc Orr wrote:
This patch updates dma_direct_unmap_sg() to mark each scatter/gather
entry invalid, after it's unmapped. This fixes two issues:
s/fixes/bodges around (badly)/
1. It makes the unmapping code able to tolerate a double unmap.
2. It prevents the NVMe driver
On 2021-01-10 23:52, Sai Prakash Ranjan wrote:
On 2021-01-11 11:52, Sai Prakash Ranjan wrote:
Hi Isaac,
I gave this series a go on chromebook and saw these warnings
and several device probe failures, logs attached below:
WARN corresponds to this code in arm_lpae_map_by_pgsize()
if
Add support for IOMMU drivers to have their own map_sg() callbacks.
This completes the path for having iommu_map_sg() invoke an IOMMU
driver's map_sg() callback, which can then invoke the io-pgtable
map_sg() callback with the entire scatter-gather list, so that it
can be processed entirely in the
While mapping a scatter-gather list, iommu_map_sg() calls
into the IOMMU driver through an indirect call, which can
call into the io-pgtable code through another indirect call.
This sequence of going through the IOMMU core code, the IOMMU
driver, and finally the io-pgtable code, occurs for every
Implement the map_sg io-pgtable op for the ARMv7s io-pgtable
code, so that IOMMU drivers can call it when they need to map
a scatter-gather list.
Signed-off-by: Isaac J. Manjarres
Tested-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm-v7s.c | 90 ++
The iommu_map_sg() code currently iterates through the given
scatter-gather list, and in the worst case, invokes iommu_map()
for each element in the scatter-gather list, which calls into
the IOMMU driver through an indirect call. For an IOMMU driver
that uses a format supported by the io-pgtable
Now that everything is in place for iommu_map_sg() to defer
mapping a scatter-gather list to the io-pgtable layer, implement
the map_sg() callback in the SMMU driver, so that iommu_map_sg()
can invoke it with the entire scatter-gather list that will be
mapped.
Signed-off-by: Isaac J. Manjarres
Implement the map_sg io-pgtable op for the ARM LPAE io-pgtable
code, so that IOMMU drivers can call it when they need to map
a scatter-gather list.
Signed-off-by: Isaac J. Manjarres
Tested-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 86 ++
Use the newly introduced IOMMU_LLC page protection flag to map
GPU buffers. This will make sure that proper stage-1 PTE
attributes are set for GPU buffers to use system cache. This
also introduces MMU_FEATURE_USE_LLC features bit to check for
GPUs supporting LLC and set them in the target specific
Add a new page protection flag IOMMU_LLC which can be used
by non-coherent masters to set cacheable memory attributes
for an outer level of cache called as last-level cache or
system cache. Initial user of this page protection flag is
the adreno gpu and then can later be used by other clients
such
Rename last-level cache quirk IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to
IO_PGTABLE_QUIRK_PTW_LLC which is used to set the required TCR
attributes for non-coherent page table walker to be more generic
and in sync with the upcoming page protection flag IOMMU_LLC.
Signed-off-by: Sai Prakash Ranjan
---
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag")
removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went
the memory type setting required for the non-coherent masters to use
system cache. Now that system cache support for GPU is added, we will
need to set the
I am the author of MediaTek iommu driver, and will to maintain and
develop it further.
Add myself to cover these items.
Signed-off-by: Yong Wu
Reviewed-by: Chun-Kuang Hu
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
Add mt8192 iommu support.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 22 ++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 084fb4394ffc..0ad14a7604b1 100644
---
This priv_data is set in the of_xlate. if of_xlate failed, it should
not enter attach_device. remove the unnecessary check.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index
After extending v7s, our pagetable already support iova reach
16GB(34bit). the master got the iova via dma_alloc_attrs may reach
34bits, but its HW register still is 32bit. then how to set the
bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
we separate whole 16GB iova to four
For multiple iommu_domains, we need to reserve some iova regions. Take a
example, If the default iova region is 0 ~ 4G, but the 0x4000_ ~
0x43ff_ is only for the special CCU0 domain. Thus we should exclude
this region for the default iova region.
Signed-off-by: Anan sun
Signed-off-by:
Some HW IP(ex: CCU) require the special iova range. That means the iova
got from dma_alloc_attrs for that devices must locate in his special range.
In this patch, we prepare a iommu group(domain) for each a iova range
requirement.
Meanwhile we still use one pagetable which support 16GB iova.
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
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
---
drivers/iommu/mtk_iommu.c | 19
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
---
drivers/iommu/mtk_iommu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
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
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
---
drivers/iommu/mtk_iommu.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git
If the iova is over 32bit, the fault status register bit is a little
different.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index
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
---
drivers/iommu/mtk_iommu.c | 10 --
1 file
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,
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
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
In the original code, we lack the error handle. This patch adds them.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index
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
---
drivers/iommu/mtk_iommu.c | 13 +++--
1 file changed, 7 insertions(+), 6
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
---
drivers/iommu/mtk_iommu.c | 6 +-
1 file changed, 5 insertions(+), 1
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
---
The standard input iova bits is 32. MediaTek quad the lvl1 pagetable
(4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach
34bit.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 7 ---
1 file changed, 4 insertions(+), 3
Add "cfg" as a parameter for some macros. This is a preparing patch for
mediatek extend the lvl1 pgtable. No functional change.
Signed-off-by: Yong Wu
Acked-by: Will Deacon
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 36 +++---
1 file changed, 18
The current _ARM_V7S_LVL_BITS/ARM_V7S_LVL_SHIFT use a formula to calculate
the corresponding value for level1 and level2 to pretend the code sane.
Actually their level1 and level2 values are different from each other.
This patch only clarify the two macro. No functional change.
Suggested-by:
Use the ias for the valid iova checking in arm_v7s_unmap. This is a
preparing patch for supporting iova 34bit for MediaTek.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
Signed-off-by: Yong Wu
Acked-by: Will Deacon
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 9 +++--
drivers/iommu/mtk_iommu.c | 2 +-
include/linux/io-pgtable.h | 4 ++--
3 files changed,
Use the common memory header(larb-port) in the source code.
Signed-off-by: Yong Wu
Acked-by: Krzysztof Kozlowski
---
drivers/iommu/mtk_iommu.c | 7 ---
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 1 +
include/soc/mediatek/smi.h | 2 --
4 files changed, 2 insertions(+),
If group->default_domain exists, avoid reallocate it.
In some iommu drivers, there may be several devices share a group. Avoid
realloc the default domain for this case.
Signed-off-by: Yong Wu
---
drivers/iommu/iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
"dev->dma_range_map" contains the devices' dma_ranges information,
This patch moves dma_range_map before of_iommu_configure. The iommu
driver may need to know the dma_address requirements of its iommu
consumer devices.
CC: Rob Herring
CC: Frank Rowand
Signed-off-by: Yong Wu
---
This patch adds decriptions for mt8192 IOMMU and SMI.
mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
table format. The M4U-SMI HW diagram is as below:
EMI
|
M4U
|
Only rename the header guard for all the SoC larb port header file.
No funtional change.
Suggested-by: Krzysztof Kozlowski
Signed-off-by: Yong Wu
Acked-by: Krzysztof Kozlowski
Acked-by: Rob Herring
---
include/dt-bindings/memory/mt2701-larb-port.h | 4 ++--
Extend the max larb number definition as mt8192 has larb_nr over 16.
Signed-off-by: Yong Wu
Acked-by: Rob Herring
Acked-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 2 +-
include/dt-bindings/memory/mtk-memory-port.h| 4 ++--
2 files
Put all the macros about smi larb/port togethers.
Signed-off-by: Yong Wu
Acked-by: Rob Herring
Acked-by: Krzysztof Kozlowski
---
include/dt-bindings/memory/mt2712-larb-port.h | 2 +-
include/dt-bindings/memory/mt6779-larb-port.h | 2 +-
include/dt-bindings/memory/mt8167-larb-port.h | 2 +-
Convert MediaTek IOMMU to DT schema.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
---
.../bindings/iommu/mediatek,iommu.txt | 105 ---
.../bindings/iommu/mediatek,iommu.yaml| 167 ++
2 files changed, 167 insertions(+), 105 deletions(-)
delete mode
This patch mainly adds support for mt8192 Multimedia IOMMU and SMI.
mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
table format. The M4U-SMI HW diagram is as below:
EMI
|
M4U
On Thu, Jan 07, 2021 at 03:14:08PM +0100, Ricardo Ribalda wrote:
> > So I think we do want these branches for coherent vs non-coherent as they
> > have very different semantics and I do not think that hiding them under
> > the same API helps people to understand those vastly different semantics.
>
60 matches
Mail list logo
