Thread (49 messages) 49 messages, 9 authors, 2014-07-11

[PATCH v2] devicetree: Add generic IOMMU device tree bindings

From: Olav Haugan <hidden>
Date: 2014-06-27 22:23:33
Also in: linux-devicetree, linux-iommu, linux-samsung-soc, linux-tegra, lkml

Possibly related (same subject, not in this thread)

On 6/25/2014 2:18 AM, Will Deacon wrote:
On Tue, Jun 24, 2014 at 10:35:54PM +0100, Olav Haugan wrote:
quoted
On 6/24/2014 11:11 AM, Will Deacon wrote:
quoted
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
quoted
On 6/24/2014 2:18 AM, Will Deacon wrote:
quoted
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
quoted
We have multiple-master SMMUs and each master emits a variable number of
StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
for this) to the StreamIDs due to limited number of StreamID 2 Context
Bank entries in the SMMU. If my understanding is correct we would
represent this in the DT like this:

	iommu {
		#address-cells = <2>;
		#size-cells = <0>;
	};

	master at a {
		...
		iommus = <&iommu StreamID0 MASK0>,
			 <&iommu StreamID1 MASK1>,
			 <&iommu StreamID2 MASK2>;
	};
Stupid question, but why not simply describe the masked IDs? What use does
the `raw' ID have to Linux?
We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply to the incoming SIDs, right?

We have a bus master that emits 43 unique SIDs. However, we have only 40
SMMU_SMRn registers in the SMMU. So we need to mask out some of the
incoming SID bits so that the 43 SIDs can match one of 40 entries in the
SMR.
Hmm, so you're talking about stream matching, right? That doesn't belong in
the device-tree. I appreciate that the current driver does a terrible job at
allocating the SMRs (it's bloody difficult!), but we should try to improve
the dynamic behaviour instead of moving configuration of the SMMU out into
device-tree, where it's inflexible at best.
I am talking about SMMU_SMRn[MASK] register bits. This is not something
that can be dynamically detected at run-time. It is configuration at the
same level as the actual StreamIDs.
Why can't it be dynamically detected? Whilst the StreamIDs are fixed in
hardware (from the SMMU architecture perspective), the SMRs are completely
programmable. Why doesn't something like Andreas's proposal work for you?
The idea there was to find the constant bits among the StreamIDs for a
master and create the mask accordingly.
Lets say I have an IOMMU with 2 masters and 2 SMRn slots with the
following stream IDs coming from the masters:

Master 1: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28
Master 2: 0x30

To make this work I would program SMR[0] with StreamID 0x20 and mask 0xF
to ignore lower 4 bits. SMR[1] would just be StreamID 0x30 with mask 0x0.

However, I could also have an IOMMU with 2 masters and 9 SMRn slots with
the following stream IDs:

Master 1: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28
Master 2: 0x29

Here I would program all SMRn and leave the mask to be 0 for all SMRn's.
So how do I detect when to apply a mask or not?

I am not familiar with Andreas's proposal. Do you have a link?

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help