From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:36:57 -0800
> Move the alloc / free routines down the file so that we can easily use
> the map / unmap helpers to implement non-consistent allocations.
>
> Also drop the _coherent postfix to match the method name.
>
> Signed-off-by: Christoph He
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:36:59 -0800
> Move the alloc / free routines down the file so that we can easily use
> the map / unmap helpers to implement non-consistent allocations.
>
> Also drop the _coherent postfix to match the method name.
>
> Signed-off-by: Christoph He
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:37:00 -0800
> Just allocate the memory and use map_page to map the memory.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@lists.linux-foundation.org
https
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:36:58 -0800
> Just allocate the memory and use map_page to map the memory.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@lists.linux-foundation.org
https
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:15 -0800
> There are enough common defintions that a single header seems nicer.
>
> Also drop the pointless include.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Sam Ravnborg
Acked-by: David S. Miller
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:14 -0800
> It has nothing to do with the content of the pci.h header.
>
> Suggested by: Sam Ravnborg
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@list
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:12 -0800
> There is no good reason to have a double indirection for the sparc32
> dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops
> instance for the different IOMMU types.
>
> Signed-off-by: Christoph Hellwig
Acked-by:
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:13 -0800
> The only thing we need to explicitly pull in is the defines for the
> CPU type.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@lists.linux-f
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:11 -0800
> Factor the code to remap memory returned from the DMA coherent allocator
> into two helpers that can be shared by the IOMMU and direct mapping code.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
_
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:10 -0800
> No need to BUG_ON() on the cache maintainance ops - they are no-ops
> by default, and there is nothing in the DMA API contract that prohibits
> calling them on sbus devices (even if such drivers are unlikely to
> ever appear).
>
> S
Hi Robin,
On 12/07/2018 09:17 PM, Robin Murphy wrote:
> On 07/12/2018 05:49, Dongli Zhang wrote:
>>
>>
>> On 12/07/2018 12:12 AM, Joe Jin wrote:
>>> Hi Dongli,
>>>
>>> Maybe move d_swiotlb_usage declare into swiotlb_create_debugfs():
>>
>> I assume the call of swiotlb_tbl_map_single() might be fre
On Sat, 2018-12-08 at 09:36 -0800, Christoph Hellwig wrote:
> For the iommu ops we can just use the implementaton for DMA coherent
> devices. For the regular ops we need mix and match a bit so that
> we either use the CMA allocator without remapping, but with a special
> error handling case for hi
On 12/7/18 9:34 AM, Christoph Hellwig wrote:
> Hi all,
>
> the ARM imx27/31 ports and various sh boards use
> dma_declare_coherent_memory on main memory taken from the memblock
> allocator.
>
> Is there any good reason these couldn't be switched to CMA areas?
> Getting rid of these magic dma_decl
There are enough common defintions that a single header seems nicer.
Also drop the pointless include.
Signed-off-by: Christoph Hellwig
Acked-by: Sam Ravnborg
---
arch/sparc/include/asm/pci.h| 53 ++---
arch/sparc/include/asm/pci_32.h | 32
There is no good reason to have a double indirection for the sparc32
dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops
instance for the different IOMMU types.
Signed-off-by: Christoph Hellwig
---
arch/sparc/include/asm/dma.h | 48 +---
arch/sparc/kernel/ioport.c |
No need to BUG_ON() on the cache maintainance ops - they are no-ops
by default, and there is nothing in the DMA API contract that prohibits
calling them on sbus devices (even if such drivers are unlikely to
ever appear).
Similarly a dma_supported method that always returns 0 is rather
pointless.
Factor the code to remap memory returned from the DMA coherent allocator
into two helpers that can be shared by the IOMMU and direct mapping code.
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/ioport.c | 151 -
1 file changed, 67 insertions(+), 84 del
The only thing we need to explicitly pull in is the defines for the
CPU type.
Signed-off-by: Christoph Hellwig
---
arch/sparc/include/asm/dma-mapping.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/sparc/include/asm/dma-mapping.h
b/arch/sparc/include/asm/dma-mappin
It has nothing to do with the content of the pci.h header.
Suggested by: Sam Ravnborg
Signed-off-by: Christoph Hellwig
---
arch/sparc/include/asm/leon.h | 9 +
arch/sparc/include/asm/pci_32.h | 9 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/sparc/incl
[sorry for the spam, had to resend due a wrongly typed linux-arm-kernel
address]
Hi all,
we had all kinds of discussions about how to best allocate DMAable memory
without having to deal with the problem that your normal "coherent"
DMA allocator can be very slow on platforms where DMA is not DMA
There is no need to have an additional kernel mapping for a contiguous
allocation if the device already is DMA coherent, so skip it.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff
We got rid of the odd selective consistent or not behavior, and now
want the normal dma_sync_single_* functions to be used for strict
ownership transfers. While dma_cache_sync hasn't been removed from
the tree yet it should not be used in any new caller, so documentation
for it is dropped here.
S
For the iommu ops we can just use the implementaton for DMA coherent
devices. For the regular ops we need mix and match a bit so that
we either use the CMA allocator without remapping, but with a special
error handling case for highmem pages, or the simple allocator.
Signed-off-by: Christoph Hell
Hi all,
we had all kinds of discussions about how to best allocate DMAable memory
without having to deal with the problem that your normal "coherent"
DMA allocator can be very slow on platforms where DMA is not DMA
coherent.
To work around this drivers basically two choices at the moment:
(1) j
Memory declared using dma_declare_coherent is ioremapped and thus not
always suitable for our tightened DMA_ATTR_NON_CONSISTENT definition.
Skip it given all the existing callers don't DMA_ATTR_NON_CONSISTENT
anyway.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 3 ++-
1 fi
If DMA_ATTR_NON_CONSISTENT is passed in the flags we can always just
use the dma_direct_alloc_pages implementation given that the callers
will take care of any cache maintainance on ownership transfers between
the CPU and the device.
Signed-off-by: Christoph Hellwig
---
arch/arc/mm/dma.c
Just allocate the memory and use map_page to map the memory.
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/iommu.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c
index 4bf0497e
Move the alloc / free routines down the file so that we can easily use
the map / unmap helpers to implement non-consistent allocations.
Also drop the _coherent postfix to match the method name.
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/pci_sun4v.c | 229 +---
Just allocate the memory and use map_page to map the memory.
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/pci_sun4v.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c
index b95c70136559..24a76ecf2986 10064
DMA_ATTR_NON_CONSISTENT forces contiguous allocations as we don't
want to remap, and is otherwise forced down the same pass as if we
were always on a coherent device. No new code required except for
a few conditionals.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 18 ++
Move the alloc / free routines down the file so that we can easily use
the map / unmap helpers to implement non-consistent allocations.
Also drop the _coherent postfix to match the method name.
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/iommu.c | 135 +++-
Just as a warning: this series now has some conflicts with the dma
mapping tree due to the ->mapping_error removal, and there might be
some bigger ones if the direct calls for the direct mapping code series
goes ahead. None of them affect the early part of the series that do
not touch the actual
On Sat, Dec 08, 2018 at 05:06:48PM +0100, Jesper Dangaard Brouer wrote:
> You can add my:
> Tested-by: Jesper Dangaard Brouer
> or
> Acked-by: Jesper Dangaard Brouer
>
> I'm very happy that you work on this. And I've done micro-benchmark
> testing of the patchset (and branch dma-direct-calls)
On Fri, 7 Dec 2018 11:07:05 -0800
Christoph Hellwig wrote:
> Hi all,
>
> a while ago Jesper reported major performance regressions due to the
> spectre v2 mitigations in his XDP forwarding workloads. A large part
> of that is due to the DMA mapping API indirect calls.
>
> It turns out that th
Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix an
off-by-one in dma_capable)
git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615
The PASEMI onboard ethernet also works with this commit and the X5000
boots without any problems.
-- Christian
On 08 December 2018 at 11
On Tue, 2018-11-27 at 08:42 +0100, Christoph Hellwig wrote:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.
So I had to cleanup some dust but it works on G5 with and without iommu
and 32-bit powermacs at least.
We're doing more tests, hopefully mpe can dig out some P
Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma: remove
max_direct_dma_addr)
git checkout 7ebc44c535f6bd726d553756d38b137acc718443
OK, the PASEMI onboard ethernet works and the P5020 board boots.
-- Christian
On 07 December 2018 at 7:33PM, Christian Zigotzky wrote:
Next ste
On Tue, 2018-11-27 at 08:42 +0100, Christoph Hellwig wrote:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.
I completely missed your posting of V4 ! I was wondering what was
taking you so long :)
I'll give it a spin & send acks over the next 2 or 3 days.
Cheers,
Ben
From: Arvind Yadav
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 . So mark the non-const
structs as const.
Signed-off-by: Arvind Yadav
Signed-off-by: Yong Wu
[Yong: Change the title to iommu/mediat
Switch to SPDX license identifier for MediaTek iommu/smi and their
header files.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
---
drivers/iommu/mtk_iommu.c | 10 +-
drivers/iommu/mtk_iommu.h | 10 +-
drivers/iommu/mtk_iommu_v1.c
In the reboot burning test, if some Multimedia HW has something wrong,
It may keep send the invalid request to IOMMU. In order to avoid
affect the reboot flow, we add the shutdown callback to disable
M4U HW when shutdown.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 6 ++
1 file ch
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
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
---
drivers/iommu/mtk_iommu.c | 2 ++
drivers/iommu/mtk_iommu.h | 1 +
2 file
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
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 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
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
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-
In some SoCs, M4U doesn't have its "bclk", it will use the EMI
clock instead which has always been enabled when entering kernel.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 10 +++---
drivers/iommu/mtk_iommu.h | 3 +++
2 files changed,
MediaTek extend the arm v7s descriptor to support the dram over 4GB.
In the mt2712 and mt8173, it's called "4GB mode", the physical address
is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
is remapped to high address from 0x1__ to 0x1__, the
bit32 is always enab
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:
Add two helper functions: paddr_to_iopte and iopte_to_paddr.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 45 --
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b
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 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
---
drivers/iommu/mtk_iommu.c | 24
drivers/iommu/mtk_iommu.h | 6 +-
2 files changed, 21 insertions(+), 9 deletions
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
|
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
|
57 matches
Mail list logo
