From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] spi: orion.c: Add direct access mode
Date: Fri, 25 Mar 2016 21:58:40 +0100 [thread overview]
Message-ID: <10747635.WkGeFaKqdy@wuerfel> (raw)
In-Reply-To: <20160325155032.GH2566@sirena.org.uk>
On Friday 25 March 2016 15:50:32 Mark Brown wrote:
> On Fri, Mar 25, 2016 at 04:11:05PM +0100, Arnd Bergmann wrote:
>
> > There is nothing magic in the binding if we just do the same thing
> > the flash driver does, and describe the memory range that is associated
> > with a chipselect.
>
> Why are we even doing that though? Like I say it just seems pointlessly
> unhelpful for users. Are we really saying that every single system has
> to go through and manually modify their DT so that they can use this
> entirely in SoC feature? That doesn't seem like winning...
I don't remember the exact details, but I think we had come up with
a generic constraint solving algorithm to pick appropriate windows for
each device with a (close to) minimal use of physical address space,
and we defined the DT binding for MBus in a way that would let us
implement that algorithm at a later point if we ever found we needed
it, but then decided against implementing it because it puts a lot
of complexity at the very early boot: it needs to do a deep walk
of all enabled child device nodes to find the size and alignment of
every reg property that translates into an mbus address, and figure out
a set of mbus translations that convert those into CPU phys addresses
without using too many mbus windows or too much address space.
> > > > Ok, so with the static mapping it could be done very easily, or
> > > > we need a more complex solution for the dynamic mapping.
>
> > > Part of what I personally don't understand is why this is complicated?
>
> > I think we'd need to add another special case in the bus driver
> > for it, which otherwise should be able to handle this in a generic
> > way: if we just use the existing binding, the spi host driver can
> > simply call devm_ioremap_resource() to see if there is a map
> > for a given chipselect and otherwise fall back to the current
> > mode.
>
> Why does the binding have to be in the client device to do that?
I don't understand the question. The client device here is the SPI
controller, right? That doesn't need to have a special binding, it
just needs to list the registers relative to the mbus address space
like any other device, and that is independent of how we implement
it.
It looks like Stefan's patch tricks here by creating an incompatible
binding for mbus that bypasses the address mapping.
Arnd
next prev parent reply other threads:[~2016-03-25 20:58 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 16:24 [PATCH v2] spi: orion.c: Add direct access mode Stefan Roese
2016-03-22 16:35 ` Thomas Petazzoni
2016-03-22 16:44 ` Stefan Roese
2016-03-23 11:33 ` Mark Brown
2016-03-23 11:59 ` Stefan Roese
2016-03-23 12:54 ` Mark Brown
2016-03-23 13:10 ` Stefan Roese
2016-03-23 13:26 ` Andrew Lunn
2016-03-23 13:36 ` Mark Brown
2016-03-23 13:56 ` Andrew Lunn
2016-03-23 19:51 ` Arnd Bergmann
2016-03-24 7:22 ` Stefan Roese
2016-03-24 12:42 ` Arnd Bergmann
2016-03-24 16:15 ` Stefan Roese
2016-03-24 16:42 ` Arnd Bergmann
2016-03-24 17:30 ` Stefan Roese
2016-03-24 16:48 ` Arnd Bergmann
2016-03-24 17:51 ` Stefan Roese
2016-03-24 20:07 ` Arnd Bergmann
2016-03-25 10:32 ` Mark Brown
2016-03-25 15:11 ` Arnd Bergmann
2016-03-25 15:50 ` Mark Brown
2016-03-25 20:58 ` Arnd Bergmann [this message]
2016-03-25 22:39 ` Mark Brown
2016-03-29 12:39 ` Arnd Bergmann
2016-03-29 16:47 ` Mark Brown
2016-03-29 19:49 ` Arnd Bergmann
2016-03-29 19:52 ` Mark Brown
2016-03-29 20:04 ` Arnd Bergmann
2016-03-29 21:00 ` Mark Brown
2016-03-29 21:08 ` Arnd Bergmann
2016-03-29 21:28 ` Mark Brown
2016-03-29 22:04 ` Arnd Bergmann
2016-04-05 7:11 ` Stefan Roese
2016-04-05 13:15 ` Andrew Lunn
2016-04-05 13:20 ` Stefan Roese
2016-04-05 13:31 ` Andrew Lunn
2016-03-23 13:27 ` Mark Brown
2016-03-23 17:25 ` Stefan Roese
2016-03-23 18:29 ` Mark Brown
2016-03-23 18:39 ` Andrew Lunn
2016-03-24 5:45 ` Stefan Roese
2016-03-24 11:23 ` Mark Brown
2016-03-24 12:05 ` Stefan Roese
2016-03-22 17:39 ` Mark Brown
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=10747635.WkGeFaKqdy@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