From: Sergei Shtylyov <sshtylyov@ru•mvista.com>
To: Segher Boessenkool <segher@kernel•crashing.org>
Cc: linuxppc-dev@ozlabs•org, David Gibson <david@gibson•dropbear.id.au>
Subject: Re: powerpc_flash_init(), wtf!?
Date: Thu, 03 May 2007 22:19:18 +0400 [thread overview]
Message-ID: <463A27A6.5050601@ru.mvista.com> (raw)
In-Reply-To: <4e36fd0fc67f14fc4ff2178468c053f0@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>>> NOR flashes are at the same level as the "memory" node (where
>>>> else you
>>>> expect them to appear I wonder?).
>>> The "memory" node doesn't describe the RAM devices;
>>> it describes the RAM address space, instead. You can
>>> have separate nodes for the actual devices.
>> If you can remember our prior discussion, the "rom" nodes don't
>> describe "the actual devices" as well, only their mapping into the
>> address space. ;-)
> I don't remember that no. And having a node for the
That's a pity. :-)
> "ROM address space" isn't useful in the same way as
> having one for the "RAM address space" is -- flash
> memory is not a resource you randomly hand out to
> anyone who wants a piece. You also need to know some
> _specifics_ about a certain ROM device before you can
> map it into CPU address space properly.
Almost all of that is handled by MTD subsys transparently by probing.
What one *must* supply are the bank width and the address mapping (may
optionally supply a probe type).
>>> Now for ROM/flash/NVRAM, nodes _can_ appear directly
>>> under the root, but only if that is where they belong
>>> on your platform (i.e., they sit directly on the "system
>>> bus" (whatever that means on your platform); on most
>>> platforms though, such devices are connected via some
>>> I/O busses, so the nodes should appear under their
>>> respective controllers.
>> Yeah, you're right here, and I've probably misunderstood what
>> "memory" node was. In fact, the flash in my system resides on the same
>> local bus as RAM, so the proper place would be behind the "lbc" (or
>> whatever -- it doesn't exist as yet) node on the "soc" bus. Do you
>> think I need to go and document it as well for such cause? :-]
> If the "lbc" isn't software visible, you can/should put
> the RAM/ROM nodes directly under the SoC node.
It has a register set of its own.
>>> Now, back to the case at hand -- it would be nice to
>>> have a platform-independent way to probe the simple
>>> case -- a single direct-mapped device -- but it isn't
>>> obvious how to make that not clash with the not-so-simple
>>> cases. A helper function that does the work but is
>>> only called by the platforms that want it would do, I
>>> suppose?
>> It probably doesn't even worth a helper (since out of those 15
>> lines, 6 were pretty useless anyway)
> Sure -- but since it is such a common device to have (a
> simple NOR boot flash), it would be nice to avoid any
> code duplication. Compare to the serial port and RTC
> situation.
UARTs should be registered as of_device by the same bus probing mechanism
(and there was an attempt at OF based driver, IIRC).
arch/powerpc/kernel/legacy_serial.c only facilitates the old, platform device
based approach.
> Segher
WBR, Sergei
next prev parent reply other threads:[~2007-05-03 18:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 5:18 powerpc_flash_init(), wtf!? David Gibson
2007-05-03 6:35 ` Vitaly Bordug
2007-05-03 7:03 ` David Gibson
2007-05-03 12:02 ` Sergei Shtylyov
2007-05-03 12:22 ` David Gibson
2007-05-03 13:28 ` Sergei Shtylyov
2007-05-03 16:21 ` Segher Boessenkool
2007-05-03 16:59 ` Sergei Shtylyov
2007-05-03 17:25 ` Segher Boessenkool
2007-05-03 21:37 ` Benjamin Herrenschmidt
2007-05-03 23:49 ` David Gibson
2007-05-03 12:29 ` Benjamin Herrenschmidt
2007-05-04 0:30 ` Vitaly Bordug
2007-05-04 1:28 ` David Gibson
2007-05-03 11:47 ` Sergei Shtylyov
2007-05-03 12:30 ` David Gibson
2007-05-03 13:04 ` Sergei Shtylyov
2007-05-03 16:20 ` Segher Boessenkool
2007-05-03 17:17 ` Sergei Shtylyov
2007-05-03 17:35 ` Segher Boessenkool
2007-05-03 18:19 ` Sergei Shtylyov [this message]
2007-05-03 21:44 ` Benjamin Herrenschmidt
2007-05-03 17:53 ` Sergei Shtylyov
2007-05-03 18:07 ` Segher Boessenkool
2007-05-03 23:56 ` David Gibson
2007-05-04 12:14 ` Segher Boessenkool
2007-05-05 17:36 ` Sergei Shtylyov
2007-05-05 20:19 ` Segher Boessenkool
-- strict thread matches above, loose matches on Subject: below --
2007-05-23 21:57 Mark A. Greer
2007-05-24 0:56 ` David Gibson
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=463A27A6.5050601@ru.mvista.com \
--to=sshtylyov@ru$(echo .)mvista.com \
--cc=david@gibson$(echo .)dropbear.id.au \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=segher@kernel$(echo .)crashing.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