All of lore.kernel.org
 help / color / mirror / Atom feed
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: mvebu-mbus: defining a DT binding
Date: Fri, 5 Apr 2013 11:29:16 -0600	[thread overview]
Message-ID: <20130405172916.GC3598@obsidianresearch.com> (raw)
In-Reply-To: <201304051858.05567.arnd@arndb.de>

On Fri, Apr 05, 2013 at 06:58:05PM +0200, Arnd Bergmann wrote:

> > So to me, this is already a guide that this might have to be board
> > specific anyhow.
> 
> I mentioned three options before, what you describe is one of
> them:

There is also 

d) The DT contains the bootloader address map, but the mbus driver
   discards that and fully reassigns everything.

e) The DT contains the bootloader address map, but some targets may be
   missing. The address map is kept, and the missing targets are
   dynamically allocated.
 
> a) make the ranges in the DT refer to what the hardware is set to,
> as you explain above. This makes it easy to run an OS without an
> mbus driver, but somewhat harder to reassign the windows at run-time

I don't think it makes things harder, it is straightforward for the
driver to wipe and rewrite the ranges property based on actual
programming.

> b) set the ranges to the windows we want to have in Linux. This is closer
> to what we have at the moment, where we basically configure mbus from
> a static configuration, and allow the windows that are to be dynamic
> (e.g. PCIe) to be left out of this.

Keep in mind that in all cases the mbus driver will zero all the
windows and write its own information. This is necessary to ensure any
left over PEX windows are blown away, for instance. So from a
driver-design standpoint a and b are identical.

The only difference is what do you put in the board
file. Pragmatically it won't matter to many people, Both will work if
the kernel has the mbus driver.

> c) Try to keep the ranges property empty at boot time, except possibly
> the internal register window, and find the optimum address map at
> boot time based on which devices are enabled.

I think d or e is a better choice, since we marry the best feature of
a, and the best function of c.

For working on the driver a/b is certainly the simplest first
step. Adding future capability to go to d or e won't require a DT
change.

Jason

      reply	other threads:[~2013-04-05 17:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 13:02 mvebu-mbus: defining a DT binding Thomas Petazzoni
2013-04-05 13:17 ` Arnd Bergmann
2013-04-05 13:51   ` Thomas Petazzoni
2013-04-05 14:36     ` Arnd Bergmann
2013-04-05 17:07       ` Jason Gunthorpe
2013-04-05 17:28         ` Arnd Bergmann
2013-04-05 17:48           ` Jason Gunthorpe
2013-04-05 19:49             ` Arnd Bergmann
2013-04-05 20:36               ` Jason Gunthorpe
2013-04-05 21:01                 ` Arnd Bergmann
2013-04-05 21:21                   ` Jason Gunthorpe
2013-04-06  8:39                     ` Arnd Bergmann
2013-04-08 17:03                       ` Jason Gunthorpe
2013-04-05 16:27 ` Jason Gunthorpe
2013-04-05 16:58   ` Arnd Bergmann
2013-04-05 17:29     ` Jason Gunthorpe [this message]

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=20130405172916.GC3598@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --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 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.