linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] iommu/arm-smmu: Introduce stream ID masking
Date: Tue, 08 Oct 2013 13:43:50 -0500	[thread overview]
Message-ID: <52545266.6010400@gmail.com> (raw)
In-Reply-To: <20131008165920.GG21189@mudshark.cambridge.arm.com>

On 10/08/2013 11:59 AM, Will Deacon wrote:
> On Tue, Oct 08, 2013 at 05:40:21PM +0100, Andreas Herrmann wrote:
>> On Tue, Oct 08, 2013 at 05:20:08PM +0200, Andreas Herrmann wrote:
>> To be more specific: For SATA I'd need to specify 10 StreamIds. This
>> would
>>
>> (1) exceed MAX_MASTER_STREAMIDS (currently it's 8)
>>
>>    (Can easily be fixed by adapting a macro.)
>>
>> (2) exceed number of available SMR groups to map the IDs to a context.
>>
>>    This can be solved by caclulating an appropriate mask for the
>>    mapping (but with a non-power-of-two number of StreamIds that's
>>    already non-trivial -- for the trivial case I have some code to do
>>    this).
>>
>> Both problems are avoided by introducing this patch -- use
>> smr_mask_bits to map all StreamIDs to the same context and be done
>> with it. (for the "single-master-SMMU" case)
> 
> The problem is, this information *really* doesn't belong in the device tree,
> but I think computing the general case dynamically is incredibly difficult
> too (and requires *complete* topological information in the device-tree, so
> you don't accidentally pull in other devices).

Couldn't this information be implied from the DT when you have no
streamID and only a single mmu-master?

Rob

>> PS: I think (2) needs to be addressed sooner or later. We should use
>>     only as many SMR groups as really required -- ie. use masking of
>>     StreamIds if possible. If more than one StreamID is given for a
>>     master it might be possible to calculate a mask for a
>>     (power-of-two) number of adjacent StreamIds and then use only one
>>     SMR group to map these IDs to a context. (But I think that should
>>     only be done if multiple masters are attached to an SMMU.)
> 
> I spent a few weeks looking at doing minimal SMR grouping whilst writing the
> driver and ended up convincing myself that it's an NP-complete problem (I
> tried a reduction involving Hamiltonian Cycles). Of course, if you have some
> ideas here, we can try to implement something for a constrained instance of
> the problem.
> 
> For example, a simple solution is to xor all the IDs together and check no
> other IDs fall under the resulting mask. However, this again relies on the
> DT telling us complete topological information as well as the IDs being
> organised in a particular way.
> 
> Will
> 

  parent reply	other threads:[~2013-10-08 18:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08  9:27 [PATCH 0/5] iommu/arm-smmu: Misc modifications to support SMMUs on Calxeda ECX-2000 Andreas Herrmann
2013-10-08  9:27 ` [PATCH 1/5] iommu/arm-smmu: Introduce driver option handling Andreas Herrmann
2013-10-08 15:06   ` Will Deacon
2013-10-08 15:16     ` Andreas Herrmann
2013-10-08  9:27 ` [PATCH 2/5] iommu/arm-smmu: Introduce bus notifier block Andreas Herrmann
2013-10-08  9:27 ` [PATCH 3/5] iommu/arm-smmu: Introduce stream ID masking Andreas Herrmann
2013-10-08 15:10   ` Will Deacon
2013-10-08 15:20     ` Andreas Herrmann
2013-10-08 16:40       ` Andreas Herrmann
2013-10-08 16:59         ` Will Deacon
2013-10-08 18:18           ` Sethi Varun-B16395
2013-10-08 18:43           ` Rob Herring [this message]
2013-10-09 10:09             ` Will Deacon
2013-10-09 23:10               ` Andreas Herrmann
2013-10-09 22:55           ` Andreas Herrmann
2013-10-08  9:27 ` [PATCH 4/5] iommu/arm-smmu: Support buggy implementations where all config accesses are secure Andreas Herrmann
2013-10-08  9:27 ` [PATCH 5/5] ARM: dts: Add nodes for SMMUs on Calxeda ECX-2000 Andreas Herrmann
2013-10-08 10:31 ` [PATCH] documentation/iommu: Update description of ARM System MMU binding Andreas Herrmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52545266.6010400@gmail.com \
    --to=robherring2@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).