Linaro QEMU package in Ubuntu?
Hello, one of the Ubuntu blueprints for 11.04 is to provide a QEMU better suited to Linaro/ARM work in the official archives, allowing to test at least the official Ubuntu ARM images. The Linaro PPA provides a package based on qemu-maemo from gitorious, and it is ahead of what is packaged in that it supports the BeagleBoard. I see there's also qemu-arm repo in git.linaro.org - I assume this is a newer and preferable upstream to the maemo one? Are the ARM patches being pushed and accepted into upstream QEMU regularly? In this case there may be no need to create a new package and just wait for that work to get released and packaged, and maybe focus the effort on helping with upstreaming the ARM changes. any pointers appreciated :) thanks Jani ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
Dnia wtorek, 7 grudnia 2010 o 17:50:50 Dave Martin napisał(a): > You can't built a kernel for pre-v7 platforms with > CONFIG_THUMB2_KERNEL: the code can't run on those platforms because > they don't support Thumb-2. > > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 > capable (and hence reasonably new) tools. Wasn't Thumb2 available in arm1176 cores? So it would be v6 too. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro QEMU package in Ubuntu?
On 8 December 2010 08:53, Jani Monoses wrote: > one of the Ubuntu blueprints for 11.04 is to provide a QEMU better suited to > Linaro/ARM work in the official archives, allowing to > at least the official Ubuntu ARM images. > > The Linaro PPA provides a package based on qemu-maemo from gitorious, > and it is ahead of what is packaged in that it supports the BeagleBoard. Yes. At the moment I think that something based on that tree is your best practical choice if you want neon support and certainly if you need omap3. > I see there's also qemu-arm repo in git.linaro.org - I assume this is a > newer and preferable upstream to the maemo one? No. This tree is currently tracking qemu upstream master and I am using it as a way to provide tested arm patches to upstream in a way that they can pull. > Are the ARM patches being pushed and accepted into upstream QEMU regularly? > In this case there may be no need to create a new package > and just wait for that work to get released and packaged, and maybe focus > the effort on helping with upstreaming the ARM changes. This depends on how long you are prepared to wait. Some ARM fixes are starting to go into upstream. OTOH upstream's proposed release cycle is about once every 6 months, with 0.14 due to branch very shortly. So 0.15 ought to be much better for ARM support but won't be available until middle of next year. I'm currently focusing most of my effort on working with upstream to get these patches accepted. I also have a blueprint for doing at least enough maintenance/bugfixing on the maemo-qemu package so it continues to boot the linaro images. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to work withCONFIG_THUMB2_KERNEL
Hi, On Tue, Dec 7, 2010 at 7:15 PM, Nicolas Pitre wrote: > On Tue, 7 Dec 2010, Dave Martin wrote: > >> On Tue, Dec 7, 2010 at 2:53 PM, Dave Martin wrote: >> [...] >> > Note that converting to C doesn't mean that code which attempts to >> > copy function bodies will work: you still need to handle the fact that >> > if f() is a C function symbol, then the value of the symbol f is >> > actually the function's base address + 1. See my changes in sram.c, >> >> To clarify, this applies *if* f is a Thumb symbol. > > To make it generic, a new macro could be used: > > #define SYM_ADDR(x) ((void *)((long)(x) & ~1L)) Could do ... I wasn't sure if it was useful for just this one case, but I guess we may encounter others. And it would make the code a lot less messy... if so, a macro for exracting just the Thumb bit, and a macro for rebasing a symbol while preserving the Thumb bit could also be useful. #define SYM_STATE(x) ((long)(x) & 1) #define SYM_REBASE(new_addr, sym) ((void *)((long)SYM_ADDR(new_addr) | SYM_STATE(sym))) The relationship could be a bit clearer if we use the name SYM_BASE instead of SYM_ADDR. With these, the affected code becomes something like: memcpy(buffer, SYM_BASE(f), size_of_f); new_f = SYM_REBASE(f, buffer); What do you think? Is there a recommended type for a pointer-sized integer? I notice linux/types.h defines uintptr_t (as unsigned long). Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Dynamic hwcaps
Hi, On Tue, Dec 7, 2010 at 9:15 PM, Ben Dooks wrote: [...] > > Could you do what the original FP did, and start with units off and use > the first use of $unit in the process to turn it on? Do things like NEON > support this? > Actually, this is still done -- it's the same code since NEON and VFP use a common register file. The issue under discussion is that userspace can't detect whether units like these are active or not, and so can't make dynamic runtime decisions about whether to run accelerated code or not. (And also, whether this would actually be usefuil) Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Wed, Dec 8, 2010 at 9:14 AM, Marcin Juszkiewicz wrote: > Dnia wtorek, 7 grudnia 2010 o 17:50:50 Dave Martin napisał(a): >> You can't built a kernel for pre-v7 platforms with >> CONFIG_THUMB2_KERNEL: the code can't run on those platforms because >> they don't support Thumb-2. >> >> So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 >> capable (and hence reasonably new) tools. > > Wasn't Thumb2 available in arm1176 cores? So it would be v6 too. No-- arm1136 and arm1176 only support the original 16-bit Thumb-1 instruction set (with some extensions specific to v6 like some v6 SIMD operations, architected BKPT etc., etc.) There is an extended v6 architecture, v6T2. However, this is only implemented by the arm1156 processor, which is rare and not supported by the Linux kernel at the present time IIUC. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar wrote: > Dave, > >> -Original Message- >> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] >> Sent: Wednesday, December 08, 2010 11:27 AM >> To: Dave Martin >> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- >> o...@vger.kernel.org; linaro-dev@lists.linaro.org >> Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() >> forCONFIG_THUMB2_KERNEL >> >> > -Original Message- >> > From: Dave Martin [mailto:dave.mar...@linaro.org] >> > Sent: Tuesday, December 07, 2010 10:21 PM >> > To: Santosh Shilimkar >> > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- >> > o...@vger.kernel.org; linaro-dev@lists.linaro.org >> > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() >> > forCONFIG_THUMB2_KERNEL >> > >> > Hi, >> > >> > On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar >> > wrote: >> > > Dave, > > [.] >> >> > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 >> > capable (and hence reasonably new) tools. >> > >> > I'll follow up shortly with a patch to the generic ARM Kconfig to make >> > this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally >> > be configured together. >> > >> sure > > When you are doing the changes can you please check if you could build > the THUMB2 kernel with omap2plus_defconfig. I suspect the build will > fail. With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that configuration: http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.html If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If my understanding is correct, this is the right behaviour. The kernel builds, fine but in ARM. I hope that clarifies things... Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
> -Original Message- > From: Dave Martin [mailto:dave.mar...@linaro.org] > Sent: Wednesday, December 08, 2010 4:11 PM > To: Santosh Shilimkar > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > o...@vger.kernel.org; linaro-dev@lists.linaro.org > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() > forCONFIG_THUMB2_KERNEL > > On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar > wrote: > > Dave, > > > >> -Original Message- > >> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > >> Sent: Wednesday, December 08, 2010 11:27 AM > >> To: Dave Martin > >> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > >> o...@vger.kernel.org; linaro-dev@lists.linaro.org > >> Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() > >> forCONFIG_THUMB2_KERNEL > >> > >> > -Original Message- > >> > From: Dave Martin [mailto:dave.mar...@linaro.org] > >> > Sent: Tuesday, December 07, 2010 10:21 PM > >> > To: Santosh Shilimkar > >> > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > >> > o...@vger.kernel.org; linaro-dev@lists.linaro.org > >> > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of > do_wfi() > >> > forCONFIG_THUMB2_KERNEL > >> > > >> > Hi, > >> > > >> > On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar > >> > wrote: > >> > > Dave, > > > > [.] > >> > >> > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 > >> > capable (and hence reasonably new) tools. > >> > > >> > I'll follow up shortly with a patch to the generic ARM Kconfig to > make > >> > this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't > accidentally > >> > be configured together. > >> > > >> sure > > > > When you are doing the changes can you please check if you could build > > the THUMB2 kernel with omap2plus_defconfig. I suspect the build will > > fail. > > With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that > configuration: > > http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.h > tml > > If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If > my understanding is correct, this is the right behaviour. > > Ofcourse it will build with ARCH_OMAP2 disabled :) (ARMv6 dependency) In other words, I wanted to say that "omap2plus_defconfig" can't be used as is to build THUMB kernel binary. Thanks for conforming. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro QEMU package in Ubuntu?
The Linaro PPA provides a package based on qemu-maemo from gitorious, and it is ahead of what is packaged in that it supports the BeagleBoard. Yes. At the moment I think that something based on that tree is your best practical choice if you want neon support and certainly if you need omap3. thanks, I'll look at that tree then more closely. I'm wondering whether the package name should reflect it is Linaro and ARM related in general and not for maemo (meego is not even called that anymore) Jani ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Wed, Dec 8, 2010 at 10:45 AM, Santosh Shilimkar wrote: >> -Original Message- >> From: Dave Martin [mailto:dave.mar...@linaro.org] >> Sent: Wednesday, December 08, 2010 4:11 PM >> To: Santosh Shilimkar >> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- >> o...@vger.kernel.org; linaro-dev@lists.linaro.org >> Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() >> forCONFIG_THUMB2_KERNEL >> >> On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar >> wrote: >> > Dave, >> > >> >> -Original Message- >> >> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] >> >> Sent: Wednesday, December 08, 2010 11:27 AM >> >> To: Dave Martin >> >> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- >> >> o...@vger.kernel.org; linaro-dev@lists.linaro.org >> >> Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of > do_wfi() >> >> forCONFIG_THUMB2_KERNEL >> >> >> >> > -Original Message- >> >> > From: Dave Martin [mailto:dave.mar...@linaro.org] >> >> > Sent: Tuesday, December 07, 2010 10:21 PM >> >> > To: Santosh Shilimkar >> >> > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- >> >> > o...@vger.kernel.org; linaro-dev@lists.linaro.org >> >> > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of >> do_wfi() >> >> > forCONFIG_THUMB2_KERNEL >> >> > >> >> > Hi, >> >> > >> >> > On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar >> >> > wrote: >> >> > > Dave, >> > >> > [.] >> >> >> >> > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume > v7/Thumb-2 >> >> > capable (and hence reasonably new) tools. >> >> > >> >> > I'll follow up shortly with a patch to the generic ARM Kconfig to >> make >> >> > this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't >> accidentally >> >> > be configured together. >> >> > >> >> sure >> > >> > When you are doing the changes can you please check if you could build >> > the THUMB2 kernel with omap2plus_defconfig. I suspect the build will >> > fail. >> >> With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that >> configuration: >> >> > http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.h >> tml >> >> If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If >> my understanding is correct, this is the right behaviour. >> >> > Ofcourse it will build with ARCH_OMAP2 disabled :) (ARMv6 dependency) > In other words, I wanted to say that "omap2plus_defconfig" can't > be used as is to build THUMB kernel binary. Well, yes, that's another way of looking at it. Anyway, I think this is the intended result -- is it OK for you? Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Dynamic hwcaps
On Wed, Dec 8, 2010 at 11:01 AM, Jamie Lokier wrote: > Dave Martin wrote: >> On Sun, Dec 5, 2010 at 2:12 PM, Thomas Petazzoni >> wrote: >> > Hi, >> > >> > On Fri, 3 Dec 2010 16:28:27 + >> > Dave Martin wrote: >> > >> >> This allows for more active power management of such functional >> >> blocks: if the CPU is not fully loaded, you can turn them off -- the >> >> kernel can spot when there is significant idle time and do this. If >> >> the CPU becomes fully loaded, applications which have soft-realtime >> >> constraints can notice this and switch to their accelerated code >> >> (which will cause the kernel to switch the functional unit(s) on). >> >> Or, the kernel can react to increasing CPU load by speculatively turn >> >> it on instead. This is analogous to the behaviour of other power >> >> governors in the system. Non-aware applications will still work >> >> seamlessly -- these may simply run accelerated code if the hardware >> >> supports it, causing the kernel to turn the affected functional >> >> block(s) on. >> > >> > From a power management perspective, is it really useful to load the >> > CPU instead of using specialized units which usually provide more >> > computing power per watt consumed ? >> >> No--- but you can't in general just exchange cycles on one functional >> unit for cycles on another in the same way as you >> >> Suppose 90% if your code (by execution time) can take advantage of a >> specialised functional unit. Should you turn that unit on? >> >> Now, suppose only 5% of the code can take advantage, but the platform >> is not completely busy. Turning on a special functional unit consumes >> extra power and will provide no speedup to the user -- is it still >> worth turning it on? What if the CPU is fully loaded doing other work >> and your program is close to missing its realtime deadlines -- should >> you turn on the separate unit now? > > I think Thomas's point is that doing the 5% on the CPU may consume > more power than turning on the special functional unit - even when > the system is not busy and the user doesn't see a time difference. > > I don't know if that's true for available hardware, but it seems like > it's worth investigating before taking the idea further. Agreed -- either could be the case. It's something you can never be certain about without doing some measurements... Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Dynamic hwcaps
Dave Martin wrote: > On Sun, Dec 5, 2010 at 2:12 PM, Thomas Petazzoni > wrote: > > Hi, > > > > On Fri, 3 Dec 2010 16:28:27 + > > Dave Martin wrote: > > > >> This allows for more active power management of such functional > >> blocks: if the CPU is not fully loaded, you can turn them off -- the > >> kernel can spot when there is significant idle time and do this. If > >> the CPU becomes fully loaded, applications which have soft-realtime > >> constraints can notice this and switch to their accelerated code > >> (which will cause the kernel to switch the functional unit(s) on). > >> Or, the kernel can react to increasing CPU load by speculatively turn > >> it on instead. This is analogous to the behaviour of other power > >> governors in the system. Non-aware applications will still work > >> seamlessly -- these may simply run accelerated code if the hardware > >> supports it, causing the kernel to turn the affected functional > >> block(s) on. > > > > From a power management perspective, is it really useful to load the > > CPU instead of using specialized units which usually provide more > > computing power per watt consumed ? > > No--- but you can't in general just exchange cycles on one functional > unit for cycles on another in the same way as you > > Suppose 90% if your code (by execution time) can take advantage of a > specialised functional unit. Should you turn that unit on? > > Now, suppose only 5% of the code can take advantage, but the platform > is not completely busy. Turning on a special functional unit consumes > extra power and will provide no speedup to the user -- is it still > worth turning it on? What if the CPU is fully loaded doing other work > and your program is close to missing its realtime deadlines -- should > you turn on the separate unit now? I think Thomas's point is that doing the 5% on the CPU may consume more power than turning on the special functional unit - even when the system is not busy and the user doesn't see a time difference. I don't know if that's true for available hardware, but it seems like it's worth investigating before taking the idea further. -- Jamie ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
> -Original Message- > From: Dave Martin [mailto:dave.mar...@linaro.org] > Sent: Wednesday, December 08, 2010 4:35 PM > To: Santosh Shilimkar > Cc: Tony Lindgren; linux-o...@vger.kernel.org; linaro- > d...@lists.linaro.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() > forCONFIG_THUMB2_KERNEL > > On Wed, Dec 8, 2010 at 10:45 AM, Santosh Shilimkar > wrote: > >> -Original Message- > >> From: Dave Martin [mailto:dave.mar...@linaro.org] > >> Sent: Wednesday, December 08, 2010 4:11 PM > >> To: Santosh Shilimkar > >> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > >> o...@vger.kernel.org; linaro-dev@lists.linaro.org > >> Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() > >> forCONFIG_THUMB2_KERNEL > >> > >> On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar > >> wrote: > >> > Dave, > >> > > >> >> -Original Message- > >> >> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > >> >> Sent: Wednesday, December 08, 2010 11:27 AM > >> >> To: Dave Martin > >> >> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > >> >> o...@vger.kernel.org; linaro-dev@lists.linaro.org > >> >> Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of > > do_wfi() > >> >> forCONFIG_THUMB2_KERNEL > >> >> > >> >> > -Original Message- > >> >> > From: Dave Martin [mailto:dave.mar...@linaro.org] > >> >> > Sent: Tuesday, December 07, 2010 10:21 PM > >> >> > To: Santosh Shilimkar > >> >> > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > >> >> > o...@vger.kernel.org; linaro-dev@lists.linaro.org > >> >> > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of > >> do_wfi() > >> >> > forCONFIG_THUMB2_KERNEL > >> >> > > >> >> > Hi, > >> >> > > >> >> > On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar > >> >> > wrote: > >> >> > > Dave, > >> > > >> > [.] > >> >> > >> >> > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume > > v7/Thumb-2 > >> >> > capable (and hence reasonably new) tools. > >> >> > > >> >> > I'll follow up shortly with a patch to the generic ARM Kconfig to > >> make > >> >> > this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't > >> accidentally > >> >> > be configured together. > >> >> > > >> >> sure > >> > > >> > When you are doing the changes can you please check if you could > build > >> > the THUMB2 kernel with omap2plus_defconfig. I suspect the build will > >> > fail. > >> > >> With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that > >> configuration: > >> > >> > > > http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.h > >> tml > >> > >> If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. If > >> my understanding is correct, this is the right behaviour. > >> > >> > > Ofcourse it will build with ARCH_OMAP2 disabled :) (ARMv6 dependency) > > In other words, I wanted to say that "omap2plus_defconfig" can't > > be used as is to build THUMB kernel binary. > > Well, yes, that's another way of looking at it. Anyway, I think this > is the intended result -- is it OK for you? > Should be ok considering you can't do much with it. But I let Tony comment on it. Regards, Santosh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Wed, Dec 8, 2010 at 11:10 AM, Santosh Shilimkar wrote: >> -Original Message- >> From: Dave Martin [mailto:dave.mar...@linaro.org] >> Sent: Wednesday, December 08, 2010 4:35 PM >> To: Santosh Shilimkar >> Cc: Tony Lindgren; linux-o...@vger.kernel.org; linaro- >> d...@lists.linaro.org; linux-arm-ker...@lists.infradead.org >> Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() >> forCONFIG_THUMB2_KERNEL >> >> On Wed, Dec 8, 2010 at 10:45 AM, Santosh Shilimkar >> wrote: >> >> -Original Message- >> >> From: Dave Martin [mailto:dave.mar...@linaro.org] >> >> Sent: Wednesday, December 08, 2010 4:11 PM >> >> To: Santosh Shilimkar >> >> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- >> >> o...@vger.kernel.org; linaro-dev@lists.linaro.org >> >> Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of > do_wfi() >> >> forCONFIG_THUMB2_KERNEL >> >> >> >> On Wed, Dec 8, 2010 at 5:59 AM, Santosh Shilimkar >> >> wrote: >> >> > Dave, >> >> > >> >> >> -Original Message- >> >> >> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] >> >> >> Sent: Wednesday, December 08, 2010 11:27 AM >> >> >> To: Dave Martin >> >> >> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- >> >> >> o...@vger.kernel.org; linaro-dev@lists.linaro.org >> >> >> Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of >> > do_wfi() >> >> >> forCONFIG_THUMB2_KERNEL >> >> >> >> >> >> > -Original Message- >> >> >> > From: Dave Martin [mailto:dave.mar...@linaro.org] >> >> >> > Sent: Tuesday, December 07, 2010 10:21 PM >> >> >> > To: Santosh Shilimkar >> >> >> > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- >> >> >> > o...@vger.kernel.org; linaro-dev@lists.linaro.org >> >> >> > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of >> >> do_wfi() >> >> >> > forCONFIG_THUMB2_KERNEL >> >> >> > >> >> >> > Hi, >> >> >> > >> >> >> > On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar >> >> >> > wrote: >> >> >> > > Dave, >> >> > >> >> > [.] >> >> >> >> >> >> > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume >> > v7/Thumb-2 >> >> >> > capable (and hence reasonably new) tools. >> >> >> > >> >> >> > I'll follow up shortly with a patch to the generic ARM Kconfig > to >> >> make >> >> >> > this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't >> >> accidentally >> >> >> > be configured together. >> >> >> > >> >> >> sure >> >> > >> >> > When you are doing the changes can you please check if you could >> build >> >> > the THUMB2 kernel with omap2plus_defconfig. I suspect the build > will >> >> > fail. >> >> >> >> With my Kconfig patch, kconfig won't let you turn on Thumb-2 in that >> >> configuration: >> >> >> >> >> > >> > http://lists.arm.linux.org.uk/lurker/message/20101207.165737.0897658f.en.h >> >> tml >> >> >> >> If you want to turn on Thumb-2, you must disable ARCH_OMAP2 first. > If >> >> my understanding is correct, this is the right behaviour. >> >> >> >> >> > Ofcourse it will build with ARCH_OMAP2 disabled :) (ARMv6 dependency) >> > In other words, I wanted to say that "omap2plus_defconfig" can't >> > be used as is to build THUMB kernel binary. >> >> Well, yes, that's another way of looking at it. Anyway, I think this >> is the intended result -- is it OK for you? >> > Should be ok considering you can't do much with it. But I let Tony comment > on it. Well, it depends on what you're trying to do. We can't combine Thumb-2 with a combined omap kernel intended to support omap2. But in linaro for example we are targeting v7+ only for the kernel and userspace, so we already build the kernel for v7 and don't include the OMAP2 support; instead we target OMAP3/4. I believe the situation for Ubuntu is similar. In our case, including the omap2 support wouldn't be useful, since the userspace won't run on that platform anyway... So really, my concerns are that a) the generic rules for CONFIG_THUMB2_KERNEL are correct, and b) the omap tree works well with this configuration to the maximum extent possible. Obviously, mixing ARCH_OMAP2 with THUMB2_KERNEL _isn't_ possible even in theory, so I don't consider it a failure if that combination isn't supported. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Tue, Dec 7, 2010 at 7:29 PM, Russell King - ARM Linux wrote: > On Tue, Dec 07, 2010 at 04:50:50PM +, Dave Martin wrote: >> I'll follow up shortly with a patch to the generic ARM Kconfig to make >> this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally >> be configured together. > > That's a rubbish dependency. You may have an ARCH_OMAP2 platform which > is Cortex A9, and you only have Cortex A9 support selected. In that > case there's no reason to prevent THUMB2_KERNEL being selected. > > The right thing to do is to make THUMB2_KERNEL depend on those CPUs > which are not to be selected - not by making it depend on some platform > configuration option(s) which aren't actually relevent. > You're correct on this point-- this was my conclusion also. If you haven't already, take a look at my other post http://www.spinics.net/lists/arm-kernel/msg106576.html Does this address your concern? Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: license for setup_sdcard.sh
On Tue, 2010-12-07 at 15:33 +, Dave Martin wrote:
> Hi,
>
> On Tue, Dec 7, 2010 at 3:10 PM, Robert Nelson wrote:
> > Hi Guilherme,
> >
> >> I know you found a workaround with fdisk so you're probably no longer
> >> using parted, but I was wondering if you were able to use parted to
> >> change the geometry in the partition table to 255heads/63sectors as the
> >> boot rom seems to require?
> >
> > Actually with current x-loader/u-boot the 255heads/63sectors isn't a
> > hard requirement anymore for the boot partition, so i've dropped it..
> >
> > https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh#L348
> >
> > So far tested on:
> >
> > Beagle B6 (oldest still booting beagle i have, any boards before that
> > had serial-ic overheating problems and eventually die under warrente.)
> > Beagle C2 & C4
> > Beagle xM A2
> >
> > with angstrom's: MLO-beagleboard-1.44+r16 & u-boot-beagleboard-2010.03+r65
> >
> > Panda A1
> >
> > with mlo/u-boot from: http://gitorious.org/pandaboard
> >
> > So right now i use parted to create the second partition. We could
> > drop fdisk for the first, if we could figure out how to make parted
> > create a partition starting at the first cylinder.
> >
> > For example, I've tried this and it doesn't boot:
> >
> > parted --script ${MMC} mkpart primary fat16 0 64
> >
> >> I ask because I'm working on converting our script to python and it'd be
> >> nice if I could use python-parted for that, but it doesn't seem to be
> >> able to.
>
> What about sfdisk? This is by far the simplest tool and works well
> for parts of linaro-media-create: by direct consequence of its
> simplicity it seems to be the most controllable and has the fewest
> unexpected limitations and failure modes among the tools I've played
> with, as well as being friendly to being program-driven. For manually
> generating an optimal partition layout for Beagles I've also found
> this the best tool to use.
sfdisk works indeed, but it'd be nicer if I could use a python library
since I'm converting the whole script. The python-parted API is crap
and undocumented, though, so I'll stick to running sfdisk in a
subprocess.
>
> Certainly it's horrible to have to use a different partitioner to
> create each partition...
Yeah, I was not planning to do that, although we currently use parted to
create a fresh partition table. It'd be nice if we could use sfdisk to
do that, but I don't think we can?
>
> sfdfisk works well for me though, e.g.:
>
> S=63; H=255
> BC=5
> cat <
> $S,$((5*BC*S-S)),0xc,*
> $(((5*BC*S+2047)/2048*2048))
> EOF
>
> ...will set up by 4GB card a treat, with a working boot partition and
> an aligned filesystem partition, with the CHS fields for the first
> partition filled in correctly:
>
> 80 01 01 00 0c fe 3f 04 3f 00 00 00 86 39 01 00
> 0010 00 19 15 05 83 2a a0 0a 00 40 01 00 00 c0 7e 00
> 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> (BC is the number of cylinders for the boot partition. The only
> constraint here is that the partition must be unambiguously FAT32,
> i.e. > 65534 clusters -- which gives a minimum sector count of 66593.
> 5 is simply (65593 + 63*255-1)/(63*255))
>
>
> Of course, the DOS partition table format is so trivial that if we're
> having to jump through a lot of hoops, it's tempting to suggest we
> could implement it ourselves (though I know I'm not supposed to say
> that due to fragmentation etc., etc)
>
> Cheers
> ---Dave
--
Guilherme Salgado
signature.asc
Description: This is a digitally signed message part
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: license for setup_sdcard.sh
On Wed, Dec 8, 2010 at 1:07 PM, Guilherme Salgado wrote:
> On Tue, 2010-12-07 at 15:33 +, Dave Martin wrote:
>> Hi,
>>
>> On Tue, Dec 7, 2010 at 3:10 PM, Robert Nelson
>> wrote:
>> > Hi Guilherme,
>> >
>> >> I know you found a workaround with fdisk so you're probably no longer
>> >> using parted, but I was wondering if you were able to use parted to
>> >> change the geometry in the partition table to 255heads/63sectors as the
>> >> boot rom seems to require?
>> >
>> > Actually with current x-loader/u-boot the 255heads/63sectors isn't a
>> > hard requirement anymore for the boot partition, so i've dropped it..
>> >
>> > https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh#L348
>> >
>> > So far tested on:
>> >
>> > Beagle B6 (oldest still booting beagle i have, any boards before that
>> > had serial-ic overheating problems and eventually die under warrente.)
>> > Beagle C2 & C4
>> > Beagle xM A2
>> >
>> > with angstrom's: MLO-beagleboard-1.44+r16 & u-boot-beagleboard-2010.03+r65
>> >
>> > Panda A1
>> >
>> > with mlo/u-boot from: http://gitorious.org/pandaboard
>> >
>> > So right now i use parted to create the second partition. We could
>> > drop fdisk for the first, if we could figure out how to make parted
>> > create a partition starting at the first cylinder.
>> >
>> > For example, I've tried this and it doesn't boot:
>> >
>> > parted --script ${MMC} mkpart primary fat16 0 64
>> >
>> >> I ask because I'm working on converting our script to python and it'd be
>> >> nice if I could use python-parted for that, but it doesn't seem to be
>> >> able to.
>>
>> What about sfdisk? This is by far the simplest tool and works well
>> for parts of linaro-media-create: by direct consequence of its
>> simplicity it seems to be the most controllable and has the fewest
>> unexpected limitations and failure modes among the tools I've played
>> with, as well as being friendly to being program-driven. For manually
>> generating an optimal partition layout for Beagles I've also found
>> this the best tool to use.
>
> sfdisk works indeed, but it'd be nicer if I could use a python library
> since I'm converting the whole script. The python-parted API is crap
> and undocumented, though, so I'll stick to running sfdisk in a
> subprocess.
Yeah, sure. Really, the best thing would to communitywise do would be
to fix libparted to work with our use case (assmuing it can't do the
right thing already of course). But I'm not very familiar with it, so
I don't know what this would involve.
>
>>
>> Certainly it's horrible to have to use a different partitioner to
>> create each partition...
>
> Yeah, I was not planning to do that, although we currently use parted to
> create a fresh partition table. It'd be nice if we could use sfdisk to
> do that, but I don't think we can?
sfdisk won't _just_ create an empty partition table if my
understanding is correct.
But if you tell sfdisk to set up partitions on a device with no
partition table it will set one up.
sfdisk doesn't appear to create a disk signature at offset 0x1B8 -
it's left as-is. Some other partitioners, such as fdisk, set up an ID
when creating an MBR-style partition table. We might decide not to
care about that...
Cheers
---Dave
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to work withCONFIG_THUMB2_KERNEL
On Wed, 8 Dec 2010, Dave Martin wrote: > Hi, > > On Tue, Dec 7, 2010 at 7:15 PM, Nicolas Pitre > wrote: > > On Tue, 7 Dec 2010, Dave Martin wrote: > > > >> On Tue, Dec 7, 2010 at 2:53 PM, Dave Martin wrote: > >> [...] > >> > Note that converting to C doesn't mean that code which attempts to > >> > copy function bodies will work: you still need to handle the fact that > >> > if f() is a C function symbol, then the value of the symbol f is > >> > actually the function's base address + 1. See my changes in sram.c, > >> > >> To clarify, this applies *if* f is a Thumb symbol. > > > > To make it generic, a new macro could be used: > > > > #define SYM_ADDR(x) ((void *)((long)(x) & ~1L)) > > Could do ... I wasn't sure if it was useful for just this one case, > but I guess we may encounter others. And it would make the code a lot > less messy... That also makes the code self documenting. > if so, a macro for exracting just the Thumb bit, and a macro for > rebasing a symbol while preserving the Thumb bit could also be useful. > > #define SYM_STATE(x) ((long)(x) & 1) > #define SYM_REBASE(new_addr, sym) ((void *)((long)SYM_ADDR(new_addr) | > SYM_STATE(sym))) > > The relationship could be a bit clearer if we use the name SYM_BASE > instead of SYM_ADDR. > > With these, the affected code becomes something like: > > memcpy(buffer, SYM_BASE(f), size_of_f); > new_f = SYM_REBASE(f, buffer); > > What do you think? Looks fine to me. > Is there a recommended type for a pointer-sized integer? I notice > linux/types.h defines uintptr_t (as unsigned long). If uintptr_t is already defined then it is probably a good idea to just use it. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro QEMU package in Ubuntu?
On Wed, Dec 8, 2010 at 7:23 AM, Peter Maydell wrote: > On 8 December 2010 08:53, Jani Monoses wrote: >> one of the Ubuntu blueprints for 11.04 is to provide a QEMU better suited to >> Linaro/ARM work in the official archives, allowing to >> at least the official Ubuntu ARM images. >> >> The Linaro PPA provides a package based on qemu-maemo from gitorious, >> and it is ahead of what is packaged in that it supports the BeagleBoard. > > Yes. At the moment I think that something based on that tree is > your best practical choice if you want neon support and certainly > if you need omap3. > >> I see there's also qemu-arm repo in git.linaro.org - I assume this is a >> newer and preferable upstream to the maemo one? > > No. This tree is currently tracking qemu upstream master and I am > using it as a way to provide tested arm patches to upstream in a way > that they can pull. Are you also tracking all those additional omap 3 patches available at the maemo/meego tree? I'm ok to use the maemo/meego one, as it's currently used by Linaro, but I don't know if they are actually following or at least rebasing their patches over the upstream tree. The idea of that blueprint is basically to identify what is the best maintainable and working tree for at least one target (omap or versatile) so we can get the best Qemu experience for ARM at Ubuntu, by the time of the Natty release. It seems that the current best working target is the omap 3 one, but at UDS it was said that upstream wasn't that happy to incorporate those patches so soon, so we get to the point that is inevitable to keep both trees, or creating a new one incorporating all these patches and help trying to get them upstream (and that's what I thought the linaro git tree was all about). >> Are the ARM patches being pushed and accepted into upstream QEMU regularly? >> In this case there may be no need to create a new package >> and just wait for that work to get released and packaged, and maybe focus >> the effort on helping with upstreaming the ARM changes. > > This depends on how long you are prepared to wait. Some ARM > fixes are starting to go into upstream. OTOH upstream's proposed > release cycle is about once every 6 months, with 0.14 due to > branch very shortly. So 0.15 ought to be much better for ARM > support but won't be available until middle of next year. > > I'm currently focusing most of my effort on working with upstream > to get these patches accepted. I also have a blueprint for doing > at least enough maintenance/bugfixing on the maemo-qemu > package so it continues to boot the linaro images. Ok, so you're saying that the maemo-qemu package will be probably the one used by the Linaro's tools for the next cycle? Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro QEMU package in Ubuntu?
On 8 December 2010 17:50, Ricardo Salveti wrote: > On Wed, Dec 8, 2010 at 7:23 AM, Peter Maydell > wrote: >> On 8 December 2010 08:53, Jani Monoses wrote: >>> one of the Ubuntu blueprints for 11.04 is to provide a QEMU better suited to >>> Linaro/ARM work in the official archives, allowing to >>> at least the official Ubuntu ARM images. >>> >>> The Linaro PPA provides a package based on qemu-maemo from gitorious, >>> and it is ahead of what is packaged in that it supports the BeagleBoard. >> >> Yes. At the moment I think that something based on that tree is >> your best practical choice if you want neon support and certainly >> if you need omap3. >> >>> I see there's also qemu-arm repo in git.linaro.org - I assume this is a >>> newer and preferable upstream to the maemo one? >> >> No. This tree is currently tracking qemu upstream master and I am >> using it as a way to provide tested arm patches to upstream in a way >> that they can pull. > > Are you also tracking all those additional omap 3 patches available at > the maemo/meego tree? Well, there's http://gitorious.org/ubuntu-qemu-omap which is really just the maemo tree with packaging patches on it. I've done the odd bugfix to the omap code but I've been able to get those taken into the maemo/meego tree so there's been no need to carry them as a separate linaro/ubuntu tree. OMAP3 support patches are on the todo list to help in getting them upstream, but they're behind the ARM correctness fixes in priority. > It seems that the current best working target is the omap 3 one, but > at UDS it was said that upstream wasn't that happy to incorporate > those patches so soon, so we get to the point that is inevitable to > keep both trees, or creating a new one incorporating all these patches > and help trying to get them upstream (and that's what I thought the > linaro git tree was all about). Well, the linaro git tree is assisting in that process, but it's doing it by being where I put small reviewed sets of patches in a rebased branch that Anthony can pull, rather than by being a complete tree of upstream + all known ARM fixes. (I think if we tried to maintain the latter it would be a lot of work and would look pretty similar to the meego tree anyhow, but if people think it's worthwhile effort we can talk about it.) >> I'm currently focusing most of my effort on working with upstream >> to get these patches accepted. I also have a blueprint for doing >> at least enough maintenance/bugfixing on the maemo-qemu >> package so it continues to boot the linaro images. > > Ok, so you're saying that the maemo-qemu package will be probably the > one used by the Linaro's tools for the next cycle? Yes. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro QEMU package in Ubuntu?
On Wed, Dec 8, 2010 at 3:59 PM, Peter Maydell wrote: > On 8 December 2010 17:50, Ricardo Salveti wrote: >> On Wed, Dec 8, 2010 at 7:23 AM, Peter Maydell >> wrote: >>> On 8 December 2010 08:53, Jani Monoses wrote: one of the Ubuntu blueprints for 11.04 is to provide a QEMU better suited to Linaro/ARM work in the official archives, allowing to at least the official Ubuntu ARM images. The Linaro PPA provides a package based on qemu-maemo from gitorious, and it is ahead of what is packaged in that it supports the BeagleBoard. >>> >>> Yes. At the moment I think that something based on that tree is >>> your best practical choice if you want neon support and certainly >>> if you need omap3. >>> I see there's also qemu-arm repo in git.linaro.org - I assume this is a newer and preferable upstream to the maemo one? >>> >>> No. This tree is currently tracking qemu upstream master and I am >>> using it as a way to provide tested arm patches to upstream in a way >>> that they can pull. >> >> Are you also tracking all those additional omap 3 patches available at >> the maemo/meego tree? > > Well, there's http://gitorious.org/ubuntu-qemu-omap which is really > just the maemo tree with packaging patches on it. I've done the > odd bugfix to the omap code but I've been able to get those taken > into the maemo/meego tree so there's been no need to carry them > as a separate linaro/ubuntu tree. > > OMAP3 support patches are on the todo list to help in getting > them upstream, but they're behind the ARM correctness fixes > in priority. Ok, good to know. >> It seems that the current best working target is the omap 3 one, but >> at UDS it was said that upstream wasn't that happy to incorporate >> those patches so soon, so we get to the point that is inevitable to >> keep both trees, or creating a new one incorporating all these patches >> and help trying to get them upstream (and that's what I thought the >> linaro git tree was all about). > > Well, the linaro git tree is assisting in that process, but it's doing > it by being where I put small reviewed sets of patches in a rebased > branch that Anthony can pull, rather than by being a complete > tree of upstream + all known ARM fixes. (I think if we tried to > maintain the latter it would be a lot of work and would look pretty > similar to the meego tree anyhow, but if people think it's worthwhile > effort we can talk about it.) Well, as you're aware of what needs to be done, and what needs to be sent upstream don't know if that would actually help you. Having all those patches on a different tree would just help people getting one tree that would probably be the best working one and with a larger feature set for ARM, but for sure it'd give you more work (as you'd need to maintain and rebase the tree from time to time). >>> I'm currently focusing most of my effort on working with upstream >>> to get these patches accepted. I also have a blueprint for doing >>> at least enough maintenance/bugfixing on the maemo-qemu >>> package so it continues to boot the linaro images. >> >> Ok, so you're saying that the maemo-qemu package will be probably the >> one used by the Linaro's tools for the next cycle? > > Yes. Nice to know, so I believe we'll probably do the same at Ubuntu, at least for Natty cycle. Hopefully for N+1 or N+2 we'll end up with a much better upstream tree for ARM. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Toolchain WG 2010-11-03
Here's what the toolchain group has been doing: * 2010.12 release is coming up. Bug list is in a good way. Build is good, test results are good. * Atomic memory operations are finished, in GCC, in GLIBC, and in Ubuntu. Coverage report is done at [[WorkingGroups/ToolChain/AtomicMemoryOperations]] * Handed off valgrind to Foundations to make sure the updated version is in Ubuntu * String routines are approaching the end of a good phase 1. Next is sorting out the copyright assignment issues * Lack of A9 hardware is causing headaches. People are benchmarking Linaro GCC on hardware and getting unexpected results. * Started investigating libffi variadic support * Received a copy of the SPEC CPU 2006 benchmark suite Weekly meeting minutes are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-12-06 Standup minutes are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-12-08 Audio is here: http://tc.seabright.co.nz/toolchainwg/ -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] export clock debug information to user space
Hi Yong,
We're getting pretty close - just a couple of changes:
> + } else {
> + struct preinit_clk *p;
> + mutex_lock(&preinit_lock);
> + p = kmalloc(sizeof(*p), GFP_KERNEL);
> + if (!p)
> + goto unlock;
> + p->clk = clk;
> + list_add(&p->list, &preinit_clks);
> +unlock:
> + mutex_unlock(&preinit_lock);
> + }
Might be best to avoid the goto:
} else {
struct preinit_clk *p;
mutex_lock(&preinit_lock);
p = kmalloc(sizeof(*p), GFP_KERNEL);
if (p) {
p->clk = clk;
list_add(&p->list, &preinit_clks);
}
mutex_unlock(&preinit_lock);
}
> +static int __init clk_debugfs_init(void)
> +{
> + struct preinit_clk *pclk, *tmp;
> +
> + if (debugfs_initialized())
> + init_done = 1;
No need to check debugfs_initialised() here; if it's not initialised we're in
trouble anyway.
> +
> + list_for_each_entry(pclk, &preinit_clks, list) {
> + clk_debug_register(pclk->clk);
> + }
You should hold preinit_lock while traversing the list here.
Cheers,
Jeremy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] export clock debug information to user space
hi Jeremy,
It's nice to be close :).
And it seems that many people in arm kernel list are also intested in
the clock debug information, maybe we can post next version to that
list and let them know how things are going.
On Thu, Dec 9, 2010 at 10:02 AM, Jeremy Kerr wrote:
> Hi Yong,
>
> We're getting pretty close - just a couple of changes:
>
>> + } else {
>> + struct preinit_clk *p;
>> + mutex_lock(&preinit_lock);
>> + p = kmalloc(sizeof(*p), GFP_KERNEL);
>> + if (!p)
>> + goto unlock;
>> + p->clk = clk;
>> + list_add(&p->list, &preinit_clks);
>> +unlock:
>> + mutex_unlock(&preinit_lock);
>> + }
>
> Might be best to avoid the goto:
Acked.
>
> } else {
> struct preinit_clk *p;
> mutex_lock(&preinit_lock);
> p = kmalloc(sizeof(*p), GFP_KERNEL);
> if (p) {
> p->clk = clk;
> list_add(&p->list, &preinit_clks);
> }
> mutex_unlock(&preinit_lock);
> }
>
>> +static int __init clk_debugfs_init(void)
>> +{
>> + struct preinit_clk *pclk, *tmp;
>> +
>> + if (debugfs_initialized())
>> + init_done = 1;
>
> No need to check debugfs_initialised() here; if it's not initialised we're in
> trouble anyway.
IMO, it is still needed. If debugfs is not initialised, we should
return directly, otherwise, it will redo clk_debug_register() again.
How about:
if (!debugfs_initialized())
return 0;
init_done = 1;
>
>> +
>> + list_for_each_entry(pclk, &preinit_clks, list) {
>> + clk_debug_register(pclk->clk);
>> + }
>
> You should hold preinit_lock while traversing the list here.
>
> Cheers,
>
>
> Jeremy
>
Thanks
Yong
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] export clock debug information to user space
Hi Yong,
> >> +static int __init clk_debugfs_init(void)
> >> +{
> >> + struct preinit_clk *pclk, *tmp;
> >> +
> >> + if (debugfs_initialized())
> >> + init_done = 1;
> >
> > No need to check debugfs_initialised() here; if it's not initialised
> > we're in trouble anyway.
>
> IMO, it is still needed. If debugfs is not initialised, we should
> return directly, otherwise, it will redo clk_debug_register() again.
>
> How about:
> if (!debugfs_initialized())
> return 0;
>
> init_done = 1;
>
debugfs is initialised as a core_initcall (and clk_debugfs_init as a
late_initcall), so we should never see this case.
However, if we ever do the 'return 0', there is no mechanism to retry the
initialisation (ie, clk_debugfs_register will only be called once), so we'll
just keep adding clocks to preinit_list.
If anything, return an error code (-EBUSY maybe?) so that we get a useful
message with initcall_debug. But I don't think this is necessary.
Cheers,
Jeremy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
