From: Olof Johansson <olof@lixom.net>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org, "Gadiyar, Anand" <gadiyar@ti.com>,
"Pandita, Vikram" <vikram.pandita@ti.com>
Subject: Re: [PATCH v3] arm: omap: Add omap3_defconfig
Date: Tue, 1 Dec 2009 20:14:57 -0600 [thread overview]
Message-ID: <20091202021457.GA30281@lixom.net> (raw)
In-Reply-To: <20091202000819.GF4348@atomide.com>
On Tue, Dec 01, 2009 at 04:08:19PM -0800, Tony Lindgren wrote:
> Hi,
>
> * Olof Johansson <olof@lixom.net> [091201 12:06]:
> > Having one combined defconfig that is the superset of the individual
> > defconfigs for OMAP3 platforms is useful for easily finding build
> > errors. Not to mention convenient as a base if you want to boot several
> > platforms with a single kernel image.
>
> Good idea, that's what many people are already doing.
Yeah, we're doing it internally for the boards we use for early software
work. In PPC land we had good success booting a wide variety (even cross
brands) with single kernels, but ARM isn't quite there yet :)
> > Tony, I noticed linux-next doesn't build many of the OMAP defconfigs,
> > and a handful of them won't build to date. I suggest adding this config,
> > and I'll as Stephen Rothwell to add it as one of the configs that are
> > tested (and build errors reported) for every release.
> >
> > He's reluctant to add too many individual configs since it adds time to
> > each cycle, but one more can surely be acceptable.
>
> I've built tested the for-next patches, they compile just fine
> except for the omap36xx patches which depend on an update to the
> mach-types.
Yep, I noticed that and figured it's no big deal and will happen when
Russell pushes that update.
> If you find some other omap related compile errors in for-next,
> can you please post the errors to this list?
Of course. The build errors I am referring to in this case are not in
your for-next branch when built individually though, but instad when I
built linux-next which included your branch and other work. I.e. others
broke the omap compiles.
Having a generic config that Stephen Rothwell can build before he pushes
out a new release means others will be notified that they broke OMAP,
which will benefit everyone in the long run. He could of course build
individual ones but every added config adds to the turnaround time for him
so he prefers just one or two. Thus the superset config I'm proposing. :)
-Olof
next prev parent reply other threads:[~2009-12-02 2:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-30 3:34 [PATCH] Add omap3_defconfig Olof Johansson
2009-11-30 5:47 ` Gadiyar, Anand
2009-11-30 15:52 ` Olof Johansson
2009-12-01 3:19 ` [PATCH v2] arm: omap: " Olof Johansson
2009-12-01 3:59 ` Pandita, Vikram
2009-12-01 4:13 ` Olof Johansson
2009-12-01 20:09 ` [PATCH v3] " Olof Johansson
2009-12-02 0:08 ` Tony Lindgren
2009-12-02 2:14 ` Olof Johansson [this message]
2009-12-03 0:52 ` [APPLIED] " Tony Lindgren
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=20091202021457.GA30281@lixom.net \
--to=olof@lixom.net \
--cc=gadiyar@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
--cc=vikram.pandita@ti.com \
/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