Hi Will,
On 20/10/2016 19:32, Will Deacon wrote:
> Hi Eric,
>
> Thanks for posting this.
>
> On Wed, Oct 12, 2016 at 01:22:08PM +, Eric Auger wrote:
>> This is the second respin on top of Robin's series [1], addressing Alex'
>> comments.
>>
>> Major changes are:
>> - MSI-doorbell API now is
On 19/10/16 15:02, Will Deacon wrote:
> On Mon, Oct 17, 2016 at 01:05:29PM +0100, Robin Murphy wrote:
>> With the new dma_{map,unmap}_resource() functions added to the DMA API
>> for the benefit of cases like slave DMA, add suitable implementations to
>> the arsenal of our generic layer. Since cach
On Fri, 21 Oct 2016 12:39:24 +0800
Rick Song wrote:
> Normally, VFIO should use only stage 2 translation of
> iommu, to create the address mapping. If nesting translation
> is disabled from VFIO core, enable iommu domain only stage 2
> attribute, otherwise, enable iommu domain nesting attribute.
On 21/10/16 15:27, Alex Williamson wrote:
> On Fri, 21 Oct 2016 12:39:24 +0800
> Rick Song wrote:
>
>> Normally, VFIO should use only stage 2 translation of
>> iommu, to create the address mapping. If nesting translation
>> is disabled from VFIO core, enable iommu domain only stage 2
>> attribute
On 19/10/16 13:49, Will Deacon wrote:
> On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
>> We now delay installing our per-bus iommu_ops until we know an SMMU has
>> successfully probed, as they don't serve much purpose beforehand, and
>> doing so also avoids fights between multiple I
The smmu needs to be functional when the respective
master/s using it are active. As there is a device_link
between the master and smmu, the pm runtime ops for the smmu
gets invoked in sync with the master's runtime, thus the
smmu remains powered only when needed.
There are couple of places in the
The smes registers and the context bank registers are
the ones that are needs to be saved and restored.
Fortunately the smes are already stored as a part
of the smmu device structure. So just write that
back. The data required to configure the context banks
are the master's domain data and pgtable
The device link between master and its smmu is added so that
the smmu gets runtime enabled/disabled when the master needs it.
This is done from add_device callback which gets called once
when the master is added to the smmu group.
Signed-off-by: Sricharan R
---
drivers/iommu/arm-smmu.c | 9 +
Document the list of clocks and powerdomains required for the
smmu's register and bus access.
Signed-off-by: Sricharan R
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
This series provides the support for turning on the arm-smmu's
clocks/powerdomains using runtime pm. This is done using the
recently introduced device links patches, which lets the symmu's
runtime to follow the master's runtime pm, so the smmu remains
powered only when the masters use it.
Also add
get_cpu() disables preemption and returns the current CPU number. The
CPU number is later only used once while retrieving the address of the
local's CPU deferred_flush pointer.
We can instead use raw_cpu_ptr() while we remain preemptible. The worst
thing that can happen is that flush_unmaps_timeout
Commit 583248e6620a ("iommu/iova: Disable preemption around use of
this_cpu_ptr()") disables preemption while accessing a per-CPU variable.
This does keep lockdep quiet. However I don't see the point why it is
bad if we get migrated after its access to another CPU.
__iova_rcache_insert() and __iova
Hi Magnus,
On 20/10/16 00:36, Magnus Damm wrote:
> From: Magnus Damm
>
> Not all architectures have an iommu member in their archdata, so
> use #ifdefs support build wit COMPILE_TEST on any architecture.
As an alternative to this we could now use iommu_fwspec in place of the
custom ipmmu_vmsa_a
On 20/10/16 00:36, Magnus Damm wrote:
> From: Magnus Damm
>
> Introduce an alternative set of iommu_ops suitable for 64-bit ARM
> as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the
> Kconfig to depend on ARM or IOMMU_DMA.
>
> Signed-off-by: Magnus Damm
> ---
>
> Changes since V5:
IOMMU driver must pick the same IOMMU as that of a Physical Function (PF) for
any of its Virtual Functions (VF). It is not practical to list all the VF's
in the DMAR scope, as this list could be quite large. Linux also ignores any
VF's listed in DMAR. See dmar_pci_bus_notifier() for virtfn handling
Hi Marek,
>This patch adds runtime pm implementation, which is based on previous
>suspend/resume code. SYSMMU controller is now being enabled/disabled mainly
>from the runtime pm callbacks. System sleep callbacks relies on generic
>pm_runtime_force_suspend/pm_runtime_force_resume helpers. To ensur
16 matches
Mail list logo
