[PATCH] powerpc: Create "rom" (MTD) device prpmc2800

Segher Boessenkool segher at kernel.crashing.org
Mon Jun 4 18:07:34 EST 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 Linuxppc-dev mailing list