From: Tony Lindgren <tony@atomide.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Ellerman <michael@ellerman.id.au>,
Kevin Hilman <khilman@deeprootsystems.com>,
Daniel Walker <dwalker@codeaurora.org>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1
Date: Thu, 3 Jun 2010 19:11:05 +0300 [thread overview]
Message-ID: <20100603161104.GK30622@atomide.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1006022112320.8175@i5.linux-foundation.org>
* Linus Torvalds <torvalds@linux-foundation.org> [100603 07:25]:
>
>
> On Thu, 3 Jun 2010, Michael Ellerman wrote:
> >
> > You can sort of do that today, by just storing a delta, but oldconfig
> > will silently turn off things you have enabled if prereqs change, so
> > that doesn't really work I think.
>
> I think you can do it today with various hacks. Up to and including
> basically doing something that just selects the options you want.
>
> IOW, you could likely have a human-written Kconfig.<platform> file that
> just does
>
> define_bool MYPLATFORM y
> select .. everything I need ..
>
> include Kconfig.main
>
> or a number of other tricks.
I agree all the defconfigs are a pain just for the omaps alone.
If this is of any help we could now just keep omap3_defconfig for
arch/arm/mach-omap2 and get rid of 23 config files:
$ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | wc -l
23
It needs some more work for omap2 though to boot to userspace as
there are still some known issues with ARMv6 vs ARMv7 support and
VFP2 vs 3 support. Will try to look at fixing those again when
I have a chance.
Then making the multi-omap thing work on all omap1 boards would
cut down another 15 defconfigs, that should be also doable.
To be able to compile in multiple arm architectures we would have
to get rid of the Makefile.boot files and NR_IRQS and then have
some kind of common clock framework at least.
I did some experiments compiling in both mach-omap1 and mach-omap2
a few years back using ARMv5 flags, there were probably other issues
too like some conflicting defines.
Cheers,
Tony
next prev parent reply other threads:[~2010-06-03 16:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 21:52 [GIT PULL] ARM MSM updates for 2.6.35-rc1 Daniel Walker
2010-06-02 20:50 ` Daniel Walker
2010-06-02 21:27 ` Linus Torvalds
2010-06-02 21:39 ` Linus Torvalds
2010-06-02 21:56 ` Daniel Walker
2010-06-02 22:30 ` Daniel Walker
2010-06-02 23:27 ` Kevin Hilman
2010-06-03 1:20 ` Linus Torvalds
2010-06-03 3:44 ` Michael Ellerman
2010-06-03 4:26 ` Linus Torvalds
2010-06-03 16:11 ` Tony Lindgren [this message]
2010-06-04 5:34 ` Eric Miao
2010-06-03 4:45 ` Ben Dooks
2010-06-03 5:36 ` Ben Dooks
2010-06-04 8:27 ` Vincent Sanders
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=20100603161104.GK30622@atomide.com \
--to=tony@atomide.com \
--cc=dwalker@codeaurora.org \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@ellerman.id.au \
--cc=torvalds@linux-foundation.org \
/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).