lkml.org 
[lkml]   [2010]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: ARM defconfig files
From
Date
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).

> - 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.

> > That way maybe you can wait a bit longer for the other defconfigs
> > and as an extra bonus I won't get flamed for removing these omap
> > defconfigs ;)
>
> Note that Linus is talking about removing all but one or two ARM
> defconfigs - which means your omap3_defconfig will probably be
> eventually culled.

Cheers,
Ben.




\
 
 \ /
  Last update: 2010-06-04 03:05    [W:0.106 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site