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
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.
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.
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?
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
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
- 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.
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?
- 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
- 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.
- 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
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?
- 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
- 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.
- 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.
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?
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
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, ...).
- 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
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?
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
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.
- 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
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 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.
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.
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
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.
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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.
+++ 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
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.
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
+++ 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:
ARMv6/v7 multiplatform: omap2plus, mx5/mx6, vexpress, ...
ARMv4/v5 multiplatform: versatile, orion5x, kirkwood, , ...
iop32x
ixp4xx
Arnd
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
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
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.
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/143523I 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
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.
-
Arnaud Patard -
Arnd Bergmann -
Ben Dooks -
Christian Robottom Reis -
David Rusling -
Deepak Saxena -
Jean-Christophe PLAGNIOL-VILLARD -
Linus Walleij -
Magnus Damm -
Rob Herring -
Russell King - ARM Linux -
Sascha Hauer -
Wookey