Re: Making ARM multiplatform kernels DT-only?
On Thu, May 03, 2012 at 11:31:13PM -0700, Deepak Saxena wrote: On 3 May 2012 07:04, Russell King - ARM Linux li...@arm.linux.org.uk 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 mach/mx3fb.h and mach/ohci.h? Such platforms with that kind of stuff haven't fully converted to DT, because these sorts of things are platform dependent yet aren't represented in DT. Arnd (or maybe Nicolas?) suggested something along the lines of scripting something to figure out the constants required for a specific driver and pulling them out of mach/*.h and into that driver as a starting point. But that doesn't solve the problem. Take a USB driver where the register layouts are different. To have it work on two different platforms, you'd need to build the driver twice. Not only that, you'd also need to figure out some way to register only one copy of that. So really, the header file thing is just a sign of larger blocking issues to getting those kinds of drivers working on a multiplatform kernel, and no amount of header munging will sort it out. The fact of that situation is the driver concerned is _not_ multiplatform and shouldn't be built in that situation until it is fixed. 3. Allow build multiple mach-* directories (which we already do... see the samsung stuff.) We still have irqs.h being SoC dependent, and we still haven't taken debug-macros.S far enough along to get rid of that. Then there's also the problem of uncompress.h. The last piece of the puzzle is the common clock stuff. There's also some stuff outside of arch/arm that needs cleanup including USB driver refactoring and some other bits that I can't recall atm. Right now we can build one and only one host controller inteface, even as modules. Not too difficult of a problem to solve and not critical to get the SOCs booting, but needed to be usable on real devices. That's already a problem today, and has nothing to do with this current issue - what I'm saying is the problem can't be made to go away through header file stuff, so this issue is not relevant to this discussion. That's not to say it doesn't need to be resolved, because it does. It's just no reason to argue against what I've said. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
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
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 jesse.bar...@linaro.org 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 david.rusl...@linaro.org 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 arwen.donag...@linaro.org 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 dsax...@linaro.org wrote: On 24 April 2012 03:22, David Rusling david.rusl...@linaro.org 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 http://www.linaro.org/* **│ *Open source software for ARM SoCs* *** Follow *Linaro: *Facebook http://www.facebook.com/pages/Linaro | Twitterhttp://twitter.com/#%21/linaroorg | Blog http://www.linaro.org/linaro-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?
On Thu, May 3, 2012 at 11:18 PM, Russell King - ARM Linux li...@arm.linux.org.uk 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?
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?
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.orghttp://www.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?
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?
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
On Thu, May 3, 2012 at 5:34 PM, Christian Robottom Reis k...@linaro.orgwrote: 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?
+++ 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
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 n-deche...@ti.com wrote: On Thu, May 3, 2012 at 5:34 PM, Christian Robottom Reis k...@linaro.orgwrote: 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?
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?
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
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 daniel.lezc...@linaro.org Reviewed-by: Jean Pihet j-pi...@ti.com --- 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
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 daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
---
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
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?
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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
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?
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?
On Fri, May 4, 2012 at 4:35 PM, Russell King - ARM Linux li...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
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 li...@arm.linux.org.uk wrote: Well, my understanding is that there's DT patches around for Versatile. Is there? There is some in-tree stuff, but haven't seen any other sign of patches. Having looked a bit at that I get the impression that this DT code has been developed (by Grant I guess) in QEMU only as a proof of concept, and never really tested on a real Versatile hardware unit. These: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7390/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7391/1 make it clear that noone ever tested an MMC card on a Versatile booted on real hardware using DT. And I strongly suspect there are more instances like that, it seems AACI, GPIO and I2C and I guess whatever you cannot test on QEMU is just unsupported. Isn't there work by Pawel that adds support for more of the Versatile platform? My quick searching finds at least: http://comments.gmane.org/gmane.linux.drivers.i2c/10143 http://comments.gmane.org/gmane.linux.ports.arm.kernel/143523 I think the latter is merged already, but I may be wrong. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
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
Daniel Lezcano daniel.lezc...@linaro.org 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 daniel.lezc...@linaro.org Reviewed-by: Jean Pihet j-pi...@ti.com 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?
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 li...@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. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
