On Tue, Jun 17, 2014 at 03:50:25PM +0100, Stuart Yoder wrote: > > > I think for simple masters (i.e. those that have all their StreamIDs > > > under control of one driver), then setting something during attach (or > > > add?) based on the DT could work pretty well. The other case is when we > > > have masters behind a bridge (such as a PCI RC). In this case, it might > > > actually be better to ask the bridge for the IDs and let it sort out > > the > > > allocation itself. That would also move the RequesterID -> StreamID > > > mapping out of the SMMU code. > > > > > > What do you think? > > The PCI bus iommu group creation code would be part of the SMMU driver > > (it is handled by other IOMMU drivers as well). My understanding is that > > there would be one is to one correspondence between the requestor ID and > > the iommu group. May be, we can have an API provided by the PCI bridge > > (architecture specific) for setting the stream ID. > > I think Will is suggesting something along those lines-- I think it's a > question of where the streamID allocation happens. You could > either do something like the following in the SMMU driver when attaching > a PCI device: > > id = alloc_stream_id(...); > pci_set_streamid(pci-dev, id); > > or > > id = pci_get_streamid(pci-dev); > > ...i.e the PCI RC could allocate (from some TBD > allocator) and set the stream ID itself. > > Not sure how big a deal it is to extend PCI RC interfaces for > something like that. I think both interfaces have their place; the latter for hotpluggable buses and the former for static allocation (i.e. set once). The only way to see how well it works is to try implementing it, I guess. Will -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |