On Thu, Oct 31, 2013 at 05:31:33PM +0000, Mark Rutland wrote:

On Wed, Oct 30, 2013 at 10:33:32PM +0000, Stephen Warren wrote:

quoted

I'm afraid I still don't quite understand what a swgroup is.

IIUC, the HW works like this based on comments in a previous patch:

Each bus-master attached to the MMU passes a "memory client ID" along
with the transaction. Some devices can generate transactions with
different "memory client IDs". There is a mapping inside the SMMU from
"memory client ID" to "address space ID". (I don't know what form that
mapping takes; can you point out where it's set up?). Each "address
space ID" has its own set of page tables. Is "swgroup" simply another
name for "memory client ID"? If so, it'd be good to use just one term
consistently.

The ARM SMMU refers to these as "stream IDs", as that's the architected name
that appears in all the hardware documentation. If "swgroup" is the term used
in the hardware documentation I think it makes sense to stick with it, as long
as there's a description in the binding document that points out what an
"swgroup" is. If there's a common term that both binding documents could refer
to to define what stream-id/swgroup are, that would be nice.

Sounds like:

  stream id == memory client id   (part of the binding)
  context id == address space id  (internal to the driver)

There are a few other differences in approach with the current ARM SMMU binding:
Documentation/devicetree/bindings/iommu/arm,smmu.txt

We should probably begin to look for commonality such that the next iommu
device that gets a binding is closer to a generic iommu class binding.

quoted

Assuming "swgroup" is "memory client ID", why can't the driver just
create a list/... of known swgroups at runtime, based on the swgroup
values that each device uses, which would presumably be either
hard-coded in the client device's driver, or represented in the DT smmu
property's "iommu specifier" value.

Assuming that the swgroup values of IP block instances are static, that sounds
like the ARM SMMU binding approach. Are the IDs static, or can they be assigned
at runtime?

The only valid case I can think of for dynamic IDs is for hotpluggable
devices sitting being a form of host controller (e.g. PCIe). In that case,
the host controller should handle the ID assignment, which must remain
static for the lifetime of a device.

Will