From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from buildserver.ru.mvista.com (unknown [85.21.88.6]) by ozlabs.org (Postfix) with ESMTP id 3B1DB67A5A for ; Fri, 31 Mar 2006 03:10:23 +1100 (EST) Date: Thu, 30 Mar 2006 19:10:16 +0400 From: Vitaly Bordug To: Kumar Gala Subject: Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation Message-ID: <20060330191016.1de7c84b@vitb.ru.mvista.com> In-Reply-To: <3A2715AD-F459-4AB3-B01B-13301BE2B908@kernel.crashing.org> References: <20060328161431.18517.82573.stgit@vitb.ru.mvista.com> <20060330142626.1a9d22f5@vitb.ru.mvista.com> <0f0e0fbbf56f73879a70f785c497756c@embeddededge.com> <9ede6f664a3419c5dda34c5e1911a7e6@embeddedalley.com> <3A2715AD-F459-4AB3-B01B-13301BE2B908@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: linuxppc-dev , Paul Mackerras List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 30 Mar 2006 09:43:38 -0600 Kumar Gala 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