From: Tony Lindgren <tony@atomide.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Russell King <rmk@arm.linux.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Kevin Hilman <khilman@deeprootsystems.com>,
Daniel Walker <dwalker@codeaurora.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-msm@vger.kernel.org
Subject: Re: ARM defconfig files
Date: Fri, 4 Jun 2010 08:29:44 +0300 [thread overview]
Message-ID: <20100604052943.GE6499@atomide.com> (raw)
In-Reply-To: <1275613325.1931.849.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> [100604 03:56]:
> On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote:
> > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> > > Compiling in multiple ARM platforms is trickier, we would have to get
> > > rid of the duplicate defines like NR_IRQS, then have some common clock
> > > framework etc. Then figure out some way to get rid of Makefile.boot.
> > > Russell probably has some other things in mind that would have to be
> > > changed to make this happen.
>
> Ok so multiple platforms in one kernel is a different subject and could
> warrant a different thread. However it's interesting because we do that
> quite well on powerpc :-)
>
> (Note also that while the device-tree helps make it even easier, it's
> not fundamentally necessary to achieve that goal).
Yeah both platform data and device tree should work just fine.
> > - Find someway to handle the wide variety of interrupt controllers.
>
> We have a very nice and simple interrupt mapping scheme on powerpc that
> makes that quite trivial along with the generic irq changes that went in
> a couple of years ago (which we mostly based on ARM iirc).
>
> We have a structure that define an interrupt numbering domain (which can
> be associated 1:1 with a given controller but doesn't have to), and
> simple APIs to allocate "linux" interrupt numbers associated with a
> given domain/HW number pair. From there, we support multiple domains,
> arbitrary layout and cascades, etc...
>
> > - Be able to handle any multitude of V:P translations, including non-linear
> > alongside linear transations.
>
> For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore
> spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic
> patching would do nicely here though it's problematic with XIP kernels
> (though my understanding is that those are getting less common).
>
> > - Different PAGE_OFFSETs
>
> Does this have to be a per SoC or mach family ? Users can change
> PAGE_OFFSET on powerpc to change the user/kernel split (for example in
> order to get more ioremap space or avoid turning on HIGHMEM) but it's in
> the domain of the config and a kernel with a lower PAGE_OFFSET can
> always boot all platforms even those that don't require it.
>
> Alternatively, you can always try to do like we do on ppc64 with fully
> runtime relocatable kernels :-)
>
> > - Different kernel VM layouts allowing for a variety of different ioremap
> > region sizes
> >
> > and so the list goes on...
>
> That's quite easily done at runtime.
Thanks for all the good info, that will be handy when trying to
figure out how to change things to support multiple ARM platforms.
Regards,
Tony
next prev parent reply other threads:[~2010-06-04 5:30 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100603074548.GA12104@flint.arm.linux.org.uk>
2010-06-03 14:48 ` ARM defconfig files Linus Torvalds
2010-06-03 16:46 ` Tony Lindgren
2010-06-03 18:13 ` Russell King
2010-06-03 21:33 ` Tony Lindgren
2010-06-03 22:45 ` Nicolas Pitre
2010-06-04 4:59 ` Tony Lindgren
2010-06-04 0:23 ` Kevin Hilman
2010-06-04 4:53 ` Tony Lindgren
2010-06-04 1:02 ` Benjamin Herrenschmidt
2010-06-04 5:29 ` Tony Lindgren [this message]
2010-06-04 6:30 ` Geert Uytterhoeven
2010-06-04 6:53 ` Geert Uytterhoeven
2010-06-04 8:52 ` Benjamin Herrenschmidt
2010-06-03 16:53 ` Daniel Walker
2010-06-08 15:30 ` Catalin Marinas
2010-06-08 16:37 ` Daniel Walker
2010-06-03 18:10 ` Russell King
2010-06-03 18:18 ` Linus Torvalds
2010-06-03 18:53 ` Russell King
2010-06-03 18:56 ` Linus Torvalds
2010-06-03 19:20 ` Russell King
2010-06-03 19:35 ` Daniel Walker
2010-06-03 19:45 ` Russell King
2010-06-03 19:49 ` Daniel Walker
2010-06-03 19:57 ` Russell King
2010-06-03 20:06 ` Daniel Walker
2010-06-03 20:18 ` Russell King
2010-06-03 20:20 ` Nicolas Pitre
2010-06-04 1:06 ` Benjamin Herrenschmidt
2010-06-03 20:09 ` Linus Torvalds
2010-06-03 20:31 ` Linus Torvalds
2010-06-03 21:17 ` Tony Lindgren
2010-06-03 22:15 ` Grant Likely
2010-06-04 5:18 ` Felipe Balbi
2010-06-04 11:31 ` Catalin Marinas
2010-06-03 22:24 ` Daniel Walker
2010-06-05 14:12 ` Felipe Contreras
2010-06-05 14:39 ` Linus Torvalds
2010-06-05 16:39 ` Felipe Contreras
2010-06-03 21:48 ` Daniel Walker
2010-06-04 0:36 ` Paul Mackerras
2010-06-04 12:39 ` Grant Likely
2010-06-05 13:47 ` Felipe Contreras
2010-06-03 20:34 ` Nicolas Pitre
2010-06-03 20:05 ` Linus Torvalds
2010-06-06 3:28 ` david
2010-06-03 18:20 ` Daniel Walker
2010-06-03 18:21 ` Linus Torvalds
2010-06-03 18:30 ` Al Viro
2010-06-03 19:26 ` Paul Mundt
2010-06-14 8:32 ` Uwe Kleine-König
2010-06-30 10:40 ` Uwe Kleine-König
2010-07-12 15:55 ` Uwe Kleine-König
2010-07-12 16:51 ` Linus Torvalds
2010-07-12 17:32 ` Russell King - ARM Linux
2010-07-12 17:40 ` Linus Torvalds
2010-07-12 18:50 ` Uwe Kleine-König
2010-07-12 19:04 ` Linus Torvalds
2010-07-12 19:17 ` Nicolas Pitre
2010-07-12 19:34 ` Linus Torvalds
2010-07-12 19:50 ` Grant Likely
2010-07-13 7:07 ` Uwe Kleine-König
2010-07-13 8:07 ` optimized script [Was: ARM defconfig files] Uwe Kleine-König
2010-07-13 18:04 ` Olof Johansson
2010-07-13 23:39 ` Nicolas Pitre
2010-07-13 18:32 ` ARM defconfig files Grant Likely
2010-07-12 19:59 ` Uwe Kleine-König
2010-07-12 20:14 ` Nicolas Pitre
2010-07-12 19:09 ` Nicolas Pitre
2010-07-12 20:31 ` Arnd Bergmann
2010-07-12 20:50 ` Nicolas Pitre
2010-07-12 23:05 ` David Brown
2010-07-12 23:18 ` Linus Torvalds
2010-07-12 23:34 ` David Brown
2010-07-13 0:55 ` Nicolas Pitre
2010-07-14 9:13 ` Felipe Contreras
2010-07-14 13:20 ` Uwe Kleine-König
2010-07-14 17:37 ` Tony Luck
2010-07-13 18:32 ` Rob Landley
2010-07-12 20:06 ` Russell King - ARM Linux
2010-07-12 20:29 ` Nicolas Pitre
2010-07-12 21:54 ` Linus Torvalds
2010-07-14 9:21 ` Felipe Contreras
2010-06-03 18:41 ` Russell King
2010-06-03 18:53 ` Linus Torvalds
2010-06-06 3:53 ` david
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=20100604052943.GE6499@atomide.com \
--to=tony@atomide.com \
--cc=benh@kernel.crashing.org \
--cc=dwalker@codeaurora.org \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--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).