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

[Vitaly Bordug]

On Thu, 30 Mar 2006 09:43:38 -0600
Kumar Gala <galak at kernel.crashing.org> wrote:

> 
> 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.
> 
Yes, that's definitely what it is intended to be...

> 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 the results we have now for 85xx family look very nice using this approach.
> (and if Vitaly finishes this off we can beat him up to add kgdb  
> support back to cpm_uart :)

Hrm, I've added that to kgdb already... I even have the KGDB stuff implemented in the platform-device-reworked cpm_uart driver :)

-- 
Sincerely, 
Vitaly