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  wrote:
> > On Thu, May 03, 2012 at 01:50:35PM +, 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  and
> ?

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: No group tracks at Connect

[Amber Graner]

Facilitator :-) http://en.wikipedia.org/wiki/Facilitator

I know I am adding my 2 cents a little late, but there I dropped it in the
collection plate.

Amber

On 25 April 2012 11:40, Jesse Barker  wrote:

> Funny, I took champion to be the equivalent of the sponsor of a
> requirement (i.e. to champion the topic at the TSC level).  I guess
> we'd better be more explicit in our nomenclature.
>
> cheers,
> jesse
>
> On Tue, Apr 24, 2012 at 11:16 PM, David Rusling
>  wrote:
> > See my earlier email.   They can be different or the same it's up to
> you...
> >
> > Dave
> >
> > Sent from my iPad
> >
> > On 25 Apr 2012, at 05:50, Arwen Donaghey 
> wrote:
> >
> > All,
> >
> > My understanding was the session lead is not necessarily the champion.
> The
> > champion is the 'guru' or 'owner' of the topic, and the session lead is
> > exactly that… the session lead. There are a number of sessions covering
> > various areas of one topic potentially? Please do correct me if this is
> > wrong.
> >
> > Regards,
> > --
> > Arwen Donaghey
> > Events Manager
> >
> > T: +44 1223 TBC | M: +44 7791 279 521
> > Suite 220 | The Quorum | Barnwell Road | Cambridge | CB2 8FH
> > Linaro.org │ Open source software for ARM SoCs
> > Follow Linaro: Facebook | Twitter | Blog
> > Registered Number: 07180318 | VAT Number: 990 0273 24
> >
> > On 25 Apr 2012, at 03:11, Ricardo Salveti wrote:
> >
> > On Tue, Apr 24, 2012 at 7:17 PM, Deepak Saxena 
> wrote:
> >
> > On 24 April 2012 03:22, David Rusling  wrote:
> >
> > All,
> >
> > I've created and shared the Connection Sessions spreadsheet, you can
> find it
> >
> > here
> >
> > -
> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnK-Uyci_D20dFlUX1ZOVm5LWDVudkxJM1B0aS1FWWc#gid=0
> .
> >
> > Arwen is happy that that spreadsheet will be used for the session
> >
> > planning.   I've added some topics and champions, please contact me to
> >
> > arrange more / discuss how best to organise things moving forward.   If
> you
> >
> > want a hint, see what Amit's done...
> >
> >
> > What are the responsibilities of the champion vs those of the session
> lead?
> >
> >
> > Nothing, we're just creating some extra naming for the same things :-)
> > Tiger, champion, all funny.
> >
> > Cheers,
> > --
> > Ricardo Salveti de Araujo
> >
> >
> >
> > ___
> > linaro-android mailing list
> > linaro-andr...@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-android
> >
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>



-- 

Amber Graner

User Experience and Community Specialist



Linaro.org * **│ *Open source software for ARM SoCs*
***

Follow *Linaro: *Facebook  |
Twitter
 | Blog 


*+1.828.582.9469* cell
*+1.828.395.1049* office

irc: akgraner
amber.gra...@linaro.org  (email and Google chat)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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 +, 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


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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 +, 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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Making ARM multiplatform kernels DT-only?

[Rtp]

Russell King - ARM Linux  writes:

Hi,

> On Thu, May 03, 2012 at 01:50:35PM +, 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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Making ARM multiplatform kernels DT-only?

[Magnus Damm]

On Thu, May 3, 2012 at 11:18 PM, Russell King - ARM Linux
 wrote:
> On Thu, May 03, 2012 at 01:50:35PM +, 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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Making ARM multiplatform kernels DT-only?

[David Rusling]

All,
not to muddy the waters, but think about where we'd like to be in the
future - able to build support for several platforms into one kernel.
Device tree is one of the mechanisms to help achieve that as it helps us
move away from code laboriously adding the same devices in per platform
ways.

OK, so who actually wants the same kernel to run on several platforms?
  I think that (a) anyone who wants to do testing and (b) anyone
interesting in supporting enterprise computing.   Frankly, none of the
mobile boys care, they are happy doing what they do.

If I put my commercial hat on, I care about ARMv7 and Cortex-A15
platforms.   I care about Cortex-A9 platforms as that's what the Linaro
members have today.   That covers enterprise and networking.

My view would be that we should move towards being able to build
support for several platforms into a single kernel.  The question
becomes 'do we allow non-device tree platforms to be included in a
single kernel?'.We could take a hard position and make device tree
mandatory or a softer position and not rule out non-DT platforms.   The
answer to this depends on how clean the end result is and how much
working around non-DT platforms has to happen.   If it's a lot of work
and the results are an ugly compromise, make single kernel device tree
only...

Dave

-- 
David Rusling, CTO

Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH

Linaro.org │ Open source software for ARM SoCs


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: PowerVR, 3.3 kernel and omap_drm

[Dechesne, Nicolas]

On Thu, May 3, 2012 at 5:34 PM, Christian Robottom Reis wrote:

> > any chance you can use current upstream libdrm
> > (http://cgit.freedesktop.org/mesa/drm)?
> >
> > there was a fix for this issue.. I guess what you are using has an
> > earlier version of libdrm_omap patches compared to what is upstream..
>
> Wouldn't it make sense to update the version in ~tiomap-dev, then?


yes, it does... we just don't update the PPA for every single commit ;-)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Making ARM multiplatform kernels DT-only?

[Wookey]

+++ Arnd Bergmann [2012-05-04 15:17 +]:
> 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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: PowerVR, 3.3 kernel and omap_drm

[Boudet, Xavier]

Hi

Can you let me know which version of libdrm-omap1 package you are using?
The  libdrm - 2.4.32-1ubuntu1+ti2.0 available into the trunk PPA shall have
all the latest fixes.

Regards,

*Xavier Boudet -* Texas Instruments France
Linux SW Integration - Platform Enablement Organization
Office: +33 4 93 22 *26 83*

Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve
Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920



On Fri, May 4, 2012 at 5:25 PM, Dechesne, Nicolas  wrote:

>
>
> On Thu, May 3, 2012 at 5:34 PM, Christian Robottom Reis 
> wrote:
>
>> > any chance you can use current upstream libdrm
>> > (http://cgit.freedesktop.org/mesa/drm)?
>> >
>> > there was a fix for this issue.. I guess what you are using has an
>> > earlier version of libdrm_omap patches compared to what is upstream..
>>
>> Wouldn't it make sense to update the version in ~tiomap-dev, then?
>
>
> yes, it does... we just don't update the PPA for every single commit ;-)
>
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 1/2] ARM: OMAP3: cpuidle - check the powerdomain lookup

[Daniel Lezcano]

At init time, check the powerdomains lookup is successful otherwise
exit the cpuidle driver init function with -ENODEV like what is done for the
omap3 cpuidle driver.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Jean Pihet 
---
 arch/arm/mach-omap2/cpuidle34xx.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index f682e17..207bc1c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -363,6 +363,9 @@ int __init omap3_idle_init(void)
per_pd = pwrdm_lookup("per_pwrdm");
cam_pd = pwrdm_lookup("cam_pwrdm");
 
+   if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
+   return -ENODEV;
+
cpuidle_register_driver(&omap3_idle_driver);
 
dev = &per_cpu(omap3_idle_dev, smp_processor_id());
-- 
1.7.5.4


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 2/2] ARM: OMAP3/4: consolidate cpuidle Makefile

[Daniel Lezcano]

Define a CPU_IDLE section in the makefile, declare the functions in
the header files conforming to the kernel coding rules and remove the
'define's in the C files.

CONFIG_PM is enabled when CPU_IDLE is enabled because the cpuidle drivers
use some functions from the pm subsystem.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Jean Pihet 
---
 arch/arm/mach-omap2/Kconfig   |2 ++
 arch/arm/mach-omap2/Makefile  |   11 +++
 arch/arm/mach-omap2/cpuidle34xx.c |8 
 arch/arm/mach-omap2/cpuidle44xx.c |8 
 arch/arm/mach-omap2/pm.h  |   17 +++--
 5 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8141b76..42f6b89 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -34,6 +34,7 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARCH_HAS_OPP
+   select PM if CPU_IDLE
select PM_OPP if PM
select ARM_CPU_SUSPEND if PM
select MULTI_IRQ_HANDLER
@@ -51,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+   select PM if CPU_IDLE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..f46c735 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,10 +64,8 @@ endif
 ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_ARCH_OMAP2)   += pm24xx.o
 obj-$(CONFIG_ARCH_OMAP2)   += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o \
-  cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4)   += pm44xx.o omap-mpuss-lowpower.o \
-  cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o
+obj-$(CONFIG_ARCH_OMAP4)   += pm44xx.o omap-mpuss-lowpower.o
 obj-$(CONFIG_PM_DEBUG) += pm-debug.o
 obj-$(CONFIG_OMAP_SMARTREFLEX)  += sr_device.o smartreflex.o
 obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)  += smartreflex-class3.o
@@ -81,6 +79,11 @@ endif
 
 endif
 
+ifeq ($(CONFIG_CPU_IDLE),y)
+obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
+endif
+
 # PRCM
 obj-y  += prm_common.o
 obj-$(CONFIG_ARCH_OMAP2)   += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 207bc1c..3134452 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,8 +36,6 @@
 #include "control.h"
 #include "common.h"
 
-#ifdef CONFIG_CPU_IDLE
-
 /* Mach specific information to be recorded in the C-state driver_data */
 struct omap3_idle_statedata {
u32 mpu_state;
@@ -379,9 +377,3 @@ int __init omap3_idle_init(void)
 
return 0;
 }
-#else
-int __init omap3_idle_init(void)
-{
-   return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index be1617c..02d15bb 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,8 +22,6 @@
 #include "pm.h"
 #include "prm.h"
 
-#ifdef CONFIG_CPU_IDLE
-
 /* Machine specific information */
 struct omap4_idle_statedata {
u32 cpu_state;
@@ -199,9 +197,3 @@ int __init omap4_idle_init(void)
 
return 0;
 }
-#else
-int __init omap4_idle_init(void)
-{
-   return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..ab04d3b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -15,12 +15,25 @@
 
 #include "powerdomain.h"
 
+#ifdef CONFIG_CPU_IDLE
+extern int __init omap3_idle_init(void);
+extern int __init omap4_idle_init(void);
+#else
+static inline int omap3_idle_init(void)
+{
+   return 0;
+}
+
+static inline int omap4_idle_init(void)
+{
+   return 0;
+}
+#endif
+
 extern void *omap3_secure_ram_storage;
 extern void omap3_pm_off_mode_enable(int);
 extern void omap_sram_idle(void);
 extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
-extern int omap3_idle_init(void);
-extern int omap4_idle_init(void);
 extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
 extern int (*omap_pm_suspend)(void);
 
-- 
1.7.5.4


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 0/2] ARM: OMAP3/4: cpuidle - misc fixes

[Daniel Lezcano]

These two patches are coming from the series I previously
sent for the cpuidle OMAP3/4 cleanups.

The first one, move the powerdomain lookup check in the init
function, the second one fix the linkage error, when the
CONFIG_PM is not set while CONFIG_CPU_IDLE is. Omap's Kconfig
has been modified to select CONFIG_PM when CONFIG_CPU_IDLE is
set.

I compiled with different options but I was not able to boot
my board because the kernel panics for another reason.

Daniel Lezcano (2):
  ARM: OMAP3: cpuidle - check the powerdomain lookup
  ARM: OMAP3/4: consolidate cpuidle Makefile

 arch/arm/mach-omap2/Kconfig   |2 ++
 arch/arm/mach-omap2/Makefile  |   11 +++
 arch/arm/mach-omap2/cpuidle34xx.c |   11 +++
 arch/arm/mach-omap2/cpuidle44xx.c |8 
 arch/arm/mach-omap2/pm.h  |   17 +++--
 5 files changed, 27 insertions(+), 22 deletions(-)

-- 
1.7.5.4


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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  in asm/irq.h
is already conditional.

Arnd

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Making ARM multiplatform kernels DT-only?

[Linus Walleij]

On Fri, May 4, 2012 at 4:35 PM, Russell King - ARM Linux
 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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/2] ARM: OMAP3: cpuidle - check the powerdomain lookup

[Kevin Hilman]

Daniel Lezcano  writes:

> At init time, check the powerdomains lookup is successful otherwise
> exit the cpuidle driver init function with -ENODEV like what is done for the
> omap3 cpuidle driver.
>
> Signed-off-by: Daniel Lezcano 
> Reviewed-by: Jean Pihet 

Thanks, applying to my for_3.5/cleanup/omap-cpuidle branch.

Kevin

> ---
>  arch/arm/mach-omap2/cpuidle34xx.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index f682e17..207bc1c 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -363,6 +363,9 @@ int __init omap3_idle_init(void)
>   per_pd = pwrdm_lookup("per_pwrdm");
>   cam_pd = pwrdm_lookup("cam_pwrdm");
>  
> + if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
> + return -ENODEV;
> +
>   cpuidle_register_driver(&omap3_idle_driver);
>  
>   dev = &per_cpu(omap3_idle_dev, smp_processor_id());

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

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

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev