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 ipmmu_
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 ma
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 fro
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 Arm
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 satisf
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 removes
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 +--
> include/linux/acp
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.
>
> Sign
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 setting(iova_s
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 othe
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
ind
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 events
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
.../devicetree/bindings/iommu/arm,smmu-v3
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 addre
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 arm_dma_dir
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
---
arc
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 high
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 +
arch/arm/mach
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 region
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 __initdata/__ini
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 change
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 sp
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 insertion
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 'dma_ranges
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 t
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 mapp
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 introduce
32 matches
Mail list logo
