Making ARM multiplatform kernels DT-only?

Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

Hi everyone,

I've been discussing multiplatform kernels with a few people recently,
and we will have a lot of discussion sessions about this at Linaro
Connect in Hong Kong.

One question that came up repeatedly is whether we should support all
possible board files for each platform in a multiplatform kernel,
or just the ones that are already using DT probing. I would like
to get a quick poll of opinions on that and I've tried to put those
people on Cc that would be most impacted by this, i.e. the maintainers
for platforms that have both DT and non-DT board files at the moment.

My feeling is that we should just mandate DT booting for multiplatform
kernels, because it significantly reduces the combinatorial space
at compile time, avoids a lot of legacy board files that we cannot
test anyway, reduces the total kernel size and gives an incentive
for people to move forward to DT with their existing boards.

The counterargument is that we won't be able to support all the
boards we currently do when the user switches on multiplatform,
but I think that is acceptable.
Note that I would still want to allow users to build platforms
separately in order to enable the ATAG style board files, even
for platforms that are not multiplatform capable.

Other opinions?

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:50 Thu 03 May     , Arnd Bergmann wrote:
> Hi everyone,
> 
> I've been discussing multiplatform kernels with a few people recently,
> and we will have a lot of discussion sessions about this at Linaro
> Connect in Hong Kong.
> 
> One question that came up repeatedly is whether we should support all
> possible board files for each platform in a multiplatform kernel,
> or just the ones that are already using DT probing. I would like
> to get a quick poll of opinions on that and I've tried to put those
> people on Cc that would be most impacted by this, i.e. the maintainers
> for platforms that have both DT and non-DT board files at the moment.
> 
> My feeling is that we should just mandate DT booting for multiplatform
> kernels, because it significantly reduces the combinatorial space
> at compile time, avoids a lot of legacy board files that we cannot
> test anyway, reduces the total kernel size and gives an incentive
> for people to move forward to DT with their existing boards.
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> 
> The counterargument is that we won't be able to support all the
> boards we currently do when the user switches on multiplatform,
> but I think that is acceptable.
> Note that I would still want to allow users to build platforms
> separately in order to enable the ATAG style board files, even
> for platforms that are not multiplatform capable.

> 
> Other opinions?
it will also avoid us alot of trouble and work to fix old platform that we can
not even test

Best Regards,
J.

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> Hi everyone,
> 
> I've been discussing multiplatform kernels with a few people recently,
> and we will have a lot of discussion sessions about this at Linaro
> Connect in Hong Kong.
> 
> One question that came up repeatedly is whether we should support all
> possible board files for each platform in a multiplatform kernel,
> or just the ones that are already using DT probing. I would like
> to get a quick poll of opinions on that and I've tried to put those
> people on Cc that would be most impacted by this, i.e. the maintainers
> for platforms that have both DT and non-DT board files at the moment.
> 
> My feeling is that we should just mandate DT booting for multiplatform
> kernels, because it significantly reduces the combinatorial space
> at compile time, avoids a lot of legacy board files that we cannot
> test anyway, reduces the total kernel size and gives an incentive
> for people to move forward to DT with their existing boards.
> 
> The counterargument is that we won't be able to support all the
> boards we currently do when the user switches on multiplatform,
> but I think that is acceptable.
> Note that I would still want to allow users to build platforms
> separately in order to enable the ATAG style board files, even
> for platforms that are not multiplatform capable.

I'm basing my comments off mach-zynq.

How about we take the following steps towards it?

1. create arch/arm/include/mach/ which contains standardized headers
   for DT based implementations.  This must include all headers included
   by asm/ or linux/ includes.  This will also be the only mach/ header
   directory included for code outside of arch/arm/mach-*.  This also
   acts as the 'default' set of mach/* includes for stuff like timex.h
   and the empty hardware.h

2. DT based mach-* directories do not have an include directory; their
   include files must be located in the main include/ heirarchy if shared
   with other parts of the kernel, otherwise they must be in the mach-*
   directory.

3. Allow build multiple mach-* directories (which we already do... see
   the samsung stuff.)

We still have irqs.h being SoC dependent, and we still haven't taken
debug-macros.S far enough along to get rid of that.  Then there's also
the problem of uncompress.h.  The last piece of the puzzle is the common
clock stuff.

So, I think we're still a way off it yet - maybe six months or so.

Re: Making ARM multiplatform kernels DT-only?

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:04 Thu 03 May     , Russell King - ARM Linux wrote:
> On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> > Hi everyone,
> > 
> > I've been discussing multiplatform kernels with a few people recently,
> > and we will have a lot of discussion sessions about this at Linaro
> > Connect in Hong Kong.
> > 
> > One question that came up repeatedly is whether we should support all
> > possible board files for each platform in a multiplatform kernel,
> > or just the ones that are already using DT probing. I would like
> > to get a quick poll of opinions on that and I've tried to put those
> > people on Cc that would be most impacted by this, i.e. the maintainers
> > for platforms that have both DT and non-DT board files at the moment.
> > 
> > My feeling is that we should just mandate DT booting for multiplatform
> > kernels, because it significantly reduces the combinatorial space
> > at compile time, avoids a lot of legacy board files that we cannot
> > test anyway, reduces the total kernel size and gives an incentive
> > for people to move forward to DT with their existing boards.
> > 
> > The counterargument is that we won't be able to support all the
> > boards we currently do when the user switches on multiplatform,
> > but I think that is acceptable.
> > Note that I would still want to allow users to build platforms
> > separately in order to enable the ATAG style board files, even
> > for platforms that are not multiplatform capable.
> 
> I'm basing my comments off mach-zynq.
> 
> How about we take the following steps towards it?
> 
> 1. create arch/arm/include/mach/ which contains standardized headers
>    for DT based implementations.  This must include all headers included
>    by asm/ or linux/ includes.  This will also be the only mach/ header
>    directory included for code outside of arch/arm/mach-*.  This also
>    acts as the 'default' set of mach/* includes for stuff like timex.h
>    and the empty hardware.h
> 
> 2. DT based mach-* directories do not have an include directory; their
>    include files must be located in the main include/ heirarchy if shared
>    with other parts of the kernel, otherwise they must be in the mach-*
>    directory.
on at91 I'm working to drop it

but will have to keep for old non DT board
> 
> 3. Allow build multiple mach-* directories (which we already do... see
>    the samsung stuff.)
> 
> We still have irqs.h being SoC dependent, and we still haven't taken
> debug-macros.S far enough along to get rid of that.  Then there's also
> the problem of uncompress.h.  The last piece of the puzzle is the common
> clock stuff.
on the decompressor I was thinking to use the DT to select it
by using a compatible string

if it's ok with you

Best Regards,
J.

Re: Making ARM multiplatform kernels DT-only?

[Deepak Saxena]

On 3 May 2012 07:04, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
>> Hi everyone,
>>
>> I've been discussing multiplatform kernels with a few people recently,
>> and we will have a lot of discussion sessions about this at Linaro
>> Connect in Hong Kong.
>>
>> One question that came up repeatedly is whether we should support all
>> possible board files for each platform in a multiplatform kernel,
>> or just the ones that are already using DT probing. I would like
>> to get a quick poll of opinions on that and I've tried to put those
>> people on Cc that would be most impacted by this, i.e. the maintainers
>> for platforms that have both DT and non-DT board files at the moment.
>>
>> My feeling is that we should just mandate DT booting for multiplatform
>> kernels, because it significantly reduces the combinatorial space
>> at compile time, avoids a lot of legacy board files that we cannot
>> test anyway, reduces the total kernel size and gives an incentive
>> for people to move forward to DT with their existing boards.
>>
>> The counterargument is that we won't be able to support all the
>> boards we currently do when the user switches on multiplatform,
>> but I think that is acceptable.
>> Note that I would still want to allow users to build platforms
>> separately in order to enable the ATAG style board files, even
>> for platforms that are not multiplatform capable.
>
> I'm basing my comments off mach-zynq.
>
> How about we take the following steps towards it?
>
> 1. create arch/arm/include/mach/ which contains standardized headers
>   for DT based implementations.  This must include all headers included
>   by asm/ or linux/ includes.  This will also be the only mach/ header
>   directory included for code outside of arch/arm/mach-*.  This also
>   acts as the 'default' set of mach/* includes for stuff like timex.h
>   and the empty hardware.h
>
> 2. DT based mach-* directories do not have an include directory; their
>   include files must be located in the main include/ heirarchy if shared
>   with other parts of the kernel, otherwise they must be in the mach-*
>   directory.

What do we do about all the mach-specific driver related headers that are
currently littered all over arch/arm/mach*? Things like <mach/mx3fb.h> and
<mach/ohci.h>? Long term I think we should move everything that is driver
specific out of arch/arm but that is fairly large task and I think
there's a lot of
intertwining between stuff that's driver specific and stuff that
should actually live
in <mach/*>.  Arnd (or maybe Nicolas?) suggested something along the lines
of scripting something to figure out the constants required for a
specific driver
and pulling them out of <mach/*.h> and into that driver as a starting point.

> 3. Allow build multiple mach-* directories (which we already do... see
>   the samsung stuff.)
>
> We still have irqs.h being SoC dependent, and we still haven't taken
> debug-macros.S far enough along to get rid of that.  Then there's also
> the problem of uncompress.h.  The last piece of the puzzle is the common
> clock stuff.

There's also some stuff outside of arch/arm that needs cleanup
including USB driver
refactoring and some other bits that I can't recall atm. Right now we
can build one and
only one host controller   inteface, even as modules. Not too
difficult of a problem to
solve and not critical to get the SOCs booting, but needed to be
usable on real devices.

We'll probably find more stuff as we start actually building things together.

~Deepak

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Thu, May 03, 2012 at 11:31:13PM -0700, Deepak Saxena wrote:
> On 3 May 2012 07:04, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> >> Hi everyone,
> >>
> >> I've been discussing multiplatform kernels with a few people recently,
> >> and we will have a lot of discussion sessions about this at Linaro
> >> Connect in Hong Kong.
> >>
> >> One question that came up repeatedly is whether we should support all
> >> possible board files for each platform in a multiplatform kernel,
> >> or just the ones that are already using DT probing. I would like
> >> to get a quick poll of opinions on that and I've tried to put those
> >> people on Cc that would be most impacted by this, i.e. the maintainers
> >> for platforms that have both DT and non-DT board files at the moment.
> >>
> >> My feeling is that we should just mandate DT booting for multiplatform
> >> kernels, because it significantly reduces the combinatorial space
> >> at compile time, avoids a lot of legacy board files that we cannot
> >> test anyway, reduces the total kernel size and gives an incentive
> >> for people to move forward to DT with their existing boards.
> >>
> >> The counterargument is that we won't be able to support all the
> >> boards we currently do when the user switches on multiplatform,
> >> but I think that is acceptable.
> >> Note that I would still want to allow users to build platforms
> >> separately in order to enable the ATAG style board files, even
> >> for platforms that are not multiplatform capable.
> >
> > I'm basing my comments off mach-zynq.
> >
> > How about we take the following steps towards it?
> >
> > 1. create arch/arm/include/mach/ which contains standardized headers
> >   for DT based implementations.  This must include all headers included
> >   by asm/ or linux/ includes.  This will also be the only mach/ header
> >   directory included for code outside of arch/arm/mach-*.  This also
> >   acts as the 'default' set of mach/* includes for stuff like timex.h
> >   and the empty hardware.h
> >
> > 2. DT based mach-* directories do not have an include directory; their
> >   include files must be located in the main include/ heirarchy if shared
> >   with other parts of the kernel, otherwise they must be in the mach-*
> >   directory.
> 
> What do we do about all the mach-specific driver related headers that are
> currently littered all over arch/arm/mach*? Things like <mach/mx3fb.h> and
> <mach/ohci.h>?

Such platforms with that kind of stuff haven't fully converted to DT,
because these sorts of things are platform dependent yet aren't represented
in DT.

> Arnd (or maybe Nicolas?) suggested something along the lines
> of scripting something to figure out the constants required for a
> specific driver and pulling them out of <mach/*.h> and into that
> driver as a starting point.

But that doesn't solve the problem.  Take a USB driver where the register
layouts are different.  To have it work on two different platforms, you'd
need to build the driver twice.  Not only that, you'd also need to figure
out some way to register only one copy of that.

So really, the header file thing is just a sign of larger blocking issues
to getting those kinds of drivers working on a multiplatform kernel, and
no amount of header munging will sort it out.  The fact of that situation
is the driver concerned is _not_ multiplatform and shouldn't be built in
that situation until it is fixed.

> > 3. Allow build multiple mach-* directories (which we already do... see
> >   the samsung stuff.)
> >
> > We still have irqs.h being SoC dependent, and we still haven't taken
> > debug-macros.S far enough along to get rid of that.  Then there's also
> > the problem of uncompress.h.  The last piece of the puzzle is the common
> > clock stuff.
> 
> There's also some stuff outside of arch/arm that needs cleanup
> including USB driver
> refactoring and some other bits that I can't recall atm. Right now we
> can build one and
> only one host controller   inteface, even as modules. Not too
> difficult of a problem to
> solve and not critical to get the SOCs booting, but needed to be
> usable on real devices.

That's already a problem today, and has nothing to do with this current
issue - what I'm saying is the problem can't be made to go away through
header file stuff, so this issue is not relevant to this discussion.

That's not to say it doesn't need to be resolved, because it does.  It's
just no reason to argue against what I've said.

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Thursday 03 May 2012, Russell King - ARM Linux wrote:
> I'm basing my comments off mach-zynq.

It's a different question because mach-zynq is already DT-only, but we
can also discuss this for a bit.

> How about we take the following steps towards it?
> 
> 1. create arch/arm/include/mach/ which contains standardized headers
>    for DT based implementations.  This must include all headers included
>    by asm/ or linux/ includes.  This will also be the only mach/ header
>    directory included for code outside of arch/arm/mach-*.  This also
>    acts as the 'default' set of mach/* includes for stuff like timex.h
>    and the empty hardware.h
>
> 2. DT based mach-* directories do not have an include directory; their
>    include files must be located in the main include/ heirarchy if shared
>    with other parts of the kernel, otherwise they must be in the mach-*
>    directory.

My idea for the header files was slightly different, reorganizing only
the headers that actually conflict between the platforms renaming the
ones that conflict by name but not by content.

I know you are aware of my experiment with just renaming the header files
from mach/*.h to mach-*/*.h, and that has helped me a lot in understanding
the specific problems. I don't care about the specific names of the headers
but it has helped so far in identifying which drivers are already relying
on a specific platform's version of a header and which ones multiplex
between different platforms (e.g. sa1100/pxa/mmp or s3c*/s5p*/exynos)
and need more work. 

I also wouldn't change anything for the current configurations where
you only have one mach-* directory at a time (or the samsung speciality).

My plan is to have multiplatform kernels in parallel with what we have now,
so we can avoid breaking working machines but also play with multiplatform
configurations at the same time for a subset of the platforms and with
certain restrictions (not all board files, not all drivers, no generic
early printk, ...).

> 3. Allow build multiple mach-* directories (which we already do... see
>    the samsung stuff.)

Incidentally, the samsung headers are what are currently causing the most
headaches regarding the header files, because they use a lot of files
with soc-specific definitions for the same symbols, which means significant
reorganization of the code using to to turn that into run-time selectable
values.

> We still have irqs.h being SoC dependent, and we still haven't taken
> debug-macros.S far enough along to get rid of that.

I believe the irqs.h conflict is only for the NR_IRQS constant, all other
defines in there should only be used inside of the mach-* directory,
or not at all for fully DT-based platforms.

> Then there's also the problem of uncompress.h.  The last piece of the
> puzzle is the common clock stuff.

Initially, I think we can live without debug-macros.S and uncompress.h
and change the code using those to just not output anything when
MULTIPLATFORM is enabled: you'd have to disable MULTIPLATFORM in order
to debug the early boot process and hope that any bugs are not
specific to multiplatform configurations. In the long run, we probably
want to have a better solution, but it's not on my hotlist.

The common clock support OTOH is definitely a requirement as soon as
we want to actually run multiplatform kernels rather than just building
them.
 
> So, I think we're still a way off it yet - maybe six months or so.

True, but in order to work on the points you raised and a few others,
I would like to know where we're heading because it does impact
some decisions like whether we need to make all initcalls in non-DT
board files aware of potentially being run on other platforms.

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Rob Herring]

On 05/04/2012 07:20 AM, Arnd Bergmann wrote:
> On Thursday 03 May 2012, Russell King - ARM Linux wrote:
>> I'm basing my comments off mach-zynq.
> 
> It's a different question because mach-zynq is already DT-only, but we
> can also discuss this for a bit.
> 
>> How about we take the following steps towards it?
>>
>> 1. create arch/arm/include/mach/ which contains standardized headers
>>    for DT based implementations.  This must include all headers included
>>    by asm/ or linux/ includes.  This will also be the only mach/ header
>>    directory included for code outside of arch/arm/mach-*.  This also
>>    acts as the 'default' set of mach/* includes for stuff like timex.h
>>    and the empty hardware.h
>>
>> 2. DT based mach-* directories do not have an include directory; their
>>    include files must be located in the main include/ heirarchy if shared
>>    with other parts of the kernel, otherwise they must be in the mach-*
>>    directory.
> 
> My idea for the header files was slightly different, reorganizing only
> the headers that actually conflict between the platforms renaming the
> ones that conflict by name but not by content.
> 
> I know you are aware of my experiment with just renaming the header files
> from mach/*.h to mach-*/*.h, and that has helped me a lot in understanding
> the specific problems. I don't care about the specific names of the headers
> but it has helped so far in identifying which drivers are already relying
> on a specific platform's version of a header and which ones multiplex
> between different platforms (e.g. sa1100/pxa/mmp or s3c*/s5p*/exynos)
> and need more work. 
> 
> I also wouldn't change anything for the current configurations where
> you only have one mach-* directory at a time (or the samsung speciality).
> 
> My plan is to have multiplatform kernels in parallel with what we have now,
> so we can avoid breaking working machines but also play with multiplatform
> configurations at the same time for a subset of the platforms and with
> certain restrictions (not all board files, not all drivers, no generic
> early printk, ...).
> 

Many of the headers are simply platform_data structs which may still be
needed on DT platforms, but could be moved elsewhere.

>> 3. Allow build multiple mach-* directories (which we already do... see
>>    the samsung stuff.)
> 
> Incidentally, the samsung headers are what are currently causing the most
> headaches regarding the header files, because they use a lot of files
> with soc-specific definitions for the same symbols, which means significant
> reorganization of the code using to to turn that into run-time selectable
> values.
> 
>> We still have irqs.h being SoC dependent, and we still haven't taken
>> debug-macros.S far enough along to get rid of that.
> 
> I believe the irqs.h conflict is only for the NR_IRQS constant, all other
> defines in there should only be used inside of the mach-* directory,
> or not at all for fully DT-based platforms.

A DT-enabled platform does not need irqs.h or NR_IRQS. SPARSE_IRQ should
be selected for DT. However, some DT enabled platforms don't have all
irq chips converted to domains and may still need to set the mach .nr_irqs.

> 
>> Then there's also the problem of uncompress.h.  The last piece of the
>> puzzle is the common clock stuff.

The smp/hotplug/localtimer related functions are still global. Marc Z
has posted patches for this, but I haven't seen recent activity. This
and clocks were the 2 main issues I saw trying to build 2 platforms
together. highbank and picoxcell could be built together since only
highbank has clocks and smp.

gpio.h is still required, but empty for most platforms.

Rob

> Initially, I think we can live without debug-macros.S and uncompress.h
> and change the code using those to just not output anything when
> MULTIPLATFORM is enabled: you'd have to disable MULTIPLATFORM in order
> to debug the early boot process and hope that any bugs are not
> specific to multiplatform configurations. In the long run, we probably
> want to have a better solution, but it's not on my hotlist.
> 
> The common clock support OTOH is definitely a requirement as soon as
> we want to actually run multiplatform kernels rather than just building
> them.
>  
>> So, I think we're still a way off it yet - maybe six months or so.
> 
> True, but in order to work on the points you raised and a few others,
> I would like to know where we're heading because it does impact
> some decisions like whether we need to make all initcalls in non-DT
> board files aware of potentially being run on other platforms.
> 
> 	Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Fri, May 04, 2012 at 11:39:30AM -0500, Rob Herring wrote:
> Many of the headers are simply platform_data structs which may still be
> needed on DT platforms, but could be moved elsewhere.

Those should be in include/linux/platform.

> >> Then there's also the problem of uncompress.h.  The last piece of the
> >> puzzle is the common clock stuff.
> 
> The smp/hotplug/localtimer related functions are still global. Marc Z
> has posted patches for this, but I haven't seen recent activity. This
> and clocks were the 2 main issues I saw trying to build 2 platforms
> together. highbank and picoxcell could be built together since only
> highbank has clocks and smp.
> 
> gpio.h is still required, but empty for most platforms.

Those empty gpio.h files are definitely a candidate for going into
arch/arm/include/mach/gpio.h, and then all those 12-byte mach/gpio.h can
be deleted (13 files).

We've not had any progress on the gpio.h issue since I did the last round
of cleanup; the next stage was to persuade SoC maintainers to get rid of
their optimized versions which aren't compatible with multi-platform
kernels.

I don't know if folk are expecting me to push that forwards or whether
there's someone else working on that aspect of it...

So this issue really does need to be progressed too.

Re: Making ARM multiplatform kernels DT-only?

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:56 Fri 04 May     , Russell King - ARM Linux wrote:
> On Fri, May 04, 2012 at 11:39:30AM -0500, Rob Herring wrote:
> > Many of the headers are simply platform_data structs which may still be
> > needed on DT platforms, but could be moved elsewhere.
> 
> Those should be in include/linux/platform.
> 
> > >> Then there's also the problem of uncompress.h.  The last piece of the
> > >> puzzle is the common clock stuff.
> > 
> > The smp/hotplug/localtimer related functions are still global. Marc Z
> > has posted patches for this, but I haven't seen recent activity. This
> > and clocks were the 2 main issues I saw trying to build 2 platforms
> > together. highbank and picoxcell could be built together since only
> > highbank has clocks and smp.
> > 
> > gpio.h is still required, but empty for most platforms.
> 
> Those empty gpio.h files are definitely a candidate for going into
> arch/arm/include/mach/gpio.h, and then all those 12-byte mach/gpio.h can
> be deleted (13 files).
> 
> We've not had any progress on the gpio.h issue since I did the last round
> of cleanup; the next stage was to persuade SoC maintainers to get rid of
> their optimized versions which aren't compatible with multi-platform
> kernels.
> 
> I don't know if folk are expecting me to push that forwards or whether
> there's someone else working on that aspect of it...
> 
> So this issue really does need to be progressed too.
on at91 as we clean it for DT we will be able to drop it soon too

Best Regards
J.

Re: Making ARM multiplatform kernels DT-only?

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:56 Fri 04 May     , Russell King - ARM Linux wrote:
> On Fri, May 04, 2012 at 11:39:30AM -0500, Rob Herring wrote:
> > Many of the headers are simply platform_data structs which may still be
> > needed on DT platforms, but could be moved elsewhere.
> 
> Those should be in include/linux/platform.
> 
> > >> Then there's also the problem of uncompress.h.  The last piece of the
> > >> puzzle is the common clock stuff.
> > 
> > The smp/hotplug/localtimer related functions are still global. Marc Z
> > has posted patches for this, but I haven't seen recent activity. This
> > and clocks were the 2 main issues I saw trying to build 2 platforms
> > together. highbank and picoxcell could be built together since only
> > highbank has clocks and smp.
> > 
> > gpio.h is still required, but empty for most platforms.
> 
> Those empty gpio.h files are definitely a candidate for going into
> arch/arm/include/mach/gpio.h, and then all those 12-byte mach/gpio.h can
> be deleted (13 files).
> 
> We've not had any progress on the gpio.h issue since I did the last round
> of cleanup; the next stage was to persuade SoC maintainers to get rid of
> their optimized versions which aren't compatible with multi-platform
> kernels.
> 
> I don't know if folk are expecting me to push that forwards or whether
> there's someone else working on that aspect of it...
> 
> So this issue really does need to be progressed too.
same with CLOCK_TICK_RATE

at91 (expect at91x40) and imx we drop it but nearly on the other platform
did not

Best Regards,
J.

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Friday 04 May 2012, Rob Herring wrote:
> On 05/04/2012 07:20 AM, Arnd Bergmann wrote:
> > On Thursday 03 May 2012, Russell King - ARM Linux wrote:

> > My plan is to have multiplatform kernels in parallel with what we have now,
> > so we can avoid breaking working machines but also play with multiplatform
> > configurations at the same time for a subset of the platforms and with
> > certain restrictions (not all board files, not all drivers, no generic
> > early printk, ...).
> > 
> 
> Many of the headers are simply platform_data structs which may still be
> needed on DT platforms, but could be moved elsewhere

Yes, as Russell pointed out, these really should go to
include/linux/platform_data/. My patchset take a few shortcuts there right
now, adding an ugly hack to redirect the header files from their current
locations so I can avoid all the hard work to do that.

> > 
> >> We still have irqs.h being SoC dependent, and we still haven't taken
> >> debug-macros.S far enough along to get rid of that.
> > 
> > I believe the irqs.h conflict is only for the NR_IRQS constant, all other
> > defines in there should only be used inside of the mach-* directory,
> > or not at all for fully DT-based platforms.
> 
> A DT-enabled platform does not need irqs.h or NR_IRQS. SPARSE_IRQ should
> be selected for DT. However, some DT enabled platforms don't have all
> irq chips converted to domains and may still need to set the mach .nr_irqs.

Ah, good to know. I hadn't realized that the #include <mach/irqs.h> in asm/irq.h
is already conditional.

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> My feeling is that we should just mandate DT booting for multiplatform
> kernels, because it significantly reduces the combinatorial space
> at compile time, avoids a lot of legacy board files that we cannot
> test anyway, reduces the total kernel size and gives an incentive
> for people to move forward to DT with their existing boards.

On this point, I strongly object, especially as I'm one who uses the
existing non-DT multiplatform support extensively.  It's really not
a problem for what you're trying to achieve.

I think what you're proposing is a totally artificial restriction.
There's no problem with a kernel supporting DT and non-DT together.
We've proven that many many times.  I prove it _every_ night that my
build and boot system runs - the OMAP LDP boots a multiplatform kernel
just fine without DT.

In any case, this is the least of the worries when you're wanting to
build multiple SoCs into the same kernel image.  See my previous reply
concerning that.

Re: Making ARM multiplatform kernels DT-only?

[Magnus Damm]

On Thu, May 3, 2012 at 11:18 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
>> My feeling is that we should just mandate DT booting for multiplatform
>> kernels, because it significantly reduces the combinatorial space
>> at compile time, avoids a lot of legacy board files that we cannot
>> test anyway, reduces the total kernel size and gives an incentive
>> for people to move forward to DT with their existing boards.
>
> On this point, I strongly object, especially as I'm one who uses the
> existing non-DT multiplatform support extensively.  It's really not
> a problem for what you're trying to achieve.

Perhaps not so surprisingly, but I'm with Russell on this one.

I'd like our work-in-progress DT support to coexist with all non-DT platforms.

Thanks,

/ magnus

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Thursday 03 May 2012, Russell King - ARM Linux wrote:
> On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> > My feeling is that we should just mandate DT booting for multiplatform
> > kernels, because it significantly reduces the combinatorial space
> > at compile time, avoids a lot of legacy board files that we cannot
> > test anyway, reduces the total kernel size and gives an incentive
> > for people to move forward to DT with their existing boards.
> 
> On this point, I strongly object, especially as I'm one who uses the
> existing non-DT multiplatform support extensively.  It's really not
> a problem for what you're trying to achieve.

Just to clarify the terminology, when I said "multiplatform", I did
not mean enabling more than one board file inside a given mach-*
directory but instead enabling multiple mach-* directories that
are currently mutually exclusive, i.e. the future stuff you replied
to in the other mail, not what everyone is doing today, and this
would not stop anything from working that works today.

> I think what you're proposing is a totally artificial restriction.
> There's no problem with a kernel supporting DT and non-DT together.
> We've proven that many many times.  I prove it every night that my
> build and boot system runs - the OMAP LDP boots a multiplatform kernel
> just fine without DT.

Of course it's an artificial restriction, if it was a technical necessity,
I would not have needed to ask ;-) IMHO however it's a helpful restriction.
My current count of board files is 393 and if you consider that we won't
build v6+ and v4/v5 together and that some of them will probably not
be multiplatform capable for a long time, we probably end up with about
half of them in a given kernel, which is still a lot and I would not
expect distributors to make a good decision about which ones of these
are important to enable and which ones are not. If we restrict the
Kconfig space to just the ones that are DT-enabled, we can be reasonably
sure that these have been recently tested on actual hardware by someone
who cares about them, and we get only a fraction of the user visible
options, roughly one per soc generation.

One counterargument that just occurred to me is build coverage, and it
would be nice to have "make allyesconfig" actually build everything
together as far as possible. We could get a bit closer to that if
we allow those platforms that have no DT support to just provide a
Kconfig option for multiplatform kernels that enables everything, e.g.
when you build an ARMv4/ARMv5 kernel, you can enable all sa1100
based boards together using one option, but when you build an sa1100
kernel, you keep picking them individually.

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Arnaud Patard]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

Hi,

> On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
>> My feeling is that we should just mandate DT booting for multiplatform
>> kernels, because it significantly reduces the combinatorial space
>> at compile time, avoids a lot of legacy board files that we cannot
>> test anyway, reduces the total kernel size and gives an incentive
>> for people to move forward to DT with their existing boards.
>
> On this point, I strongly object, especially as I'm one who uses the
> existing non-DT multiplatform support extensively.  It's really not
> a problem for what you're trying to achieve.
>

Please, don't do this. afaik, the idea was to reduce the numbers of
kernel to deal with. Unfortunately, this kind of restriction would
increase it. Consider orion platforms. This would mean having to deal
with 4 kernels (1 for DT, 1 for orion5x, 1 for kirkwood, 1 for mv78xx0).

Dropping HW support because one wants to encourage people to convert
their board file into DT seems weird. Doing this, imho, should even be
called a regression. The DT conversion won't happen in an eye blink so
non-DT kernels are still something we should take care of.

> I think what you're proposing is a totally artificial restriction.
> There's no problem with a kernel supporting DT and non-DT together.
> We've proven that many many times.  I prove it _every_ night that my
> build and boot system runs - the OMAP LDP boots a multiplatform kernel
> just fine without DT.

I think it's true for imx too. iirc, one can build a single image for
armv4/armv5 and one other for armv6/armv7 without having to use DT.

Regards,
Arnaud

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Friday 04 May 2012, Arnaud Patard wrote:
> > On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> >> My feeling is that we should just mandate DT booting for multiplatform
> >> kernels, because it significantly reduces the combinatorial space
> >> at compile time, avoids a lot of legacy board files that we cannot
> >> test anyway, reduces the total kernel size and gives an incentive
> >> for people to move forward to DT with their existing boards.
> >
> > On this point, I strongly object, especially as I'm one who uses the
> > existing non-DT multiplatform support extensively.  It's really not
> > a problem for what you're trying to achieve.
> >
> 
> Please, don't do this. afaik, the idea was to reduce the numbers of
> kernel to deal with. Unfortunately, this kind of restriction would
> increase it. Consider orion platforms. This would mean having to deal
> with 4 kernels (1 for DT, 1 for orion5x, 1 for kirkwood, 1 for mv78xx0).

Ok, point taken. 

My hope for Orion is that we can actually proceed quicker there than
on other platforms because the hardware is relatively simple, especially
its clock and pinctrl aspects, so we would be able to boot almost anything
with just supplying the right .dts file before we get to the point
where we can boot the first multiplatform kernel on orion.

> Dropping HW support because one wants to encourage people to convert
> their board file into DT seems weird. Doing this, imho, should even be
> called a regression. The DT conversion won't happen in an eye blink so
> non-DT kernels are still something we should take care of.

It's not dropping support for anything and not a regression in that
sense. We will have other restrictions with multiplatform kernels
for some time, with a lot of drivers breaking at first, and this question
is basically about which tradeoffs and priorities we make with the
new multiplatform enablement. 

> > I think what you're proposing is a totally artificial restriction.
> > There's no problem with a kernel supporting DT and non-DT together.
> > We've proven that many many times.  I prove it every night that my
> > build and boot system runs - the OMAP LDP boots a multiplatform kernel
> > just fine without DT.
> 
> I think it's true for imx too. iirc, one can build a single image for
> armv4/armv5 and one other for armv6/armv7 without having to use DT.

Yes, it's true for most platforms, and with my proposal, you would
still be able to build an i.mx kernel that runs on all boards it
runs on today, dt or not, nothing changed. The only question is
when you want to build a combined kernel for orion+imx+omap+...
whether that should allow the same options or just a subset.

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Ben Dooks]

On Thu, May 03, 2012 at 03:18:53PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> > My feeling is that we should just mandate DT booting for multiplatform
> > kernels, because it significantly reduces the combinatorial space
> > at compile time, avoids a lot of legacy board files that we cannot
> > test anyway, reduces the total kernel size and gives an incentive
> > for people to move forward to DT with their existing boards.
> 
> On this point, I strongly object, especially as I'm one who uses the
> existing non-DT multiplatform support extensively.  It's really not
> a problem for what you're trying to achieve.

I object firstly on principle that you don't need the DT support to
allow this, it could have been done years ago if anyone had taken the
time to do it.
 
> I think what you're proposing is a totally artificial restriction.
> There's no problem with a kernel supporting DT and non-DT together.
> We've proven that many many times.  I prove it _every_ night that my
> build and boot system runs - the OMAP LDP boots a multiplatform kernel
> just fine without DT.

We could have had the same for Samsung's entire range if a bit of work
had been applied to do things like PAGE_OFFSET and replaceable IRQ
controllers.

> In any case, this is the least of the worries when you're wanting to
> build multiple SoCs into the same kernel image.  See my previous reply
> concerning that.

-- 
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Thu, May 10, 2012 at 11:55:15AM +0100, Ben Dooks wrote:
> On Thu, May 03, 2012 at 03:18:53PM +0100, Russell King - ARM Linux wrote:
> > I think what you're proposing is a totally artificial restriction.
> > There's no problem with a kernel supporting DT and non-DT together.
> > We've proven that many many times.  I prove it _every_ night that my
> > build and boot system runs - the OMAP LDP boots a multiplatform kernel
> > just fine without DT.
> 
> We could have had the same for Samsung's entire range if a bit of work
> had been applied to do things like PAGE_OFFSET and replaceable IRQ
> controllers.

We never did dynamic PAGE_OFFSET because we _had_ taken the decision with
the inclusion of XIP support that we weren't going to have self-modifying
code in the kernel - and loading the offset for every page table walk
would have been very expensive.

The self-modifying code viewpoint seems to have changed as a result of
Nicolas moving jobs, from an employer who wanted XIP to one who wants a
single kernel image, which in itself isn't surprising.

Re: Making ARM multiplatform kernels DT-only?

[Sascha Hauer]

On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> Hi everyone,
> 
> I've been discussing multiplatform kernels with a few people recently,
> and we will have a lot of discussion sessions about this at Linaro
> Connect in Hong Kong.
> 
> One question that came up repeatedly is whether we should support all
> possible board files for each platform in a multiplatform kernel,
> or just the ones that are already using DT probing. I would like
> to get a quick poll of opinions on that and I've tried to put those
> people on Cc that would be most impacted by this, i.e. the maintainers
> for platforms that have both DT and non-DT board files at the moment.
> 
> My feeling is that we should just mandate DT booting for multiplatform
> kernels, because it significantly reduces the combinatorial space
> at compile time, avoids a lot of legacy board files that we cannot
> test anyway, reduces the total kernel size and gives an incentive
> for people to move forward to DT with their existing boards.
> 
> The counterargument is that we won't be able to support all the
> boards we currently do when the user switches on multiplatform,
> but I think that is acceptable.
> Note that I would still want to allow users to build platforms
> separately in order to enable the ATAG style board files, even
> for platforms that are not multiplatform capable.
> 
> Other opinions?

I don't think that enforcing DT only in multiplatform kernels will speed
up porting to DT. As a platform maintainer I am interested in building
multiplatform Kernels, but our customers are mostly uninterested in
this. They probably disable other platforms anyway to save the binary space.

So unless there are real technical problems supporting DT and !DT in a
single kernel (and Russells answer seems to say there aren't) I say no
to creating this restriction.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Thursday 03 May 2012, Sascha Hauer wrote:
> I don't think that enforcing DT only in multiplatform kernels will speed
> up porting to DT. As a platform maintainer I am interested in building
> multiplatform Kernels, but our customers are mostly uninterested in
> this. They probably disable other platforms anyway to save the binary space.

I was not asking about enabling multiple board files but multiple mach-*
directories, which is something that I'm probably more interested in than
you are, and the customers you refer to would certainly not do that if
they only want to run on one board.

This is really about people who distribute kernels that run on a wide
variety of machines across soc vendor boundaries, people like
ubuntu or cyanogenmod. The question is really whether you see a reason
why they should enable the 25 non-DT board files on your platform, rather
than helping out getting DT support for the machines they are
interested in?

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Sascha Hauer]

On Fri, May 04, 2012 at 04:24:17PM +0000, Arnd Bergmann wrote:
> On Thursday 03 May 2012, Sascha Hauer wrote:
> > I don't think that enforcing DT only in multiplatform kernels will speed
> > up porting to DT. As a platform maintainer I am interested in building
> > multiplatform Kernels, but our customers are mostly uninterested in
> > this. They probably disable other platforms anyway to save the binary space.
> 
> I was not asking about enabling multiple board files but multiple mach-*
> directories, 

Yes, I understood that.

> which is something that I'm probably more interested in than
> you are, and the customers you refer to would certainly not do that if
> they only want to run on one board.
> 
> This is really about people who distribute kernels that run on a wide
> variety of machines across soc vendor boundaries, people like
> ubuntu or cyanogenmod. The question is really whether you see a reason
> why they should enable the 25 non-DT board files on your platform, rather
> than helping out getting DT support for the machines they are
> interested in?

They should not if they are not interested in these boards, but why
shouldn't I be able to enable these 25 boards plus a few atmel or pxa
boards?

When there are technical reasons to limit a multiplatform Kernel to DT
only, then fine, lets do it that way. If there are no technical reasons
and this limitation shall only be used to put some political pressure on
platform board maintainers, then I am against it. Look around, people
actually *are* porting their boards over to device tree, I don't think
that such pressure is necessary.

Only my two cents, it's not that important to me since I want to port my
(relevant) boards over to DT anyway, so I won't argue about this.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Saturday 05 May 2012, Sascha Hauer wrote:
> They should not if they are not interested in these boards, but why
> shouldn't I be able to enable these 25 boards plus a few atmel or pxa
> boards?
> 
> When there are technical reasons to limit a multiplatform Kernel to DT
> only, then fine, lets do it that way. If there are no technical reasons
> and this limitation shall only be used to put some political pressure on
> platform board maintainers, then I am against it. Look around, people
> actually are porting their boards over to device tree, I don't think
> that such pressure is necessary.

It's definitely not a hard technical reason, just me trying to find
ways to simplify the problem space an any possible way. Basically all
code that can get built into the kernel has the ability to break other
stuff and causes bloat, see the recent discussion about putting
late_initcall into the machine_desc.

> Only my two cents, it's not that important to me since I want to port my
> (relevant) boards over to DT anyway, so I won't argue about this.

Ok, thanks for your input!

>From the statements made so far, I can see no clear policy that we can
apply to everyone. My take on this is that for any work I spend on
multiplatform kernel, I concentrate on the DT-based board files and
get them to work together first, but leave it up to the individual
subarch maintainers whether they want to add other board files into
the mix.

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Saturday 05 May 2012, Arnd Bergmann wrote:

> From the statements made so far, I can see no clear policy that we can
> apply to everyone. My take on this is that for any work I spend on
> multiplatform kernel, I concentrate on the DT-based board files and
> get them to work together first, but leave it up to the individual
> subarch maintainers whether they want to add other board files into
> the mix.

A small update that I already posted as a comment in the lwn article
covering this discussion:

| Over the last week, I've actually tried out building kernels for
| multiple platforms combined to get a better feeling for the remaining
| problems. The result is in the testing/multiplatform branch of
| git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git and it
| can build arbitrary combinations of four of the five subarchitectures
| that the Linaro organization is most interested in (imx, omap, ux500 and
| vexpress, but not exynos for now). Most other platforms should actually
| be simpler to convert.
| 
| However, this kernel is not yet going to be useful on real hardware
| because I had to disable or add hacks for a number of features (SMP,
| sparseirq, clocks) that are still being worked on, but as soon as one
| oatform has all that work done, we can actually build a kernel with
| everything enabled and run on that particular platform and see what
| else breaks.
|
| Unlike I suggested earlier, this kernel at the moment actually allows
| enabling all the board files including non-DT ones because that was
| easier to do with the Kconfig dependencies, but I found two real technical
| issues that would be solved by making the combined kernel DT-only:
|
| 1. The exynos platform defines static platform devices from files
| shared with five other Samsung platforms that are mutually exclusive
| because the device definitions depend on platform specific compile-time
| constants. Using DT probing we can just drop those static platform device
| definitions and make the conflict go away.
|
| 2. With sparse IRQs, a lot of the hardcoded interrupt numbers in static
| platform device definitions are broken, while the definitions from DT
| still work. Sparse IRQs are currently needed to build multiplatform
| kernels and I expect that requirement to stay.

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Deepak Saxena]

On 3 May 2012 06:50, Arnd Bergmann <arnd@arndb.de> wrote:
> Hi everyone,
>
> I've been discussing multiplatform kernels with a few people recently,
> and we will have a lot of discussion sessions about this at Linaro
> Connect in Hong Kong.
>
> One question that came up repeatedly is whether we should support all
> possible board files for each platform in a multiplatform kernel,
> or just the ones that are already using DT probing. I would like
> to get a quick poll of opinions on that and I've tried to put those
> people on Cc that would be most impacted by this, i.e. the maintainers
> for platforms that have both DT and non-DT board files at the moment.
>
> My feeling is that we should just mandate DT booting for multiplatform
> kernels, because it significantly reduces the combinatorial space
> at compile time, avoids a lot of legacy board files that we cannot
> test anyway, reduces the total kernel size and gives an incentive
> for people to move forward to DT with their existing boards.

+1

I'm of the opinion that we support DT only platforms for
multi-platform but this is based on the approach of only caring for
multi-platform for newer systems and not worrying too much for legacy
HW.  I look at this from the perspective of how much return do we get
on investing effort into making it possible for every platform to be
built as part of consolidated zImage.  I don't expect distros (the
main users of a single zImage IMHO) to spend many cycles on older
platforms and those of us who still have some of them sitting around
to use are generally developers who are going to be doing a lot of
builds anyways...

~Deepak

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Thu, May 03, 2012 at 10:38:15PM -0700, Deepak Saxena wrote:
> I'm of the opinion that we support DT only platforms for
> multi-platform but this is based on the approach of only caring for
> multi-platform for newer systems and not worrying too much for legacy
> HW.

You do realise that you're advocating that we forcefully regress stuff
that works today.  Sorry, that's not going to happen.

Re: Making ARM multiplatform kernels DT-only?

[Wookey]

+++ Deepak Saxena [2012-05-03 22:38 -0700]:

> I'm of the opinion that we support DT only platforms for
> multi-platform but this is based on the approach of only caring for
> multi-platform for newer systems and not worrying too much for legacy
> HW.    I don't expect distros (the
> main users of a single zImage IMHO) to spend many cycles on older
> platforms 

Well, it depends exactly what you mean by 'older', and 'spend many
cycles', but distros certainly care about relatively old platforms,
because that's often what users have on their desks, and that is the
driver for what is supported.

Debian tries very hard not to support anything in the kernel that
upstream don't support in the kernel because otherwise it's way too
much work. The current list of supplied arm kernels is:

iop32x (ThecusN2100, intel SS4000, GLAN tank)
ixp4xx (Linksys NSLU2)
kirkwood (*plugs, QNAP NAS, OPenRD)
orion5x (QNAP NAS, HP mv2120)
versatile
mx5
omap

because that's a good compromise between coverage and 'building 20-odd
images'. I have no idea how much of that lot is going to get DTified,
but I'm guessing the older stuff won't be?

We are keen on multiplatform kernels because building a great pile of
different ones is a massive pain (and not just for arm because it
holds up security updates), and if we could still cover all that
lot with one kernel, or indeed any number less than 7 that would be
great. But the focus is very much on 'still in use' hardware, not just
'still newly available' hardware, and definately not 'will be
available sometime' hardware.

So I think that means we'd vote for multiple zImages that did
support non-DT platforms, but my impression of the available effort is
that we'll take what we're given and make the best of it. If the older
stuff has to be supported with current-style one-platform/few machines
kernels then we'll carry on supporting them like that until no-one
cares any more or it's too hard.

Note that that I'm not involved with the Debian arm kernel team, so
this is merely my general impression from afar. Someone closer to the
problem could be more authoratative.

Wookey

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Fri, May 04, 2012 at 03:20:57PM +0100, Wookey wrote:
> Debian tries very hard not to support anything in the kernel that
> upstream don't support in the kernel because otherwise it's way too
> much work. The current list of supplied arm kernels is:
> 
> iop32x (ThecusN2100, intel SS4000, GLAN tank)
> ixp4xx (Linksys NSLU2)
> kirkwood (*plugs, QNAP NAS, OPenRD)
> orion5x (QNAP NAS, HP mv2120)
> versatile
> mx5
> omap
> 
> because that's a good compromise between coverage and 'building 20-odd
> images'. I have no idea how much of that lot is going to get DTified,
> but I'm guessing the older stuff won't be?

Well, my understanding is that there's DT patches around for Versatile.
OMAP and MX5 are both heading for DT.  I'm less certain about the Orion
and Kirkwood stuff, but as they're only about 4 years old, I would hope
that there was some active movement for these.

The iop32x and ixp4xx stuff hasn't seen much in the way of maintenance
so its highly likely that these won't be converted to DT unless someone
with the hardware decides to step up and do it.

So, that means your list should reduce down to five kernels, or three if
the Orion/Kirkwood stuff gets converted to DT.

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Friday 04 May 2012, Russell King - ARM Linux wrote:
> 
> On Fri, May 04, 2012 at 03:20:57PM +0100, Wookey wrote:
> > Debian tries very hard not to support anything in the kernel that
> > upstream don't support in the kernel because otherwise it's way too
> > much work. The current list of supplied arm kernels is:
> > 
> > iop32x (ThecusN2100, intel SS4000, GLAN tank)
> > ixp4xx (Linksys NSLU2)
> > kirkwood (*plugs, QNAP NAS, OPenRD)
> > orion5x (QNAP NAS, HP mv2120)
> > versatile
> > mx5
> > omap
> > 
> > because that's a good compromise between coverage and 'building 20-odd
> > images'. I have no idea how much of that lot is going to get DTified,
> > but I'm guessing the older stuff won't be?

Thanks for the list, Wookey!

This is very important because distros are obviously the primary consumer
of multiplatform builds (aside from build testing). The goal should very
much be to reduce the number of distinct kernels that folks like debian,
fedora or cyanogenmod have to build.

> Well, my understanding is that there's DT patches around for Versatile.
> OMAP and MX5 are both heading for DT.  I'm less certain about the Orion
> and Kirkwood stuff, but as they're only about 4 years old, I would hope
> that there was some active movement for these.

FWIW, there is a lot of new activity on orion5x and kirkwood (less on
mv78xxx and dove) and new board support for those platforms is being done
using DT already, at least for the drivers that have been converted.

As soon as the support is complete, I would hope that we can add dts files
for the older boards that people are using as well, and a few releases
later remove the respective board files.
 
> The iop32x and ixp4xx stuff hasn't seen much in the way of maintenance
> so its highly likely that these won't be converted to DT unless someone
> with the hardware decides to step up and do it.

Right. For those, I agree that it makes sense to support them without DT
even in a multiplatform kernel. So I'll revise my initial proposal to

* For mach-* directories that we expect to support using DT in the
  near future, support the ATAG based board files only in the current
  (single-platform, multi-board) way but not for multiplatform (i.e.
  multiple mach-*/ combined) builds.
* For mach-* directories that look like they will not support DT anytime
  soon, support them as is in the multiplatform build, possibly enabling
  all their boards (or a well-defined subset) unconditionally.

> So, that means your list should reduce down to five kernels, or three if
> the Orion/Kirkwood stuff gets converted to DT.

I count four if we were to proceed with the initial proposal:

1. ARMv6/v7 multiplatform: omap2plus, mx5/mx6, vexpress, ...
2. ARMv4/v5 multiplatform: versatile, orion5x, kirkwood, , ...
3. iop32x
4. ixp4xx

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Wookey]

+++ Arnd Bergmann [2012-05-04 15:17 +0000]:
> On Friday 04 May 2012, Russell King - ARM Linux wrote:
> > 
> > On Fri, May 04, 2012 at 03:20:57PM +0100, Wookey wrote:
> > > Debian tries very hard not to support anything in the kernel that
> > > upstream don't support in the kernel because otherwise it's way too
> > > much work. The current list of supplied arm kernels is:
> > > 
> > > iop32x (ThecusN2100, intel SS4000, GLAN tank)
> > > ixp4xx (Linksys NSLU2)
> > > kirkwood (*plugs, QNAP NAS, OPenRD)
> > > orion5x (QNAP NAS, HP mv2120)
> > > versatile
> > > mx5
> > > omap
> > > 
> > > because that's a good compromise between coverage and 'building 20-odd
> > > images'. I have no idea how much of that lot is going to get DTified,
> > > but I'm guessing the older stuff won't be?
> 
> Thanks for the list, Wookey!
> 
> This is very important because distros are obviously the primary consumer
> of multiplatform builds (aside from build testing). The goal should very
> much be to reduce the number of distinct kernels that folks like debian,
> fedora or cyanogenmod have to build.

Just to be clear, we'd very much like to support more hardware, ideally
'everything a significant number of people have', but the overhead to
the whole distro for each new kernel added to the build (for every
upload, slowing and potentially breaking releases on all arches) is
sufficiently high that we have been strict about what is supported. As
a result a lot of people use Debian with non-distro kernels.

Obviously missing things are tegra, dove/armada, omap4. Freerunner
would have been nice a while back but probably a bit late now. 

It's not clear to me how many omap platforms our 'omap' kernel
actually serves in practice, and similarly for the other 'generic'
kernels.

Obviously any and all progress in the direction of making existing
coverage or expanded coverage easier/faster/more-reliable/simpler is
very welcome. 

> > So, that means your list should reduce down to five kernels, or three if
> > the Orion/Kirkwood stuff gets converted to DT.
> 
> I count four if we were to proceed with the initial proposal:
> 
> 1. ARMv6/v7 multiplatform: omap2plus, mx5/mx6, vexpress, ...
> 2. ARMv4/v5 multiplatform: versatile, orion5x, kirkwood, , ...
> 3. iop32x
> 4. ixp4xx
> 
> 	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Friday 04 May 2012, Wookey wrote:
> > This is very important because distros are obviously the primary consumer
> > of multiplatform builds (aside from build testing). The goal should very
> > much be to reduce the number of distinct kernels that folks like debian,
> > fedora or cyanogenmod have to build.
> 
> Just to be clear, we'd very much like to support more hardware, ideally
> 'everything a significant number of people have', but the overhead to
> the whole distro for each new kernel added to the build (for every
> upload, slowing and potentially breaking releases on all arches) is
> sufficiently high that we have been strict about what is supported. As
> a result a lot of people use Debian with non-distro kernels.

Right, and this is the main motivation behind starting the multiplatform
kernel anyway: supporting more hardware with fewer kernels. Other distros
already aim at supporting only one ARM kernel binary, like things are
on other architectures. One related issue is the kernel binary size, which
we haven't discussed here yet. If we want to build 200 board files into
the kernel, that alone becomes a burden, even if most of it can be discarded
from RAM after the initcalls are done. Supporting only DT-enabled machines
can significantly reduce the size while only reducing the number of supported
boards by a bit, I'd hope.

> Obviously missing things are tegra, dove/armada, omap4. Freerunner
> would have been nice a while back but probably a bit late now. 

I can think of a few more: vexpress would be nice for running something
useful inside of KVM when we get there, various samsung socs are used
in cheap tablet PCs, and stuff like highbank is becoming more relevant
for distros now on the server side.

> It's not clear to me how many omap platforms our 'omap' kernel
> actually serves in practice, and similarly for the other 'generic'
> kernels.
> 
> Obviously any and all progress in the direction of making existing
> coverage or expanded coverage easier/faster/more-reliable/simpler is
> very welcome. 

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Linus Walleij]

On Fri, May 4, 2012 at 4:35 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> Well, my understanding is that there's DT patches around for Versatile.

Is there? There is some in-tree stuff, but haven't seen any other
sign of patches.

Having looked a bit at that I get the impression that this DT code has
been developed (by Grant I guess) in QEMU only as a proof of concept,
and never really tested on a real Versatile hardware unit.

These:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7390/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7391/1

make it clear that noone ever tested an MMC card on a Versatile
booted on real hardware using DT. And I strongly suspect there
are more instances like that, it seems AACI, GPIO and I2C and
I guess whatever you cannot test on QEMU is just unsupported.

But maybe the majority of Versatile users are on QEMU anyway,
I sometimes get that impression :-/

Yours,
Linus Walleij

Re: Making ARM multiplatform kernels DT-only?

[Christian Robottom Reis]

On Fri, May 04, 2012 at 10:03:40PM +0200, Linus Walleij wrote:
> On Fri, May 4, 2012 at 4:35 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> > Well, my understanding is that there's DT patches around for Versatile.
> 
> Is there? There is some in-tree stuff, but haven't seen any other
> sign of patches.
> 
> Having looked a bit at that I get the impression that this DT code has
> been developed (by Grant I guess) in QEMU only as a proof of concept,
> and never really tested on a real Versatile hardware unit.
> 
> These:
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7390/1
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7391/1
> 
> make it clear that noone ever tested an MMC card on a Versatile
> booted on real hardware using DT. And I strongly suspect there
> are more instances like that, it seems AACI, GPIO and I2C and
> I guess whatever you cannot test on QEMU is just unsupported.

Isn't there work by Pawel that adds support for more of the Versatile
platform? My quick searching finds at least:

    http://comments.gmane.org/gmane.linux.drivers.i2c/10143
    http://comments.gmane.org/gmane.linux.ports.arm.kernel/143523

I think the latter is merged already, but I may be wrong.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

Re: Making ARM multiplatform kernels DT-only?

[Arnd Bergmann]

On Friday 04 May 2012, Christian Robottom Reis wrote:
> Isn't there work by Pawel that adds support for more of the Versatile
> platform? My quick searching finds at least:
> 
>     http://comments.gmane.org/gmane.linux.drivers.i2c/10143
>     http://comments.gmane.org/gmane.linux.ports.arm.kernel/143523
> 
> I think the latter is merged already, but I may be wrong.

That work was done for versatile express, which is very different
from versatile, although it shares a few devices like the i2c controller
mentioned in the first link.

	Arnd

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Fri, May 04, 2012 at 10:03:40PM +0200, Linus Walleij wrote:
> On Fri, May 4, 2012 at 4:35 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> > Well, my understanding is that there's DT patches around for Versatile.
> 
> Is there? There is some in-tree stuff, but haven't seen any other
> sign of patches.
>[...]
> make it clear that noone ever tested an MMC card on a Versatile
> booted on real hardware using DT. And I strongly suspect there
> are more instances like that, it seems AACI, GPIO and I2C and
> I guess whatever you cannot test on QEMU is just unsupported.

Given that we've converted stuff like MMCI to use DT, it _should_ be
the case that we can just add the appropriate DT description to the
existing Versatile DT - we might need to create some new GPIO devices
for things like SYSMCI and get rid of the status function, or we
could just use the auxdata stuff in the mean time.

Either way, we've solved these problems on other platforms, and the
shared code has already been fixed or is being fixed for stuff like
Versatile Express.

Lets also not forget that the VIC code has already been converted to
DT.

So I don't think there's a big problem here - I think most of the
pieces of the jigsaw are in place through converting other platforms.