On Thu, Feb 13, 2014 at 04:55:25PM +, Timur Tabi wrote:
On Thu, Feb 6, 2014 at 12:09 PM, Will Deacon will.dea...@arm.com 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
+++
On Thu, Feb 6, 2014 at 12:09 PM, Will Deacon will.dea...@arm.com 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
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
From: Florian Vaussard florian.vauss...@epfl.ch
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 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
Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 52 +-
1 file changed, 10
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
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
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.
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 s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 83
From: Florian Vaussard florian.vauss...@epfl.ch
With full DT boot, the legacy mode of platform device creation
for OMAP IOMMUs is not needed anymore.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/omap-iommu.c | 79
From: Florian Vaussard florian.vauss...@epfl.ch
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
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
From: Florian Vaussard florian.vauss...@epfl.ch
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 florian.vauss...@epfl.ch
Signed-off-by: Suman Anna
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
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
OMAP5 has the same iommus as OMAP4, so extend the OMAP4
iommu pdata quirks for OMAP5 as well.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
From: Florian Vaussard florian.vauss...@epfl.ch
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.
From: Florian Vaussard florian.vauss...@epfl.ch
Update the IOMMU node for the camera subsystem as per the
OMAP IOMMU bindings.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: corrected interrupt number]
Signed-off-by: Suman Anna s-a...@ti.com
---
From: Florian Vaussard florian.vauss...@epfl.ch
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 florian.vauss...@epfl.ch
[s-a...@ti.com: split the entry and disable the node]
On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim kgene@gmail.com 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,
-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 kgene@gmail.com wrote:
Just adding KyongHo Cho.
If he can fixup for this time, it would be best solution because he knows
21 matches
Mail list logo
