From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nommos.sslcatacombnetworking.com (nommos.sslcatacombnetworking.com [67.18.224.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 99A9B679EF for ; Fri, 31 Mar 2006 01:36:55 +1100 (EST) In-Reply-To: <0f0e0fbbf56f73879a70f785c497756c@embeddededge.com> References: <20060328161431.18517.82573.stgit@vitb.ru.mvista.com> <20060330142626.1a9d22f5@vitb.ru.mvista.com> <0f0e0fbbf56f73879a70f785c497756c@embeddededge.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: From: Kumar Gala Subject: Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation Date: Thu, 30 Mar 2006 08:37:00 -0600 To: Dan Malek Cc: linuxppc-dev , Paul Mackerras List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mar 30, 2006, at 7:09 AM, Dan Malek wrote: > > On Mar 30, 2006, at 5:26 AM, Vitaly Bordug wrote: > >> - 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