On Tue, Jul 15, 2014 at 9:25 PM, Olav Haugan <ohaugan@xxxxxxxxxxxxxx> wrote: > On 7/13/2014 4:43 AM, Rob Clark wrote: >> 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 ;-) > > Is the reason you want to do it this way because you want to guarantee > that all masters (and stream IDs) have been identified before the first > attach call? I am just wondering why you cannot continue doing the > master/streamID discovery during add_device() callback? it was mostly because I couldn't think of a sane way to differentiate between first and second time a device attaches (without keeping a reference to the device). But I guess it is ok to assume no hotplug (since walking the device tree also seems acceptable) BR, -R >>> >>> 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. >> > > The msm-v0 IOMMU is not compatible with ARM SMMUv1 specification. > However, it is a close cousin. The hardware was designed before the ARM > SMMUv1 specification was available I believe. But it shares many of the > same concepts as the ARM SMMUv1. > > msm-v0 IOMMU supports V7S page table format only. The ARM SMMU driver > does not support V7S at this time. However, I believe we need to support > this. > > Will, this reminds me. We definitely have a need to use different page > tables in the ARM SMMU driver vs. the ARM CPU. We have an SoC with ARMv8 > cores (and thus ARMv8 page tables) but the SMMUs (SMMUv1) on this SoC > only have support for V7S/V7L page table format. So we cannot use the > same page table format as the CPU. > > Thanks, > > Olav > > -- > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation -- 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
