From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace•com>
To: linuxppc-dev@ozlabs•org
Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
Date: Wed, 04 Oct 2006 12:05:21 -0400 [thread overview]
Message-ID: <4523DBC1.30108@smiths-aerospace.com> (raw)
In-Reply-To: <80EE3621-ED80-408E-BF04-BA3CB985C769@embeddedalley.com>
Dan Malek wrote:
> On Oct 4, 2006, at 1:52 AM, Benjamin Herrenschmidt wrote:
>
>> 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.
>
>> ... 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
next prev parent reply other threads:[~2006-10-04 16:05 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 12:20 [PATCH 10/11] Add MPC8360EMDS board support Li Yang
2006-09-27 6:39 ` Paul Mackerras
2006-09-27 11:56 ` Vitaly Bordug
2006-09-27 12:02 ` Li Yang-r58472
2006-09-27 12:55 ` Vitaly Bordug
2006-09-27 13:09 ` Ben Warren
2006-09-27 13:20 ` Li Yang-r58472
2006-09-27 13:33 ` Kumar Gala
2006-09-28 6:12 ` Li Yang-r58472
2006-09-30 0:49 ` Paul Mackerras
2006-09-27 14:14 ` Jon Loeliger
2006-09-28 6:38 ` Li Yang-r58472
2006-09-27 14:42 ` Dan Malek
2006-09-27 16:22 ` Olof Johansson
2006-09-28 4:10 ` Dan Malek
2006-09-30 15:56 ` Li Yang
2006-10-04 0:40 ` Paul Mackerras
2006-10-04 13:53 ` Dan Malek
2006-10-04 17:28 ` Tim Bird
2006-10-05 0:27 ` Paul Mackerras
2006-10-05 6:29 ` Eugene Surovegin
2006-10-04 6:08 ` Benjamin Herrenschmidt
2006-10-04 14:48 ` Dan Malek
2006-10-04 23:36 ` Benjamin Herrenschmidt
2006-10-05 0:03 ` Paul Mackerras
2006-10-05 0:08 ` Benjamin Herrenschmidt
2006-10-05 0:16 ` Vitaly Bordug
2006-10-05 6:21 ` Eugene Surovegin
2006-10-05 6:26 ` Benjamin Herrenschmidt
2006-10-05 6:31 ` Eugene Surovegin
2006-10-05 6:33 ` Eugene Surovegin
2006-10-05 6:51 ` Benjamin Herrenschmidt
2006-10-04 5:52 ` Benjamin Herrenschmidt
2006-10-04 14:57 ` Dan Malek
2006-10-04 16:05 ` Jerry Van Baren [this message]
2006-09-27 14:57 ` Sergei Shtylyov
-- strict thread matches above, loose matches on Subject: below --
2006-09-27 13:54 Joakim Tjernlund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4523DBC1.30108@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox