linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 20 Jun 2014 20:55:23 +0200	[thread overview]
Message-ID: <63766434.z4MqtGKoIA@wuerfel> (raw)
In-Reply-To: <20140620175051.GE30656@arm.com>

On Friday 20 June 2014 18:50:51 Will Deacon wrote:
> On Fri, Jun 20, 2014 at 04:53:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 18 June 2014 11:14:39 Will Deacon wrote:
> > > On Wed, Jun 18, 2014 at 12:37:16AM +0100, Thierry Reding wrote:
> > >   - Each master has a set of fixed StreamIDs
> > >   - StreamIDs can be remastered by adding a constant offset (this could also
> > >     be used to describe RequesterID -> StreamID mapping)
> > > 
> > > I'd hope this would be sufficient for most people. Dynamic ID assignment can
> > > be worked out later (I'm not even sure it belongs in this binding) and any
> > > mappings other than `add a constant offset' can be treated on a case-by-case
> > > basis. We don't want to throw the kitchen sink at a language for describing
> > > arbitrary transformations!
> > > 
> > > > We've had similar discussions before (power sequences anyone?) where we
> > > > tried to come up with a generic way to describe something in device tree
> > > > that just didn't work out too well. Some things are better done in code,
> > > > so I think we should at least consider that possibility rather than
> > > > blindly try and force everything into device tree.
> > > 
> > > If we can support 90% of SoCs with a simple DT-based description, we can
> > > address the corner cases as they arise. I'm not ruling our hardcoding
> > > topology if we have no choice, but I don't think that's a healthy place to
> > > start from.
> > 
> > So we could use the "arm,gicv3" comaptible string for all those that
> > have a relatively simple mapping, and describe that mapping entirely
> > in DT properties, but use a different compatible string for those
> > SoCs that have a mapping which we can't easily describe, and then
> > put that into code?
> 
> That doesn't sound unreasonable, but I don't think we should commit to
> putting things into code until they come along and we can't describe them.

Yes, that makes sense. But it's good to know that we have the option so
we don't have to cover all corner cases with the binding.

	Arnd

  reply	other threads:[~2014-06-20 18:55 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-23 20:36 [PATCH v2] devicetree: Add generic IOMMU device tree bindings Thierry Reding
2014-05-29 15:52 ` Stephen Warren
2014-05-30  7:30   ` Thierry Reding
2014-05-30 11:27     ` Dave Martin
2014-05-30 19:11       ` Arnd Bergmann
2014-06-02 10:56         ` Dave Martin
2014-06-04 21:12       ` Thierry Reding
2014-06-16 12:57         ` Will Deacon
2014-06-17 11:58           ` Thierry Reding
2014-06-17 12:18             ` Will Deacon
2014-06-17 23:37               ` Thierry Reding
2014-06-18 10:14                 ` Will Deacon
2014-06-20 15:53                   ` Arnd Bergmann
2014-06-20 17:50                     ` Will Deacon
2014-06-20 18:55                       ` Arnd Bergmann [this message]
2014-05-30 11:22 ` Dave Martin
2014-05-30 19:01   ` Arnd Bergmann
2014-06-02 11:44     ` Dave Martin
2014-06-04 21:32     ` Thierry Reding
2014-06-05  9:42       ` Arnd Bergmann
     [not found] <1400877218-4113-1-git-send-email-thierry.reding@gmail.com>
2014-05-30 13:16 ` Rob Herring
2014-05-30 19:06   ` Arnd Bergmann
2014-05-30 19:29     ` Hiroshi Doyu
2014-05-30 19:54       ` Arnd Bergmann
2014-06-01  9:55         ` Will Deacon
2014-06-04 13:39           ` Thierry Reding
2014-06-04 13:44         ` Thierry Reding
2014-06-04 13:53           ` Arnd Bergmann
2014-06-04 13:56           ` Will Deacon
2014-06-04 14:01             ` Arnd Bergmann
2014-06-04 16:39               ` Will Deacon
2014-05-30 19:31     ` Rob Herring
2014-05-30 19:49       ` Arnd Bergmann
2014-06-02 10:41         ` Dave Martin
2014-06-04 14:35           ` Thierry Reding
2014-06-04 16:41             ` Will Deacon
2014-06-04 21:00               ` Thierry Reding
2014-06-05 19:10               ` Varun Sethi
2014-06-16 15:27                 ` Will Deacon
2014-06-16 16:56                   ` Stuart Yoder
2014-06-16 17:04                     ` Will Deacon
2014-06-16 17:30                       ` Arnd Bergmann
2014-06-16 18:53                       ` Stuart Yoder
2014-06-17 10:26                         ` Varun Sethi
2014-06-17 10:43                           ` Will Deacon
2014-06-17 11:21                             ` Varun Sethi
2014-06-17 14:50                               ` Stuart Yoder
2014-06-18  9:29                                 ` Will Deacon
2014-06-17 14:39                           ` Stuart Yoder
2014-06-20 23:16     ` Olav Haugan
2014-06-24  9:18       ` Will Deacon
2014-06-24 17:57         ` Olav Haugan
2014-06-24 18:11           ` Will Deacon
2014-06-24 18:20             ` Arnd Bergmann
2014-06-25  9:17               ` Will Deacon
2014-06-25  9:27                 ` Arnd Bergmann
2014-06-25  9:38                   ` Will Deacon
2014-06-25  9:48                     ` Arnd Bergmann
2014-06-25  9:57                       ` Will Deacon
2014-06-25 10:12                         ` Arnd Bergmann
2014-06-25 10:14                           ` Will Deacon
2014-06-24 21:35             ` Olav Haugan
2014-06-25  9:18               ` Will Deacon
2014-06-27 22:23                 ` Olav Haugan
2014-06-30  9:52                   ` Will Deacon
2014-07-09  1:07                     ` Olav Haugan
2014-07-09 10:54                       ` Will Deacon
2014-07-10 22:32                         ` Olav Haugan
2014-07-11 12:24                           ` Will Deacon
     [not found] <20140606224542.GA22188@mithrandir>
2014-06-07 13:22 ` Arnd Bergmann
2014-06-09 10:49   ` Thierry Reding

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=63766434.z4MqtGKoIA@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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).