On Sun, Jul 13, 2014 at 5:43 AM, Will Deacon <will.deacon@xxxxxxx> 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 <arnd@xxxxxxxx> 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 -- 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
