Hi Linus,
On Fri, Jun 27, 2014 at 07:03:45PM -0700, Linus Torvalds wrote:
> this email was in my spam-box. No real indication as to why, although
> the usual suspect is
>
>Received-SPF: none (google.com: j...@8bytes.org does not designate
> permitted sender hosts) client-ip=85.214.48.195;
H
Hi Olav,
On Fri, Jun 27, 2014 at 11:23:27PM +0100, Olav Haugan wrote:
> On 6/25/2014 2:18 AM, Will Deacon wrote:
> > Why can't it be dynamically detected? Whilst the StreamIDs are fixed in
> > hardware (from the SMMU architecture perspective), the SMRs are completely
> > programmable. Why doesn't
T0SZ controls the input address range for TTBR0, so use the input
address range rather than the output address range for the calculation.
For stage-2, this means using the output size of stage-1.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu.c | 4 +++-
1 file changed, 3 insertions(+), 1
MSIs are just seen as bog standard memory writes by the ARM SMMU, so
they can be translated (and isolated) in the same way.
This patch adds the IOMMU_CAP_INTR_REMAP capability to the ARM SMMU
driver and reworks our capabaility code so that we don't assume the
caps are organised as bits in a bitmas
This patch extends the ARM SMMU driver so that it can handle PCI master
devices in addition to platform devices described in the device tree.
The driver is informed about the PCI host controller in the DT via a
phandle to the host controller in the mmu-masters property. The host
controller is then
Hi all,
Here is the set of arm/smmu patches I currently have that I'd like to get
in for 3.17 (pending review comments). The diffstat is bigger than usual,
since I've got my hands on a PCI-capable platform (model) and subsequently
started to get that up and running. I've also been playing with VFI
For an SMMU that supports both Stage-1 and Stage-2 mappings (but not
nested translation), then we should prefer stage-1 mappings as we
otherwise rely on the memory attributes of the incoming transactions
for IOMMU_CACHE mappings.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu.c | 8 --
The ARM SMMU driver has supported chained SMMUs (i.e. SMMUs connected
back-to-back in series) via the smmu-parent property in device tree.
This was in anticipation of somebody building such a configuration,
however that seems not to be the case.
This patch removes the unused chained SMMU hack from
On Mon, Jun 30, 2014 at 02:41:24PM +, Gabbay, Oded wrote:
> On Fri, 2014-06-27 at 22:00 -0400, Jérôme Glisse wrote:
> > From: Jérôme Glisse
> >
> > Several subsystem require a callback when a mm struct is being destroy
> > so that they can cleanup there respective per mm struct. Instead of
>
On Mon, Jun 30, 2014 at 02:41:24PM +, Gabbay, Oded wrote:
> I did face some problems regarding the amd IOMMU v2 driver, which
> changed its behavior (see commit "iommu/amd: Implement
> mmu_notifier_release call-back") to use mmu_notifier_release and did
> some "bad things" inside that
> notifie
On Mon, Jun 30, 2014 at 05:40:42PM +0200, Joerg Roedel wrote:
> On Mon, Jun 30, 2014 at 02:41:24PM +, Gabbay, Oded wrote:
> > I did face some problems regarding the amd IOMMU v2 driver, which
> > changed its behavior (see commit "iommu/amd: Implement
> > mmu_notifier_release call-back") to use
Rename the MSM IOMMU driver for MSM8960 SoC to "-v0" version to align
with hardware version number for next generation MSM IOMMU (v1).
Signed-off-by: Olav Haugan
---
arch/arm/configs/qcom_defconfig | 2 +-
drivers/iommu/Kconfig| 11 ++
From: Matt Wagantall
It is sometimes necessary to poll a memory-mapped register until its
value satisfies some condition. Introduce a family of convenience macros
that do this. Tight-loop and sleeping versions are provided with and
without timeouts.
Signed-off-by: Matt Wagantall
---
include/li
These patches add support for Qualcomm MSM SMMUv1 hardware. The first patch
renames the files for the existing MSM IOMMU driver to align with the SMMU
hardware revision (v1 is ARM SMMUv1 spec). The second patch adds back
map_range/unmap_range APIs. These APIs allows SMMU driver implementations to
o
Enable the Qualcomm SMMUv1 driver allowing bus masters to operate
on physically discontigous memory.
Signed-off-by: Olav Haugan
---
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 0414889.
Mapping and unmapping are more often than not in the critical path.
map_range and unmap_range allows SMMU driver implementations to optimize
the process of mapping and unmapping buffers into the SMMU page tables.
Instead of mapping one physical address, do TLB operation (expensive),
mapping, do TLB
Add support for VMSA long descriptor page table format (V7L) supporting the
following features:
- ARM V7L page table format independent of ARM CPU page table format
- 4K/64K/2M/32M/1G mappings (V7L)
Signed-off-by: Olav Haugan
---
.../devicetree/bindings/iommu/msm,iommu_v1.txt | 4
Add a new iommu domain attribute that can be used to enable cache
coherent hardware table walks (HTW) by the SMMU. HTW might be supported
by the SMMU HW but depending on the use case and the usage of the SMMU
in the SoC it might not be always beneficial to always turn on coherent HTW for
all domain
Hi Olav,
On Mon, Jun 30, 2014 at 05:51:53PM +0100, Olav Haugan wrote:
> MSM IOMMUv1 driver supports Qualcomm SoC MSM8974 and
> MSM8084.
>
> The IOMMU driver supports the following features:
>
> - ARM V7S page table format independent of ARM CPU page table format
> - 4K/64K/1M/16M mapping
On Mon, Jun 30, 2014 at 12:06:05PM -0400, Jerome Glisse wrote:
> No this patch does not duplicate it. Current user of mmu_notifier
> rely on file close code path to call mmu_notifier_unregister. New
> code like AMD IOMMUv2 or HMM can not rely on that. Thus they need
> a way to call the mmu_notifer_
On Mon, Jun 30, 2014 at 08:16:23PM +0200, Joerg Roedel wrote:
> On Mon, Jun 30, 2014 at 12:06:05PM -0400, Jerome Glisse wrote:
> > No this patch does not duplicate it. Current user of mmu_notifier
> > rely on file close code path to call mmu_notifier_unregister. New
> > code like AMD IOMMUv2 or HMM
On Mon, Jun 30, 2014 at 09:51:51AM -0700, Olav Haugan wrote:
[...]
> +int iommu_map_range(struct iommu_domain *domain, unsigned int iova,
> + struct scatterlist *sg, unsigned int len, int prot)
> +{
> + if (unlikely(domain->ops->map_range == NULL))
> + return -ENODEV
On Mon, Jun 30, 2014 at 09:51:52AM -0700, Olav Haugan wrote:
[...]
> diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
[...]
> +/**
> + * readl_poll_timeout - Periodically poll an address until a condition is
> met or a timeout occurs
> + * @addr: Address to poll
> + * @val: Variable to
On 06/26/2014 02:49 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed
On 06/26/2014 02:49 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> The memory controller on NVIDIA Tegra124 exposes various knobs that can
> be used to tune the behaviour of the clients attached to it.
>
> Currently this driver sets up the latency allowance registers to the HW
> defaults.
25 matches
Mail list logo
