Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Jerry Van Baren <hidden>
Date: 2006-10-04 16:05:24
Dan Malek wrote:
On Oct 4, 2006, at 1:52 AM, Benjamin Herrenschmidt wrote:quoted
I don't see how a mecanism of feature call at the board support level is in any way incompatible with the device-tree thing.It isn't.quoted
... I'm happy mixing both on powermac :)I know. This was just an opportunity to make people realize that a board port does require the writing of some board specific code. Using the feature call is an excellent model of portability and flexibility. My point was that any BCSR access is necessary to be hidden behind such a function, because it is truly board specific. You can't require the drivers to have this kind of logic in them, they must call out to board support functions for assistance. Just like the powermac ports, embedded drivers will need a feature call at some points during their processing (set up clock routing, IO pin configuration, board specific bus connections, power management, etc). Some board ports may do nothing, others may do lots of work. Therefore, I see no reason why a BSCR address and all of it's associated format can't simply be a #define in a board specific file. There is no need for this in the device tree. -- Dan
The promise of OF for me is that it promises to keep configuration information in _one place_. My experience to date is that my u-boot has a bunch of semi-hardcoded constants, my linux drivers have a bunch of semi-hardcoded constants that likely do not match 1:1 (name and definitely not location) with the equivalent u-boot constants, and some constants are passed from u-boot to linux using the BD structure, which is never defined the same (for me) in u-boot and linux. The result is that, when I upgrade my u-boot and/or linux sources, I end up having to re-find all the places where the constants live (and find some new places), fix them, and then make the u-boot and linux BD structures match. Granted, this isn't insurmountable, but it is a major hassle and should be unnecessary. In a perfect world perhaps we would have one (set of) #include file(s) that had all the configuration information necessary to build u-boot and linux. In the current world, u-boot and linux are in different repositories with different people with different machines (and agendas) doing different development on them, and the result is disjoint. I look at OF to be the /lingua franca/ of PowerPC bootloaders and linux. gvb