From: Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Stuart Yoder
<stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
Date: Tue, 19 Aug 2014 14:03:00 +0300 [thread overview]
Message-ID: <87wqa4hhcr.fsf@nvidia.com> (raw)
In-Reply-To: <a0244b6befa9407fb6c2c35cc29f92f7-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:
>> >> > Also, for dynamic stream ID allocation we would need to represent
>> >> > the specific master register (to store the stream ID) in the device tree.
>> >>
>> >> I assmue that the above means that iMX has such configuration
>> >> register to map steramID and a device dynamically.
>> >
>> > We have per master registers for setting the stream ID on the
>> > Layerscape platforms. My point was that we would need the iommu master
>> > node to include a reference to the master id register.
>> >
>> > master@1 {
>> > /* device has master ID 42 in the IOMMU */
>> > iommus = <&{/iommu} 42>;
>> > master-id-reg = <phandle offset> };
>>
>> In the above, for "iommus=" bindings, you wouldn't need to break
>> ARM,SMMU compatibility at all if you set "streamID" exactly as below.
>>
>> master@1 {
>> /* device has master ID 42 in the IOMMU */
>> iommus = <&{/iommu} 'any given streamID'>;
>> master-id-reg = <phandle offset>
>> };
>>
>> And your SoC needs to register bus_notifier and ADD_DEVICE should configure
>> to map 'any given streamID' to a device via the above register. This wouldn't
>> need any modification from ARM,SMMU driver and keep the iommus bindings
>> as it is.
>>
>> IOW, SoC only needs to register ADD_DEVICE in bus_notifier to map StreamID
>> to a device. This needs to be executed earlier than IOMMU bus's ADD_DEVICE,
>> though.
>>
>> Is my understanding right?
>
> I don't think that SOC specific code needs a bus notifier for setting
> the stream ID. It can be done as a part of SOC specific
> initialization. The device tree can be updated to reflect the correct
> stream ID (SMMU driver can get the updated stream ID from device
> tree).
That's possible.
> I was thinking more on the lines of updating the device stream id
> while attaching a device to the domain.
I thought the same but this would break the ARM,SMMU /compatibility/
since the 1st param of "iommus=" is always expected as "streamID".
If streamID can be assigned dynamically like PCIe, not like streamID
statically set in DT, how should we describe this dynmaic steramID
shifting/assignment in DT?
next prev parent reply other threads:[~2014-08-19 11:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 10:43 [PATCH v5] devicetree: Add generic IOMMU device tree bindings Thierry Reding
[not found] ` <1406803383-11601-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-31 10:54 ` Mark Rutland
2014-07-31 12:04 ` Joerg Roedel
[not found] ` <20140731120424.GK9809-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-07-31 15:38 ` Olof Johansson
[not found] ` <CAOesGMiS_MJNnkfPOsqxV27=rXPgT9UNbp-+VhpMRNf9u0+-eA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-31 16:36 ` Joerg Roedel
[not found] ` <20140731163611.GM9809-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-07-31 17:14 ` Olof Johansson
[not found] ` <CAOesGMjovbqn86Q97_SCgsC4jeZf1M_gTKk-Twjr_=6rvnXTCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-31 17:23 ` Joerg Roedel
2014-08-14 6:47 ` Hiroshi Doyu
[not found] ` <87a9774lf5.fsf-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-14 14:45 ` Varun Sethi
[not found] ` <cfb1d2ff66004685b7ead3f5e6321681-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-08-14 16:04 ` Hiroshi Doyu
[not found] ` <87y4ur2h23.fsf-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-19 9:52 ` Varun Sethi
[not found] ` <d9fb045d54244f26a773ba45ad3caa2d-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-08-19 10:03 ` Hiroshi Doyu
[not found] ` <87zjf0hk3b.fsf-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-19 10:47 ` Varun Sethi
[not found] ` <a0244b6befa9407fb6c2c35cc29f92f7-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-08-19 11:03 ` Hiroshi Doyu [this message]
[not found] ` <87wqa4hhcr.fsf-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-19 12:01 ` Varun Sethi
2014-08-15 11:51 ` Will Deacon
[not found] ` <20140815115110.GO27466-5wv7dgnIgG8@public.gmane.org>
2014-08-15 12:29 ` Hiroshi Doyu
[not found] ` <87tx5ehr62.fsf-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-15 13:14 ` Will Deacon
2014-08-19 12:11 ` Varun Sethi
[not found] ` <6a3d4048ddb84bd19c847adf7f02fc52-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-08-22 15:33 ` Will Deacon
2014-07-31 18:09 ` Laurent Pinchart
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=87wqa4hhcr.fsf@nvidia.com \
--to=hdoyu-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=thierry.reding-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).