* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
@ 2007-06-02 4:30 Milton Miller
2007-06-02 7:39 ` Benjamin Herrenschmidt
` (3 more replies)
0 siblings, 4 replies; 81+ messages in thread
From: Milton Miller @ 2007-06-02 4:30 UTC (permalink / raw)
To: Mark A. Greer; +Cc: ppcdev
On Sat Jun 2 09:20:22 EST 2007, Mark A. Greer wrote:
> Find the "rom" device for the prpmc2800 and create a device for it.
> The device will be picked up by the code in
> drivers/mtd/maps/physmap_of.c
> and will setup MTD on that FLASH device.
...
> /*
> + * Register a platform device for MTD.
> + */
> +static int __init prpmc2800_register_mtd(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, "rom", "direct-mapped");
> + of_platform_device_create(np, np->name, NULL);
> +}
> +arch_initcall(prpmc2800_register_mtd);
>
I think "direct-mapped" as compatible is a bit too broad or vague.
The compatible is supposed to be useable to find and match a driver
without regard to the name of the node. Perhaps direct-mapped-rom?
(as opossed to a direct-mapped-ram, sram, or some width flash bank).
Actually, looking back at your device tree {1], your list several
properties for flash, including bank-width and partition names.
Perhaps first compatible should be direct-mapped-partitioned-flash,
direct-mapped-partitioned-rom, direct-mapped-rom (to me a
direct-mapped-rom driver would expose one section of address space
read-only). I'm assuming that your driver for this "direct-mapped"
device will look at these properties from the of device node and
call the mtd layer somewhat directly with their contents.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035858.html
milton
PS: I know you've posted this a few times. I'm just behind in
my reading and replying :-).
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-02 4:30 [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Milton Miller
@ 2007-06-02 7:39 ` Benjamin Herrenschmidt
2007-06-03 16:10 ` Sergei Shtylyov
2007-06-02 8:53 ` Segher Boessenkool
` (2 subsequent siblings)
3 siblings, 1 reply; 81+ messages in thread
From: Benjamin Herrenschmidt @ 2007-06-02 7:39 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
On Fri, 2007-06-01 at 23:30 -0500, Milton Miller wrote:
>
> Actually, looking back at your device tree {1], your list several
> properties for flash, including bank-width and partition names.
> Perhaps first compatible should be direct-mapped-partitioned-flash,
> direct-mapped-partitioned-rom, direct-mapped-rom (to me a
> direct-mapped-rom driver would expose one section of address space
> read-only). I'm assuming that your driver for this "direct-mapped"
> device will look at these properties from the of device node and
> call the mtd layer somewhat directly with their contents.
If it's a flash, compatible should be the chip type, and maybe as a
second entry, what type of flash protocol (amd, intel, cfi, ...) it's
compatible.
Ben.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-02 7:39 ` Benjamin Herrenschmidt
@ 2007-06-03 16:10 ` Sergei Shtylyov
2007-06-03 17:36 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 16:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev, Milton Miller
Hello.
Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-01 at 23:30 -0500, Milton Miller wrote:
>
>>Actually, looking back at your device tree {1], your list several
>>properties for flash, including bank-width and partition names.
>>Perhaps first compatible should be direct-mapped-partitioned-flash,
>>direct-mapped-partitioned-rom, direct-mapped-rom (to me a
>>direct-mapped-rom driver would expose one section of address space
>>read-only). I'm assuming that your driver for this "direct-mapped"
>>device will look at these properties from the of device node and
>>call the mtd layer somewhat directly with their contents.
> If it's a flash, compatible should be the chip type, and maybe as a
> second entry, what type of flash protocol (amd, intel, cfi, ...) it's
> compatible.
As I've already (and repatedly) stated before, this gets you *nothing* WRT
selecting the proper driver in the current Linux MTD subsystem. What it
actually *needs* to know is flash mapping information, the CFI/JEDEC interface
then can be deduced by probing -- so, this property ("ptobe-type"), although
specified in Documentation/powerpc/booting-without-of.txt, is optional.
> Ben.
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 16:10 ` Sergei Shtylyov
@ 2007-06-03 17:36 ` Segher Boessenkool
2007-06-03 18:03 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 17:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, Milton Miller
>> If it's a flash, compatible should be the chip type, and maybe as a
>> second entry, what type of flash protocol (amd, intel, cfi, ...) it's
>> compatible.
>
> As I've already (and repatedly) stated before,
And you repeatedly got answers too, yet you choose
to rehash this whole discussion again.
> this gets you *nothing* WRT
> selecting the proper driver in the current Linux MTD subsystem.
Which Linux driver to use is not something that should
be (directly) communicated in a device tree -- even if
you take the position the device tree is a nice big
configuration file for Linux, what if a new Linux flash
subsystem shows up (or even simply a driver got renamed,
etc.) -- the device tree on your board doesn't necessarily
change when your kernel version does.
> What it
> actually *needs* to know is flash mapping information,
It needs to know what kind of flash it is, and how it
is connected -- i.e., it needs to describe the hardware.
How Linux then decides to use it is its own game, but
at least the device tree puts all the information it
could possibly need out there.
> the CFI/JEDEC interface
> then can be deduced by probing
Most of the time, sure. Not always.
> -- so, this property ("ptobe-type"), although
> specified in Documentation/powerpc/booting-without-of.txt, is optional.
Who is talking about "probe-type"? We are talking
about "compatible".
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 17:36 ` Segher Boessenkool
@ 2007-06-03 18:03 ` Sergei Shtylyov
2007-06-03 18:25 ` Segher Boessenkool
` (2 more replies)
0 siblings, 3 replies; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 18:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
Hello.
Segher Boessenkool wrote:
>>> If it's a flash, compatible should be the chip type, and maybe as a
>>> second entry, what type of flash protocol (amd, intel, cfi, ...) it's
>>> compatible.
>> As I've already (and repatedly) stated before,
> And you repeatedly got answers too, yet you choose
> to rehash this whole discussion again.
Not I have started it. And I have my reasons, too. :-)
>> this gets you *nothing* WRT
>> selecting the proper driver in the current Linux MTD subsystem.
> Which Linux driver to use is not something that should
> be (directly) communicated in a device tree -- even if
Bah... what's "name" and "compatible" properties are for then. Nobody's
talking about the direct match but making the task of selecting a proper
driver more complex by specifying the details that don't help (if not hinder)
the correct selection is certainly not a way to go.
> you take the position the device tree is a nice big
> configuration file for Linux, what if a new Linux flash
> subsystem shows up (or even simply a driver got renamed,
> etc.)
There is no direct match in *this* case (for an example of such, refer to
FSL "gianfar" nodes ;-).
> -- the device tree on your board doesn't necessarily
> change when your kernel version does.
Well, I'm not anticipating any changes either in this case...
>> What it
>> actually *needs* to know is flash mapping information,
> It needs to know what kind of flash it is, and how it
> is connected -- i.e., it needs to describe the hardware.
> How Linux then decides to use it is its own game, but
> at least the device tree puts all the information it
> could possibly need out there.
>> the CFI/JEDEC interface then can be deduced by probing
> Most of the time, sure. Not always.
That's the way the cookie crumbles in Linux MTD for now. It's *always*
detecting this by probing -- you only can say what [not] to probe.
>> -- so, this property ("ptobe-type"), although specified in
>> Documentation/powerpc/booting-without-of.txt, is optional.
> Who is talking about "probe-type"? We are talking about "compatible".
See my other mail where I've told why I don't consider your example of
this prop valid...
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:03 ` Sergei Shtylyov
@ 2007-06-03 18:25 ` Segher Boessenkool
2007-06-03 18:36 ` Sergei Shtylyov
2007-06-03 21:04 ` Benjamin Herrenschmidt
2007-06-07 14:47 ` David Woodhouse
2 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 18:25 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
>> Which Linux driver to use is not something that should
>> be (directly) communicated in a device tree -- even if
>
> Bah... what's "name" and "compatible" properties are for then.
They communicate to the kernel what exactly a certain device
is. Nothing more, nothing less. The kernel is supposed to
use this information to select what device driver to use for
it. Any extra information the kernel might need/want to drive
the device is described in other properties (or, in some cases,
in different device nodes, even).
> Nobody's talking about the direct match but making the task of
> selecting a proper driver more complex by specifying the details that
> don't help (if not hinder) the correct selection is certainly not a
> way to go.
Nonsense. If the kernel doesn't care about certain details,
it can just ignore them.
>> -- the device tree on your board doesn't necessarily
>> change when your kernel version does.
>
> Well, I'm not anticipating any changes either in this case...
That's a problem then.
>>> the CFI/JEDEC interface then can be deduced by probing
>
>> Most of the time, sure. Not always.
>
> That's the way the cookie crumbles in Linux MTD for now. It's
> *always* detecting this by probing -- you only can say what [not] to
> probe.
So go fix that :-)
>> Who is talking about "probe-type"? We are talking about "compatible".
>
> See my other mail where I've told why I don't consider your example
> of this prop valid...
I haven't read that yet, but I can tell you now that I'm already
very sceptical about the arguments.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:25 ` Segher Boessenkool
@ 2007-06-03 18:36 ` Sergei Shtylyov
2007-06-03 18:46 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 18:36 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>> Which Linux driver to use is not something that should
>>> be (directly) communicated in a device tree -- even if
>> Bah... what's "name" and "compatible" properties are for then.
> They communicate to the kernel what exactly a certain device
> is. Nothing more, nothing less. The kernel is supposed to
> use this information to select what device driver to use for
> it. Any extra information the kernel might need/want to drive
> the device is described in other properties (or, in some cases,
> in different device nodes, even).
Yeah, the different node sounds more like this case.
>> Nobody's talking about the direct match but making the task of
>> selecting a proper driver more complex by specifying the details that
>> don't help (if not hinder) the correct selection is certainly not a
>> way to go.
> Nonsense. If the kernel doesn't care about certain details,
> it can just ignore them.
That's OK, as long as it has the details it needs. Your suggestions on the
"compatible" devoided it of such.
>>> -- the device tree on your board doesn't necessarily
>>> change when your kernel version does.
>> Well, I'm not anticipating any changes either in this case...
> That's a problem then.
At least not in the direction that you wanted us to change the MTD device
node. :-)
>>>> the CFI/JEDEC interface then can be deduced by probing
>>> Most of the time, sure. Not always.
>> That's the way the cookie crumbles in Linux MTD for now. It's
>> *always* detecting this by probing -- you only can say what [not] to
>> probe.
> So go fix that :-)
Wanna pay me for that? ;-)
>>> Who is talking about "probe-type"? We are talking about "compatible".
>> See my other mail where I've told why I don't consider your example
>> of this prop valid...
> I haven't read that yet, but I can tell you now that I'm already
> very sceptical about the arguments.
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:36 ` Sergei Shtylyov
@ 2007-06-03 18:46 ` Segher Boessenkool
2007-06-03 19:16 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 18:46 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
>>> Nobody's talking about the direct match but making the task of
>>> selecting a proper driver more complex by specifying the details
>>> that don't help (if not hinder) the correct selection is certainly
>>> not a way to go.
>
>> Nonsense. If the kernel doesn't care about certain details,
>> it can just ignore them.
>
> That's OK, as long as it has the details it needs. Your suggestions
> on the "compatible" devoided it of such.
Sigh.
[snip]
>>> That's the way the cookie crumbles in Linux MTD for now. It's
>>> *always* detecting this by probing -- you only can say what [not] to
>>> probe.
>
>> So go fix that :-)
>
> Wanna pay me for that? ;-)
You're the one complaining, you go pay yourself.
[snip, plunk]
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:46 ` Segher Boessenkool
@ 2007-06-03 19:16 ` Sergei Shtylyov
0 siblings, 0 replies; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 19:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>>> Nobody's talking about the direct match but making the task of
>>>> selecting a proper driver more complex by specifying the details
>>>> that don't help (if not hinder) the correct selection is certainly
>>>> not a way to go.
>>> Nonsense. If the kernel doesn't care about certain details,
>>> it can just ignore them.
>> That's OK, as long as it has the details it needs. Your suggestions
>> on the "compatible" devoided it of such.
> Sigh.
There had been no suggestions about other props or using "ranges" at that
point. That wouldn't have covered all issues anyway.
> [snip]
>>>> That's the way the cookie crumbles in Linux MTD for now. It's
>>>> *always* detecting this by probing -- you only can say what [not] to
>>>> probe.
>>> So go fix that :-)
>> Wanna pay me for that? ;-)
> You're the one complaining, you go pay yourself.
I'm lost here. Complaining about what?
> [snip, plunk]
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:03 ` Sergei Shtylyov
2007-06-03 18:25 ` Segher Boessenkool
@ 2007-06-03 21:04 ` Benjamin Herrenschmidt
2007-06-04 12:34 ` Sergei Shtylyov
2007-06-07 14:53 ` David Woodhouse
2007-06-07 14:47 ` David Woodhouse
2 siblings, 2 replies; 81+ messages in thread
From: Benjamin Herrenschmidt @ 2007-06-03 21:04 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
On Sun, 2007-06-03 at 22:03 +0400, Sergei Shtylyov wrote:
> >> the CFI/JEDEC interface then can be deduced by probing
>
> > Most of the time, sure. Not always.
>
> That's the way the cookie crumbles in Linux MTD for now. It's
> *always*
> detecting this by probing -- you only can say what [not] to probe.
So you are saying that because the current linux MTD stuff can only
probe (which doesn't always work), we should not put the proper chip
interface type in the device-tree ?
Your argument makes no sense to me.
Put the proper interface informations in the device-tree, maybe some OS
smarter than linux will make good use on it and maybe linux will be
fixed at one point too (not by you, of course, you gave us that line
often enough about not being paid to do the right thing).
Ben.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 21:04 ` Benjamin Herrenschmidt
@ 2007-06-04 12:34 ` Sergei Shtylyov
2007-06-04 14:37 ` Segher Boessenkool
2007-06-07 14:53 ` David Woodhouse
1 sibling, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-04 12:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev, linux-mtd, Milton Miller
Benjamin Herrenschmidt wrote:
>>>>the CFI/JEDEC interface then can be deduced by probing
>>>Most of the time, sure. Not always.
>> That's the way the cookie crumbles in Linux MTD for now. It's
>>*always*
>>detecting this by probing -- you only can say what [not] to probe.
> So you are saying that because the current linux MTD stuff can only
> probe (which doesn't always work), we should not put the proper chip
> interface type in the device-tree ?
No. But if/when we put it, it'll only be able to influence interface
probing, but not "force" the interface.
> Your argument makes no sense to me.
As I said, that's the way the cookie crumbles.
> Put the proper interface informations in the device-tree, maybe some OS
> smarter than linux will make good use on it and maybe linux will be
> fixed at one point too (not by you, of course, you gave us that line
> often enough about not being paid to do the right thing).
The money was not the only factor, you know, I was under the pressure of
schedules, and had a lot more things to do.
> Ben.
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-04 12:34 ` Sergei Shtylyov
@ 2007-06-04 14:37 ` Segher Boessenkool
2007-06-04 14:49 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-04 14:37 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
>> So you are saying that because the current linux MTD stuff can only
>> probe (which doesn't always work), we should not put the proper chip
>> interface type in the device-tree ?
>
> No. But if/when we put it, it'll only be able to influence
> interface probing, but not "force" the interface.
Of course it can; that just means you have to fix MTD
and/or the way your platform calls MTD.
> The money was not the only factor, you know, I was under the
> pressure of schedules, and had a lot more things to do.
The bigger Linux community does not (and should not)
care about your corporate schedules. Your patches
won't be merged upstream until they are deemed to be
of acceptable quality. If that doesn't fit your
employer's schedule, well tough luck, they can maintain
their own kernel fork I'm sure?
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-04 14:37 ` Segher Boessenkool
@ 2007-06-04 14:49 ` Sergei Shtylyov
0 siblings, 0 replies; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-04 14:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>> So you are saying that because the current linux MTD stuff can only
>>> probe (which doesn't always work), we should not put the proper chip
>>> interface type in the device-tree ?
>> No. But if/when we put it, it'll only be able to influence
>> interface probing, but not "force" the interface.
> Of course it can; that just means you have to fix MTD
I wouldn't call this a fix, more like an additional feature. Probing has
worked well enough.
> and/or the way your platform calls MTD.
The platform code is not supposed to call MTD *at all*. The only expeption
so far are physmap_configure() and physmap_set_partitions() which are both
considered obsolete (in favor of platform device). Maybe linux-mtd people will
correct me though...
>> The money was not the only factor, you know, I was under the
>> pressure of schedules, and had a lot more things to do.
> The bigger Linux community does not (and should not)
> care about your corporate schedules. Your patches
> won't be merged upstream until they are deemed to be
> of acceptable quality. If that doesn't fit your
> employer's schedule, well tough luck, they can maintain
> their own kernel fork I'm sure?
But the driver have been nevertheless merged. Moreover, the it was one of
the MTD maintainers who expressed desire for partition info to be kept with
device node in the first place.
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 21:04 ` Benjamin Herrenschmidt
2007-06-04 12:34 ` Sergei Shtylyov
@ 2007-06-07 14:53 ` David Woodhouse
2007-06-07 15:49 ` Segher Boessenkool
1 sibling, 1 reply; 81+ messages in thread
From: David Woodhouse @ 2007-06-07 14:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev, linux-mtd, Milton Miller
On Mon, 2007-06-04 at 07:04 +1000, Benjamin Herrenschmidt wrote:
> So you are saying that because the current linux MTD stuff can only
> probe (which doesn't always work), we should not put the proper chip
> interface type in the device-tree ?
>
> Your argument makes no sense to me.
>
> Put the proper interface informations in the device-tree, maybe some OS
> smarter than linux will make good use on it and maybe linux will be
> fixed at one point too (not by you, of course, you gave us that line
> often enough about not being paid to do the right thing).
In general, Linux is doing the right thing by probing.
There are two major command sets for NOR flash -- the Intel/Sharp
command set, and the AMD/Fujitsu command set.
There are also two major ways to detect flash chips -- the JEDEC probe
with magic numbers for mfr/chip ident, and the CFI ('Common Flash
Interface') probe which gets you tables of information about the chip,
including what optional command set extensions it has, etc.
You _can_ bypass the probe and pass straight through to the 'back-end'
chip driver. But unless you provide the CFI information you won't get to
use any of the optional chip features (or blacklist some of the
known-broken features). It doesn't make a lot of sense to try using the
back-end chip drivers directly. Just go through the normal probe
process, really.
If you really want to bypass the probe, then I suspect you want the full
CFI tables to be present in your OF properties.
--
dwmw2
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-07 14:53 ` David Woodhouse
@ 2007-06-07 15:49 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-07 15:49 UTC (permalink / raw)
To: David Woodhouse; +Cc: ppcdev, linux-mtd, Milton Miller
>> Put the proper interface informations in the device-tree, maybe some
>> OS
>> smarter than linux will make good use on it and maybe linux will be
>> fixed at one point too (not by you, of course, you gave us that line
>> often enough about not being paid to do the right thing).
>
> In general, Linux is doing the right thing by probing.
Compare to PCI. After Linux has found out how to
drive a PHB from the device tree, it can detect the
whole PCI tree on its own. The device tree can still
be used to find out special things about the devices
(interrupt routing, ...) or to change some of the
probing algorithm (in the case of hardware bugs, for
example).
Now with NOR flash, the situation is analogue. The
device tree tells Linux how to drive the flash bus
controller, and certain things about that bus (width,
for example). It also should tell Linux what kind
of devices are on that bus (CFI, ...). Linux can
do its own probes then, or it can use the device tree
for special cases.
> There are two major command sets for NOR flash -- the Intel/Sharp
> command set, and the AMD/Fujitsu command set.
>
> There are also two major ways to detect flash chips -- the JEDEC probe
> with magic numbers for mfr/chip ident,
A heuristic, but it's been worked out well enough over
the years that it is pretty reliable now.
> and the CFI ('Common Flash
> Interface') probe which gets you tables of information about the chip,
> including what optional command set extensions it has, etc.
But it only is 100% reliable _if_ you already know the
chip is CFI compatible.
> You _can_ bypass the probe and pass straight through to the 'back-end'
> chip driver. But unless you provide the CFI information you won't get
> to
> use any of the optional chip features (or blacklist some of the
> known-broken features). It doesn't make a lot of sense to try using the
> back-end chip drivers directly. Just go through the normal probe
> process, really.
Just don't do any heuristic probes ("just try if something's
there", etc.) -- using the CFI probe algorithm on a flash
device that the device tree tells you is a CFI device should
be just fine, certainly.
> If you really want to bypass the probe, then I suspect you want the
> full
> CFI tables to be present in your OF properties.
I never saw how that kind of info is useful for the OS to
have in the device tree -- if the OS can use the device at
all, it can get that info straight from the device easy
enough.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:03 ` Sergei Shtylyov
2007-06-03 18:25 ` Segher Boessenkool
2007-06-03 21:04 ` Benjamin Herrenschmidt
@ 2007-06-07 14:47 ` David Woodhouse
2007-06-07 15:32 ` Segher Boessenkool
2 siblings, 1 reply; 81+ messages in thread
From: David Woodhouse @ 2007-06-07 14:47 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
On Sun, 2007-06-03 at 22:03 +0400, Sergei Shtylyov wrote:
> That's the way the cookie crumbles in Linux MTD for now. It's
> *always* detecting this by probing -- you only can say what [not] to
> probe.
You could hook it up to the chip drivers directly if you want, and
bypass the probe code. I'm not sure it's worth it.
--
dwmw2
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-07 14:47 ` David Woodhouse
@ 2007-06-07 15:32 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-07 15:32 UTC (permalink / raw)
To: David Woodhouse; +Cc: ppcdev, linux-mtd, Milton Miller
>> That's the way the cookie crumbles in Linux MTD for now. It's
>> *always* detecting this by probing -- you only can say what [not] to
>> probe.
>
> You could hook it up to the chip drivers directly if you want, and
> bypass the probe code. I'm not sure it's worth it.
In most cases it is probably not worth it. It is good
to hear that the option to bypass the probe if needed
is available though.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-02 4:30 [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Milton Miller
2007-06-02 7:39 ` Benjamin Herrenschmidt
@ 2007-06-02 8:53 ` Segher Boessenkool
2007-06-03 16:22 ` Sergei Shtylyov
2007-06-03 17:29 ` Sergei Shtylyov
2007-06-04 19:40 ` Mark A. Greer
3 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-02 8:53 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
> I think "direct-mapped" as compatible is a bit too broad or vague.
>
> The compatible is supposed to be useable to find and match a driver
> without regard to the name of the node. Perhaps direct-mapped-rom?
> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
"actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems
like a good start.
> Actually, looking back at your device tree {1], your list several
> properties for flash, including bank-width and partition names.
> Perhaps first compatible should be direct-mapped-partitioned-flash,
> direct-mapped-partitioned-rom, direct-mapped-rom (to me a
> direct-mapped-rom driver would expose one section of address space
> read-only). I'm assuming that your driver for this "direct-mapped"
> device will look at these properties from the of device node and
> call the mtd layer somewhat directly with their contents.
People here tried to create a generic "flash" device binding.
It didn't work out (part of the problem is its scope was way
too big; another problem is it was too Linux-mtd specific).
Now since the probing is done in platform-specific code here,
you don't *need* an "official" binding -- just get your
"compatible" prop right so you can correctly probe the device
node, and then maybe add some node-specific properties if you
need them.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-02 8:53 ` Segher Boessenkool
@ 2007-06-03 16:22 ` Sergei Shtylyov
2007-06-03 17:40 ` Segher Boessenkool
2007-06-03 21:12 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 16:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
Hello.
Segher Boessenkool wrote:
>>I think "direct-mapped" as compatible is a bit too broad or vague.
>>The compatible is supposed to be useable to find and match a driver
>>without regard to the name of the node. Perhaps direct-mapped-rom?
>>(as opossed to a direct-mapped-ram, sram, or some width flash bank).
> "actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems
> like a good start.
No, it doesn't -- since that info is almost *absolutely* useless (the only
exception is "cfi") in the context of Linux MTD subsys.
Please, try to understand that knowing that chip is CFI compatible in
itself doesn't yet guarantee that you can access the chip -- it all depends on
its mapping to the real physical address range, therefore this group IMO
cannot even constitute a valid "compatible" property.
>>Actually, looking back at your device tree {1], your list several
>>properties for flash, including bank-width and partition names.
>>Perhaps first compatible should be direct-mapped-partitioned-flash,
>>direct-mapped-partitioned-rom, direct-mapped-rom (to me a
>>direct-mapped-rom driver would expose one section of address space
>>read-only). I'm assuming that your driver for this "direct-mapped"
>>device will look at these properties from the of device node and
>>call the mtd layer somewhat directly with their contents.
> People here tried to create a generic "flash" device binding.
> It didn't work out (part of the problem is its scope was way
> too big; another problem is it was too Linux-mtd specific).
And that's why its worked, and the abstaractly "correct" scheme wouldn't have.
> Now since the probing is done in platform-specific code here,
> you don't *need* an "official" binding -- just get your
> "compatible" prop right so you can correctly probe the device
> node, and then maybe add some node-specific properties if you
> need them.
I wonder what are you trying to get us to do: directly call stuff from
drivers/mtd/ or what (that's especially starnge because we now have an OF
driver for simply mapped NOR flashes)?
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 16:22 ` Sergei Shtylyov
@ 2007-06-03 17:40 ` Segher Boessenkool
2007-06-03 18:31 ` Sergei Shtylyov
2007-06-03 21:12 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 17:40 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>
>>> The compatible is supposed to be useable to find and match a driver
>>> without regard to the name of the node. Perhaps direct-mapped-rom?
>>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>
>> "actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems
>> like a good start.
>
> No, it doesn't -- since that info is almost *absolutely* useless
> (the only exception is "cfi") in the context of Linux MTD subsys.
> Please, try to understand that knowing that chip is CFI compatible
> in itself doesn't yet guarantee that you can access the chip -- it all
> depends on its mapping to the real physical address range, therefore
> this group IMO cannot even constitute a valid "compatible" property.
You obviously completely misunderstand the semantics
of the "compatible" property.
>> People here tried to create a generic "flash" device binding.
>> It didn't work out (part of the problem is its scope was way
>> too big; another problem is it was too Linux-mtd specific).
>
> And that's why its worked, and the abstaractly "correct" scheme
> wouldn't have.
Ha. Ha. Ha. Great joke :-)
>> Now since the probing is done in platform-specific code here,
>> you don't *need* an "official" binding -- just get your
>> "compatible" prop right so you can correctly probe the device
>> node, and then maybe add some node-specific properties if you
>> need them.
>
> I wonder what are you trying to get us to do: directly call stuff
> from drivers/mtd/ or what (that's especially starnge because we now
> have an OF driver for simply mapped NOR flashes)?
I am pointing out how to do a flash node in a platform-
specific way, in platform-specific code, since there is
no working "generic" way yet (and very likely there will
never be).
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 17:40 ` Segher Boessenkool
@ 2007-06-03 18:31 ` Sergei Shtylyov
2007-06-03 18:44 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 18:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>>>> The compatible is supposed to be useable to find and match a driver
>>>> without regard to the name of the node. Perhaps direct-mapped-rom?
>>>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>>> "actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems
>>> like a good start.
>> No, it doesn't -- since that info is almost *absolutely* useless
>> (the only exception is "cfi") in the context of Linux MTD subsys.
>> Please, try to understand that knowing that chip is CFI compatible
>> in itself doesn't yet guarantee that you can access the chip -- it all
>> depends on its mapping to the real physical address range, therefore
>> this group IMO cannot even constitute a valid "compatible" property.
> You obviously completely misunderstand the semantics
> of the "compatible" property.
Oh well, on the chip level, your "compatible" prop would be correct. But
that only means we need another level representating the flash mapping for
which the chip node would be a child... That seems a viable representation but
it would certainly complicate things Linux-wise.
>>> People here tried to create a generic "flash" device binding.
>>> It didn't work out (part of the problem is its scope was way
>>> too big; another problem is it was too Linux-mtd specific).
>> And that's why its worked, and the abstaractly "correct" scheme
>> wouldn't have.
> Ha. Ha. Ha. Great joke :-)
/me bows
>>> Now since the probing is done in platform-specific code here,
>>> you don't *need* an "official" binding -- just get your
>>> "compatible" prop right so you can correctly probe the device
>>> node, and then maybe add some node-specific properties if you
>>> need them.
>> I wonder what are you trying to get us to do: directly call stuff
>> from drivers/mtd/ or what (that's especially starnge because we now
>> have an OF driver for simply mapped NOR flashes)?
> I am pointing out how to do a flash node in a platform-
> specific way, in platform-specific code, since there is
I don't thing that confining the "bloody" MTD details into platform code
would be an acceptable solution.
> no working "generic" way yet (and very likely there will
> never be).
There is something working, at least Linux-generic.
However, the MTD device node was certainly misplaced my me, and probably
oversimplified too -- that's the cost one usually pays when he has to think
something up and to fit it into existing scheme in a limited time. :-<
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:31 ` Sergei Shtylyov
@ 2007-06-03 18:44 ` Segher Boessenkool
2007-06-03 19:13 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 18:44 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
>> You obviously completely misunderstand the semantics
>> of the "compatible" property.
>
> Oh well, on the chip level, your "compatible" prop would be correct.
This has nothing to do with a "chip level", it is plain and
simply the most basic device tree stuff.
[rest snipped]
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:44 ` Segher Boessenkool
@ 2007-06-03 19:13 ` Sergei Shtylyov
2007-06-03 19:56 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 19:13 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>> You obviously completely misunderstand the semantics
>>> of the "compatible" property.
>> Oh well, on the chip level, your "compatible" prop would be correct.
> This has nothing to do with a "chip level", it is plain and
> simply the most basic device tree stuff.
If it was as "plain and simple" as you say, there would be nothing to
argue about. What we ended up with is 2 or 3 level hierarchy of nodes which
doesn't at all seem to be such simple (considering the fact that what's
covered by a the simple "bank-width" property could be represented by several
combinations of interleaved flash chips). So, what you wanted us to do was
either substantially redesign Linux MTD subsys to fit it into that model
(either that or over-engineer the physmap_of driver to gather that kind of
information from the multiple "chip" subnodes). Guess how well would that
have been accepted even if we had time to do that...
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 19:13 ` Sergei Shtylyov
@ 2007-06-03 19:56 ` Segher Boessenkool
2007-06-03 20:26 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 19:56 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
>>>> You obviously completely misunderstand the semantics
>>>> of the "compatible" property.
>
>>> Oh well, on the chip level, your "compatible" prop would be
>>> correct.
>
>> This has nothing to do with a "chip level", it is plain and
>> simply the most basic device tree stuff.
>
> If it was as "plain and simple" as you say, there would be nothing
> to argue about.
There isn't as far as I am concerned; the purpose and
meaning of the "compatible" property, as well as of any
other standard OF properties, is clear.
> What we ended up with is 2 or 3 level hierarchy of nodes which doesn't
> at all seem to be such simple (considering the fact that what's
> covered by a the simple "bank-width" property could be represented by
> several combinations of interleaved flash chips).
Yes, the more complex (and sometimes insane) ways that
flash chips are connected to systems can be really hard
to describe properly. Which is why I don't even want
to make a "binding" for it (yet). It seems easy enough
to do this for single flash chips (possibly direct-mapped)
though.
> So, what you wanted us to do was either substantially redesign Linux
> MTD subsys to fit it into that model
Nah. The current MTD model has some issues of course,
but that is a separate problem.
> (either that or over-engineer the physmap_of driver to gather that
> kind of information from the multiple "chip" subnodes).
I would say it is overengineered already. It shouldn't
try to be a general solution for all possible cases since
it has no hope of achieving that. Get the simple cases
(that actually are used in real life) right, first.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 19:56 ` Segher Boessenkool
@ 2007-06-03 20:26 ` Sergei Shtylyov
2007-06-04 8:07 ` Segher Boessenkool
2007-06-07 15:00 ` David Woodhouse
0 siblings, 2 replies; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 20:26 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>>>> You obviously completely misunderstand the semantics
>>>>> of the "compatible" property.
>>>> Oh well, on the chip level, your "compatible" prop would be correct.
>>> This has nothing to do with a "chip level", it is plain and
>>> simply the most basic device tree stuff.
>> If it was as "plain and simple" as you say, there would be nothing
>> to argue about.
> There isn't as far as I am concerned; the purpose and
> meaning of the "compatible" property, as well as of any
> other standard OF properties, is clear.
Erm, concerning matching those with drivers it wasn't as clear that those
props aren't the same as driver names b/c of the follwing passage in Generic
Names:
"It is possible that the operating system will find a driver matching the
generic name, and that said driver will not be the correct one. However, this
is not a new problem, because generic names have already been used in the past
for built-in devices. Consequently, an operating system that does not already
have a mechanism for resolving or avoiding such false matches is likely to
have problems eventually, with or without the proliferation of generic names.
The following suggests some possible techniques for dealing with such false
generic matches.
a) In collections of OS drivers, avoid the use of generic names for the
drivers themselves. For example, it is generally unwise to name a driver
ethernet, since there are many different ethernet adapters with different
programming models. Using the generic name ethernet to identify only one such
driver is presumptuous.
b) Separate the OS's name spaces for drivers for real hardware devices and
pseudodrivers (collections of support routines that are used by real drivers).
Some operating systems load such pseudo-drivers using a mechanism similar to
the mechanism used for real drivers. Pseudo drivers often perform generic
functions that apply equally well to, for example, all ethernet adapters,
independent of their low-level programming models. Consequently, it is
reasonable to use generic names (e.g. ethernet) for such pseudodrivers.
Separating the name spaces of real drivers and pseudo-drivers avoids false
matches from generic device names to generic psuedo-driver names.
c) Make the OS's driver search mechanism depend upon the device's parent. In
other words, separate the OS's driver name spaces so that drivers for devices
that attach to, for example, PCI bus can be distinguished from those that
attach to, for example, ISA bus. This reduces the range over which false
matches can occur.
d) For cases where false matches are unavoidable (for example, if there is an
existing driver with a generic name that must be retained for backwards
compatibility) allow the drivers that can be incorrectly matched the
possibility of rejecting the match. One technique for doing so is to for the
driver to inspect the compatible property to ensure that it is appropriate.
Another common technique is to have the generic driver probe the hardware to
see if it behaves as expected (although this technique can cause problems)."
Well, I've already pointed that out in the past...
>> What we ended up with is 2 or 3 level hierarchy of nodes which doesn't
>> at all seem to be such simple (considering the fact that what's
>> covered by a the simple "bank-width" property could be represented by
>> several combinations of interleaved flash chips).
> Yes, the more complex (and sometimes insane) ways that
> flash chips are connected to systems can be really hard
> to describe properly. Which is why I don't even want
> to make a "binding" for it (yet). It seems easy enough
Neither do we. :-)
> to do this for single flash chips (possibly direct-mapped)
> though.
Erm, FSL boards seem to generally have dual 16-bit NOR flash chips
interleaved -- and that's seems quite a common case, not only in PPC world.
Perhaps... those interleaved chips could really be merged (abstracted)
into a single one, with the bus width being a sum of two?
>> (either that or over-engineer the physmap_of driver to gather that
>> kind of information from the multiple "chip" subnodes).
> I would say it is overengineered already. It shouldn't
> try to be a general solution for all possible cases since
> it has no hope of achieving that.
It's not trying to be such a general solution, it's just trying to handle
all the cases of simply-mapped NOR flashes, just like its non-OF counterpart does.
> Get the simple cases
> (that actually are used in real life) right, first.
We pursued this task exactly. Get it working, quick. :-)
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 20:26 ` Sergei Shtylyov
@ 2007-06-04 8:07 ` Segher Boessenkool
2007-06-04 13:34 ` Sergei Shtylyov
2007-06-07 15:00 ` David Woodhouse
1 sibling, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-04 8:07 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
>>>> This has nothing to do with a "chip level", it is plain and
>>>> simply the most basic device tree stuff.
>
>>> If it was as "plain and simple" as you say, there would be
>>> nothing to argue about.
>
>> There isn't as far as I am concerned; the purpose and
>> meaning of the "compatible" property, as well as of any
>> other standard OF properties, is clear.
>
> Erm, concerning matching those with drivers it wasn't as clear that
> those props aren't the same as driver names b/c of the follwing
> passage in Generic Names:
[huge snip]
Please point out the exact passage you don't understand, and
what you don't understand about it, if you want any help.
>> Yes, the more complex (and sometimes insane) ways that
>> flash chips are connected to systems can be really hard
>> to describe properly. Which is why I don't even want
>> to make a "binding" for it (yet). It seems easy enough
>
> Neither do we. :-)
>
>> to do this for single flash chips (possibly direct-mapped)
>> though.
>
> Erm, FSL boards seem to generally have dual 16-bit NOR flash chips
> interleaved -- and that's seems quite a common case, not only in PPC
> world.
It's not all that common; I can see why it would be used on
flash controllers that handle a 32-bit bus only.
> Perhaps... those interleaved chips could really be merged
> (abstracted) into a single one, with the bus width being a sum of two?
Perhaps. It is a nasty situation, it'll take long hard
thinking to come up with a reasonably good solution.
>> Get the simple cases
>> (that actually are used in real life) right, first.
>
> We pursued this task exactly. Get it working, quick. :-)
That is something *TOTALLY DIFFERENT* and quite a bad plan
IMNSHO.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-04 8:07 ` Segher Boessenkool
@ 2007-06-04 13:34 ` Sergei Shtylyov
0 siblings, 0 replies; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-04 13:34 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
Hello.
Segher Boessenkool wrote:
>>>>> This has nothing to do with a "chip level", it is plain and
>>>>> simply the most basic device tree stuff.
>>>> If it was as "plain and simple" as you say, there would be
>>>> nothing to argue about.
>>> There isn't as far as I am concerned; the purpose and
>>> meaning of the "compatible" property, as well as of any
>>> other standard OF properties, is clear.
>> Erm, concerning matching those with drivers it wasn't as clear that
>> those props aren't the same as driver names b/c of the follwing
>> passage in Generic Names:
> [huge snip]
> Please point out the exact passage you don't understand, and
> what you don't understand about it, if you want any help.
Ah, nevermind... It was too late in the Sunday evening. :-)
>>> Yes, the more complex (and sometimes insane) ways that
>>> flash chips are connected to systems can be really hard
>>> to describe properly. Which is why I don't even want
>>> to make a "binding" for it (yet). It seems easy enough
>> Neither do we. :-)
>>> to do this for single flash chips (possibly direct-mapped)
>>> though.
>> Erm, FSL boards seem to generally have dual 16-bit NOR flash chips
>> interleaved -- and that's seems quite a common case, not only in PPC
>> world.
> It's not all that common; I can see why it would be used on
> flash controllers that handle a 32-bit bus only.
OK, maybe it's just we, embedded guys, that comes to see only such cheapo
boards. :-)
>> Perhaps... those interleaved chips could really be merged
>> (abstracted) into a single one, with the bus width being a sum of two?
> Perhaps. It is a nasty situation, it'll take long hard
> thinking to come up with a reasonably good solution.
I hoped to get some hints from the linux-mtd list as well...
>>> Get the simple cases
>>> (that actually are used in real life) right, first.
>> We pursued this task exactly. Get it working, quick. :-)
> That is something *TOTALLY DIFFERENT* and quite a bad plan
> IMNSHO.
I haven't considered 2 inteleaved 16-bit CFI NOR flashes a complex case so
far, sorry. :-) And that's what I had on my board. Prior to my acquaintance
with the device trees, this was indeed a no-brainer. :-)
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 20:26 ` Sergei Shtylyov
2007-06-04 8:07 ` Segher Boessenkool
@ 2007-06-07 15:00 ` David Woodhouse
2007-06-07 15:55 ` Segher Boessenkool
1 sibling, 1 reply; 81+ messages in thread
From: David Woodhouse @ 2007-06-07 15:00 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
On Mon, 2007-06-04 at 00:26 +0400, Sergei Shtylyov wrote:
> Erm, FSL boards seem to generally have dual 16-bit NOR flash chips
> interleaved -- and that's seems quite a common case, not only in PPC world.
Yes, it's something we've seen quite frequently. It's a common way of
improving read/write/erase speed.
> Perhaps... those interleaved chips could really be merged (abstracted)
> into a single one, with the bus width being a sum of two?
That's how Linux deals with it, as I'm sure you're aware. Other
operating systems do likewise. If two 'separate' flash chips hold
alternate bytes of a given address range, you really don't gain much by
representing them as two separate devices to the system.
Any representation of flash devices in the device-tree should ideally
have 'bus width' and 'interleave' properties to contain this
information.
The 'bus width' cannot necessarily be inferred, especially where a given
bus can be configured to allow multiple sizes of access. It's purely a
function of how the flash chips are wired up. That's why we actually
call it 'bank width', not 'bus width' in the Linux code.
--
dwmw2
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-07 15:00 ` David Woodhouse
@ 2007-06-07 15:55 ` Segher Boessenkool
2007-06-07 16:05 ` David Woodhouse
` (2 more replies)
0 siblings, 3 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-07 15:55 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linux-mtd, Milton Miller
> Any representation of flash devices in the device-tree should ideally
> have 'bus width' and 'interleave' properties to contain this
> information.
>
> The 'bus width' cannot necessarily be inferred, especially where a
> given
> bus can be configured to allow multiple sizes of access. It's purely a
> function of how the flash chips are wired up. That's why we actually
> call it 'bank width', not 'bus width' in the Linux code.
Ah, "bank width" as in "bus width" per chip select. I see.
So I think the best thing to have would be
compatible "cfi-flash"
bank-width like you said
device-width width of a single flash device
reg complete address range of this thing
and then the Linux OF CFI flash code / MTD code just keeps
on probing devices from that address range until it has it
filled.
Sounds good / comments / anything I missed?
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-07 15:55 ` Segher Boessenkool
@ 2007-06-07 16:05 ` David Woodhouse
2007-06-07 16:46 ` Segher Boessenkool
2007-06-12 4:44 ` David Gibson
2007-06-15 4:14 ` David Gibson
2 siblings, 1 reply; 81+ messages in thread
From: David Woodhouse @ 2007-06-07 16:05 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
On Thu, 2007-06-07 at 17:55 +0200, Segher Boessenkool wrote:
> > Any representation of flash devices in the device-tree should ideally
> > have 'bus width' and 'interleave' properties to contain this
> > information.
> >
> > The 'bus width' cannot necessarily be inferred, especially where a
> > given
> > bus can be configured to allow multiple sizes of access. It's purely a
> > function of how the flash chips are wired up. That's why we actually
> > call it 'bank width', not 'bus width' in the Linux code.
>
> Ah, "bank width" as in "bus width" per chip select. I see.
>
> So I think the best thing to have would be
>
> compatible "cfi-flash"
> bank-width like you said
> device-width width of a single flash device
> reg complete address range of this thing
>
> and then the Linux OF CFI flash code / MTD code just keeps
> on probing devices from that address range until it has it
> filled.
>
> Sounds good / comments / anything I missed?
That seems reasonable. I would personally have used 'interleave' to give
the number of devices interleaved together into the specified
bank-width, rather than specifying device-width. People might get
confused by device-width because many devices can actually be _either_
x16 or x8. But I don't care much. Linux will only be using the
bank-width anyway.
The other thing that might be seen in the 'compatible' property would be
'jedec-flash', and in that case perhaps we also want properties for the
manufacturer and device ident? Linux wouldn't necessarily care about
them, but other operating systems might.
And we also need partition information to get through somehow, in the
cases where the firmware knows it.
--
dwmw2
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-07 16:05 ` David Woodhouse
@ 2007-06-07 16:46 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-07 16:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linux-mtd, Milton Miller
>> So I think the best thing to have would be
>>
>> compatible "cfi-flash"
>> bank-width like you said
>> device-width width of a single flash device
>> reg complete address range of this thing
>>
>> and then the Linux OF CFI flash code / MTD code just keeps
>> on probing devices from that address range until it has it
>> filled.
>>
>> Sounds good / comments / anything I missed?
>
> That seems reasonable. I would personally have used 'interleave' to
> give
> the number of devices interleaved together into the specified
> bank-width, rather than specifying device-width.
I think "device-width" is much clearer -- from the name
"interleave" you cannot tell that it actually means
"number-of-interleaved-devices-in-this-bank".
> People might get
> confused by device-width because many devices can actually be _either_
> x16 or x8.
Well after it has been soldered down to the board, it's
pretty much fixed what the device's bus width is ;-)
> But I don't care much. Linux will only be using the
> bank-width anyway.
So it can reliably detect interleaving itself?
I'd like "device-width" to be a required property still,
for the benefit of non-Linux device tree users, or just
in case.
> The other thing that might be seen in the 'compatible' property would
> be
> 'jedec-flash',
I don't want to deal with that yet, one thing at a time,
and CFI flash it is now. JEDEC is a bit hairier.
> and in that case perhaps we also want properties for the
> manufacturer and device ident?
Certainly, since they cannot be reliably probed.
> Linux wouldn't necessarily care about
> them, but other operating systems might.
>
> And we also need partition information to get through somehow, in the
> cases where the firmware knows it.
A child node per partition I suppose, dunno.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-07 15:55 ` Segher Boessenkool
2007-06-07 16:05 ` David Woodhouse
@ 2007-06-12 4:44 ` David Gibson
2007-06-12 10:53 ` Segher Boessenkool
2007-06-15 4:14 ` David Gibson
2 siblings, 1 reply; 81+ messages in thread
From: David Gibson @ 2007-06-12 4:44 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, David Woodhouse, Milton Miller, linux-mtd
On Thu, Jun 07, 2007 at 05:55:44PM +0200, Segher Boessenkool wrote:
> > Any representation of flash devices in the device-tree should ideally
> > have 'bus width' and 'interleave' properties to contain this
> > information.
> >
> > The 'bus width' cannot necessarily be inferred, especially where a
> > given
> > bus can be configured to allow multiple sizes of access. It's purely a
> > function of how the flash chips are wired up. That's why we actually
> > call it 'bank width', not 'bus width' in the Linux code.
>
> Ah, "bank width" as in "bus width" per chip select. I see.
>
> So I think the best thing to have would be
>
> compatible "cfi-flash"
> bank-width like you said
> device-width width of a single flash device
> reg complete address range of this thing
>
> and then the Linux OF CFI flash code / MTD code just keeps
> on probing devices from that address range until it has it
> filled.
>
> Sounds good / comments / anything I missed?
Looks pretty sensible to me. Presumably the compatible property could
also have more specific entries for the particular chip type.
Of course, Ebony has flash which is JEDEC rather than CFI probed, so I
have an interest in a binding for that, too.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-12 4:44 ` David Gibson
@ 2007-06-12 10:53 ` Segher Boessenkool
2007-06-13 3:16 ` David Gibson
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-12 10:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
>> So I think the best thing to have would be
>>
>> compatible "cfi-flash"
>> bank-width like you said
>> device-width width of a single flash device
>> reg complete address range of this thing
>>
>> and then the Linux OF CFI flash code / MTD code just keeps
>> on probing devices from that address range until it has it
>> filled.
>>
>> Sounds good / comments / anything I missed?
>
> Looks pretty sensible to me.
Great!
> Presumably the compatible property could
> also have more specific entries for the particular chip type.
Yes, of course.
> Of course, Ebony has flash which is JEDEC rather than CFI probed, so I
> have an interest in a binding for that, too.
For JEDEC flash, you probably want extra properties
for manufacturing ID and chip ID. Also, you need
to describe the block sizes in some way (on CFI, this
can be probed; on JEDEC, not). Anything else?
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-12 10:53 ` Segher Boessenkool
@ 2007-06-13 3:16 ` David Gibson
2007-06-13 5:05 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: David Gibson @ 2007-06-13 3:16 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
On Tue, Jun 12, 2007 at 12:53:36PM +0200, Segher Boessenkool wrote:
> >> So I think the best thing to have would be
> >>
> >> compatible "cfi-flash"
> >> bank-width like you said
> >> device-width width of a single flash device
> >> reg complete address range of this thing
> >>
> >> and then the Linux OF CFI flash code / MTD code just keeps
> >> on probing devices from that address range until it has it
> >> filled.
> >>
> >> Sounds good / comments / anything I missed?
> >
> > Looks pretty sensible to me.
>
> Great!
>
> > Presumably the compatible property could
> > also have more specific entries for the particular chip type.
>
> Yes, of course.
>
> > Of course, Ebony has flash which is JEDEC rather than CFI probed, so I
> > have an interest in a binding for that, too.
>
> For JEDEC flash, you probably want extra properties
> for manufacturing ID and chip ID. Also, you need
> to describe the block sizes in some way (on CFI, this
> can be probed; on JEDEC, not). Anything else?
Hrm. At the moment it appears to work without supplying this
information for the Ebony flash... I wonder if there are defaults in
the mtd layer or something.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-13 3:16 ` David Gibson
@ 2007-06-13 5:05 ` Segher Boessenkool
2007-06-13 6:11 ` David Gibson
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-13 5:05 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
>>> Of course, Ebony has flash which is JEDEC rather than CFI probed, so
>>> I
>>> have an interest in a binding for that, too.
>>
>> For JEDEC flash, you probably want extra properties
>> for manufacturing ID and chip ID. Also, you need
>> to describe the block sizes in some way (on CFI, this
>> can be probed; on JEDEC, not). Anything else?
>
> Hrm. At the moment it appears to work without supplying this
> information for the Ebony flash... I wonder if there are defaults in
> the mtd layer or something.
MTD does a lot of heuristic probing. It is pretty good,
but it would be nice if you could skip that and hand it
the exact values it needs. Also, this information should
be in the device tree no matter what, even if Linux
doesn't use it yet ;-)
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-13 5:05 ` Segher Boessenkool
@ 2007-06-13 6:11 ` David Gibson
2007-06-13 9:10 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: David Gibson @ 2007-06-13 6:11 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
On Wed, Jun 13, 2007 at 07:05:31AM +0200, Segher Boessenkool wrote:
> >>> Of course, Ebony has flash which is JEDEC rather than CFI probed, so
> >>> I
> >>> have an interest in a binding for that, too.
> >>
> >> For JEDEC flash, you probably want extra properties
> >> for manufacturing ID and chip ID. Also, you need
> >> to describe the block sizes in some way (on CFI, this
> >> can be probed; on JEDEC, not). Anything else?
> >
> > Hrm. At the moment it appears to work without supplying this
> > information for the Ebony flash... I wonder if there are defaults in
> > the mtd layer or something.
>
> MTD does a lot of heuristic probing. It is pretty good,
> but it would be nice if you could skip that and hand it
> the exact values it needs. Also, this information should
> be in the device tree no matter what, even if Linux
> doesn't use it yet ;-)
I agree. Of course, this means figuring out what the values actually
are for Ebony. I presently have no idea, since the heuristic probing
appears to work without problem.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-13 6:11 ` David Gibson
@ 2007-06-13 9:10 ` Segher Boessenkool
2007-06-15 4:12 ` David Gibson
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-13 9:10 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
>> MTD does a lot of heuristic probing. It is pretty good,
>> but it would be nice if you could skip that and hand it
>> the exact values it needs. Also, this information should
>> be in the device tree no matter what, even if Linux
>> doesn't use it yet ;-)
>
> I agree. Of course, this means figuring out what the values actually
> are for Ebony. I presently have no idea, since the heuristic probing
> appears to work without problem.
Doesn't it show it in sysfs, or in the dmesg at least?
Maybe some other important stuff is there, too.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-13 9:10 ` Segher Boessenkool
@ 2007-06-15 4:12 ` David Gibson
2007-06-15 11:22 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: David Gibson @ 2007-06-15 4:12 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
On Wed, Jun 13, 2007 at 11:10:42AM +0200, Segher Boessenkool wrote:
> >> MTD does a lot of heuristic probing. It is pretty good,
> >> but it would be nice if you could skip that and hand it
> >> the exact values it needs. Also, this information should
> >> be in the device tree no matter what, even if Linux
> >> doesn't use it yet ;-)
> >
> > I agree. Of course, this means figuring out what the values actually
> > are for Ebony. I presently have no idea, since the heuristic probing
> > appears to work without problem.
>
> Doesn't it show it in sysfs, or in the dmesg at least?
> Maybe some other important stuff is there, too.
Not as far as I can tell. Only dmesg information I can see is:
1ff800000.large-fla: Found 1 x8 devices at 0x0 in 8-bit bank
1ff800000.large-fla: Found 1 x8 devices at 0x200000 in 8-bit bank
number of JEDEC chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code
brokenness.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-15 4:12 ` David Gibson
@ 2007-06-15 11:22 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-15 11:22 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
>>> I agree. Of course, this means figuring out what the values actually
>>> are for Ebony. I presently have no idea, since the heuristic probing
>>> appears to work without problem.
>>
>> Doesn't it show it in sysfs, or in the dmesg at least?
>> Maybe some other important stuff is there, too.
>
> Not as far as I can tell. Only dmesg information I can see is:
>
> 1ff800000.large-fla: Found 1 x8 devices at 0x0 in 8-bit bank
> 1ff800000.large-fla: Found 1 x8 devices at 0x200000 in 8-bit bank
> number of JEDEC chips: 2
> cfi_cmdset_0002: Disabling erase-suspend-program due to code
> brokenness.
Hrm, nothing in sysfs either?
Anyway, from jedec_probe.c:
cfi->mfr = jedec_read_mfr(map, base, cfi);
cfi->id = jedec_read_id(map, base, cfi);
DEBUG(MTD_DEBUG_LEVEL3,
"Search for id:(%02x %02x) interleave(%d)
type(%d)\n",
cfi->mfr, cfi->id, cfi_interleave(cfi),
cfi->device_type);
so you'll could enable some more debugging output.
Or, open the case, look at the chips, and look it up
in the big table at the start of that file (or the
relevant datasheet).
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-07 15:55 ` Segher Boessenkool
2007-06-07 16:05 ` David Woodhouse
2007-06-12 4:44 ` David Gibson
@ 2007-06-15 4:14 ` David Gibson
2007-06-15 8:42 ` Segher Boessenkool
2 siblings, 1 reply; 81+ messages in thread
From: David Gibson @ 2007-06-15 4:14 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, David Woodhouse, Milton Miller, linux-mtd
On Thu, Jun 07, 2007 at 05:55:44PM +0200, Segher Boessenkool wrote:
> > Any representation of flash devices in the device-tree should ideally
> > have 'bus width' and 'interleave' properties to contain this
> > information.
> >
> > The 'bus width' cannot necessarily be inferred, especially where a
> > given
> > bus can be configured to allow multiple sizes of access. It's purely a
> > function of how the flash chips are wired up. That's why we actually
> > call it 'bank width', not 'bus width' in the Linux code.
>
> Ah, "bank width" as in "bus width" per chip select. I see.
>
> So I think the best thing to have would be
>
> compatible "cfi-flash"
> bank-width like you said
> device-width width of a single flash device
> reg complete address range of this thing
>
> and then the Linux OF CFI flash code / MTD code just keeps
> on probing devices from that address range until it has it
> filled.
>
> Sounds good / comments / anything I missed?
Slight revision suggestion. Can we make 'device-width' optional, with
the default value being equal to the bank-width?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-15 4:14 ` David Gibson
@ 2007-06-15 8:42 ` Segher Boessenkool
2007-06-15 8:47 ` David Woodhouse
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-15 8:42 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
>> So I think the best thing to have would be
>>
>> compatible "cfi-flash"
>> bank-width like you said
>> device-width width of a single flash device
>> reg complete address range of this thing
>>
>> and then the Linux OF CFI flash code / MTD code just keeps
>> on probing devices from that address range until it has it
>> filled.
>>
>> Sounds good / comments / anything I missed?
>
> Slight revision suggestion. Can we make 'device-width' optional, with
> the default value being equal to the bank-width?
Yes, certainly. Or, the other way around I like better
("bank-width" optional).
I didn't say all these properties were required anyway,
this is still a very rough draft.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-15 8:42 ` Segher Boessenkool
@ 2007-06-15 8:47 ` David Woodhouse
2007-06-15 8:59 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: David Woodhouse @ 2007-06-15 8:47 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller, David Gibson
On Fri, 2007-06-15 at 10:42 +0200, Segher Boessenkool wrote:
> Yes, certainly. Or, the other way around I like better
> ("bank-width" optional).
No, we need bank-width. It's device-width which can be optional.
--
dwmw2
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-15 8:47 ` David Woodhouse
@ 2007-06-15 8:59 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-15 8:59 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linux-mtd, Milton Miller, David Gibson
>> Yes, certainly. Or, the other way around I like better
>> ("bank-width" optional).
>
> No, we need bank-width. It's device-width which can be optional.
One is defaulted to the other so it doesn't really
matter _which_ you make optional, the OS device driver
can always get both values. For the device tree, it
seems more natural to have "device-width" a required
property. Feel free to disagree but I'd like to hear
arguments if so :-)
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 16:22 ` Sergei Shtylyov
2007-06-03 17:40 ` Segher Boessenkool
@ 2007-06-03 21:12 ` Benjamin Herrenschmidt
2007-06-04 8:11 ` Segher Boessenkool
2007-06-04 12:41 ` Sergei Shtylyov
1 sibling, 2 replies; 81+ messages in thread
From: Benjamin Herrenschmidt @ 2007-06-03 21:12 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
On Sun, 2007-06-03 at 20:22 +0400, Sergei Shtylyov wrote:
>
> No, it doesn't -- since that info is almost *absolutely* useless
> (the only
> exception is "cfi") in the context of Linux MTD subsys.
> Please, try to understand that knowing that chip is CFI compatible
> in
> itself doesn't yet guarantee that you can access the chip -- it all
> depends on
> its mapping to the real physical address range, therefore this group
> IMO
> cannot even constitute a valid "compatible" property.
You make no sense to me. It's like saying that knowing that a 8250 chip
on ISA cannot be accessed if you don't know it's IO ports so it
shouldn't say "8250" in compatible property ?!?!?!?
Also, whatever shortcomings of the linux MTD drivers are totally
irrelevant to what is correct to have in a device-tree. While we do
tailor our device-tree specification around linux needs in most cases,
there are cases like this one where common sense should be enough to
understand that it's not because the linux MTD subsystem, as of today,
cannot be told what programming interface to use, that we shouldn't
provide that information in the tree.
Regarding physical address ranges for the flash mapping, I suppose the
best is to define a property for flash chips for it.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 21:12 ` Benjamin Herrenschmidt
@ 2007-06-04 8:11 ` Segher Boessenkool
2007-06-04 13:16 ` Sergei Shtylyov
2007-06-04 12:41 ` Sergei Shtylyov
1 sibling, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-04 8:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-mtd, Milton Miller
> Regarding physical address ranges for the flash mapping, I suppose the
> best is to define a property for flash chips for it.
There is, namely "reg". How to best describe flash chips
interleaved on the bus is still an open problem. And things
like combining two sequential in address space flash chips
into a virtual one, or describing flash "partitions" doesn't
belong in the device tree at all; it is a policy thing, not
a hardware thing.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-04 8:11 ` Segher Boessenkool
@ 2007-06-04 13:16 ` Sergei Shtylyov
0 siblings, 0 replies; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-04 13:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linux-mtd, Milton Miller, linuxppc-dev
Hello.
Segher Boessenkool wrote:
>> Regarding physical address ranges for the flash mapping, I suppose the
>> best is to define a property for flash chips for it.
> There is, namely "reg". How to best describe flash chips
> interleaved on the bus is still an open problem. And things
> like combining two sequential in address space flash chips
> into a virtual one, or describing flash "partitions" doesn't
> belong in the device tree at all; it is a policy thing, not
> a hardware thing.
Gah, it's becoming worse and worse...
While I would agree with that argument, not having flash partition table
in the device tree makes things even more ugly -- as we *already* can't use
platform device to pass that info, we'll have to either force the user to
supply that via the kernel option, or add more kludgery to Linux/MTD. :-/
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 21:12 ` Benjamin Herrenschmidt
2007-06-04 8:11 ` Segher Boessenkool
@ 2007-06-04 12:41 ` Sergei Shtylyov
2007-06-04 14:49 ` Segher Boessenkool
1 sibling, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-04 12:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-mtd, Milton Miller
Hello.
Benjamin Herrenschmidt wrote:
>> No, it doesn't -- since that info is almost *absolutely* useless
>>(the only
>>exception is "cfi") in the context of Linux MTD subsys.
>> Please, try to understand that knowing that chip is CFI compatible in
>>itself doesn't yet guarantee that you can access the chip -- it all depends on
>>its mapping to the real physical address range, therefore this group IMO
>>cannot even constitute a valid "compatible" property.
> You make no sense to me. It's like saying that knowing that a 8250 chip
> on ISA cannot be accessed if you don't know it's IO ports so it
> shouldn't say "8250" in compatible property ?!?!?!?
No, it's a completely different case. Base address and even flash size
are not the only things that matter. There's bus width and interleave factors
that influence the access (and possibly, byte-swapping too, although this is
unlikely to happen in PPC world).
> Also, whatever shortcomings of the linux MTD drivers are totally
> irrelevant to what is correct to have in a device-tree. While we do
> tailor our device-tree specification around linux needs in most cases,
> there are cases like this one where common sense should be enough to
> understand that it's not because the linux MTD subsystem, as of today,
> cannot be told what programming interface to use, that we shouldn't
> provide that information in the tree.
We did provide it, in the form of probing hints ("probe-type" prop).
> Regarding physical address ranges for the flash mapping, I suppose the
> best is to define a property for flash chips for it.
Flash chips in themselves have little to do with how they are mapped to
the physical address space (considers the interleave factor), so that doesn't
seem a practical idea.
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-04 12:41 ` Sergei Shtylyov
@ 2007-06-04 14:49 ` Segher Boessenkool
2007-06-04 15:54 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-04 14:49 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
>> You make no sense to me. It's like saying that knowing that a 8250
>> chip
>> on ISA cannot be accessed if you don't know it's IO ports so it
>> shouldn't say "8250" in compatible property ?!?!?!?
>
> No, it's a completely different case. Base address and even flash
> size are not the only things that matter. There's bus width
Bus width is an (inherent) property of the _parent_
node. Device width is normally equal to that, and
if not, it is obvious from the device model.
Also, you need to know if the devices are byte-addressable
or only per natural unit; and even more importantly,
the same question for the flash bus.
> and interleave factors
Not a property of the flash chips really.
> that influence the access (and possibly, byte-swapping too, although
> this is unlikely to happen in PPC world).
Byte swapping? 1) This should _never_ be necessary,
just swap the data on the device itself, duh; 2) more
likely this would be determined by the flash bus, not
per flash device.
And, 3) why would you want to include this in the flash
binding while we don't yet have a reasonable overview
of in what circumstances byte swap is needed/used?
>> Also, whatever shortcomings of the linux MTD drivers are totally
>> irrelevant to what is correct to have in a device-tree. While we do
>> tailor our device-tree specification around linux needs in most cases,
>> there are cases like this one where common sense should be enough to
>> understand that it's not because the linux MTD subsystem, as of today,
>> cannot be told what programming interface to use, that we shouldn't
>> provide that information in the tree.
>
> We did provide it, in the form of probing hints ("probe-type" prop).
Which is 103% redundant. That same information (and
more!) is required in the "compatible" property, already.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-04 14:49 ` Segher Boessenkool
@ 2007-06-04 15:54 ` Sergei Shtylyov
0 siblings, 0 replies; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-04 15:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>> You make no sense to me. It's like saying that knowing that a 8250 chip
>>> on ISA cannot be accessed if you don't know it's IO ports so it
>>> shouldn't say "8250" in compatible property ?!?!?!?
>> No, it's a completely different case. Base address and even flash
>> size are not the only things that matter. There's bus width
> Bus width is an (inherent) property of the _parent_
> node. Device width is normally equal to that, and
> if not, it is obvious from the device model.
Eh... obvious? From the bus controller node? Maybe and maybe not. Those
are seem to be generally multifuntional and so don't have their "chip selects"
fixed to some kind of interface, i.e. it's selectable, as well as the bus
width even... at least it's so in my case (and nevertheless, the board has
interleaved flash, so it's not a matter of a bus width fixed to 32 bits as you
can see).
> Also, you need to know if the devices are byte-addressable
> or only per natural unit; and even more importantly,
> the same question for the flash bus.
>> and interleave factors
> Not a property of the flash chips really.
Who said it is?
>> that influence the access (and possibly, byte-swapping too, although
>> this is unlikely to happen in PPC world).
> Byte swapping? 1) This should _never_ be necessary,
> just swap the data on the device itself, duh;
Oh, I'm afraid that's only wishful thinking after having some real life
experience in bi-endian world. Luckily, the PPC world seems to be (at least
mostly) big-endian.
> 2) more likely this would be determined by the flash bus, not
> per flash device.
Indeed, by wiring the bus pins to flash pins. :-)
> And, 3) why would you want to include this in the flash
> binding while we don't yet have a reasonable overview
> of in what circumstances byte swap is needed/used?
This was just a real world example. I do hope PPC would never have to deal
with it, though...
>>> Also, whatever shortcomings of the linux MTD drivers are totally
>>> irrelevant to what is correct to have in a device-tree. While we do
>>> tailor our device-tree specification around linux needs in most cases,
>>> there are cases like this one where common sense should be enough to
>>> understand that it's not because the linux MTD subsystem, as of today,
>>> cannot be told what programming interface to use, that we shouldn't
>>> provide that information in the tree.
>> We did provide it, in the form of probing hints ("probe-type" prop).
> Which is 103% redundant. That same information (and
> more!) is required in the "compatible" property, already.
Yeah, but then we would have needed more than one node -- which I avoided
back then... well, I have cheated and mistaken. :-)
Anyway, the "rom" device node as it appeared in booting-without-of.txt
was based upon suggestions from Linux/MTD maintainer.
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-02 4:30 [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Milton Miller
2007-06-02 7:39 ` Benjamin Herrenschmidt
2007-06-02 8:53 ` Segher Boessenkool
@ 2007-06-03 17:29 ` Sergei Shtylyov
2007-06-03 17:45 ` Segher Boessenkool
2007-06-04 19:40 ` Mark A. Greer
3 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 17:29 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
Hello.
Milton Miller wrote:
>>Find the "rom" device for the prpmc2800 and create a device for it.
>>The device will be picked up by the code in
>>drivers/mtd/maps/physmap_of.c
>>and will setup MTD on that FLASH device.
> ...
>> /*
>>+ * Register a platform device for MTD.
>>+ */
>>+static int __init prpmc2800_register_mtd(void)
>>+{
>>+ struct device_node *np;
>>+
>>+ np = of_find_compatible_node(NULL, "rom", "direct-mapped");
>>+ of_platform_device_create(np, np->name, NULL);
>>+}
>>+arch_initcall(prpmc2800_register_mtd);
> I think "direct-mapped" as compatible is a bit too broad or vague.
It's actually not -- it means simple 1:1 address mapping (w/o explicit
byte-swapping and such).
> The compatible is supposed to be useable to find and match a driver
> without regard to the name of the node. Perhaps direct-mapped-rom?
> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
Note that we're matching by both "device_type" and "compatible".
> Actually, looking back at your device tree {1], your list several
> properties for flash, including bank-width and partition names.
> Perhaps first compatible should be direct-mapped-partitioned-flash,
> direct-mapped-partitioned-rom, direct-mapped-rom (to me a
> direct-mapped-rom driver would expose one section of address space
> read-only).
This would serve no purpose, as the driver that would catches all these is
signle one, drivers/mtd/maps/physmap_of.c...
> I'm assuming that your driver for this "direct-mapped"
> device will look at these properties from the of device node and
> call the mtd layer somewhat directly with their contents.
Yeah, it does.
> [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035858.html
> milton
> PS: I know you've posted this a few times. I'm just behind in
> my reading and replying :-).
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 17:29 ` Sergei Shtylyov
@ 2007-06-03 17:45 ` Segher Boessenkool
2007-06-03 18:18 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 17:45 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, Milton Miller
>> I think "direct-mapped" as compatible is a bit too broad or vague.
>
> It's actually not -- it means simple 1:1 address mapping (w/o
> explicit
> byte-swapping and such).
Which has nothing to do with "compatible"; instead,
it is implied by the parent node have a "ranges"
property. Or you can put some other property in
the flash node for all I care, if that seems
necessary for certain cases.
>> The compatible is supposed to be useable to find and match a driver
>> without regard to the name of the node. Perhaps direct-mapped-rom?
>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>
> Note that we're matching by both "device_type" and "compatible".
Which is wrong.
> This would serve no purpose, as the driver that would catches all
> these is
> signle one, drivers/mtd/maps/physmap_of.c...
With the current kernel version, perhaps. Did you check
out 2.6.28? Does it work with that?
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 17:45 ` Segher Boessenkool
@ 2007-06-03 18:18 ` Sergei Shtylyov
2007-06-03 18:43 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 18:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>> It's actually not -- it means simple 1:1 address mapping (w/o
>> explicit
>> byte-swapping and such).
> Which has nothing to do with "compatible"; instead,
> it is implied by the parent node have a "ranges"
No! It doesn't have anything to do with "ranges" of parent (don't even
know why it would). :-O
> property. Or you can put some other property in
> the flash node for all I care, if that seems
> necessary for certain cases.
Erm... it's *certainly* necessary to mark this somewhere.
>>> The compatible is supposed to be useable to find and match a driver
>>> without regard to the name of the node. Perhaps direct-mapped-rom?
That really depends on whether we choose to follow the Generic Names spec.
Even if we do, it does *not* preclude OS from using both props for the driver
selection.
>>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>> Note that we're matching by both "device_type" and "compatible".
> Which is wrong.
Why? And why then it's allowed to match by "device_type"? And why you
haven't complained at MPC5200 IDE driver which does the same (well, maybe you
have :-) or at PowerMac IDE driver which matches wither by "name" or
"device_type"? Well, quite a lot of drivers are doing this...
>> This would serve no purpose, as the driver that would catches all
>> these is signle one, drivers/mtd/maps/physmap_of.c...
> With the current kernel version, perhaps. Did you check
> out 2.6.28? Does it work with that?
For the simply mapped flashes, physmap_of will suffice, for more complex
cases, other driver will be needed. If you're hinting at the possibility that
MTD subsys will be substantially reworked -- I don't find that likely. If it
will -- well, bad luck. :-)
Anyway, reasonable suggestions on how to make MTD nodes more viable are
always welcome. I just haven't seen reasonable enough yet. ;-)
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:18 ` Sergei Shtylyov
@ 2007-06-03 18:43 ` Segher Boessenkool
2007-06-03 18:59 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 18:43 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
>>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>
>>> It's actually not -- it means simple 1:1 address mapping (w/o
>>> explicit
>>> byte-swapping and such).
>
>> Which has nothing to do with "compatible"; instead,
>> it is implied by the parent node have a "ranges"
>
> No! It doesn't have anything to do with "ranges" of parent (don't
> even know why it would). :-O
So learn about it please? "ranges" means exactly that:
child nodes' address space is direct mapped.
>> property. Or you can put some other property in
>> the flash node for all I care, if that seems
>> necessary for certain cases.
>
> Erm... it's *certainly* necessary to mark this somewhere.
Not if it's redundant information.
>>>> The compatible is supposed to be useable to find and match a driver
>>>> without regard to the name of the node. Perhaps direct-mapped-rom?
>
> That really depends on whether we choose to follow the Generic
> Names spec.
No, it doesn't. OF before the generic names recommended practice
was different only in that it had "name" be the most specific
of the device descriptions.
Also, it has already been decided to follow this recommended
practice. It would have been foolish not to, it being collected
wisdom by real-life implementations and all.
> Even if we do, it does *not* preclude OS from using both props for the
> driver selection.
An OS is *required* (erm, "supposed", if you like) to use
first "name", and then "compatible". An OS is not supposed
to use "device_type" or any other properties for device
matching.
>>> Note that we're matching by both "device_type" and "compatible".
>
>> Which is wrong.
>
> Why?
Because that is a) not what you are supposed to do according
to the standard (so it might very well not work with a
"third-party" device tree that equally conforms to the standard);
b) "device_type" describes some other information (namely, the
OF programming model for the device node) that is completely
unrelated to the process of driver matching; and c) it is wholly
redundant to the information in "compatible" *ANYWAY*.
> And why then it's allowed to match by "device_type"?
Anything is allowed, this is a free world. It is wrong though.
Linux used to do this wrong, there are many remnants of that
left. You also might *need* to do this for certain imperfect
device trees. None of this is an argument to continue this
"tradition".
> And why you haven't complained at MPC5200 IDE driver
Since no one paid me to review the code? Please don't try
that argument ever again, thank you very much. I think I
do quite enough work here already, I don't need people
demanding stuff from me.
> which does the same (well, maybe you have :-) or at PowerMac IDE
> driver which matches wither by "name" or "device_type"? Well, quite a
> lot of drivers are doing this...
See before why that may be. Short answer is "history".
>>> This would serve no purpose, as the driver that would catches
>>> all these is signle one, drivers/mtd/maps/physmap_of.c...
>
>> With the current kernel version, perhaps. Did you check
>> out 2.6.28? Does it work with that?
>
> For the simply mapped flashes, physmap_of will suffice, for more
> complex cases, other driver will be needed.
Ah, so you can predict the future of the Linux kernel!
> If you're hinting at the possibility that MTD subsys will be
> substantially reworked -- I don't find that likely. If it will --
> well, bad luck. :-)
Which is not an acceptable outcome.
> Anyway, reasonable suggestions on how to make MTD nodes more viable
> are always welcome. I just haven't seen reasonable enough yet. ;-)
I suggest you read, and try to understand, some of the base
device tree specifications first.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:43 ` Segher Boessenkool
@ 2007-06-03 18:59 ` Sergei Shtylyov
2007-06-03 19:48 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 18:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>>>> It's actually not -- it means simple 1:1 address mapping (w/o
>>>> explicit
>>>> byte-swapping and such).
>>> Which has nothing to do with "compatible"; instead,
>>> it is implied by the parent node have a "ranges"
>> No! It doesn't have anything to do with "ranges" of parent (don't
>> even know why it would). :-O
> So learn about it please? "ranges" means exactly that:
> child nodes' address space is direct mapped.
Well, now we certainly need a parent node -- which would be static bus
controller? But those have multiple chips selects, so we should know which
range to use. Ugh...
>>> property. Or you can put some other property in
>>> the flash node for all I care, if that seems
>>> necessary for certain cases.
>> Erm... it's *certainly* necessary to mark this somewhere.
> Not if it's redundant information.
>>>> Note that we're matching by both "device_type" and "compatible".
>>> Which is wrong.
>> Why?
> Because that is a) not what you are supposed to do according
> to the standard (so it might very well not work with a
> "third-party" device tree that equally conforms to the standard);
> b) "device_type" describes some other information (namely, the
> OF programming model for the device node) that is completely
> unrelated to the process of driver matching; and c) it is wholly
> redundant to the information in "compatible" *ANYWAY*.
Hm, well. Than changing "compatible" prop would make sense.
>> And why then it's allowed to match by "device_type"?
> Anything is allowed, this is a free world. It is wrong though.
> Linux used to do this wrong, there are many remnants of that
> left. You also might *need* to do this for certain imperfect
> device trees. None of this is an argument to continue this
> "tradition".
>> And why you haven't complained at MPC5200 IDE driver
> Since no one paid me to review the code? Please don't try
Sigh, nobody pays me for that too. :-)
> that argument ever again, thank you very much. I think I
> do quite enough work here already, I don't need people
> demanding stuff from me.
I wasn't demanding anything. I just wanted to clear things out.
>> which does the same (well, maybe you have :-) or at PowerMac IDE
>> driver which matches wither by "name" or "device_type"? Well, quite a
>> lot of drivers are doing this...
> See before why that may be. Short answer is "history".
Well, at least that's cleared.
>>>> This would serve no purpose, as the driver that would catches
>>>> all these is signle one, drivers/mtd/maps/physmap_of.c...
>>> With the current kernel version, perhaps. Did you check
>>> out 2.6.28? Does it work with that?
>
>> For the simply mapped flashes, physmap_of will suffice, for more
>> complex cases, other driver will be needed.
> Ah, so you can predict the future of the Linux kernel!
If I could, I'd have taken measures. :-)
>> If you're hinting at the possibility that MTD subsys will be
>> substantially reworked -- I don't find that likely. If it will --
>> well, bad luck. :-)
> Which is not an acceptable outcome.
>> Anyway, reasonable suggestions on how to make MTD nodes more viable
>> are always welcome. I just haven't seen reasonable enough yet. ;-)
> I suggest you read, and try to understand, some of the base
> device tree specifications first.
Read them some months ago -- do you think I would have plunged into that
not reading anything first? :-/
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 18:59 ` Sergei Shtylyov
@ 2007-06-03 19:48 ` Segher Boessenkool
2007-06-03 20:10 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-03 19:48 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
>>> No! It doesn't have anything to do with "ranges" of parent (don't
>>> even know why it would). :-O
>
>> So learn about it please? "ranges" means exactly that:
>> child nodes' address space is direct mapped.
>
> Well, now we certainly need a parent node -- which would be static
> bus controller?
I have no clue what a "static bus controller" is. Your
flash node obviously needs _some_ parent node though --
this is a tree after all.
> But those have multiple chips selects, so we should know which range
> to use. Ugh...
That is described in the "reg" property of the flash
node, just like for any other node.
>> Because that is a) not what you are supposed to do according
>> to the standard (so it might very well not work with a
>> "third-party" device tree that equally conforms to the standard);
>> b) "device_type" describes some other information (namely, the
>> OF programming model for the device node) that is completely
>> unrelated to the process of driver matching; and c) it is wholly
>> redundant to the information in "compatible" *ANYWAY*.
>
> Hm, well. Than changing "compatible" prop would make sense.
Yes.
>>> And why you haven't complained at MPC5200 IDE driver
>
>> Since no one paid me to review the code? Please don't try
>
> Sigh, nobody pays me for that too. :-)
Yeah it's a shame isn't it?
>>> which does the same (well, maybe you have :-) or at PowerMac IDE
>>> driver which matches wither by "name" or "device_type"? Well, quite
>>> a lot of drivers are doing this...
>
>> See before why that may be. Short answer is "history".
>
> Well, at least that's cleared.
Okido, good to hear.
>>> Anyway, reasonable suggestions on how to make MTD nodes more
>>> viable are always welcome. I just haven't seen reasonable enough
>>> yet. ;-)
>
>> I suggest you read, and try to understand, some of the base
>> device tree specifications first.
>
> Read them some months ago -- do you think I would have plunged into
> that not reading anything first? :-/
It seems we really need more howto-style docs...
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 19:48 ` Segher Boessenkool
@ 2007-06-03 20:10 ` Sergei Shtylyov
2007-06-04 8:02 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-03 20:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
Segher Boessenkool wrote:
>>>> No! It doesn't have anything to do with "ranges" of parent (don't
>>>> even know why it would). :-O
>>
>>
>>> So learn about it please? "ranges" means exactly that:
>>> child nodes' address space is direct mapped.
>>
>>
>> Well, now we certainly need a parent node -- which would be static
>> bus controller?
> I have no clue what a "static bus controller" is. Your
As has been pointed out in the previous "fit" of this dispute, the NOR
flashes are usually behind a kind of bridge between the "host" and
"peripheral" (static) busses.
> flash node obviously needs _some_ parent node though --
> this is a tree after all.
Yes, of course it always has a perent. The question is which parent it
should be. :-)
>> But those have multiple chips selects, so we should know which range
>> to use. Ugh...
> That is described in the "reg" property of the flash
> node, just like for any other node.
Ah. So simple. :-)
What I failed to realize so far was that "ranges" imply 1:1 address
correspondence. But not all is so simple, I'm afraid. The flash chips
themselves could be connected to their bus in some weird fashion, I'm afraid
(not that it's likely to happen on mostly big-endian PPC though).
>>>> And why you haven't complained at MPC5200 IDE driver
>>> Since no one paid me to review the code? Please don't try
>> Sigh, nobody pays me for that too. :-)
> Yeah it's a shame isn't it?
Well, I'm doing it anyway. :-)
>>>> Anyway, reasonable suggestions on how to make MTD nodes more
>>>> viable are always welcome. I just haven't seen reasonable enough
>>>> yet. ;-)
>>> I suggest you read, and try to understand, some of the base
>>> device tree specifications first.
>> Read them some months ago -- do you think I would have plunged into
>> that not reading anything first? :-/
> It seems we really need more howto-style docs...
It may indeed be non-trivial task to find all the necessary specs besides
1285 itself -- I just happened to know where to grab them beforehand:
http://www.openbios.org/Bindings
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-03 20:10 ` Sergei Shtylyov
@ 2007-06-04 8:02 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-04 8:02 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
>> flash node obviously needs _some_ parent node though --
>> this is a tree after all.
>
> Yes, of course it always has a perent. The question is which parent
> it should be. :-)
Almosts always the correct choice is the physical
bridge/controller for the bus the flash sits on.
>> That is described in the "reg" property of the flash
>> node, just like for any other node.
>
> Ah. So simple. :-)
> What I failed to realize so far was that "ranges" imply 1:1 address
> correspondence. But not all is so simple, I'm afraid. The flash chips
> themselves could be connected to their bus in some weird fashion, I'm
> afraid
In that case it is not direct-mapped, you have no "ranges"
in the parent node, and the kernel driver for the parent
node will know how to access its child bus.
>> It seems we really need more howto-style docs...
>
> It may indeed be non-trivial task to find all the necessary specs
> besides 1285 itself -- I just happened to know where to grab them
> beforehand:
1275
> http://www.openbios.org/Bindings
There is only a subset there. http://playground.sun.com/1275/
is the canonical location; there is a bunch of good docs in
the Sun library thing too (search for "FCode" or "OpenBoot").
Much of that has to do with using real OF, but lots of it is
valid/useful for a bare device tree as well.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-02 4:30 [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Milton Miller
` (2 preceding siblings ...)
2007-06-03 17:29 ` Sergei Shtylyov
@ 2007-06-04 19:40 ` Mark A. Greer
3 siblings, 0 replies; 81+ messages in thread
From: Mark A. Greer @ 2007-06-04 19:40 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
On Fri, Jun 01, 2007 at 11:30:32PM -0500, Milton Miller wrote:
> On Sat Jun 2 09:20:22 EST 2007, Mark A. Greer wrote:
>
> >Find the "rom" device for the prpmc2800 and create a device for it.
> >The device will be picked up by the code in
> >drivers/mtd/maps/physmap_of.c
> >and will setup MTD on that FLASH device.
> ...
> > /*
> >+ * Register a platform device for MTD.
> >+ */
> >+static int __init prpmc2800_register_mtd(void)
> >+{
> >+ struct device_node *np;
> >+
> >+ np = of_find_compatible_node(NULL, "rom", "direct-mapped");
> >+ of_platform_device_create(np, np->name, NULL);
> >+}
> >+arch_initcall(prpmc2800_register_mtd);
> >
>
> I think "direct-mapped" as compatible is a bit too broad or vague.
It is. Basically, all I was trying to do was fit with the code that was
already in drivers/mtd/maps/physmap_of.c. I wasn't expecting to (re)trigger
the debate that it did. Its a good thing, though. FLASH/MTD
representation in the DT needs to get sorted out.
> The compatible is supposed to be useable to find and match a driver
> without regard to the name of the node. Perhaps direct-mapped-rom?
> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>
> Actually, looking back at your device tree {1], your list several
> properties for flash, including bank-width and partition names.
> Perhaps first compatible should be direct-mapped-partitioned-flash,
> direct-mapped-partitioned-rom, direct-mapped-rom (to me a
> direct-mapped-rom driver would expose one section of address space
> read-only). I'm assuming that your driver for this "direct-mapped"
> device will look at these properties from the of device node and
> call the mtd layer somewhat directly with their contents.
The "driver" is already there, drivers/mtd/maps/physmap_of.c. I
conjured up the DT node so it would work with that existing driver.
> PS: I know you've posted this a few times. I'm just behind in
> my reading and replying :-).
No problem. I just missed an entire thread the was directed at me :-P
Mark
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
@ 2007-06-01 23:20 Mark A. Greer
2007-06-02 8:46 ` Segher Boessenkool
2007-06-04 20:56 ` Mark A. Greer
0 siblings, 2 replies; 81+ messages in thread
From: Mark A. Greer @ 2007-06-01 23:20 UTC (permalink / raw)
To: linuxppc-dev
Find the "rom" device for the prpmc2800 and create a device for it.
The device will be picked up by the code in drivers/mtd/maps/physmap_of.c
and will setup MTD on that FLASH device.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index d9db135..44c3144 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -20,6 +20,7 @@
#include <asm/system.h>
#include <asm/time.h>
#include <asm/kexec.h>
+#include <asm/of_platform.h>
#include <mm/mmu_decl.h>
@@ -134,6 +135,18 @@ void prpmc2800_show_cpuinfo(struct seq_file *m)
}
/*
+ * Register a platform device for MTD.
+ */
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, "rom", "direct-mapped");
+ of_platform_device_create(np, np->name, NULL);
+}
+arch_initcall(prpmc2800_register_mtd);
+
+/*
* Called very early, device-tree isn't unflattened
*/
static int __init prpmc2800_probe(void)
^ permalink raw reply related [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-01 23:20 Mark A. Greer
@ 2007-06-02 8:46 ` Segher Boessenkool
2007-06-04 20:56 ` Mark A. Greer
1 sibling, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-02 8:46 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
> +static int __init prpmc2800_register_mtd(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, "rom", "direct-mapped");
> + of_platform_device_create(np, np->name, NULL);
> +}
Needs error checking -- what if the node doesn't exist.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-01 23:20 Mark A. Greer
2007-06-02 8:46 ` Segher Boessenkool
@ 2007-06-04 20:56 ` Mark A. Greer
2007-06-05 20:35 ` Sergei Shtylyov
2007-06-06 2:39 ` David Gibson
1 sibling, 2 replies; 81+ messages in thread
From: Mark A. Greer @ 2007-06-04 20:56 UTC (permalink / raw)
To: linuxppc-dev
Okay, >25 msgs from a ~10 line patch. I think that's a new personal
record for me. ;)
More seriously, I've simply been trying to provide a DT node that works
with the current code in drivers/mtd/maps/physmap_of.c. Obviously,
there are issues with that code and my DT node.
So to try a different approach, here is the hardware info and a copy of
the relevant DT that I currently have. Segher, et. al., if you can
find the time, please give me your best guidance as to what the DT
node(s) should really look like (and how physmap.c should really work).
I'll be happy to hack physmap_of.c once I have a clear understanding of
how it should work (and there is clear agreement on that :).
Mark
---
Hardware:
---------
[As I read this, I realize I have the DT node messed up anyway.]
- Not that this matters but this is a Marvell mv64360/mv64362 based board
with a MPC7447A processor.
- There are two 32MB banks of two Intel Stata Flash (NOR) chips (CFI).
Each 32MB bank is 32-bits wide built with two 8Mx16 28F128K3 devices
(http://download.intel.com/design/flcomp/datashts/29073709.pdf).
Bits 0-15 from the first device, bits 16-31 from the second one.
The two banks are contiguous in the processor's physical memory space.
- The MTD partitions are described in the DT.
For your reference, the exiting DT:
-----------------------------------
mv64x60@f1000000 { /* Marvell Discovery */
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <1>;
model = "mv64360"; /* Default */
compatible = "marvell,mv64x60";
clock-frequency = <7f28155>; /* 133.333333 MHz */
reg = <f1000000 00010000>;
virtual-reg = <f1000000>;
ranges = <88000000 88000000 01000000 /* PCI 0 I/O Space */
80000000 80000000 08000000 /* PCI 0 MEM Space */
a0000000 a0000000 04000000 /* User FLASH */
00000000 f1000000 00010000 /* Bridge's regs */
f2000000 f2000000 00040000>; /* Integrated SRAM */
flash@a0000000 {
device_type = "rom";
compatible = "direct-mapped";
reg = <a0000000 4000000>; /* Default (64MB) */
probe-type = "CFI";
bank-width = <4>;
partitions = <00000000 00100000 /* RO */
00100000 00040001 /* RW */
00140000 00400000 /* RO */
00540000 039c0000 /* RO */
03f00000 00100000>; /* RO */
partition-names = "FW Image A", "FW Config Data", "Kernel Image", "Filesystem", "FW Image B";
};
So, what should the DT look like for this thing? And, what should
phymap_of.c be doing?
Mark
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-04 20:56 ` Mark A. Greer
@ 2007-06-05 20:35 ` Sergei Shtylyov
2007-06-05 21:11 ` Mark A. Greer
2007-06-06 2:39 ` David Gibson
1 sibling, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-05 20:35 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
Mark A. Greer wrote:
> For your reference, the exiting DT:
> -----------------------------------
>
> mv64x60@f1000000 { /* Marvell Discovery */
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <1>;
> model = "mv64360"; /* Default */
> compatible = "marvell,mv64x60";
> clock-frequency = <7f28155>; /* 133.333333 MHz */
> reg = <f1000000 00010000>;
> virtual-reg = <f1000000>;
> ranges = <88000000 88000000 01000000 /* PCI 0 I/O Space */
> 80000000 80000000 08000000 /* PCI 0 MEM Space */
> a0000000 a0000000 04000000 /* User FLASH */
> 00000000 f1000000 00010000 /* Bridge's regs */
> f2000000 f2000000 00040000>; /* Integrated SRAM */
>
> flash@a0000000 {
> device_type = "rom";
> compatible = "direct-mapped";
> reg = <a0000000 4000000>; /* Default (64MB) */
> probe-type = "CFI";
> bank-width = <4>;
> partitions = <00000000 00100000 /* RO */
> 00100000 00040001 /* RW */
> 00140000 00400000 /* RO */
> 00540000 039c0000 /* RO */
> 03f00000 00100000>; /* RO */
Hm, this should have been the other way around -- ones with odd size are
RO, ones with even size are RW.
> partition-names = "FW Image A", "FW Config Data", "Kernel Image", "Filesystem", "FW Image B";
> };
> So, what should the DT look like for this thing? And, what should
> phymap_of.c be doing?
> Mark
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-05 20:35 ` Sergei Shtylyov
@ 2007-06-05 21:11 ` Mark A. Greer
2007-06-06 12:41 ` Sergei Shtylyov
0 siblings, 1 reply; 81+ messages in thread
From: Mark A. Greer @ 2007-06-05 21:11 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
On Wed, Jun 06, 2007 at 12:35:00AM +0400, Sergei Shtylyov wrote:
> Mark A. Greer wrote:
> >
> > flash@a0000000 {
> > device_type = "rom";
> > compatible = "direct-mapped";
> > reg = <a0000000 4000000>; /* Default (64MB) */
> > probe-type = "CFI";
> > bank-width = <4>;
> > partitions = <00000000 00100000 /* RO */
> > 00100000 00040001 /* RW */
> > 00140000 00400000 /* RO */
> > 00540000 039c0000 /* RO */
> > 03f00000 00100000>; /* RO */
>
> Hm, this should have been the other way around -- ones with odd size are
> RO, ones with even size are RW.
Yeah, that's what the comment says but the code says the opposite:
if (*part++ & 1) /* bit 0 set signifies read only partition */
(*parts)[i].mask_flags = MTD_WRITEABLE;
Doesn't that make it RW if bit 0 is set?
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-05 21:11 ` Mark A. Greer
@ 2007-06-06 12:41 ` Sergei Shtylyov
2007-06-07 15:08 ` David Woodhouse
0 siblings, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-06 12:41 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, linux-mtd
Hello.
Mark A. Greer wrote:
>>Mark A. Greer wrote:
>>> flash@a0000000 {
>>> device_type = "rom";
>>> compatible = "direct-mapped";
>>> reg = <a0000000 4000000>; /* Default (64MB) */
>>> probe-type = "CFI";
>>> bank-width = <4>;
>>> partitions = <00000000 00100000 /* RO */
>>> 00100000 00040001 /* RW */
>>> 00140000 00400000 /* RO */
>>> 00540000 039c0000 /* RO */
>>> 03f00000 00100000>; /* RO */
>> Hm, this should have been the other way around -- ones with odd size are
>>RO, ones with even size are RW.
> Yeah, that's what the comment says but the code says the opposite:
> if (*part++ & 1) /* bit 0 set signifies read only partition */
> (*parts)[i].mask_flags = MTD_WRITEABLE;
> Doesn't that make it RW if bit 0 is set?
Contrarywise, though this may surprise you. ;-)
This is a question to MTD people...
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-04 20:56 ` Mark A. Greer
2007-06-05 20:35 ` Sergei Shtylyov
@ 2007-06-06 2:39 ` David Gibson
2007-06-07 13:30 ` Segher Boessenkool
1 sibling, 1 reply; 81+ messages in thread
From: David Gibson @ 2007-06-06 2:39 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
On Mon, Jun 04, 2007 at 01:56:46PM -0700, Mark A. Greer wrote:
> Okay, >25 msgs from a ~10 line patch. I think that's a new personal
> record for me. ;)
>
> More seriously, I've simply been trying to provide a DT node that works
> with the current code in drivers/mtd/maps/physmap_of.c. Obviously,
> there are issues with that code and my DT node.
>
> So to try a different approach, here is the hardware info and a copy of
> the relevant DT that I currently have. Segher, et. al., if you can
> find the time, please give me your best guidance as to what the DT
> node(s) should really look like (and how physmap.c should really work).
> I'll be happy to hack physmap_of.c once I have a clear understanding of
> how it should work (and there is clear agreement on that :).
>
> Mark
> ---
>
> Hardware:
> ---------
> [As I read this, I realize I have the DT node messed up anyway.]
> - Not that this matters but this is a Marvell mv64360/mv64362 based board
> with a MPC7447A processor.
> - There are two 32MB banks of two Intel Stata Flash (NOR) chips (CFI).
> Each 32MB bank is 32-bits wide built with two 8Mx16 28F128K3 devices
> (http://download.intel.com/design/flcomp/datashts/29073709.pdf).
> Bits 0-15 from the first device, bits 16-31 from the second one.
> The two banks are contiguous in the processor's physical memory space.
> - The MTD partitions are described in the DT.
>
> For your reference, the exiting DT:
> -----------------------------------
>
> mv64x60@f1000000 { /* Marvell Discovery */
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <1>;
> model = "mv64360"; /* Default */
> compatible = "marvell,mv64x60";
> clock-frequency = <7f28155>; /* 133.333333 MHz */
> reg = <f1000000 00010000>;
> virtual-reg = <f1000000>;
> ranges = <88000000 88000000 01000000 /* PCI 0 I/O Space */
> 80000000 80000000 08000000 /* PCI 0 MEM Space */
> a0000000 a0000000 04000000 /* User FLASH */
> 00000000 f1000000 00010000 /* Bridge's regs */
> f2000000 f2000000 00040000>; /* Integrated SRAM */
>
> flash@a0000000 {
> device_type = "rom";
> compatible = "direct-mapped";
> reg = <a0000000 4000000>; /* Default (64MB) */
> probe-type = "CFI";
> bank-width = <4>;
> partitions = <00000000 00100000 /* RO */
> 00100000 00040001 /* RW */
> 00140000 00400000 /* RO */
> 00540000 039c0000 /* RO */
> 03f00000 00100000>; /* RO */
> partition-names = "FW Image A", "FW Config Data", "Kernel Image", "Filesystem", "FW Image B";
> };
Whatever Segher says, I think it's fine to have the partition
information here. It may not be hardware information, but it is
(often) firmware information; there are plenty precedents for things
like this in the device tree and it doesn't get in the way of any real
hardware information.
That said, I'm a bit dubious about the encoding of the RO/RW bit into
the partition length (which I only just realised was used now).
I'll have to think some more about the rest.
> So, what should the DT look like for this thing? And, what should
> phymap_of.c be doing?
>
> Mark
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-06 2:39 ` David Gibson
@ 2007-06-07 13:30 ` Segher Boessenkool
2007-06-12 4:42 ` David Gibson
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-07 13:30 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
> Whatever Segher says, I think it's fine to have the partition
> information here.
It's nonsense to have it *inside that device node*. I
understand if you want to express it elsewhere.
> It may not be hardware information, but it is
> (often) firmware information;
Only part of it is. The rest should *not* be dictated
by the firmware; for example, if a new OS image for
the device needs different flash partition sizes, you
would have to reflash the firmware! Obviously less than
ideal, and we can't have that kind of stuff in a more-
or-less generic device tree binding.
> there are plenty precedents for things
> like this in the device tree and it doesn't get in the way of any real
> hardware information.
There is plenty of precedent for putting stuff that
is not configuration info for some OS in the device
tree, yes -- like describing the flash region used
by firmware code (as a subnode of the flash node,
perhaps). A "generic" (i.e., specific to the current
implementation of linux-mtd) partition map is no such
thing.
> That said, I'm a bit dubious about the encoding of the RO/RW bit into
> the partition length (which I only just realised was used now).
Quite.
>> So, what should the DT look like for this thing? And, what should
>> phymap_of.c be doing?
I think we want to define a binding for a "cfi-flash"
device, instead.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-07 13:30 ` Segher Boessenkool
@ 2007-06-12 4:42 ` David Gibson
2007-06-12 10:50 ` Segher Boessenkool
2007-06-14 12:50 ` Sergei Shtylyov
0 siblings, 2 replies; 81+ messages in thread
From: David Gibson @ 2007-06-12 4:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
On Thu, Jun 07, 2007 at 03:30:46PM +0200, Segher Boessenkool wrote:
> > Whatever Segher says, I think it's fine to have the partition
> > information here.
>
> It's nonsense to have it *inside that device node*. I
> understand if you want to express it elsewhere.
>
> > It may not be hardware information, but it is
> > (often) firmware information;
>
> Only part of it is. The rest should *not* be dictated
> by the firmware; for example, if a new OS image for
> the device needs different flash partition sizes, you
> would have to reflash the firmware! Obviously less than
> ideal, and we can't have that kind of stuff in a more-
> or-less generic device tree binding.
>
> > there are plenty precedents for things
> > like this in the device tree and it doesn't get in the way of any real
> > hardware information.
>
> There is plenty of precedent for putting stuff that
> is not configuration info for some OS in the device
> tree, yes -- like describing the flash region used
> by firmware code (as a subnode of the flash node,
> perhaps). A "generic" (i.e., specific to the current
> implementation of linux-mtd) partition map is no such
> thing.
So, what you're suggesting is a subnode for each described partition?
Seems an awfully verbose way of going about it, and I don't see what
it buys us over the partitions/partition-names pair of properties.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-12 4:42 ` David Gibson
@ 2007-06-12 10:50 ` Segher Boessenkool
2007-06-13 6:12 ` David Gibson
2007-06-14 12:48 ` Sergei Shtylyov
2007-06-14 12:50 ` Sergei Shtylyov
1 sibling, 2 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-12 10:50 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
> So, what you're suggesting is a subnode for each described partition?
I'm saying this is a reasonable way to describe the regions
of flash the firmware itself cares about.
This isn't anything new; it is done like this on some
Apple systems, for example.
> Seems an awfully verbose way of going about it,
Not verbose, but flexible, and in line with everything
else about the device tree.
> and I don't see what
> it buys us over the partitions/partition-names pair of properties.
It is extensible. It makes parsing trivial. It
represents a flash partition in a way similar to how
a "whole" flash device is represented.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-12 10:50 ` Segher Boessenkool
@ 2007-06-13 6:12 ` David Gibson
2007-06-13 9:13 ` Segher Boessenkool
2007-06-14 12:48 ` Sergei Shtylyov
1 sibling, 1 reply; 81+ messages in thread
From: David Gibson @ 2007-06-13 6:12 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
On Tue, Jun 12, 2007 at 12:50:25PM +0200, Segher Boessenkool wrote:
> > So, what you're suggesting is a subnode for each described partition?
>
> I'm saying this is a reasonable way to describe the regions
> of flash the firmware itself cares about.
>
> This isn't anything new; it is done like this on some
> Apple systems, for example.
>
> > Seems an awfully verbose way of going about it,
>
> Not verbose, but flexible, and in line with everything
> else about the device tree.
>
> > and I don't see what
> > it buys us over the partitions/partition-names pair of properties.
>
> It is extensible. It makes parsing trivial. It
> represents a flash partition in a way similar to how
> a "whole" flash device is represented.
Hrm, ok. Between you and BenH you've convinced me. I'll try to come
up with something. I think we'll still need to support the old
properties as backwards compatibility thing.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-13 6:12 ` David Gibson
@ 2007-06-13 9:13 ` Segher Boessenkool
2007-06-13 9:19 ` David Gibson
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-13 9:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
> Hrm, ok. Between you and BenH you've convinced me. I'll try to come
> up with something. I think we'll still need to support the old
> properties as backwards compatibility thing.
Yes, of course.
I'm still not happy with creating nodes for application
flash partitions in the device tree; this isn't done
for disk partitions either, for analogue reasons (namely,
that info doesn't belong in the device tree, it is the
wrong abstraction).
How do non-device-tree MTD users handle this?
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-13 9:13 ` Segher Boessenkool
@ 2007-06-13 9:19 ` David Gibson
2007-06-13 9:37 ` Segher Boessenkool
0 siblings, 1 reply; 81+ messages in thread
From: David Gibson @ 2007-06-13 9:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
On Wed, Jun 13, 2007 at 11:13:21AM +0200, Segher Boessenkool wrote:
> > Hrm, ok. Between you and BenH you've convinced me. I'll try to come
> > up with something. I think we'll still need to support the old
> > properties as backwards compatibility thing.
>
> Yes, of course.
>
> I'm still not happy with creating nodes for application
> flash partitions in the device tree; this isn't done
> for disk partitions either, for analogue reasons (namely,
> that info doesn't belong in the device tree, it is the
> wrong abstraction).
>
> How do non-device-tree MTD users handle this?
Invidual, board-specific map files with hardcoded partition tables.
See drivers/mtd/maps/ebony.c for example. Hence my view of the device
tree as a preferable option.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-13 9:19 ` David Gibson
@ 2007-06-13 9:37 ` Segher Boessenkool
2007-06-14 4:29 ` David Gibson
0 siblings, 1 reply; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-13 9:37 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
>> How do non-device-tree MTD users handle this?
>
> Invidual, board-specific map files with hardcoded partition tables.
That's what I was afraid of. Sigh.
> See drivers/mtd/maps/ebony.c for example.
[/me looks...] Oh horror.
> Hence my view of the device
> tree as a preferable option.
I think some binary partition table format that can be
used by _all_ MTD consumers should be defined. How
that table should be communicated to the kernel in the
device tree case we can discuss later, then. Maybe
something as simple as storing it in flash, and have a
"partition-table-offset" property or something like that.
This is something the MTD people will have to buy into
of course.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-13 9:37 ` Segher Boessenkool
@ 2007-06-14 4:29 ` David Gibson
2007-06-14 8:00 ` Segher Boessenkool
2007-06-14 12:39 ` Sergei Shtylyov
0 siblings, 2 replies; 81+ messages in thread
From: David Gibson @ 2007-06-14 4:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
On Wed, Jun 13, 2007 at 11:37:42AM +0200, Segher Boessenkool wrote:
> >> How do non-device-tree MTD users handle this?
> >
> > Invidual, board-specific map files with hardcoded partition tables.
>
> That's what I was afraid of. Sigh.
>
> > See drivers/mtd/maps/ebony.c for example.
>
> [/me looks...] Oh horror.
>
> > Hence my view of the device
> > tree as a preferable option.
>
> I think some binary partition table format that can be
> used by _all_ MTD consumers should be defined. How
> that table should be communicated to the kernel in the
> device tree case we can discuss later, then. Maybe
> something as simple as storing it in flash, and have a
> "partition-table-offset" property or something like that.
>
> This is something the MTD people will have to buy into
> of course.
I tought I saw some config option implying that there already existed
an on-device partition table format for flashes. Doesn't help us for
existing boards which don't expect such a setup, of course.
Incidentally, with either the partitions-described-by-properties, or
the revised more-flexible partitions-described-by-subnodes format, I'm
not seeing it as required that the whole of the flash address space be
described. So it would certainly be possible to *only* describe the
sections of the flash used by firmware. But I'm suggesting that we
optionally allow other partitions to be described for boards / systems
which have strong conventions about how the flash is divided and where
we don't have any other way of recording the partition layout short of
hardcoding.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-14 4:29 ` David Gibson
@ 2007-06-14 8:00 ` Segher Boessenkool
2007-06-14 12:39 ` Sergei Shtylyov
1 sibling, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-14 8:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
>> I think some binary partition table format that can be
>> used by _all_ MTD consumers should be defined. How
>> that table should be communicated to the kernel in the
>> device tree case we can discuss later, then. Maybe
>> something as simple as storing it in flash, and have a
>> "partition-table-offset" property or something like that.
>>
>> This is something the MTD people will have to buy into
>> of course.
>
> I tought I saw some config option implying that there already existed
> an on-device partition table format for flashes.
Interesting.
> Doesn't help us for
> existing boards which don't expect such a setup, of course.
If they don't use a device tree yet, I don't see much
of a problem. If they do already, that can be fixed,
too -- gradually.
> Incidentally, with either the partitions-described-by-properties, or
> the revised more-flexible partitions-described-by-subnodes format, I'm
> not seeing it as required that the whole of the flash address space be
> described.
Indeed. It is fine to simply tell the OS "there is
some flash here, you figure out what to use it for".
> So it would certainly be possible to *only* describe the
> sections of the flash used by firmware. But I'm suggesting that we
> optionally allow other partitions to be described for boards / systems
> which have strong conventions about how the flash is divided and where
> we don't have any other way of recording the partition layout short of
> hardcoding.
As long as it's optional there should be no harm in
that, of course.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-14 4:29 ` David Gibson
2007-06-14 8:00 ` Segher Boessenkool
@ 2007-06-14 12:39 ` Sergei Shtylyov
2007-06-14 13:20 ` Segher Boessenkool
1 sibling, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-14 12:39 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
David Gibson wrote:
>>>>How do non-device-tree MTD users handle this?
>>>Invidual, board-specific map files with hardcoded partition tables.
>>That's what I was afraid of. Sigh.
>>>See drivers/mtd/maps/ebony.c for example.
>>[/me looks...] Oh horror.
>>>Hence my view of the device
>>>tree as a preferable option.
>>I think some binary partition table format that can be
>>used by _all_ MTD consumers should be defined. How
>>that table should be communicated to the kernel in the
>>device tree case we can discuss later, then. Maybe
>>something as simple as storing it in flash, and have a
>>"partition-table-offset" property or something like that.
>>This is something the MTD people will have to buy into
>>of course.
> I tought I saw some config option implying that there already existed
> an on-device partition table format for flashes. Doesn't help us for
You probably mean RedBoot table?
> existing boards which don't expect such a setup, of course.
Exactly. It's specific to RedBoot.
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-14 12:39 ` Sergei Shtylyov
@ 2007-06-14 13:20 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-14 13:20 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
>> I tought I saw some config option implying that there already existed
>> an on-device partition table format for flashes. Doesn't help us for
>
> You probably mean RedBoot table?
>
>> existing boards which don't expect such a setup, of course.
>
> Exactly. It's specific to RedBoot.
Sounds like we need to create a more generic format
then -- perhaps adopting most of the redboot thing.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-12 10:50 ` Segher Boessenkool
2007-06-13 6:12 ` David Gibson
@ 2007-06-14 12:48 ` Sergei Shtylyov
2007-06-14 13:18 ` Segher Boessenkool
1 sibling, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-14 12:48 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
Segher Boessenkool wrote:
>>So, what you're suggesting is a subnode for each described partition?
> I'm saying this is a reasonable way to describe the regions
> of flash the firmware itself cares about.
> This isn't anything new; it is done like this on some
> Apple systems, for example.
First you're saying that nodes should correspont to *real* devices, then
it turns out that there have been precedents for the nodes corresponding to
completely virtual entities? ;-)
>>Seems an awfully verbose way of going about it,
> Not verbose, but flexible, and in line with everything
Yes, I'd agree about more flexibility...
> else about the device tree.
How about your earlier arguments against the representation of flashes?
>>and I don't see what
>>it buys us over the partitions/partition-names pair of properties.
> It is extensible. It makes parsing trivial. It
Excellent -- previously my arguments about more simplicity for
representing flash itself were sent to /dev/null.
> represents a flash partition in a way similar to how
> a "whole" flash device is represented.
Except it's not a device. :-)
> Segher
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-14 12:48 ` Sergei Shtylyov
@ 2007-06-14 13:18 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-14 13:18 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
>>> So, what you're suggesting is a subnode for each described partition?
>
>> I'm saying this is a reasonable way to describe the regions
>> of flash the firmware itself cares about.
>
>> This isn't anything new; it is done like this on some
>> Apple systems, for example.
>
> First you're saying that nodes should correspont to *real* devices,
> then it turns out that there have been precedents for the nodes
> corresponding to completely virtual entities? ;-)
Every physical device should have its own node (there
_can_ be exceptions, but if you can help it at all...)
There can be virtual devices as well, although you don't
often need or want them. There are a few pseudo-nodes
too, not representing _any_ device, physical or virtual.
>>> Seems an awfully verbose way of going about it,
>
>> Not verbose, but flexible, and in line with everything
>
> Yes, I'd agree about more flexibility...
Good to hear :-)
>> else about the device tree.
>
> How about your earlier arguments against the representation of
> flashes?
What arguments, exactly? Perhaps you're not understanding
exactly what I meant, or perhaps I changed my mind -- that
happens sometimes, after long discussions. That is what
those discussions are for, even -- only after looking at
every detail, and discussing all those details with other
people, including non-experts on OF who can bring in valuable
concerns about use cases etc.; only then can a good device
binding be defined. Sometimes also it should be concluded
there is not enough experience yet on how to do a certain
device binding; in such a case, the best course of action is
usually to _not_ define such a binding yet.
>>> and I don't see what
>>> it buys us over the partitions/partition-names pair of properties.
>
>> It is extensible. It makes parsing trivial. It
>
> Excellent -- previously my arguments about more simplicity for
> representing flash itself were sent to /dev/null.
Do you like my proposed CFI binding? I need a bit more
input on how to do a JEDEC flash binding still. After
I've written it all up properly, I plan to send this to
the OF working group to turn it into a standard binding.
>> represents a flash partition in a way similar to how
>> a "whole" flash device is represented.
>
> Except it's not a device. :-)
Yes, but in many aspects it can be treated as one. And
it cannot be mistaken for one, either.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-12 4:42 ` David Gibson
2007-06-12 10:50 ` Segher Boessenkool
@ 2007-06-14 12:50 ` Sergei Shtylyov
2007-06-14 13:43 ` Segher Boessenkool
1 sibling, 1 reply; 81+ messages in thread
From: Sergei Shtylyov @ 2007-06-14 12:50 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
Hello.
David Gibson wrote:
> So, what you're suggesting is a subnode for each described partition?
> Seems an awfully verbose way of going about it, and I don't see what
> it buys us over the partitions/partition-names pair of properties.
I was thinking of using a signle multipart prop but dtc had no support for
it at that time...
WBR, Sergei
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
2007-06-14 12:50 ` Sergei Shtylyov
@ 2007-06-14 13:43 ` Segher Boessenkool
0 siblings, 0 replies; 81+ messages in thread
From: Segher Boessenkool @ 2007-06-14 13:43 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
>> , and I don't see what
>> it buys us over the partitions/partition-names pair of properties.
>
> I was thinking of using a signle multipart prop but dtc had no
> support for it at that time...
The kernel (and probably most DTB parsers) cannot handle
unaligned integers in properties, even though it is a
perfectly fine thing to have.
Segher
^ permalink raw reply [flat|nested] 81+ messages in thread
end of thread, other threads:[~2007-06-15 11:22 UTC | newest]
Thread overview: 81+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-02 4:30 [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Milton Miller
2007-06-02 7:39 ` Benjamin Herrenschmidt
2007-06-03 16:10 ` Sergei Shtylyov
2007-06-03 17:36 ` Segher Boessenkool
2007-06-03 18:03 ` Sergei Shtylyov
2007-06-03 18:25 ` Segher Boessenkool
2007-06-03 18:36 ` Sergei Shtylyov
2007-06-03 18:46 ` Segher Boessenkool
2007-06-03 19:16 ` Sergei Shtylyov
2007-06-03 21:04 ` Benjamin Herrenschmidt
2007-06-04 12:34 ` Sergei Shtylyov
2007-06-04 14:37 ` Segher Boessenkool
2007-06-04 14:49 ` Sergei Shtylyov
2007-06-07 14:53 ` David Woodhouse
2007-06-07 15:49 ` Segher Boessenkool
2007-06-07 14:47 ` David Woodhouse
2007-06-07 15:32 ` Segher Boessenkool
2007-06-02 8:53 ` Segher Boessenkool
2007-06-03 16:22 ` Sergei Shtylyov
2007-06-03 17:40 ` Segher Boessenkool
2007-06-03 18:31 ` Sergei Shtylyov
2007-06-03 18:44 ` Segher Boessenkool
2007-06-03 19:13 ` Sergei Shtylyov
2007-06-03 19:56 ` Segher Boessenkool
2007-06-03 20:26 ` Sergei Shtylyov
2007-06-04 8:07 ` Segher Boessenkool
2007-06-04 13:34 ` Sergei Shtylyov
2007-06-07 15:00 ` David Woodhouse
2007-06-07 15:55 ` Segher Boessenkool
2007-06-07 16:05 ` David Woodhouse
2007-06-07 16:46 ` Segher Boessenkool
2007-06-12 4:44 ` David Gibson
2007-06-12 10:53 ` Segher Boessenkool
2007-06-13 3:16 ` David Gibson
2007-06-13 5:05 ` Segher Boessenkool
2007-06-13 6:11 ` David Gibson
2007-06-13 9:10 ` Segher Boessenkool
2007-06-15 4:12 ` David Gibson
2007-06-15 11:22 ` Segher Boessenkool
2007-06-15 4:14 ` David Gibson
2007-06-15 8:42 ` Segher Boessenkool
2007-06-15 8:47 ` David Woodhouse
2007-06-15 8:59 ` Segher Boessenkool
2007-06-03 21:12 ` Benjamin Herrenschmidt
2007-06-04 8:11 ` Segher Boessenkool
2007-06-04 13:16 ` Sergei Shtylyov
2007-06-04 12:41 ` Sergei Shtylyov
2007-06-04 14:49 ` Segher Boessenkool
2007-06-04 15:54 ` Sergei Shtylyov
2007-06-03 17:29 ` Sergei Shtylyov
2007-06-03 17:45 ` Segher Boessenkool
2007-06-03 18:18 ` Sergei Shtylyov
2007-06-03 18:43 ` Segher Boessenkool
2007-06-03 18:59 ` Sergei Shtylyov
2007-06-03 19:48 ` Segher Boessenkool
2007-06-03 20:10 ` Sergei Shtylyov
2007-06-04 8:02 ` Segher Boessenkool
2007-06-04 19:40 ` Mark A. Greer
-- strict thread matches above, loose matches on Subject: below --
2007-06-01 23:20 Mark A. Greer
2007-06-02 8:46 ` Segher Boessenkool
2007-06-04 20:56 ` Mark A. Greer
2007-06-05 20:35 ` Sergei Shtylyov
2007-06-05 21:11 ` Mark A. Greer
2007-06-06 12:41 ` Sergei Shtylyov
2007-06-07 15:08 ` David Woodhouse
2007-06-06 2:39 ` David Gibson
2007-06-07 13:30 ` Segher Boessenkool
2007-06-12 4:42 ` David Gibson
2007-06-12 10:50 ` Segher Boessenkool
2007-06-13 6:12 ` David Gibson
2007-06-13 9:13 ` Segher Boessenkool
2007-06-13 9:19 ` David Gibson
2007-06-13 9:37 ` Segher Boessenkool
2007-06-14 4:29 ` David Gibson
2007-06-14 8:00 ` Segher Boessenkool
2007-06-14 12:39 ` Sergei Shtylyov
2007-06-14 13:20 ` Segher Boessenkool
2007-06-14 12:48 ` Sergei Shtylyov
2007-06-14 13:18 ` Segher Boessenkool
2007-06-14 12:50 ` Sergei Shtylyov
2007-06-14 13:43 ` Segher Boessenkool
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).