Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Friday, October 11, 2019 9:32 PM
>
> Hi Shimoda-san,
>
> On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
> wrote:
> > Since we will have changed memory mapping of the IPMMU in the future,
> > this patch adds a utlb_offset_base into struct
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Friday, October 11, 2019 9:29 PM
>
> Hi Shimoda-san,
>
> On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
> wrote:
> > Since we will have changed memory mapping of the IPMMU in the future,
> > this patch uses ipmmu_features values instead of a
On Mon, 2019-10-14 at 15:21 +0100, Robin Murphy wrote:
> On 14/10/2019 07:38, Yong Wu wrote:
> > 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.
> >
> > Note: If iotlb_sync comes
On Mon, 2019-10-14 at 15:04 +0100, Robin Murphy wrote:
> On 14/10/2019 07:38, Yong Wu wrote:
> > Use writel for the register F_MMU_INV_RANGE which is for triggering the
> > HW work. We expect all the setting(iova_start/iova_end...) have already
> > been finished before F_MMU_INV_RANGE.
>
> For
On Mon, 2019-10-14 at 15:22 +0100, Robin Murphy wrote:
> On 14/10/2019 07:38, Yong Wu wrote:
> > In our tlb range flush, we don't care the "leaf". Remove it to simplify
> > the code. no functional change.
>
> Presumably you don't care about the granule either?
Yes. I only keep "granule" to
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Friday, October 11, 2019 9:11 PM
>
> Hi Shimoda-san,
>
> Thanks for your patch!
>
> On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
> wrote:
> > To support different registers memory mapping hardware easily
> > in the future, this patch
On 2019/9/30 22:33, John Garry wrote:
> Now that we can identify a PMCG implementation from the parent SMMUv3
> IIDR, drop all the code to match based on the ACPI OEM ID.
>
> Signed-off-by: John Garry
> ---
> drivers/acpi/arm64/iort.c | 35 +--
>
Hi John,
On 2019/9/30 22:33, John Garry wrote:
> In the IORT, a PMCG node includes a node reference to its associated
> device.
>
> Set the PMCG platform device parent device for future referencing.
>
> For now, we only consider setting for when the associated component is an
> SMMUv3.
>
>
On Mon, 2019-10-14 at 22:11 +0100, Will Deacon wrote:
> On Sat, Oct 12, 2019 at 02:23:47PM +0800, Yong Wu wrote:
> > On Fri, 2019-10-11 at 17:29 +0100, Will Deacon wrote:
> > > On Wed, Oct 09, 2019 at 09:19:02PM +0800, Yong Wu wrote:
> > > > Use writel for the register F_MMU_INV_RANGE which is for
On Sat, Oct 12, 2019 at 02:23:47PM +0800, Yong Wu wrote:
> On Fri, 2019-10-11 at 17:29 +0100, Will Deacon wrote:
> > On Wed, Oct 09, 2019 at 09:19:02PM +0800, Yong Wu wrote:
> > > Use writel for the register F_MMU_INV_RANGE which is for triggering the
> > > HW work. We expect all the
On Mon, Oct 14, 2019 at 08:31:02PM +0200, Nicolas Saenz Julienne wrote:
> the Raspberry Pi 4 offers up to 4GB of memory, of which only the first
> is DMA capable device wide. This forces us to use of bounce buffers,
> which are currently not very well supported by ARM's custom DMA ops.
> Among
Reuse existing macro to simplify the code and improve readability.
Cc: Joerg Roedel
Cc: Gary R Hook
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd_iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
IOMMU Event Log encodes 20-bit PASID for events:
ILLEGAL_DEV_TABLE_ENTRY
IO_PAGE_FAULT
PAGE_TAB_HARDWARE_ERROR
INVALID_DEVICE_REQUEST
as:
PASID[15:0] = bit 47:32
PASID[19:16] = bit 19:16
Note that INVALID_PPR_REQUEST event has different encoding
from the rest of the
Convert the Arm SMMv3 binding to the DT schema format.
Cc: Joerg Roedel
Cc: Mark Rutland
Cc: Will Deacon
Cc: Robin Murphy
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring
---
v2:
- Refine interrupt definition based on Robin's comments
The Raspberry Pi 4 has a 1GB ZONE_DMA area starting at address
0x and a mapping between physical and DMA memory offset by
0xc000. It transpires that, on non LPAE systems, any attempt to
translate physical addresses outside of ZONE_DMA will result in an
overflow. The resulting DMA
ARM devices might use the arch's custom dma-mapping implementation or
dma-direct/swiotlb depending on how the kernel is built. This is not
good enough as we need to be able to control the device's DMA ops based
on the specific machine configuration.
Centralise control over DMA ops with
A bounce buffering feature is already available in ARM, dmabounce.c, yet
it doesn't support high memory which some devices need. Instead of
fixing it, provide a means for devices to enable dma-direct, which is the
preferred way of doing DMA now days.
Signed-off-by: Nicolas Saenz Julienne
---
Hi all,
the Raspberry Pi 4 offers up to 4GB of memory, of which only the first
is DMA capable device wide. This forces us to use of bounce buffers,
which are currently not very well supported by ARM's custom DMA ops.
Among other things the current mechanism (see dmabounce.c) isn't
suitable for
Some architectures, notably ARM, are interested in tweaking this
depending on their runtime DMA addressing limitations.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/include/asm/page.h | 2 --
arch/arm64/mm/init.c| 9 +++--
arch/powerpc/include/asm/page.h | 9
The Raspberry Pi 4 supports up to 4GB of memory yet most of its devices
are only able to address the fist GB. Enable dma-direct for that board
in order to benefit from swiotlb's bounce buffering mechanism.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm/mach-bcm/Kconfig | 1 +
Hi Joerg,
Just another gentle reminder. I think we have reached consensus in this
common code. Jean and Eric can confirm.
Thanks,
Jacob
On Mon, 7 Oct 2019 12:39:12 -0700
Jacob Pan wrote:
> Hi Joerg and all,
>
> Just wondering if you have more comments on this series.
>
> Thanks,
>
> Jacob
On 10/14/19 2:54 PM, Robin Murphy wrote:
> On 13/10/2019 15:28, Daniele Alessandrelli wrote:
>> Hi,
>>
>> It looks like dma_alloc_coherent() is setting the dma_handle output
>> parameter to the memory physical address and not the device bus
>> address when the device is using reserved memory
On 12/10/2019 13:29, Shyam Saini wrote:
This parameters are not changed after early boot.
By making them __ro_after_init will reduce any attack surface in the
kernel.
At a glance, it looks like these are only referenced by a couple of
__init functions, so couldn't they just be
On 14/10/2019 07:38, Yong Wu wrote:
In our tlb range flush, we don't care the "leaf". Remove it to simplify
the code. no functional change.
Presumably you don't care about the granule either?
Robin.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 16
1 file
On Mon, 14 Oct 2019, Guilherme G. Piccoli wrote:
> Modules linked in: <...>
> CPU: 40 PID: 78274 Comm: qemu-system-x86 Tainted: P W OE
Tainted: P - Proprietary module loaded ...
Try again without that module
Tainted: W - Warning issued before
Are you sure that that warning is harmless
On 14/10/2019 07:38, Yong Wu wrote:
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.
Note: If iotlb_sync comes from iommu_iotlb_gather_add_page, we have to
avoid retry the lock since the
On 14/10/2019 07:38, Yong Wu wrote:
Use the correct tlb_flush_all instead of the original one.
Reviewed-by: Robin Murphy
Fixes: 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API TLB sync")
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1
On 13/10/2019 15:28, Daniele Alessandrelli wrote:
Hi,
It looks like dma_alloc_coherent() is setting the dma_handle output
parameter to the memory physical address and not the device bus
address when the device is using reserved memory regions for DMA
allocation. This is despite using
On 14/10/2019 07:38, Yong Wu wrote:
Use writel for the register F_MMU_INV_RANGE which is for triggering the
HW work. We expect all the setting(iova_start/iova_end...) have already
been finished before F_MMU_INV_RANGE.
For Arm CPUs, these registers should be mapped as Device memory,
therefore
Hello kernel community, I'm investigating a recurrent problem, and
hereby I'm seeking some advice - perhaps anybody reading this had
similar issue, for example. I've iterated some mailing-lists I thought
would be of interest, apologize if I miss any or if I shouldn't have
included some.
We have a
Hi,
It looks like dma_alloc_coherent() is setting the dma_handle output
parameter to the memory physical address and not the device bus
address when the device is using reserved memory regions for DMA
allocation. This is despite using 'dma_ranges' in the device tree to
describe the DMA memory
On 14/10/2019 05:51, David Gibson wrote:
On Fri, Oct 11, 2019 at 06:25:18PM -0700, Ram Pai wrote:
From: Thiago Jung Bauermann
In order to safely use the DMA API, virtio needs to know whether DMA
addresses are in fact physical addresses and for that purpose,
dma_addr_is_phys_addr() is
Right now, the tlb_add_flush_nosync and tlb_sync always appear together.
we merge the two functions into one. No functional change.
mtk_iommu_tlb_add_flush_nosync
mtk_iommu_tlb_sync
Signed-off-by: Chao Hao
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 36
Use writel for the register F_MMU_INV_RANGE which is for triggering the
HW work. We expect all the setting(iova_start/iova_end...) have already
been finished before F_MMU_INV_RANGE.
Signed-off-by: Anan.Sun
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 3 +--
1 file changed, 1
Reduce the tlb timeout value from 10us to 1000us. the original value
is so long that affect the multimedia performance. This is only a minor
improvement rather than fixing a issue.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
In our tlb range flush, we don't care the "leaf". Remove it to simplify
the code. no functional change.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c
This patchset mainly fixes a tlb flush timeout issue and use the new
iommu_gather to re-implement the tlb flush flow. and several clean up
patches about the tlb_flush.
change note:
v3:
1. Use the gather to implement the tlb_flush suggested from Tomasz.
2. add some clean up patches.
v2:
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.
Note: If iotlb_sync comes from iommu_iotlb_gather_add_page, we have to
avoid retry the lock since the spinlock have already been acquired.
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 dom->pgtlock, then it will cause the variable "tlb_flush_active"
may be
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
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c
40 matches
Mail list logo
