On 1/29/2014 12:03 PM, Will Deacon wrote:
On Wed, Jan 29, 2014 at 05:57:16PM +0000, Suravee Suthikulanit wrote:
On 1/29/2014 11:29 AM, Will Deacon wrote:
On Wed, Jan 29, 2014 at 05:26:35PM +0000, Suravee Suthikulanit wrote:
On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
Actually, we are using 32 on the AMD system. So, do you think we can set
this to 32 instead?
I think that's ok.
But are we really talking about number of SMRs or number of StreamIDs
per master device here? Ie. are you just having 32 SMRs for an SMMU on
your AMD system or do you have master devices which have 32 StreamIDs?
If it's just number of SMRs we don't need to modify this macro.
I am referring to the case where each mmu-master can have upto 32 streamID.
Crikey, how many SMRs do you have? Andreas and I have been struggling to
write a decent allocator for those, so if you have any algorithms that don't
require a quantum computer, we'd love to hear from you :)!
Will
Are you talking about the __arm_smmu_alloc_bitmap()?
Currently, we have configured the each SMMU to have 32 SMRs and using
15-bit streamID. However, we mostly have upto 32 streamID for each
master, and most of the SMMU only have one master. So it looks like the
current logic should be ok.
Interesting... how does that work for PCI? Do you force all devices behind a
given RC into the same address space?
Will
For PCI devices, we are using the bus, device, and function id to make
up the 15-bit SID for devices behind a particular PCI root complex.
I also notice that we are currently not supporting the streamID mask in
the SMR. Is this something planed for the future?
Suravee
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
