From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Wolfgang Denk" <wd@denx.de>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: Please pull linux-2.6-mpc52xx.git
Date: Mon, 17 Mar 2008 20:42:14 -0600 [thread overview]
Message-ID: <fa686aa40803171942u78d2aa68y47c1de3321f727f1@mail.gmail.com> (raw)
In-Reply-To: <20080318002650.AE701246C5@gemini.denx.de>
On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
>
> in message <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com> you wrote:
> >
> > However, I have declined (for now) to pick up the defconfigs for those
> > boards and instead merged in the config features they require into the
> > mpc5200 defconfig. My primary reason for doing so is to increase the
> > likelyhood that full featured kernels are built and tested so that
> > situations where board ports conflict with each other are caught and
> > fixed.
>
> I know what you mean, and I agree with the idea.
>
> Unfortunately I think it's impossible to implement, especially on such
> embedded processors with their high level of pin multiplexing.
>
> For example, if you want to include testing of the FEC ethernet
> driver, you will probably fail to test the second USB port. I think
> it's simply not possible to test all possible options in a single
> kernel configuration - first it doesn't work (for example because of
> pin multiplexing issues), second you will likely not be able to find
> hardware that implements all features at once.
I don't think this example really applies. Yes, I agree that I cannot
test all the functions, but that does not preclude building in all the
drivers and making sure that they don't cause a conflict by just being
present. For instance, I can build a single kernel image right now
that should boot and fully run on the Efika, lite5200, tqm and motion
pro boards (although the Efika has a different wrapper). I can only
test it on the Efika and lite5200 boards and I have to rely on other
people for the boards I don't have. If it breaks; I expect to receive
an irate email in my Inbox telling me to fix it!
pin multiplexing shouldn't be an issue at all. Only the devices which
are instantiated in the device tree will actually get initialized so
if the pins aren't hooked up then it shouldn't be in the tree.
Ideally, the bootloader should take care of the pin multiplexing
setup, but even if it doesn't it can be setup by platform code and
CONFIG_MULTIPLATFORM supports building multiple platforms into a
single image (within a processor family of course; you can't build a
405+6xx multiplatform kernel.) tqm, motionpro and cm boards can all
use simple platform because they all have good firmware ports that
setup the hardware correctly in the first place. lite5200(b) does not
because there are quite a few lite5200 boards 'in the wild' with
firmware that doesn't setup the board the way it should be (or at
least the way Linux likes it).
> > There has been some discussion about having a subdirectory for
> > optimized board configs, but nobody has done anything about it yet.
>
> Is this a hint?
Oh, probably. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2008-03-18 2:42 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-24 7:35 Please pull linux-2.6-mpc52xx.git Grant Likely
[not found] ` <47DE94F4.90804@semihalf.com>
2008-03-17 19:19 ` Grant Likely
2008-03-17 20:59 ` Wolfgang Denk
2008-03-17 21:43 ` Grant Likely
2008-03-17 22:28 ` Wolfgang Denk
2008-03-17 23:43 ` Grant Likely
2008-03-18 0:26 ` Wolfgang Denk
2008-03-18 2:42 ` Grant Likely [this message]
2008-03-18 12:20 ` Josh Boyer
2008-03-18 8:29 ` Bartlomiej Sieka
2008-03-18 10:04 ` Richard Purdie
2008-03-25 15:29 ` Bartlomiej Sieka
2008-03-18 14:47 ` Grant Likely
2008-03-18 16:41 ` Richard Purdie
2008-03-18 16:53 ` Grant Likely
2008-03-25 16:50 ` Bartlomiej Sieka
2008-03-25 18:49 ` Grant Likely
2008-03-25 17:38 ` Bartlomiej Sieka
2008-03-25 18:51 ` Grant Likely
2008-04-01 12:37 ` Bartlomiej Sieka
2008-04-04 11:13 ` Bartlomiej Sieka
2008-04-04 16:11 ` Grant Likely
2008-04-04 16:14 ` Grant Likely
2008-04-04 16:38 ` Olof Johansson
2008-04-04 17:15 ` Josh Boyer
2008-04-04 17:25 ` Grant Likely
2008-04-15 10:34 ` Bartlomiej Sieka
2008-03-18 7:57 ` Bartlomiej Sieka
-- strict thread matches above, loose matches on Subject: below --
2009-01-09 23:09 Grant Likely
2008-11-14 19:20 Grant Likely
2008-11-24 3:38 ` Paul Mackerras
2008-11-24 14:41 ` Grant Likely
2008-05-01 18:04 Grant Likely
2008-04-29 13:34 Grant Likely
2007-10-16 23:22 Grant Likely
2007-10-17 10:27 ` Paul Mackerras
2007-10-17 13:13 ` Grant Likely
2007-10-10 16:30 Grant Likely
2007-10-11 17:35 ` tnt
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=fa686aa40803171942u78d2aa68y47c1de3321f727f1@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=linuxppc-dev@ozlabs.org \
--cc=wd@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).