ASID register offset is caclulated by SWGROUP ID so that we can get
rid of old SoC specific MACROs. This ID conversion is needed for the
unified SMMU driver over Tegra SoCs. We use dt-bindings MACRO instead
of SoC dependent MACROs. The formula is:
MC_SMMU__ASID_0 = MC_SMMU_AFI_ASID_0 + ID * 4;
ops->{bound,unbind}_driver() functions are called at
BUS_NOTIFY_{BOUND,UNBIND}_DRIVER respectively.
This is necessary to control the device population order. IOMMU master
devices depend on an IOMMU device instanciation. IOMMU master devices
can be registered to an IOMMU only after it's successfull
The device, which belongs to the same ASID, can try to enable the same
ASID as the other swgroup devices. This should be allowed but just
skip the actual register write. If the write value is different, it
will return -EINVAL.
Signed-off-by: Hiroshi Doyu
---
v4:
This was the part of v3, which isn
Use the correct term for SWGROUP related variables and macros.
The term "swgroup" is the collection of "memory client". A "memory
client" usually represents a HardWare Accelerator(HWA) like
GPU. Sometimes a strut device can belong to multiple "swgroup" so that
"swgroup's'" is used here. This "swgr
This provides the info about which swgroups a device belongs to. This
info is passed from DT. This is necessary for the unified SMMU driver
among Tegra SoCs since each has different H/W accelerators.
Signed-off-by: Hiroshi Doyu
---
v6:
- Explained "#iommu-cells" in the binding document.
- Fixed o
This allows to inquire if SMMU is populated or not.
Suggested by Thierry Reding and copied his example code.
Signed-off-by: Hiroshi Doyu
Cc: Thierry Reding
---
v6:
New for v6.
Signed-off-by: Hiroshi Doyu
---
drivers/iommu/tegra-smmu.c | 55 +-
1 fi
platform_devices are registered as IOMMU'able dynamically via
add_device() and remove_device().
Tegra SMMU can have multiple address spaces(AS). IOMMU'able devices
can belong to one of them. Multiple IOVA maps are created at boot-up,
which can be attached to devices later. We reserve 2 of them for
IOMMU devices on the bus need to be poplulated first, then iommu
master devices are done later.
With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify
whether a device can be an iommu msater or not. If a device can, we'll
defer to populate that device till an iommu device is populate
Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
binding. "swgroup" is a group of H/W clients which a Tegra SoC
supports. This unique ID can be used to calculate MC_SMMU__ASID_0 register offset and MC__HOTRESET_*_0
register bit. This will allow the same header to be used by bo
This enables to find an populated IOMMU device via a device node. This
can be used to see if an dependee IOMMU is populated or not to keep
correct device population order. Client devices need to wait an IOMMU
to be populated.
Suggested by Thierry Reding and copied his example code.
Signed-off-by:
IOMMU devices on the bus need to be poplulated first, then iommu
master devices are done later.
With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify
whether a device can be an iommu msater or not. If a device can, we'll
defer to populate that device till an depending iommu device i
Hi,
This series provide:
(0) IOMMU standard DT binding("iommus")
(1) Unified IOMMU(SMMU) driver among Tegra SoCs
(2) Multiple Address Space support(MASID) in IOMMU(SMMMU)
(3) Tegra IOMMU'able devices, most of platform devices are IOMMU'able.
There's been some discussion[1] about device populatio
Iterating over a property containing a list of phandles with arguments
is a common operation for device drivers. This patch adds a new
of_property_for_each_phandle_with_args() macro to make the iteration
simpler.
Signed-off-by: Hiroshi Doyu
Cc: Rob Herring
Cc: Grant Likely
---
v7:
Fixed some mi
Dear iommu@lists.linux-foundation.org
I submit the following help-support to IPS(Intel Premier Support),
but the person who checked this help-request told me that
I shuould ask for iommu@lists.linux-foundation.org because this is
Software issue.
| Hello Tomohisa,
|
| This is a software issu
Adds support to mask interrupts, and also for automasked interrupts.
Level sensitive interrupts are exposed as automasked interrupts and
are masked and disabled automatically when they fire.
Signed-off-by: Antonios Motakis
Tested-by: Alvise Rigo
---
drivers/vfio/platform/vfio_platform_irq.c
Return information for the interrupts exposed by the device.
This patch extends VFIO_DEVICE_GET_INFO with the number of IRQs
and enables VFIO_DEVICE_GET_IRQ_INFO
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/Makefile| 2 +-
drivers/vfio/platform/vfio_platform.c
VFIO returns a file descriptor which we can use to manipulate the memory
regions of the device. Since some memory regions we cannot mmap due to
security concerns, we also allow to read and write to this file descriptor
directly.
Signed-off-by: Antonios Motakis
Tested-by: Alvise Rigo
---
drivers
This patch allows to set an eventfd for a patform device's interrupt,
and also to trigger the interrupt eventfd from userspace for testing.
Signed-off-by: Antonios Motakis
Tested-by: Alvise Rigo
---
drivers/vfio/platform/vfio_platform.c | 36 +++-
drivers/vfio/platform/vfio_platfor
This patch forms the skeleton for platform devices support with VFIO.
To bind this driver with a platform device, the match_any_dev property
is used as introduced by Kim Phillips' patch to allow platform drivers to
bind to any device [1].
[1] https://lkml.org/lkml/2013/12/3/223
Signed-off-by: Ant
Allow to memory map the MMIO regions of the device so userspace can
directly access them.
Signed-off-by: Antonios Motakis
Tested-by: Alvise Rigo
---
drivers/vfio/platform/vfio_platform.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/vfio/platform
This patch series aims to implement VFIO support for platform devices that
reside behind an IOMMU. Examples of such devices are devices behind an ARM SMMU,
or behind a Samsung Exynos System MMU.
The API used is based on the existing VFIO API that is also used with PCI
devices. Only devices that in
This is a workaround to make the VFIO_IOMMU_TYPE1 driver usable with
platform devices instead of PCI. A future permanent fix should support
both. This is required in order to use the Exynos SMMU, or ARM SMMU
driver with VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig|
A VFIO userspace driver will start by opening the VFIO device
that corresponds to an IOMMU group, and will use the ioctl interface
to get the basic device info, such as number of memory regions and
interrupts, and their properties.
This patch enables the IOCTLs:
- VFIO_DEVICE_GET_INFO
- VFIO_DEV
The ARM SMMU driver expects the IOMMU_EXEC flag, otherwise it will
set the page tables for a device as XN (execute never). This affects
devices such as the ARM PL330 DMA Controller, which fails to operate
if the XN flag is set on the memory it tries to fetch its instructions
from.
We introduce the
domain_has_cap is a misnomer bc the func name should be
the same for CONFIG_IOMMU_API and !CONFIG_IOMMU_API.
Signed-off-by: Upinder Malhi
---
include/linux/iommu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7ea319e
Hi Grant,
Grant Likely wrote @ Wed, 11 Dec 2013 14:28:45 +0100:
> On Thu, 21 Nov 2013 11:57:00 -0700, Stephen Warren
> wrote:
> > On 11/21/2013 10:17 AM, Hiroshi Doyu wrote:
> > > Iterating over a property containing a list of phandles with arguments
> > > is a common operation for device driv
On Thu, 21 Nov 2013 11:57:00 -0700, Stephen Warren
wrote:
> On 11/21/2013 10:17 AM, Hiroshi Doyu wrote:
> > Iterating over a property containing a list of phandles with arguments
> > is a common operation for device drivers. This patch adds a new
> > of_property_for_each_phandle_with_args() macro
On Thu, 21 Nov 2013 18:17:20 +0100, Hiroshi Doyu wrote:
> Iterating over a property containing a list of phandles with arguments
> is a common operation for device drivers. This patch adds a new
> of_property_for_each_phandle_with_args() macro to make the iteration
> simpler.
>
> Signed-off-by: H
Hi Joerg,
Could you please pick this patch up for v3.14 ?
On Thursday 28 November 2013 16:36:51 Simon Horman wrote:
> On Wed, Nov 27, 2013 at 02:18:26AM +0100, Laurent Pinchart wrote:
> > This helps increasing build testing coverage.
> >
> > The driver doesn't compile on non-ARM platforms due to
29 matches
Mail list logo