From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753417AbaGMLnO (ORCPT ); Sun, 13 Jul 2014 07:43:14 -0400 Received: from mail-ie0-f182.google.com ([209.85.223.182]:35796 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750941AbaGMLnJ (ORCPT ); Sun, 13 Jul 2014 07:43:09 -0400 MIME-Version: 1.0 In-Reply-To: <20140713094341.GB23235@arm.com> References: <1404487757-18829-1-git-send-email-thierry.reding@gmail.com> <20140712093917.GD18601@arm.com> <201407121422.02078.arnd@arndb.de> <20140713094341.GB23235@arm.com> Date: Sun, 13 Jul 2014 07:43:08 -0400 Message-ID: Subject: Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings From: Rob Clark To: Will Deacon Cc: Arnd Bergmann , Thierry Reding , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Stephen Warren , Joerg Roedel , Olav Haugan , "devicetree@vger.kernel.org" , Grant Grundler , Linux Kernel Mailing List , Marc Zyngier , "iommu@lists.linux-foundation.org" , "linux-tegra@vger.kernel.org" , Varun Sethi , Cho KyongHo , Dave P Martin , "linux-arm-kernel@lists.infradead.org" , Hiroshi Doyu , linux-arm-msm Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 13, 2014 at 5:43 AM, Will Deacon wrote: > On Sat, Jul 12, 2014 at 01:57:31PM +0100, Rob Clark wrote: >> On Sat, Jul 12, 2014 at 8:22 AM, Arnd Bergmann wrote: >> > On Saturday 12 July 2014, Rob Clark wrote: >> >> >> Was there actually a good reason for having the device link to the >> >> >> iommu rather than the other way around? How much would people hate it >> >> >> if I just ignore the generic bindings and use something that works for >> >> >> me instead. I mean, it isn't exactly like there is going to be .dts >> >> >> re-use across different SoC's.. and at least with current IOMMU API >> >> >> some sort of of_get_named_iommu() API doesn't really make sense. >> >> > >> >> > The thing is, if you end up ignoring the generic binding then we have two >> >> > IOMMUs using the same (ARM SMMU) binding and it begs the question as to >> >> > which is the more generic! I know we're keen to get this merged, but merging >> >> > something that people won't use and calling it generic doesn't seem ideal >> >> > either. We do, however, desperately need a generic binding. >> >> >> >> yeah, ignoring the generic binding is not my first choice. I'd rather >> >> have something that works well for everyone. But I wasn't really sure >> >> if the current proposal was arbitrary, or if there are some >> >> conflicting requirements between different platforms. >> > >> > The common case that needs to be simple is attaching one (master) device >> > to an IOMMU using the shared global context for the purposes of implementing >> > the dma-mapping API. >> >> well, I don't disagree that IOMMU API has some problems. It is too >> tied to the bus type, which doesn't really seem to make sense for >> platform devices. (Unless we start having multiple platform busses?) >> >> But at least given the current IOMMU API I'm not really sure how it >> makes a difference which way the link goes. But if there has already >> been some discussion about how you want to handle the tie in with >> dma-mapping, if you could point me at that then maybe your point will >> make more sense to me. > > If you look at the proposed binding in isolation, I think it *is* cleaner > than the ARM SMMU binding (I've acked it...) and I believe it's more > consistent with the way we describe linkages elsewhere. > > However, the issue you're raising is that it's more difficult to make use of > in a Linux IOMMU driver. The reward you'll get for using it will come > eventually when the DMA ops are automatically swizzled for devices using the > generic binding. > > My plan for the ARM SMMU driver is: > > (1) Change ->probe() to walk the device-tree looking for all masters with > phandles back to the SMMU instance being probed > > (2) For each master, extract the Stream IDs and add them to the internal > SMMU driver data structures (an rbtree per SMMU instance). For > hotpluggable buses, we'll need a way for the bus controller to > reserve a range of IDs -- this will likely be a later extension to > the binding. > > (3) When we get an ->add() call, warn if it's a device we haven't seen > and reject the addition. > > That way, ->attach() should be the same as it is now, I think. > > Have you tried implementing something like that? We agreed that (1) isn't > pretty, but I don't have a good alternative and it's only done at > probe-time. I haven't tried implementing that yet, but I'm sure it would work. I was just hoping to avoid having to do that ;-) I suppose perhaps there is room for a shared helper here, to at least avoid duplicating that in each IOMMU driver which needs the stream-id's up front. > Will > > BTW: Is the msm-v0 IOMMU compatible with the ARM SMMU driver, or is it a > completely different design requiring a different driver? My understanding is that it is different from msm v1 IOMMU, although I think it shares the same pagetable format with v1. Not sure if that is the same as arm-smmu? If so it might be nice to try to extract out some shared helper fxns for map/unmap as well. I expect Olav knows better the similarities/differences. BR, -R