From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH RFC v2 3/3] documentation/iommu: Add description of Hisilicon SMMU private binding
Date: Mon, 16 Jun 2014 17:39:30 +0100 [thread overview]
Message-ID: <20140616163930.GX16758@arm.com> (raw)
In-Reply-To: <1402549692-5224-4-git-send-email-thunder.leizhen@huawei.com>
On Thu, Jun 12, 2014 at 06:08:12AM +0100, Zhen Lei wrote:
> This patch adds a description of private properties for the Hisilicon
> System MMU architecture.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei•com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index f284b99..75b1351 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -15,6 +15,7 @@ conditions.
> "arm,smmu-v2"
> "arm,mmu-400"
> "arm,mmu-500"
> + "hisilicon,smmu-v1"
>
> depending on the particular implementation and/or the
> version of the architecture implemented.
> @@ -54,6 +55,21 @@ conditions.
> aliases of secure registers have to be used during
> SMMU configuration.
>
> +** Hisilicon SMMU private properties:
> +
> +- smmu-force-memtype : A list of StreamIDs which not translate address but
> + translate attributes. The StreamIDs list here can not be
> + used for map(translation) mode again.
> + StreamID first, then the type list below:
> + 1, cahceable, WBRAWA, Normal outer and inner write-back
> + 2, non-cacheable, Normal outer and inner non-cacheable
> + 3, device, nGnRE
> + others, bypass
> +
> +- smmu-bypass-vmid : Specify which context bank is used for bypass mode.
> + If omit, vmid=255 is default. If bypass and map mode can
> + share a same S2CR, config vmid=0.
These don't feel like they belong in the device-tree to me. Is the list of
StreamIDs described in smmu-force-memtype a property of the hardware
configuration, or a software policy to allow you to generate cacheable
traffic for particular masters?
Will
next prev parent reply other threads:[~2014-06-16 16:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 5:08 [PATCH RFC v2 0/3] Add support for Hisilicon SMMU architecture Zhen Lei
2014-06-12 5:08 ` [PATCH RFC v2 1/3] iommu/arm: Adjust code to facilitate support arm smmu variants Zhen Lei
2014-06-12 5:08 ` [PATCH RFC v2 2/3] iommu/hisilicon: Add support for Hisilicon Ltd. System MMU architecture Zhen Lei
2014-06-12 5:08 ` [PATCH RFC v2 3/3] documentation/iommu: Add description of Hisilicon SMMU private binding Zhen Lei
2014-06-16 16:39 ` Will Deacon [this message]
2014-06-17 7:50 ` leizhen
2014-06-17 9:11 ` Varun Sethi
2014-06-17 9:33 ` Will Deacon
2014-06-18 1:28 ` leizhen
2014-06-18 12:03 ` Varun Sethi
2014-06-18 12:34 ` leizhen
2014-06-18 13:32 ` Will Deacon
2014-06-19 1:58 ` leizhen
2014-06-16 16:37 ` [PATCH RFC v2 0/3] Add support for Hisilicon SMMU architecture Will Deacon
2014-06-17 6:32 ` leizhen
2014-06-17 9:27 ` Will Deacon
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=20140616163930.GX16758@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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