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: > > 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. > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
