From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: Master-aware devices and sideband ID data
Date: Wed, 8 Jul 2015 17:02:28 +0100 [thread overview]
Message-ID: <20150708160227.GJ9283@arm.com> (raw)
In-Reply-To: <20150708133049.GD7025@leverpostej>
On Wed, Jul 08, 2015 at 02:30:50PM +0100, Mark Rutland wrote:
> On Tue, Jun 09, 2015 at 11:17:54AM +0100, Mark Rutland wrote:
> > On Fri, Jun 05, 2015 at 10:05:34AM +0100, Will Deacon wrote:
> > > Mark: how do you see this co-existing/merging with the current bindings?
> >
> > As I mentioned in my initial mail, it's not clear to me how this can be
> > reconciled with the current bindings. Everything I've been able to come
> > up with so far at best ends up describing the same thing repeatedly.
> >
> > I'll see what I can come up with. Any sugestions are welcome!
>
> I can't see a way of keeping the ID transformations explicit with the
> existing bindings, but I think we can simply fold these down into
> properties in the master nodes, given we expect each ID to be derived
> from some initial master ID anyway.
>
> So, to cater for the ITS we would need to pass master IDs along with the
> MSI parent information, which we could do by extending msi-parent or by
> introducing a new msis property which behaves similarly to the iommus
> property, describing the MSI controllers the device can address (via any
> IOMMUs), along with any controller-specific identification data.
>
> Which means we'd have DT fragments like the following for an arbitrary
> platform device:
>
> its0: its {
> ...
> msi-controller;
> #msi-cells = <1>; // DeviceId
> };
>
> its1: its {
> ...
> msi-controller;
> #msi-cells = <1>; // DeviceId
> };
>
> smmu: smmu {
> ...
> iommu-cells = <1>; // StreamId
> };
>
> device {
> ...
> iommus = <&its 0>;
> /* Can use either ITS, but has a different ID at each */
> msis = <&its0 0x0>, <&its1 0x400>;
> };
>
> That doesn't allow you to describe a device with multiple mater ports
> where each master port might want to generate MSIs, but I'm not sure if
> that's a real case.
In this case, I think we'd need something extra to define precisely how
those master ports relate to the rest of the system anyway. That would
likely be a device-specific property, I reckon.
> For PCIe root complexes, we'd need to describe the BDF -> iommu-cells
> and BDF -> msi-cells translations separately with new properties on the
> node for the root complex itself.
>
> Is there anything obviously broken with the above approach?
Works for me. Can you write this up as a binding extension to msi-parent,
please?
Will
next prev parent reply other threads:[~2015-07-08 16:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-24 15:50 Master-aware devices and sideband ID data Mark Rutland
2015-05-07 17:49 ` Stuart Yoder
2015-05-08 15:49 ` Will Deacon
2015-05-08 19:30 ` Stuart Yoder
2015-05-11 9:52 ` Will Deacon
2015-05-26 22:20 ` Chalamarla, Tirumalesh
2015-05-27 17:39 ` Mark Rutland
2015-05-29 17:46 ` Chalamarla, Tirumalesh
2015-06-01 10:22 ` Mark Rutland
2015-06-04 22:19 ` Chalamarla, Tirumalesh
2015-06-05 9:05 ` Will Deacon
2015-06-09 10:17 ` Mark Rutland
2015-06-10 8:11 ` Will Deacon
2015-07-08 13:30 ` Mark Rutland
2015-07-08 16:02 ` Will Deacon [this message]
2015-07-16 13:34 ` Mark Rutland
2015-07-17 10:36 ` 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=20150708160227.GJ9283@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