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

[Kumar Gala]

On Mar 30, 2006, at 7:09 AM, Dan Malek wrote:

>
> On Mar 30, 2006, at 5:26 AM, Vitaly Bordug wrote:
>
>> - 	the new way, all that will not follow it will be obsoleted sooner
>> or later
>
> The problem I see is the "new way" is done for the sake of doing
> something
> new, without adding any value.  If you want to make the drivers
> dynamically
> configurable, which I'll continue to argue is silly in an embedded
> environment
> of the type with CPMs, all you need to know is personality of the
> device.
> The reason it's silly is the wiring on the particular board dictates
> how a
> CPM peripheral will be used.  The SCC1 can't be a serial uart one
> moment and an Ethernet the next time you boot up.  Since you have
> already
> done a "board port", you may as well wire this as part of the
> configuration
> and eliminate potential mistakes.  If you insist on making this  
> dynamic
> (and as a port maintainer I would reject such patches), the only thing
> you need to describe is the device type.  For example, the SCC1 can be
> an Ethernet or uart.  We only support FCCs as Ethernets, and unless
> someone submits some other kind of driver, like ATM/UTOPIA, there
> isn't anything variable to configure.
>
> All of the truly configurable options, like NMSI vs. TSA, are so  
> complex
> the device tree would not be helpful, as that would be built into the
> custom driver to configure as necessary.
>
> The offsets into the internal register maps are not so variable that
> adding
> the information into the device tree is useful.  There is CPM1 and  
> CPM2,
> some common code shared between them that already solves the
> problems, and the real difference between the two different CPM2 maps
> on 82xx isn't reflected here (but again is already solved in the
> existing
> software).  As I said in the past message, this seems more likely to
> cause
> errors than be helpful.  To me it just seems new for the sake of being
> new, rather than providing any real value.
>
> I'd rather we spend our time adding the xmon and kgdb over serial port
> features back into the driver that were lost during the "great driver
> clean up"
> than pursing stuff like this.

Maybe we should look at this from a different point of view.  What  
are the things that change can change between boards for the same CPU?

* What a give channel (SCC, FCC, UCC, SMC?) is used for serial,  
ethernet, ATM, etc.
* How a channel is wired? [pin muxing]  (I really hate having drivers  
have board specific ifdefs for this)
* which (if any) BRG a channel is using?
* ...? [I feel like I'm missing some but haven't worked on a CPM  
driver in a while :)]

The other question is what changes between CPUs?

* Number/Mix of channels
* some PRAM offset (8272 FCC comes to mind)
* channel differences for same channel type? (what's an example of  
this?)
* ...?

I think we should attempt to answer my two questions first (which Dan  
took an initial swag at) and use those answers to drive how/what we  
need in the description of a CPM node.

- kumar