> -Original Message-
> From: Olof Johansson [mailto:o...@lixom.net]
> Sent: Friday, February 14, 2014 4:34 AM
>
> On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim wrote:
>
> > Just adding KyongHo Cho.
> >
> > If he can fixup for this time, it would be best solution because he knows
> > well
On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim wrote:
> Just adding KyongHo Cho.
>
> If he can fixup for this time, it would be best solution because he knows
> well than others, I think.
It's not so much a matter of "fixup for this time", it's a about
having ownership of the driver, making sure i
Hi,
This series includes patches that adds the iommu DT nodes on
OMAP3 (IVA), and OMAP4 and OMAP5 SoCs. It also includes an
updated OMAP3 ISP iommu DT node patch posted previously [1].
Posting the series separately from the driver DT adapation
changes [2]. The series adds the DTS patches in line
From: Florian Vaussard
Add the DT node for the IOMMU within the DSP subsystem. The entry
is disabled to keep in line with the current hwmod usage.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: split the entry and disable the node]
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap3.dtsi |
From: Florian Vaussard
Add the IOMMU nodes for the DSP and IPU subsystems. The external
address space for DSP starts at 0x2000 in OMAP4 compared to
0x1100 in OMAP3, and the addresses beyond 0xE000 are
private address space for the Cortex-M3 cores in the IPU subsystem.
The MMU within t
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 | 17 +
1 file changed, 17 insertions(+)
diff --git a/
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 | 8 +---
1 file changed, 5 insertions(+), 3 deletio
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
The device attribute data and ocp address space have all been
cleaned up for OMAP4 iommus. All this data is populated via
the corresponding dt node.
Signed-off-by: Florian Vaussard
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 35 ---
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 IOMMU DT adaptation support uses the device name instead
of an iommu object name. The iommu object names should eventually
vanish when all the IOMMU users have been converted to DT nodes.
NOTE: This change is not compatible with legacy boots, but OMAP3
is expected to be DT-boot only going forw
From: Florian Vaussard
The irq numbers, ocp address space and device attribute data
have all been cleaned up for OMAP3 IOMMUs. All this data is
populated via the corresponding dt node.
Signed-off-by: Florian Vaussard
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4
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,
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
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!
Signed-of
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:
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
From: Florian Vaussard
With full DT boot, the legacy mode of platform device creation
for OMAP IOMMUs is not needed anymore.
Signed-off-by: Florian Vaussard
---
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/omap-iommu.c | 79
2 files cha
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
Hi,
This is an updated series to the initial OMAP IOMMU DT driver
adaptation series [1], that primarily dealt with just the OMAP3
ISP MMU. This series is based on 3.14-rc2, and the patches were
developed in collaboration with Florian. I am hoping that the
series can make the 3.15 merge window.
Th
Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions.
Signed-off-by: Florian Vaussard
Signed-off-by: Suman Anna
---
drivers/iommu/omap-iommu.c | 52 +-
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/d
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
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
From: Florian Vaussard
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 when
omap_iommu_attach_dev() dereferences the pointer.
In such case,
On 02/13/2014 11:04 AM, Will Deacon wrote:
It's harmless to enable CONFIG_ARM_AMBA, even if you don't have any AMBA
devices in your SoC,
Ah, ok. It's seems obvious now, but somehow that didn't click.
it just makes your binary a bit bigger because you're
compiling in code that you don't need
On Thu, Feb 6, 2014 at 12:09 PM, Will Deacon wrote:
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 0ae4dd39197f..6fe7922ecc1d 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2004,8 +2004,10 @@ static int __init arm_smmu_init(void)
>
On Thu, Feb 13, 2014 at 04:55:25PM +, Timur Tabi wrote:
> On Thu, Feb 6, 2014 at 12:09 PM, Will Deacon wrote:
>
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index 0ae4dd39197f..6fe7922ecc1d 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.
27 matches
Mail list logo
