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

On Mar 30, 2006, at 5:26 AM, Vitaly Bordug wrote:

quoted

- 	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