[PATCH] iommu/ipmmu-vmsa: Return proper error if devm_request_irq fails
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/iommu/ipmmu-vmsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 7dab5cb..d25fa12 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -1184,7 +1184,7 @@ static int ipmmu_probe(struct platform_device *pdev)
dev_name(pdev-dev), mmu);
if (ret 0) {
dev_err(pdev-dev, failed to request IRQ %d\n, irq);
- return irq;
+ return ret;
}
ipmmu_device_reset(mmu);
--
1.9.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 05/12] memory: Add NVIDIA Tegra memory controller support
On Fri, Oct 31, 2014 at 10:27 PM, Thierry Reding thierry.red...@gmail.com wrote: On Thu, Oct 30, 2014 at 04:08:41PM +0100, Thierry Reding wrote: On Wed, Oct 15, 2014 at 03:09:30PM -0700, Olof Johansson wrote: Hi, Oh, a few more comments: On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding thierry.red...@gmail.com wrote: diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index c32d31981be3..1c932e7e7b8d 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -12,4 +12,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o + +obj-$(CONFIG_ARCH_TEGRA) += tegra/ diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile new file mode 100644 index ..51b9e8fcde1b --- /dev/null +++ b/drivers/memory/tegra/Makefile @@ -0,0 +1,5 @@ +obj-y = tegra-mc.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= tegra30-mc.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.o You'll need a Kconfig and not just a makefile -- there are definitely dependencies on this driver (IOMMU in particular). This is handled within the tegra-mc driver by only setting up the IOMMU when TEGRA_IOMMU_SMMU is enabled. That config option remains in place. Also, the problem of having a global enable bit that is only under control of TrustZone FW is a big problem -- if the bit is not set, the driver will not work (and the machine will crash). I think you'll need to come up with a way to detect that in the driver. I don't have a good idea of how it can be done though. I don't think I ever got back to you on this. We discussed this internally and it seems like there's no way to detect this properly, so the best suggestion so far was to make it a requirement on the secure firmware to enable IOMMU or not. Since there's no way for the kernel to detect whether IOMMU was enabled or not, I think the firmware would equally have to adjust the SMMU's device tree node's status property appropriately. The other option would be for the firmware not to touch the SMMU device tree node and the kernel simply assuming that if it's running in non- secure mode then there must be secure firmware and it has enabled the SMMU. Enabling the SMMU would become part of the contract between firmware and kernel, much like locking the VPR is required to get the GPU to work. Those are really the only two choices we have. We got the exact same problem with GPU and VPR registers, and it seems like the approach we will be taking here is to have the firmware/bootloader do whatever is needed to get the GPU working and enable the DT node once it did. IOW, the kernel will never touch protected registers, and will not freeze if the hardware is not properly set up. It would be nice for consistency if the same approach can be taken with the IOMMU. OTOH we will need to make sure that all these initialization contracts are clearly documented somewhere. Maybe a comment in the DTS to explain what is expected from the firmware to enable such nodes would be a good idea, too. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v7 1/3] iommu/rockchip: rk3288 iommu driver
The rk3288 has several iommus. Each iommu belongs to a single master device. There is one device (ISP) that has two slave iommus, but that case is not yet supported by this driver. At subsys init, the iommu driver registers itself as the iommu driver for the platform bus. The master devices find their slave iommus using the iommus field in their devicetree description. Since each slave iommu belongs to exactly one master, their is no additional data needed at probe to associate a slave with its master. An iommu device's power domain, clock and irq are all shared with its master device, and the master device must be careful to attach from the iommu only after powering and clocking it (and leave it powered and clocked before detaching). Because their is no guarantee what the status of the iommu is at probe, and since the driver does not even know if the device is powered, we delay requesting its irq until the master device attaches, at which point we have a guarantee that the device is powered and clocked and we can reset it and disable its interrupt mask. An iommu_domain describes a virtual iova address space. Each iommu_domain has a corresponding page table that lists the mappings from iova to physical address. For the rk3288 iommu, the page table has two levels: The Level 1 directory_table has 1024 4-byte dte entries. Each dte points to a level 2 page_table. Each level 2 page_table has 1024 4-byte pte entries. Each pte points to a 4 KiB page of memory. An iommu_domain is created when a dma_iommu_mapping is created via arm_iommu_create_mapping. Master devices can then attach themselves to this mapping (or attach the mapping to themselves?) by calling arm_iommu_attach_device(). This in turn instructs the iommu driver to write the page table's physical address into the slave iommu's Directory Table Entry (DTE) register. In fact multiple master devices, each with their own slave iommu device, can all attach to the same mapping. The iommus for these devices will share the same iommu_domain and therefore point to the same page table. Thus, the iommu domain maintains a list of iommu devices which are attached. This driver relies on the iommu core to ensure that all devices have detached before destroying a domain. v6: - add .add/remove_device() callbacks. - parse platform_device device tree nodes for iommus property - store platform device pointer as group iommudata - Check for existence of iommu group instead of relying on a dev_get_drvdata() to return NULL for a NULL device. v7: - fixup some strings. - In rk_iommu_disable_paging() # and % were reversed. Signed-off-by: Daniel Kurtz djku...@chromium.org Signed-off-by: Simon Xue x...@rock-chips.com Reviewed-by: Grant Grundler grund...@chromium.org Reviewed-by: Stéphane Marchesin marc...@chromium.org Tested-by: Heiko Stuebner he...@sntech.de --- drivers/iommu/Kconfig | 12 + drivers/iommu/Makefile |1 + drivers/iommu/rockchip-iommu.c | 1038 3 files changed, 1051 insertions(+) create mode 100644 drivers/iommu/rockchip-iommu.c diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index dd51122..d0a1261 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -152,6 +152,18 @@ config OMAP_IOMMU_DEBUG Say N unless you know you need this. +config ROCKCHIP_IOMMU + bool Rockchip IOMMU Support + depends on ARCH_ROCKCHIP + select IOMMU_API + select ARM_DMA_USE_IOMMU + help + Support for IOMMUs found on Rockchip rk32xx SOCs. + These IOMMUs allow virtualization of the address space used by most + cores within the multimedia subsystem. + Say Y here if you are using a Rockchip SoC that includes an IOMMU + device. + config TEGRA_IOMMU_GART bool Tegra GART IOMMU Support depends on ARCH_TEGRA_2x_SOC diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 16edef7..3e47ef3 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o +obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c new file mode 100644 index 000..b2023af --- /dev/null +++ b/drivers/iommu/rockchip-iommu.c @@ -0,0 +1,1038 @@ +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include asm/cacheflush.h +#include asm/pgtable.h +#include linux/compiler.h +#include linux/delay.h +#include
