On Mon, May 13, 2013 at 10:50:20AM +0100, Andreas Herrmann wrote: > Hi Will,
Hi Andreas, > so far, I thought, that this proposal is fine. After I have tried to > make use of the binding I have some points that might need further > disucssion. Sure, although I've been using the binding without issues so it would be interesting to understand your use-case and why it's raising problems. > Olav already asked (in another thread) how to model the mapping of > stream IDs to contexts for master devices that support multiple > contexts. I doubt that this is fully covered yet. Yeah, I've been meaning to reply to that. Given the way that the IOMMU API is structure in Linux, I don't think having multiple stream IDs per (struct) device, where each StreamID points at a different context (and therefore address space) makes much sense. It also doesn't solve the more general problem where StreamIDs for a device might have different SMMUs downstream. To solve this, I think it is better to treat the device as having multiple struct device instances, and managing the mappings in the device driver. For most devices, I'd expect a single context to be enough. This is certainly the case for device virtualisation at stage-2 and DMA at stage-1. > I also think that it is more useful to move the stream-id property to > the device node of a master device. (It's a characteristic of the > master device not of the SMMU.) Currently with multiple stream IDs per > master device you have repeated entries in the mmu-master property. The problem with that approach is how to handle StreamID remastering. This can and will happen, so the StreamID for a device is actually a property of both the device *and* a particular point in the bus topology. Putting this information in the device nodes will drag topology information all over the place and I don't think it will make things clearer to read or easier to parse. > But all that is needed is to point (once) to each mmu-master in the > SMMU device node. Then you should be able to look up the corresponding > stream IDs in the device node for each mmu-master. Again, you also need to tie in topology information if you go down this route. Will _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
