[PATCH] powerpc: consolidate mpc83xx platform files

Kim Phillips kim.phillips at freescale.com
Thu Dec 14 05:21:43 EST 2006


On Wed, 13 Dec 2006 00:07:43 -0600
Kumar Gala <galak at kernel.crashing.org> wrote:

> 
> On Dec 12, 2006, at 11:25 PM, Geoff Thorpe wrote:
> 
> > Kumar Gala wrote:
> >
> >> It adds code to all those people that don't need it just so we  
> >> don't  duplicate a few lines of source code.
> >>
> >
> > Sounds like you're describing the raison d'être for device-trees  
> > though? After all, if you want to build a kernel that supports  
> > these minor h/w variations depending on the device-tree it's booted  
> > with, then the "few lines of duplicated source code" you're talking  
> > about would also "add code to all those people that don't need it".
> 
> No, because those people (myself included) wouldn't build in support  
> for the freescale referend boards into the kernel I'm building for my  
> custom board.

my understanding is that embedded developers would *add* code to the generic platform code base that this exercise proves exists.

> 
> My question has been what's the value in trying to save a few lines  
> of code for the reference boards.  The idea of a generic board  
> doesn't make sense in the embedded space.  Just because the reference  
> boards for mpc83xx look similar doesn't mean anything else using it  
> will.  I know both of the boards I've worked would and still do  
> require custom code.

the boards aren't that similar, it's just that all board specific code has actually migrated to the right place for it; it now goes where it belongs, e.g. RTCs go to the RTC subsystem, PHYs go the PHY layer, etc.

> 
> The reason for the custom code is the device tree doesn't describe  
> all variants of all hardware.  Its just not spec'd that far. How do  
> you describe the FPGA and local bus interface to it on my board? How  
> do you describe the compact flash drive on localbus?  How do you  
> describe the microcontroller connect over SPI?  You dont because  
> there isn't any spec.  The majority of developers dont have the time  
> to spend trying to come up with one to solve their specific problem  
> so they hard code some solution that works for them.

this has always been the case, and we're not changing that. You can still add code to support unspec'ed functionality. We're just trying to refactor the code for its obvious benefits.

> 
> Over time will we improve the spec, it will cover more cases and  
> that's great, but trying to come up with some generic board port  
> right now is a waste of time.  There are a ton of better things to be  
> spending your guys time on.
> 
> I've yet to see anything that describes any real value to a customer.

The ability to have a single kernel run on multiple boards is of value, esp. if the only thing preventing that from happening is a strcmp between a kernel string and a string in the dt (both software sources).

> 
> > Kumar Gala also wrote:
> >
> >> On Dec 12, 2006, at 4:41 PM, Scott Wood wrote:
> >>
> >>> And an 83xx-generic machine description does not stop them from   
> >>> doing so.  "Generic" does not mean "universal".  It means  
> >>> "there's  nothing special about this board".  If you need board- 
> >>> specific code  in the kernel, then don't label it generic.
> >>>
> >>
> >> But what value does this have?  83xx, and the majority of  
> >> freescale's  devices are not put into something as standard as a  
> >> desktop computer.
> >
> > Then what value do device-trees have at all? Why require new code  
> > for new h/w if it's technically unnecessary? If I've understood  
> > correctly (I confess to not having followed all of the discussion  
> > nor the finer technical points), this would require new code to  
> > find its way "upstream" (to whoever/wherever/whatever that means)  
> > from freescale and then downstream to it's user before the h/w is  
> > supported, when this situation is precisely what device-trees  
> > apparently ought to resolve.
> 
> This is partial true, but if freescale puts out a new processor/board  
> there is some expectation that its going to require some new code.   
> If nothing else it's going to require a device-tree be provided.  If  
> the concern is about how long it takes to support new HW for existing  
> functionality I think that's BS.
> 
I don't think it's that, my problem is the redundancy in the code. I wanted it gone before we added more :)

> > Maybe I'm missing something (quite possible). Ben's objection  
> > seemed to be one of naming, but yours seems to be that new h/w  
> > should require new code because it's not wintel fodder for desktop  
> > grannies? So why bother separating h/w description from the  
> > compiled kernel in the first place?
> 
> My argument is that trying to describe all HW variants for embedded  
> systems in the device tree is never going to happen.  Describing the  
> generality of devices on SoC is useful because everyone has to deal  
> with that.  Once you start going past that you get into trouble  
> because of all the various ways people hook things up to busses.

but this patch isn't claiming to do that.  It doesn't stop providing a base to start from.

> There are a number of subtle reasons I think a generic port is  
> pointless and the only arguments I've heard are some concern about  
> duplication of code and the ability to boot a kernel w/o modification  
> on new HW.

yes, and those are indeed valid points.  I for one, have access to multiple 83xx based boards and would love to not have to build a kernel that has one text in a string preventing it from booting on another.

> The duplication code I believe is a style issue and we can reduce the  
> duplication to a minimum.  The ability to boot a kernel w/o  
> modification on new HW is a nice to have, but I dont see this as  
> providing any "real value".
> 
> I'd rather see people spending time on problems which need solutions  
> and this isn't one of them.
> 
sorry, this redundancy has been going on for too long.  I brought this issue up a long time ago on this list asking for your opinion and got no response.  Now a new board is here.  So how long would you have us submit code generated by sed?

Having said all that, I acknowledge your comments.  For now, I'm willing to settle for at least one line of less redundant code than what's in the tree today.  How can we make that happen?

Kim



More information about the Linuxppc-dev mailing list