[PATCH] powerpc: Create "rom" (MTD) device prpmc2800
Segher Boessenkool
segher at kernel.crashing.org
Mon Jun 4 04:07:34 EDT 2007
>>>> 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
More information about the linux-mtd
mailing list