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

[Kumar Gala]

On Mar 30, 2006, at 9:14 AM, Dan Malek wrote:

>
> 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.

Oh, I agree with you.  This becomes more obvious with QE where  
everything is a UCC channel.

>> * 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.

still waiting :)

>> * 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.

Ok, good.

>> * ...? [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.

I'm hopefully not suggesting that or at least not something I see as  
this extensive.

> 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.

I know.

I guess what I'd suggest is something that makes letting the kernel  
know about serial & enet usage on the CPM is the extent to take this  
to start with.  If in time we have more drivers for more things  
great, then extend it then.  I dont see any reason we can't leverage  
the flat-dev-tree to have a single way to describe the serial & enet  
configs for a board.

I see how you can see this as duplication of a solved problem.   
However, we need some place to describe some basic config info that  
we have in arch/ppc for arch/powerpc and flat-dev/.dts is that  
mechanism.  While we are moving it out of the kernel proper, I think  
the idea is that over time using the flat-dev tree will allow the  
information we have to be described in one place and shared between  
kernel & firmware.

(and if Vitaly finishes this off we can beat him up to add kgdb  
support back to cpm_uart :)

- kumar