All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Herrmann <andreas.herrmann@calxeda.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Olav Haugan <ohaugan@codeaurora.org>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] documentation: iommu: add description of ARM System MMU binding
Date: Mon, 13 May 2013 11:50:20 +0200	[thread overview]
Message-ID: <20130513095020.GB10369@alberich> (raw)
In-Reply-To: <1365789727-5371-1-git-send-email-will.deacon@arm.com>

Hi Will,

so far, I thought, that this proposal is fine. After I have tried to
make use of the binding I have some points that might need further
disucssion.

Olav already asked (in another thread) how to model the mapping of
stream IDs to contexts for master devices that support multiple
contexts.  I doubt that this is fully covered yet.

I also think that it is more useful to move the stream-id property to
the device node of a master device. (It's a characteristic of the
master device not of the SMMU.) Currently with multiple stream IDs per
master device you have repeated entries in the mmu-master property.

But all that is needed is to point (once) to each mmu-master in the
SMMU device node. Then you should be able to look up the corresponding
stream IDs in the device node for each mmu-master.


Regars,
Andreas


On Fri, Apr 12, 2013 at 02:02:07PM -0400, Will Deacon wrote:
> This patch adds a description of the device tree binding for the ARM
> System MMU architecture.
> 
> Cc: Rob Herring <robherring2@gmail.com>
> Cc: Andreas Herrmann <andreas.herrmann@calxeda.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt         | 66 ++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> new file mode 100644
> index 0000000..56de07c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -0,0 +1,66 @@
> +* ARM System MMU Architecture Implementation
> +
> +ARM SoCs may contain an implementation of the ARM System Memory
> +Management Unit Architecture, which can be used to provide 1 or 2 stages
> +of address translation to bus masters external to the CPU.
> +
> +The SMMU may also raise interrupts in response to various fault
> +conditions.
> +
> +** System MMU required properties:
> +
> +- compatible    : Should be one of:
> +
> +                        "arm,smmu-v1"
> +                        "arm,smmu-v2"
> +                        "arm,mmu-400"
> +
> +                  depending on the particular implementation and/or the
> +                  version of the architecture implemented.
> +
> +- reg           : Base address and size of the SMMU.
> +
> +- #global-interrupts : The number of global interrupts exposed by the
> +                       device.
> +
> +- interrupts    : Interrupt list, with the first #global-irqs entries
> +                  corresponding to the global interrupts and any
> +                  following entries corresponding to context interrupts,
> +                  specified in order of their indexing by the SMMU.
> +
> +- mmu-masters   : A list of phandles to device nodes representing bus
> +                  masters for which the SMMU can provide a translation.
> +
> +- stream-ids    : A list of 32-bit values corresponding to the StreamIDs
> +                  for the devices listed in the mmu-masters property.
> +                  This list must be same length as mmu-masters, so
> +                  masters with multiple stream-ids will have multiple
> +                  entries in mmu-masters.
> +
> +** System MMU optional properties:
> +
> +- smmu-parent   : When multiple SMMUs are chained together, this
> +                  property can be used to provide a phandle to the
> +                  parent SMMU (that is the next SMMU on the path going
> +                  from the mmu-masters towards memory) node for this
> +                  SMMU.
> +
> +Example:
> +
> +        smmu {
> +                compatible = "arm,smmu-v1";
> +                reg = <0xba5e0000 0x10000>;
> +                #global-interrupts = <2>;
> +                interrupts = <0 32 4>,
> +                             <0 33 4>,
> +                             <0 34 4>, /* This is the first context interrupt */
> +                             <0 35 4>,
> +                             <0 36 4>,
> +                             <0 37 4>;
> +                mmu-masters = <&dma0>,
> +                              <&dma0>,
> +                              <&dma1>;
> +                stream-ids  = <0xd01d>,
> +                              <0xd01e>,
> +                              <0xd11c>;
> +        };
> -- 
> 1.8.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: andreas.herrmann@calxeda.com (Andreas Herrmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] documentation: iommu: add description of ARM System MMU binding
Date: Mon, 13 May 2013 11:50:20 +0200	[thread overview]
Message-ID: <20130513095020.GB10369@alberich> (raw)
In-Reply-To: <1365789727-5371-1-git-send-email-will.deacon@arm.com>

Hi Will,

so far, I thought, that this proposal is fine. After I have tried to
make use of the binding I have some points that might need further
disucssion.

Olav already asked (in another thread) how to model the mapping of
stream IDs to contexts for master devices that support multiple
contexts.  I doubt that this is fully covered yet.

I also think that it is more useful to move the stream-id property to
the device node of a master device. (It's a characteristic of the
master device not of the SMMU.) Currently with multiple stream IDs per
master device you have repeated entries in the mmu-master property.

But all that is needed is to point (once) to each mmu-master in the
SMMU device node. Then you should be able to look up the corresponding
stream IDs in the device node for each mmu-master.


Regars,
Andreas


On Fri, Apr 12, 2013 at 02:02:07PM -0400, Will Deacon wrote:
> This patch adds a description of the device tree binding for the ARM
> System MMU architecture.
> 
> Cc: Rob Herring <robherring2@gmail.com>
> Cc: Andreas Herrmann <andreas.herrmann@calxeda.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt         | 66 ++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> new file mode 100644
> index 0000000..56de07c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -0,0 +1,66 @@
> +* ARM System MMU Architecture Implementation
> +
> +ARM SoCs may contain an implementation of the ARM System Memory
> +Management Unit Architecture, which can be used to provide 1 or 2 stages
> +of address translation to bus masters external to the CPU.
> +
> +The SMMU may also raise interrupts in response to various fault
> +conditions.
> +
> +** System MMU required properties:
> +
> +- compatible    : Should be one of:
> +
> +                        "arm,smmu-v1"
> +                        "arm,smmu-v2"
> +                        "arm,mmu-400"
> +
> +                  depending on the particular implementation and/or the
> +                  version of the architecture implemented.
> +
> +- reg           : Base address and size of the SMMU.
> +
> +- #global-interrupts : The number of global interrupts exposed by the
> +                       device.
> +
> +- interrupts    : Interrupt list, with the first #global-irqs entries
> +                  corresponding to the global interrupts and any
> +                  following entries corresponding to context interrupts,
> +                  specified in order of their indexing by the SMMU.
> +
> +- mmu-masters   : A list of phandles to device nodes representing bus
> +                  masters for which the SMMU can provide a translation.
> +
> +- stream-ids    : A list of 32-bit values corresponding to the StreamIDs
> +                  for the devices listed in the mmu-masters property.
> +                  This list must be same length as mmu-masters, so
> +                  masters with multiple stream-ids will have multiple
> +                  entries in mmu-masters.
> +
> +** System MMU optional properties:
> +
> +- smmu-parent   : When multiple SMMUs are chained together, this
> +                  property can be used to provide a phandle to the
> +                  parent SMMU (that is the next SMMU on the path going
> +                  from the mmu-masters towards memory) node for this
> +                  SMMU.
> +
> +Example:
> +
> +        smmu {
> +                compatible = "arm,smmu-v1";
> +                reg = <0xba5e0000 0x10000>;
> +                #global-interrupts = <2>;
> +                interrupts = <0 32 4>,
> +                             <0 33 4>,
> +                             <0 34 4>, /* This is the first context interrupt */
> +                             <0 35 4>,
> +                             <0 36 4>,
> +                             <0 37 4>;
> +                mmu-masters = <&dma0>,
> +                              <&dma0>,
> +                              <&dma1>;
> +                stream-ids  = <0xd01d>,
> +                              <0xd01e>,
> +                              <0xd11c>;
> +        };
> -- 
> 1.8.0
> 

  reply	other threads:[~2013-05-13  9:50 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 [this message]
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
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=20130513095020.GB10369@alberich \
    --to=andreas.herrmann@calxeda.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=ohaugan@codeaurora.org \
    --cc=will.deacon@arm.com \
    /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.