Thread (34 messages) 34 messages, 12 authors, 2006-10-05

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help