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

[Dan Malek]

On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:

> * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
> ethernet, ATM, etc.

You need to view this from the other direction.  As I've always
said, we don't have an "SCC driver", we have a uart driver for
SCCs.  So, you configure from that perspective.  The uart driver
is configured to use certain SCCs.

> * How a channel is wired? [pin muxing]  (I really hate having drivers
> have board specific ifdefs for this)

I've got a solution for IO pin multiplexing that I have to get pushed
in using the "feature_call" method like a pmac.  The other thing
to realize here is there is often hardware beyond just "pin muxing"
that is unique to a board and requires configuration.  Statically
describing what pins set/clear is a small, and already understood
part, of more complex set up that needs to be done with code
unique to a board.

> * which (if any) BRG a channel is using?

These are already a dynamically allocated resource.  Drivers
don't care which one is assigned, you should be allocating
one and using the handle provided to the support functions.

> * ...? [I feel like I'm missing some but haven't worked on a CPM
> driver in a while :)]

I can't think of any, and I use the CPM all of the time.  :-)

> The other question is what changes between CPUs?

Almost nothing, except the PRAM offset you mention below
and I've mentioned in past messages as memory bank differences.

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

Don't be creating problems to solve because we seem to have
a solution for _something_.  Yes, this would be a cute piece of code
to write and interesting driver updates, but in the end all we have
is change for the sake of change, without adding any new features.

The thing to remember is the few public Linux drivers we have
take little advantage of the CPM features.  We just configure a few
fixed standard modes (like serial and Ethernet).  The CPM is far
more powerful and flexible than this, so it seems silly to create some
complex method of describing our trivial fixed modes that has no
hope of actually being useful for "real" CPM usage.  Then, when
someone does write a more complex driver, we have all of this
"framework" that just gets in the way instead of being useful.

Thanks.


	-- Dan