From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"will.deacon-5wv7dgnIgG8@public.gmane.org"
<will.deacon-5wv7dgnIgG8@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: RFC: extend iommu-map binding to support #iommu-cells > 1
Date: Fri, 16 Dec 2016 11:39:14 +0000 [thread overview]
Message-ID: <20161216113914.GC20265@leverpostej> (raw)
In-Reply-To: <VI1PR0401MB2638DE2D30F8423F6F8C7A6E8D9C0-9IDQY6o3qQjcXZ0H4ZLnAo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Fri, Dec 16, 2016 at 02:36:57AM +0000, Stuart Yoder wrote:
> For context, please see the thread:
> https://www.spinics.net/lists/arm-kernel/msg539066.html
>
> The existing iommu-map binding did not account for the situation where
> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
> of the IOMMU specifier being the SMR mask. The existing binding defines
> the mapping as:
> Any RID r in the interval [rid-base, rid-base + length) is associated with
> the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
>
> ...and that does not work if iommu-base is 2 cells, the second being the
> SMR mask.
>
> While this can be worked around by always having length=1, it seems we
> can get this cleaned up by updating the binding definition for iommu-map.
To reiterate, I'm very much not keen on the pci-iommu binding having
knowledge of the decomposition of iommu-specifiers from other bindings.
As mentioned previously, there's an intended interpretation [1] that we
need to fix up the pci-iommu binding with. With that, I don't think it's
even necessary to bodge iommu-cells = <1> AFAICT.
I'm sorry that the patch I suggested never materialized; let me figure
out the wording now...
Thanks,
Mark.
[1] https://www.spinics.net/lists/arm-kernel/msg539357.html
>
> See patch below. Thoughts?
>
> Thanks,
> Stuart
>
> -------------------------------------------------------------------------
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> index 56c8296..e81b461 100644
> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> @@ -38,8 +38,20 @@ Optional properties
> The property is an arbitrary number of tuples of
> (rid-base,iommu,iommu-base,length).
>
> - Any RID r in the interval [rid-base, rid-base + length) is associated with
> - the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> + If the associated IOMMU has an #iommu-cells value of 1, any RID r in the
> + interval [rid-base, rid-base + length) is associated with the listed IOMMU,
> + with the iommu-specifier (r - rid-base + iommu-base).
> +
> + ARM SMMU Note:
> + The ARM SMMU binding permits an #iommu-cells value of 2 and in this
> + case defines an IOMMU specifier to be: (stream-id,smr-mask)
> +
> + In an iommu-map this means the iommu-base consists of 2 cells:
> + (rid-base,iommu,[stream-id,smr-mask],length).
> +
> + In this case the RID to IOMMU specifier mapping is defined to be:
> + any RID r in the interval [rid-base, rid-base + length) is associated
> + with the listed IOMMU, with the iommu-specifier (r - rid-base + stream-id).
>
> - iommu-map-mask: A mask to be applied to each Requester ID prior to being
> mapped to an iommu-specifier per the iommu-map property.
>
>
>
next prev parent reply other threads:[~2016-12-16 11:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-16 2:36 RFC: extend iommu-map binding to support #iommu-cells > 1 Stuart Yoder
[not found] ` <VI1PR0401MB2638DE2D30F8423F6F8C7A6E8D9C0-9IDQY6o3qQjcXZ0H4ZLnAo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2016-12-16 3:46 ` Bharat Bhushan
[not found] ` <AM5PR0401MB25455AE3850ED6E724B025EF9A9C0-oQ3wXcTHOqrg6d/1FbYcvI3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2016-12-16 15:06 ` Stuart Yoder
2016-12-16 11:34 ` Robin Murphy
2016-12-16 11:39 ` Mark Rutland [this message]
2016-12-16 14:21 ` Stuart Yoder
[not found] ` <VI1PR0401MB26387C2712FC4BF74B4B96028D9C0-9IDQY6o3qQjcXZ0H4ZLnAo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2016-12-16 14:50 ` Robin Murphy
[not found] ` <07c70fde-2bce-a517-0f5f-a2405049c87c-5wv7dgnIgG8@public.gmane.org>
2016-12-16 15:07 ` Bharat Bhushan
2016-12-16 15:56 ` Stuart Yoder
[not found] ` <VI1PR0401MB2638870C58173D5906AE0D9E8D9C0-9IDQY6o3qQjcXZ0H4ZLnAo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2016-12-16 16:49 ` Robin Murphy
[not found] ` <41edab27-c73a-7a1a-4369-fb43d7f57f78-5wv7dgnIgG8@public.gmane.org>
2016-12-16 17:05 ` Stuart Yoder
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=20161216113914.GC20265@leverpostej \
--to=mark.rutland-5wv7dgnigg8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=stuart.yoder-3arQi8VN3Tc@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.