[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