On Thu, Jan 19, 2017 at 08:57:55PM +, Eric Auger wrote:
> The get() populates the list with the MSI IOVA reserved window.
>
> At the moment an arbitray MSI IOVA window is set at 0x800
> of size 1MB. This will allow to report those info in iommu-group
> sysfs.
>
> Signed-off-by: Eric Auger
From: Magnus Damm
Update the IPMMU DT binding documentation to include the r8a7796 compat
string for R-Car M3-W.
Signed-off-by: Magnus Damm
Acked-by: Laurent Pinchart
Acked-by: Rob Herring
Acked-by: Simon Horman
Acked-by: Geert Uytterhoeven
---
Previously posted separately as
[PATCH v3]
[adding David Woodhouse, since he maintains this driver]
Will
On Thu, Jan 19, 2017 at 08:57:53PM +, Eric Auger wrote:
> This patch registers the [FEE0_h - FEF0_000h] 1MB MSI
> range as a reserved region and RMRR regions as direct regions.
>
> This will allow to report those reserved regi
iommu/ipmmu-vmsa: r8a7796 support V2
[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
[PATCH v2 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
[PATCH v2 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
This series adds r8a7796 support to the IPMMU driver. The DT binding
ge
From: Magnus Damm
Bump up the maximum numbers of micro-TLBS to 48.
Each IPMMU device instance get micro-TLB assignment via
the "iommus" property in DT. Older SoCs tend to use a
maximum number of 32 micro-TLBs per IPMMU instance however
newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
From: Magnus Damm
Support the r8a7796 IPMMU by sharing feature flags between
r8a7795 and r8a7796. Also update IOMMU_OF_DECLARE to hook
up the updated compat string.
Signed-off-by: Magnus Damm
---
Changes since V1:
- None
drivers/iommu/ipmmu-vmsa.c |9 +++--
1 file changed, 7 insert
Hi Will,
On 23/01/2017 12:46, Will Deacon wrote:
> [adding David Woodhouse, since he maintains this driver]
Thank you for adding David to the list.
Whoever is likely to pull this, please let me know if I need to respin
to add missed Will's Acked-by.
Thanks
Eric
>
> Will
>
> On Thu, Jan 19, 2
[+bjorn]
On Sat, Jan 21, 2017 at 12:45:43AM +0530, Sricharan R wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver pr
From: Magnus Damm
Consider failure of iommu_get_domain_for_dev() as non-critical and
get rid of the warning printout. This allows IOMMU properties to be
included in the DTB even though the kernel is configured with
CONFIG_IOMMU_API=n or in case a particular IOMMU driver refuses to
enable IOMMU su
iommu/ipmmu-vmsa: IPMMU slave device whitelist
[PATCH/RFC 1/2] arm64: mm: Silently allow devices lacking IOMMU group
[PATCH/RFC 2/2] iommu/ipmmu-vmsa: Opt-in slave devices based on ES version
Here's a little prototype that shows how DT integration of IPMMU details
may be integrated and merged ups
From: Magnus Damm
Match on r8a7795 ES2 and enable a certain DMA controller.
In other cases the IPMMU driver remains disabled.
Signed-off-by: Magnus Damm
---
drivers/iommu/ipmmu-vmsa.c | 24
1 file changed, 24 insertions(+)
--- 0001/drivers/iommu/ipmmu-vmsa.c
+++ wo
Hi Magnus,
On 23/01/17 12:12, Magnus Damm wrote:
> From: Magnus Damm
>
> Consider failure of iommu_get_domain_for_dev() as non-critical and
> get rid of the warning printout. This allows IOMMU properties to be
> included in the DTB even though the kernel is configured with
> CONFIG_IOMMU_API=n o
Hi Magnus,
On Mon, Jan 23, 2017 at 12:40 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Bump up the maximum numbers of micro-TLBS to 48.
>
> Each IPMMU device instance get micro-TLB assignment via
> the "iommus" property in DT. Older SoCs tend to use a
> maximum number of 32 micro-TLBs per IPMMU
On Mon, Jan 16, 2017 at 01:23:34AM -0600, Suravee Suthikulpanit wrote:
> From: Suravee Suthikulpanit
>
> In, perf_iommu_start(), we need to check the return value from
> amd_iommu_set_reg(). In case of failure, we should not enable the PMU.
>
> Also, in perf_iommu_read(), we need to check the re
Hi Magnus,
On Mon, Jan 23, 2017 at 1:12 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Match on r8a7795 ES2 and enable a certain DMA controller.
> In other cases the IPMMU driver remains disabled.
>
> Signed-off-by: Magnus Damm
> ---
>
> drivers/iommu/ipmmu-vmsa.c | 24 ++
On Mon, Jan 16, 2017 at 01:23:30AM -0600, Suravee Suthikulpanit wrote:
> static void perf_iommu_read(struct perf_event *event)
> {
> - u64 count = 0ULL;
> - u64 prev_raw_count = 0ULL;
> - u64 delta = 0ULL;
> + u64 count, prev;
> + s64 delta;
I did send that email where I told
Hi Lorenzo,
>-Original Message-
>From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
>Sent: Monday, January 23, 2017 5:37 PM
>To: Sricharan R
>Cc: robin.mur...@arm.com; will.dea...@arm.com; j...@8bytes.org;
>iommu@lists.linux-foundation.org; linux-arm-
>ker...@lists.infradead.org;
This series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the probe of the
bus/driver is called. Similarly dma_deconfigure is called during
device/dri
From: Robin Murphy
In preparation for some upcoming cleverness, rework the control flow in
of_iommu_configure() to minimise duplication and improve the propogation
of errors. It's also as good a time as any to switch over from the
now-just-a-compatibility-wrapper of_iommu_get_ops() to using the g
From: Robin Murphy
IOMMU configuration represents unchanging properties of the hardware,
and as such should only need happen once in a device's lifetime, but
the necessary interaction with the IOMMU device and driver complicates
exactly when that point should be.
Since the only reasonable tool a
From: Laurent Pinchart
Invalid dma-ranges values should be worked around when retrieving the
DMA range in of_dma_get_range(), not by all callers of the function.
This isn't much of a problem now that we have a single caller, but that
situation will change when moving DMA configuration to device p
From: Laurent Pinchart
As part of moving DMA initializing to probe time the
of_dma_deconfigure() function will need to be called from different
source files. Make it public and move it to drivers/of/device.c where
the of_dma_configure() function is.
Signed-off-by: Laurent Pinchart
---
drivers/
From: Lorenzo Pieralisi
The IOMMU probe deferral implementation requires a mechanism to detect
if drivers for SMMU components are built-in in the kernel to detect
whether IOMMU configuration for a given device should be deferred (ie
SMMU drivers present but still not probed) or not (drivers not p
With arch_setup_dma_ops now being called late during device's probe after
the device's iommu is probed, the notifier trick required to handle the
early setup of dma_ops before the iommu group gets created is not
required. So removing the notifier's here.
Acked-by: Will Deacon
Signed-off-by: Srich
Configuring DMA ops at probe time will allow deferring device probe when
the IOMMU isn't available yet. The dma_configure for the device is
now called from the generic device_attach callback just before the
bus/driver probe is called. This way, configuring the DMA ops for the
device would be called
From: Laurent Pinchart
Failures to look up an IOMMU when parsing the DT iommus property need to
be handled separately from the .of_xlate() failures to support deferred
probing.
The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having b
This is an equivalent to the DT's handling of the iommu master's probe
with deferred probing when the corrsponding iommu is not probed yet.
The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having been performed yet, having
been deferred,
From: Robin Murphy
Now that the appropriate ordering is enforced via profe-deferral of
masters in core code, rip it all out and bask in the simplicity.
Acked-by: Will Deacon
Signed-off-by: Robin Murphy
[Sricharan: Rebased on top of ACPI IORT SMMU series]
Signed-off-by: Sricharan R
---
driver
From: Lorenzo Pieralisi
The IORT linker section introduced by commit 34ceea275f62
("ACPI/IORT: Introduce linker section for IORT entries probing")
was needed to make sure SMMU drivers are registered (and therefore
probed) in the kernel before devices using the SMMU have a chance
to probe in turn.
Hi Lorenzo,
>>[+bjorn]
>>
>>On Sat, Jan 21, 2017 at 12:45:43AM +0530, Sricharan R wrote:
>>> Configuring DMA ops at probe time will allow deferring device probe when
>>> the IOMMU isn't available yet. The dma_configure for the device is
>>> now called from the generic device_attach callback just b
On Mon, Jan 16, 2017 at 01:24:55PM +, Robin Murphy wrote:
> Whilst PCI devices may have 64-bit DMA masks, they still benefit from
> using 32-bit addresses wherever possible in order to avoid DAC (PCI) or
> longer address packets (PCIe), which may incur a performance overhead.
> Implement the sa
On Mon, Jan 16, 2017 at 01:24:54PM +, Robin Murphy wrote:
> iommu_dma_init_domain() was originally written under the misconception
> that dma_32bit_pfn represented some sort of size limit for IOVA domains.
> Since the truth is almost the exact opposite of that, rework the logic
> and comments t
Hi Sricharan
On 2017-01-23 17:18, Sricharan R wrote:
This series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the probe of the
bus/driver is calle
33 matches
Mail list logo
