On Tue, Jun 17, 2014 at 11:26:48AM +0100, Varun Sethi wrote: > > The way we generally thought it would work was something like > > this: > > -u-boot/bootloader makes any static streamID allocation if needed, > > sets a default streamID (e.g. 0x0) in device and expresses > > that in the device tree > > -device tree would express relationship between devices > > (including bus controllers) and the SMMU through mmu-masters > > property > > -u-boot would express the range of unused (or used) streamIDs via a > > new > > device tree property so the kernel SMMU driver knows what streamIDs > > are > > free > > -in the SMMU driver a different vendor specific 'add_device' callback > > could be used to handle our special cases where we need to set/change > > the stream ID for devices added to a domain > > Another possibility, could be to program the stream Id in the device > registers (reference for the stream ID register can be obtained from the > device tree) during device attach. This could be relevant in case of VFIO, > when we are assigning multiple devices to a single VM. All the devices can > share the same stream ID. 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? 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
 |