[PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Vitaly Bordug]

On Thu, 30 Mar 2006 17:10:48 +1100
Paul Mackerras <paulus at samba.org> wrote:

> Dan Malek writes:
> 
> > I haven't followed the device tree development in detail, but when
> > looking at this the only question that comes to mind is wondering
> > what this really does to help me.  None of the information provided
> > here is variable nor configurable .... except I guess for the internal
> > register base address (IMMR), which for some reason has turned
> > into a variable which hasn't changed since I did the first kernel port.
> > About the only thing that is variable, which is the two different bank
> > addresses of the CPM memory that affects the configuration of
> > the FCCs in Ethernet mode, isn't reflected here in any way.
> 
> I don't know much about the CPM or CPM2, so I don't know precisely why
> these bits have been put in.  If the CPM2 is completely unique and is
> identical across all possible past and future implementations, then
> indeed there isn't a lot of value in putting details about it in the
> device tree.  Having details in the device tree becomes useful if:
> 
> * there are variants that have different collections of subdevices, or
>   subdevices at different offsets, or
> 
Yes. Offsets differ across the different PQ families. Collections may differ even on the same reference design, 885 for instance could have all the scc's/smc's utilized as UARTs, while on classic SMC1+SMC2, only, SCC may be used as 10M network.

> * there are common subdevices between CPM and CPM2 (or future CPM*
>   devices), potentially with subtle variations in offset, method of
>   enabling, etc., or
> 
Yes, but this is similar with the first point... Well even cpm and cpm2 differ (different immap.h ), and we have CPM future heading for QE. 
> * there are subdevices in CPM/CPM2 which match some common device
>   (e.g. a 16550 uart) for which a generic driver can be used with some
>   appropriate configuration.
Yep - cpm_uart and fs_enet are live examples. Both are intended to deal with serial and Ethernet stuff from the different variations of CPM. Right now they are not ideal, because they still have to remap the whole immr (say to access cpm command register) ,and such parts are still board-specific which is not good...
> 
> As I say, I don't know if these points apply to CPM/CPM2 specifically.
> 
> Paul.
> 
> 
Thank you for your comments - now I'm sure all this following the right way...

-- 
Sincerely, 
Vitaly