All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: Andreas Herrmann
	<andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [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-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>

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
> 

WARNING: multiple messages have this Message-ID (diff)
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: 36+ 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 ` Andreas Herrmann
     [not found] ` <1381224444-27303-1-git-send-email-andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
2013-10-08  9:27   ` [PATCH 1/5] iommu/arm-smmu: Introduce driver option handling Andreas Herrmann
2013-10-08  9:27     ` Andreas Herrmann
     [not found]     ` <1381224444-27303-2-git-send-email-andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
2013-10-08 15:06       ` Will Deacon
2013-10-08 15:06         ` Will Deacon
     [not found]         ` <20131008150613.GC21189-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-10-08 15:16           ` Andreas Herrmann
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     ` Andreas Herrmann
2013-10-08  9:27   ` [PATCH 3/5] iommu/arm-smmu: Introduce stream ID masking Andreas Herrmann
2013-10-08  9:27     ` Andreas Herrmann
     [not found]     ` <1381224444-27303-4-git-send-email-andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
2013-10-08 15:10       ` Will Deacon
2013-10-08 15:10         ` Will Deacon
     [not found]         ` <20131008151007.GD21189-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-10-08 15:20           ` Andreas Herrmann
2013-10-08 15:20             ` Andreas Herrmann
2013-10-08 16:40             ` Andreas Herrmann
2013-10-08 16:40               ` Andreas Herrmann
2013-10-08 16:59               ` Will Deacon
2013-10-08 16:59                 ` Will Deacon
     [not found]                 ` <20131008165920.GG21189-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-10-08 18:18                   ` Sethi Varun-B16395
2013-10-08 18:18                     ` Sethi Varun-B16395
2013-10-08 18:43                   ` Rob Herring [this message]
2013-10-08 18:43                     ` Rob Herring
     [not found]                     ` <52545266.6010400-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-10-09 10:09                       ` Will Deacon
2013-10-09 10:09                         ` Will Deacon
     [not found]                         ` <20131009100917.GB5985-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-10-09 23:10                           ` Andreas Herrmann
2013-10-09 23:10                             ` Andreas Herrmann
2013-10-09 22:55                   ` 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     ` 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  9:27     ` Andreas Herrmann
2013-10-08 10:31   ` [PATCH] documentation/iommu: Update description of ARM System MMU binding Andreas Herrmann
2013-10-08 10:31     ` 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-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.