* Suman Anna [140228 12:46]:
> Hi Joerg, Tony,
>
> This is an updated series of the OMAP IOMMU DT adaptation intended
> for 3.15 merge window, addressing the comments from the v2 series.
> This series is rebased onto 3.14-rc4, and the only change to bindings
> is to drop the dma-window property.
From: Florian Vaussard
Update the IOMMU node for the camera subsystem as per the
OMAP IOMMU bindings.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: corrected interrupt number]
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap3.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletion
From: Florian Vaussard
Add the IOMMU nodes for the DSP and IPU subsystems. The MMU
within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: IPU bus error back addition]
Signed-off-by: Suman Anna
---
arch
The IOMMU DT nodes have been added for the DSP and IPU
subsystems. The MMUs in OMAP5 are identical to those in
OMAP4, including the bus error back capability on IPU.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap5.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/ar
From: Florian Vaussard
Add the DT node for the IOMMU within the DSP subsystem. The entry
is disabled to keep in line with the hwmod usage as intended by
the deprecated CONFIG_OMAP_IOMMU_IVA2 flag.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: split the entry and disable the node]
Signed-off-b
Hi,
This is an updated series of the OMAP IOMMU DTS nodes
for OMAP3, OMAP4 and OMAP5. The main change is the removal
of the dma-window property from all the IOMMU DT nodes, as
per the discussion on the bindings posted previously [1].
This series goes along with the v3 version of the driver
DT ada
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset p
The IOMMU DT adaptation support uses the device name instead
of an iommu object name. Fixup the ISP device archdata MMU
name at runtime if using DT-boot. This allows the OMAP3 camera
to be functional in both legacy and DT boots. The iommu object
names should eventually vanish when all the IOMMU use
A new MMU hwmod class and data structures are created
to represent the MMUs within the IPU and DSP processor
subsystems in OMAP5. The MMUs in OMAP5 are identical to
those in OMAP4.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 83 ++
1 fil
OMAP5 has the same iommus as OMAP4, so extend the OMAP4
iommu pdata quirks for OMAP5 as well.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/pdata-quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 74
The IVA MMU is not functional when used through the hwmod and
omap_device layers. Add fixes to clockdomain and hwmod data
to have it functional. The hwmod changes are needed to enable
the clock, and the SWSUP change is needed to wakeup the domain
because the power domain is programmed to be in RET,
From: Laurent Pinchart
The OMAP IOMMU driver locates the IOMMU associated to a device using the
IOMMU name stored in the device archdata iommu field. That field is
expected to be populated by platform code and is left unset for DT-based
devices. This results in a crash when the IOMMU driver attac
The remoteproc MMUs in OMAP4+ SoCs have some additional debug
registers that can give out the PC value in addition to the
MMU fault address. The PC value can be extracted properly only
on the DSP cores, and is not available on the ARM processors
within the IPU sub-systems. Instead, the MMUs have be
From: Florian Vaussard
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by:
From: Florian Vaussard
CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.
Cc: Paul Walmsley
Signed-
From: Florian Vaussard
As OMAP2+ is moving to a full DT boot for all SoC families, commit
7ce93f3 "ARM: OMAP2+: Fix more missing data for omap3.dtsi file"
adds basic DT bits for OMAP3. But the driver is not yet converted,
so this will not work and driver will not be probed. Convert it!
The legac
Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions.
Signed-off-by: Florian Vaussard
Signed-off-by: Suman Anna
Acked-by: Laurent Pinchart
---
drivers/iommu/omap-iommu.c | 52 +-
1 file changed, 10 insertions(+), 42
Hi Joerg, Tony,
This is an updated series of the OMAP IOMMU DT adaptation intended
for 3.15 merge window, addressing the comments from the v2 series.
This series is rebased onto 3.14-rc4, and the only change to bindings
is to drop the dma-window property.
The first 7 patches in the series are in
From: Florian Vaussard
When booting with a devicetree, no platform data is provided.
Do not prematurely exit iommu_enable() and iommu_disable() in
such a case.
Note: As OMAP do not yet has a proper reset controller driver,
IOMMUs requiring a reset signal should use pdata-quirks as a
transitional
There are couple of issues with the error return paths in
omap_iommu_attach():
1. omap_iommu_attach() returns NULL or ERR_PTR in case of error,
but omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL
return value (in case driver_find_device fails) will cause the
kernel to panic whe
Paul,
On 02/28/2014 01:58 PM, Paul Walmsley wrote:
On Thu, 13 Feb 2014, Suman Anna wrote:
From: Florian Vaussard
CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove
On Fri, Feb 28, 2014 at 4:24 PM, Laurent Pinchart
wrote:
> +/*
> + * VMSA that states in section B3.6.3 "Control of Secure or Non-secure memory
VMSA states
> + * access, Long-descriptor format" that the NStable bit being set in a table
> + * descriptor will result in the NStable and NS bits of a
On 02/28/2014 10:21 AM, Will Deacon wrote:
> >+- calxeda,smmu-secure-config-access : Enable proper handling of buggy
> >+ implementations that always use secure access to
> >+ SMMU configuration registers. In this case non-secure
> >+ aliases of s
On Fri, Feb 28, 2014 at 03:37:10PM +, Laurent Pinchart wrote:
> The IOMMU core expects the unmap operation to return the number of bytes
> that have been unmapped or 0 on failure, a negative return value being
> treated like a number of bytes.
Makes sense, thanks. It's a pity we can't propagat
Hi Laurent,
On Fri, Feb 28, 2014 at 03:37:09PM +, Laurent Pinchart wrote:
> Instead of walking the list of registered SMMU devices at remove time to
> locate the device being removed, set platform driver data at probe time
> to point to the SMMU and retrieve the pointer at remove time.
What d
On Fri, Feb 28, 2014 at 04:17:43PM +, Timur Tabi wrote:
> On Fri, Feb 21, 2014 at 11:16 AM, Will Deacon wrote:
> >
> > +- calxeda,smmu-secure-config-access : Enable proper handling of buggy
> > + implementations that always use secure access to
> > + SMMU conf
On Fri, Feb 21, 2014 at 11:16 AM, Will Deacon wrote:
>
> +- calxeda,smmu-secure-config-access : Enable proper handling of buggy
> + implementations that always use secure access to
> + SMMU configuration registers. In this case non-secure
> + alias
Hi Ben,
On Friday 28 February 2014 15:37:00 Ben Dooks wrote:
> only minor issue so far:
> > diff --git a/include/linux/platform_data/ipmmu-vmsa.h
> > b/include/linux/platform_data/ipmmu-vmsa.h new file mode 100644
> > index 000..8be27e0
> > --- /dev/null
> > +++ b/include/linux/platform_data/i
The IOMMU core expects the unmap operation to return the number of bytes
that have been unmapped or 0 on failure, a negative return value being
treated like a number of bytes.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Instead of walking the list of registered SMMU devices at remove time to
locate the device being removed, set platform driver data at probe time
to point to the SMMU and retrieve the pointer at remove time.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/arm-smmu.c | 15 ---
1 file
Hello Will,
I've studied your arm-smmu driver as a base to write a Renesas IOMMU driver
and found two small issues. Here are patches to fix them. Please bear with me
if my understanding was incorrect and the patches wrong :-)
Laurent Pinchart (2):
iommu/arm-smmu: Replace list walk with platform
Not-Signed-off-by: Laurent Pinchart
---
arch/arm/mach-shmobile/board-koelsch-reference.c | 30
1 file changed, 30 insertions(+)
diff --git a/arch/arm/mach-shmobile/board-koelsch-reference.c
b/arch/arm/mach-shmobile/board-koelsch-reference.c
index a3fd302..d2f4ed8 100644
Signed-off-by: Laurent Pinchart
---
drivers/iommu/Kconfig| 12 +
drivers/iommu/Makefile |1 +
drivers/iommu/ipmmu-vmsa.c | 1070 ++
include/linux/platform_data/ipmmu-vmsa.h | 24 +
4 files changed, 1107 insert
Hello,
This patch set adds a new driver for the Renesas IOMMU found in the R-Car H2
(r8a7790) and R-Car M2 (r8a7791) SoCs. Despite being called IPMMU like the
IOMMU present in older ARM Sh Mobile SoCs, the hardware has nothing in common
with the previous versions and thus requires a separate drive
Hi Joerg,
Please can you pull the following arm-smmu changes for 3.15?
The main changes are for accessing the buggy Calxeda SMMU, which is wired
as secure despite being non-secure. Unfortunately, the apparent demise
of Calxeda means that Andreas is no longer working on this, so I had to
extract w
35 matches
Mail list logo
