On Tue, Jun 17, 2014 at 11:26:48AM +0100, Varun Sethi wrote:

quoted

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