All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Andreas Herrmann
	<andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Olav Haugan <ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@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 v2] documentation: iommu: add description of ARM System MMU binding
Date: Mon, 20 May 2013 11:18:41 +0100	[thread overview]
Message-ID: <20130520101841.GK31359@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20130517201639.GL10369@alberich>

Hi Andreas,

On Fri, May 17, 2013 at 09:16:39PM +0100, Andreas Herrmann wrote:
> On Mon, May 13, 2013 at 12:41:47PM +0200, Andreas Herrmann wrote:
> > On Mon, May 13, 2013 at 05:58:46AM -0400, Will Deacon wrote:
> > > Again, you also need to tie in topology information if you go down this
> > > route.
> 
> I still don't like the approach of having two independend lists that
> must be in sync to associate a master with its stream-ids.
> 
> Why? Say you have 8 masters for an SMMU with 1 or 2 stream-ids each:
> 
>      	 smmu {
> 		...
>                 mmu-masters = <&dma0>, <&dma0>, <&dma1>, <&dma1>,
> 			      <&dma2>, <&dma2>, <&dma4>, <&dma4>,
> 			      <&dma5>, <&dma6>, <&dma7>, <&dma8>;
>                 stream-ids =	<0>, <1>, <2>, <3>,
> 				<4>, <5>, <6>, <7>,
> 		                <8>, <9>, <0xa>, <0xb>;
> 	}
> 
> Couldn't we use of_phandle_args for this purpose? So your example
> 
> +        smmu {
> 		 ...
> +                mmu-masters = <&dma0>,
> +                              <&dma0>,
> +                              <&dma1>;
> +                stream-ids  = <0xd01d>,
> +                              <0xd01e>,
> +                              <0xd11c>;
> +        };
> 
> would look like
> 
> 	dma0 {
> 		...
> 		#stream-id-cells = <2>
> 		...
> 	}
> 
> 	dma1 {
> 		...
> 		#stream-id-cells = <1>
> 		...
> 	}
> 
>         smmu {
> 		...
> 		mmu-masters = <&dma0 0xd01d 0xd01e
> 			       &dma1 0xd11c>,
>        };
> 
> and my example would be converted to
> 
> 	smmu {
> 		...
>                 mmu-masters = <&dma0 0 1 &dma1 2 3 &dma2 4 5
> 			       &dma4 6 7 &dma5 8 &dma6 9
> 			       &dma7 0xa &dma8 0xb>
> 		...
> 	}

That also looks fine to me, although I'd like to write the parsing code in
my driver before I commit to anything!

> Of course usage of of_phandle_args would restrict the number of
> stream-ids per master to 8 (which is currently used as
> MAX_PHANDLE_ARGS). But I don't think that this is a restriction in
> practice or do you expect to have more than 8 stream-ids per master
> (ie. per struct device in Linux)?

Actually, I think that could be a problem. It doesn't sound unlikely that
multi-channel DMA controllers could have:

	- Separate instruction fetch streamid per channel
	- Separate read/write streamids per channel

so 8 does sound a bit small to me. How difficult would it be to bump that
number in the future if we needed to?

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] documentation: iommu: add description of ARM System MMU binding
Date: Mon, 20 May 2013 11:18:41 +0100	[thread overview]
Message-ID: <20130520101841.GK31359@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20130517201639.GL10369@alberich>

Hi Andreas,

On Fri, May 17, 2013 at 09:16:39PM +0100, Andreas Herrmann wrote:
> On Mon, May 13, 2013 at 12:41:47PM +0200, Andreas Herrmann wrote:
> > On Mon, May 13, 2013 at 05:58:46AM -0400, Will Deacon wrote:
> > > Again, you also need to tie in topology information if you go down this
> > > route.
> 
> I still don't like the approach of having two independend lists that
> must be in sync to associate a master with its stream-ids.
> 
> Why? Say you have 8 masters for an SMMU with 1 or 2 stream-ids each:
> 
>      	 smmu {
> 		...
>                 mmu-masters = <&dma0>, <&dma0>, <&dma1>, <&dma1>,
> 			      <&dma2>, <&dma2>, <&dma4>, <&dma4>,
> 			      <&dma5>, <&dma6>, <&dma7>, <&dma8>;
>                 stream-ids =	<0>, <1>, <2>, <3>,
> 				<4>, <5>, <6>, <7>,
> 		                <8>, <9>, <0xa>, <0xb>;
> 	}
> 
> Couldn't we use of_phandle_args for this purpose? So your example
> 
> +        smmu {
> 		 ...
> +                mmu-masters = <&dma0>,
> +                              <&dma0>,
> +                              <&dma1>;
> +                stream-ids  = <0xd01d>,
> +                              <0xd01e>,
> +                              <0xd11c>;
> +        };
> 
> would look like
> 
> 	dma0 {
> 		...
> 		#stream-id-cells = <2>
> 		...
> 	}
> 
> 	dma1 {
> 		...
> 		#stream-id-cells = <1>
> 		...
> 	}
> 
>         smmu {
> 		...
> 		mmu-masters = <&dma0 0xd01d 0xd01e
> 			       &dma1 0xd11c>,
>        };
> 
> and my example would be converted to
> 
> 	smmu {
> 		...
>                 mmu-masters = <&dma0 0 1 &dma1 2 3 &dma2 4 5
> 			       &dma4 6 7 &dma5 8 &dma6 9
> 			       &dma7 0xa &dma8 0xb>
> 		...
> 	}

That also looks fine to me, although I'd like to write the parsing code in
my driver before I commit to anything!

> Of course usage of of_phandle_args would restrict the number of
> stream-ids per master to 8 (which is currently used as
> MAX_PHANDLE_ARGS). But I don't think that this is a restriction in
> practice or do you expect to have more than 8 stream-ids per master
> (ie. per struct device in Linux)?

Actually, I think that could be a problem. It doesn't sound unlikely that
multi-channel DMA controllers could have:

	- Separate instruction fetch streamid per channel
	- Separate read/write streamids per channel

so 8 does sound a bit small to me. How difficult would it be to bump that
number in the future if we needed to?

Will

  reply	other threads:[~2013-05-20 10:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-12 18:02 [PATCH v2] documentation: iommu: add description of ARM System MMU binding Will Deacon
2013-04-12 18:02 ` Will Deacon
2013-05-13  9:50 ` Andreas Herrmann
2013-05-13  9:50   ` Andreas Herrmann
2013-05-13  9:58   ` Will Deacon
2013-05-13  9:58     ` Will Deacon
2013-05-13 10:41     ` Andreas Herrmann
2013-05-13 10:41       ` Andreas Herrmann
2013-05-17 20:16       ` Andreas Herrmann
2013-05-17 20:16         ` Andreas Herrmann
2013-05-20 10:18         ` Will Deacon [this message]
2013-05-20 10:18           ` Will Deacon
     [not found]           ` <20130520101841.GK31359-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-05-21 10:25             ` Andreas Herrmann
2013-05-21 10:25               ` Andreas Herrmann
2013-05-21 17:33               ` Will Deacon
2013-05-21 17:33                 ` Will Deacon
     [not found]                 ` <20130521173357.GA26251-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-05-21 18:35                   ` Andreas Herrmann
2013-05-21 18:35                     ` 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=20130520101841.GK31359@mudshark.cambridge.arm.com \
    --to=will.deacon-5wv7dgnigg8@public.gmane.org \
    --cc=andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@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.