On Mon, Feb 08, 2016 at 06:13:11PM +0530, Anup Patel wrote: > On Mon, Feb 8, 2016 at 4:48 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote: > >> To allow use of large memory (> 4Gb) with 32bit devices we need to use > >> IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings > >> allows us do this by specifying 'iommus' attribute in 32bit device DT > >> node. Unfortunately, specifying 'iommus' attribute does not work with > >> current SMMUv1/SMMUv2 driver because it requires of_xlate() operation > >> to be implemented by the driver. > >> > >> This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2 > >> driver to allow usage of 'iommus' attribute in DT for 32bit devices. > >> > >> Signed-off-by: Anup Patel <anup.patel@xxxxxxxxxxxx> > >> Reviewed-by: Ray Jui <rjui@xxxxxxxxxxxx> > >> Reviewed-by: Scott Branden <sbranden@xxxxxxxxxxxx> > >> --- > >> drivers/iommu/arm-smmu.c | 11 +++++++++++ > >> 1 file changed, 11 insertions(+) > >> > >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c > >> index 02cd67d..8e090d8 100644 > >> --- a/drivers/iommu/arm-smmu.c > >> +++ b/drivers/iommu/arm-smmu.c > >> @@ -1398,6 +1398,16 @@ static int arm_smmu_init_platform_device(struct device *dev, > >> return 0; > >> } > >> > >> +int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args) > >> +{ > >> + /* > >> + * Nothing to do here because SMMU is already aware of all > >> + * MMU masters and their stream IDs using mmu-master attibute > >> + * SMMU DT node. > >> + */ > >> + return 0; > >> +} > > > > NAK to this. > > I had no intention in continuing this change if I knew some work > on generic IOMMU binding was in-progress. In fact, I had asked > about alternate options previously. (Refer, > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/403128.html) Ok. To be clear, I expect the generic binding alone to be used for the case you described, regardless of who implements that or how long it takes to appear. > > As previously mentioned by others [1], this is an abuse of the generic > > iommu binding support code. > > > > The SMMU binding currently does not define its implementation of the > > generic IOMMU binding. This series did not define what an SMMU's > > #iommu-cells would be nor what the contained values would represent. > > Therefore it is not valid to use an SMMU node with an iommus property as > > the SMMu doesn't follwo the generic IOMMU binding. > > > > There is ongoing work to have generic iommu binding support for the > > SMMU. In the absence of documentation for what this means for the > > binding, I am worried that this hack harms that effort. > > Thanks for the info, I would like to try this on Broadcom SoCs. > > Whats the ETA of patches for generic IOMMU binding for SMMU? That I do not know. Robin, what's the state of the generic IOMMU binding support? Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html