linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[RFC PATCH v4 0/4] Consolidate cpuidle timekeeping and irq enabling

by Robert Lee

This patch series moves the timekeeping and irq enabling from the platform code to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). To save reviewers time, only a few platforms which required the most changes are included in this version. If these changes are approved, the next version will include the remaining platform code which should require minimal changes. For those who have followed the previous patch versions, as you know, the previous version of this patch series added some helper functionality which used a wrapper function to remove the time keeping and irq enabling/disabling from the platform code. There was also initialization helper functionality which has now been removed from this version. If the basic implementation in this version is approved, then a separate patch submission effort can be made to focus on consolidation of initialziation functionality. Based on 3.3-rc1 v3 submission can be found here: http://www.spinics.net/lists/arm-kernel/msg156751.html Changes since v3: * Removed drivers/cpuidle/common.c ** Removed the initialization helper functions ** Removed the wrapper used to consolidate time keeping and irq enable/disable * Add time keeping and local_irq_disable handling in cpuidle_call_idle(). * Made necessary modifications to a few platforms that required the most changes ** Note on omap3: changed structure of omap3_idle_drvdata and added per_next_state and per_saved_state vars to accomodate new framework. v2 submission can be found here: http://comments.gmane.org/gmane.linux.ports.arm.kernel/144199 Changes since v2: * Made various code organization and style changes as suggested in v1 review. * Removed at91 use of common code. A separate effort is underway to clean at91 code and the author has offered to convert to common interface as part of those changes (if this common interface is accepted in time). * Made platform cpuidle_driver objects __initdata and dynamically added one persistent instance of this object in common code. * Removed imx5 pm usage of gpc_dvfs clock as it is no longer needed after being enabled during clock initialization. * Re-organized patches. v1 submission can be found here: http://comments.gmane.org/gmane.linux.ports.arm.kernel/142791 Changes since v1: * Common interface moved to drivers/cpuidle and made non arch-specific. * Made various fixes and suggested additions to the common cpuidle code from v1 review. * Added callback for filling in driver_data field as needed. * Modified the various platforms with these changes. Robert Lee (4): cpuidle: Add time keeping and irq enabling ARM: omap: Remove cpuidle timekeeping and irq enable/disable acpi: Remove cpuidle timekeeping and irq enable/disable x86: Remove cpuidle timekeeping and irq enable/disable arch/arm/mach-omap2/cpuidle34xx.c | 96 ++++++++---------- drivers/acpi/processor_idle.c | 203 ++++++++++++++++++++++--------------- drivers/cpuidle/cpuidle.c | 75 +++++++++++--- drivers/idle/intel_idle.c | 110 ++++++++++++++------ include/linux/cpuidle.h | 26 +++-- 5 files changed, 317 insertions(+), 193 deletions(-)

14 years, 1 month

describing who can see restricted lava jobs

by Michael Hudson-Doyle

Hi all, The LAVA team is working on support for private jobs -- we already have some support for private results, but if the log of the job that produced the results is publicly visible, this isn't much privacy. The model for result security is that a set of results can be: - anonymous (anyone can see, anyone can write) - public (anyone can see, only owning user or group can write) - private (only owning user or group can see or write) Each non-anonymous set of results is owned by a group or user. I think this model is sufficiently flexible -- the only gap I can see is that it's not possible to have a stream where a subset of the people who can see it can submit results to it. Clearly it makes sense to have the set of people who can see the eventual results and see the job output be the same. Currently the former group is encoded in the stream name of the submit_results action, for example: { "command": "submit_results", "parameters": { "server": "http://locallava/RPC2/", "stream": "/private/personal/mwhudson/test/" } } would place results in a stream called 'test' that only I can or "stream": "/public/team/linaro/kernel/" identifies a stream that anyone can see but only members of the linaro group can put results in. The scheduler *could* read out this parameter from the job json and enforce the privacy rules based on this, but that seems a bit fragile somehow. I think top level attribute in the json describing who can see the job would make sense -- we can then make sure the stream name on the submit_results matches this. Does the /{public,private}/{personal,team}/{team-or-user-name} syntax make sense to people? I think it's reasonably clear and nicely terse. We should do as much validation at submit time as we can (rejecting jobs that submit to streams that do not exist, for example). Cheers, mwh

14 years, 1 month

Re: linaro blocking issue

by Christian Robottom Reis

On Thu, Feb 16, 2012 at 12:49:21PM +0530, Amit wrote: > I am not able to install any packages related to linaro for example > when I tried that below command > > sudo add-apt-repository ppa:linaro-maintainers/toolchain > I am getting error like > Error reading > https://launchpad.net/api/1.0/~linaro-maintainers/+archive/toolchain: > <urlopen error [Errno 111] Connection refused> > > But when I use a direct INTERNET connection without proxy its working > fine. The problem you're running into is that add-apt-repository is fetching a GPG key from the Ubuntu keyserver, which is running on port 11371. You can indeed punch a hold in the firewall, but you can also just issue sudo gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 7BE1F97B since this is a one-time operation -- once the key is set up transferring packages is done over regular http. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs

14 years, 1 month

looking for sources for beagle u-boot/u-boot SPL for 1201 images

by Peter Maydell

Hi. I'm trying to track down the sources that made the U-Boot and U-Boot SPL for the beagle 1201 release image: http://releases.linaro.org/images/12.01/oneiric/nano/ sources.txt says that's this hwpack: http://releases.linaro.org/12.01/ubuntu/oneiric-hwpacks/ but the manifest.txt there: http://releases.linaro.org/12.01/ubuntu/oneiric-hwpacks/hwpack_linaro-omap3… only says: u-boot-tools=2011.06-3ubuntu1 and doesn't say where I should find this version of the package. I guessed that it might be the u-boot package 2011.06-3ubuntu1 from oneiric, but that does not seem to contain the SPL code, so I'm guessing it's the wrong one. (Also U-Boot announces itself as "U-Boot 2011.12 (Jan 22 2012 - 00:52:03)" so that manifest is clearly a load of rubbish...) Can anybody help? thanks in advance -- PMM

14 years, 1 month

[ANN] Support for fetching build configs from git for Android Builds

by Paul Sokolovsky

Hello, As the result of implementation of https://blueprints.launchpad.net/linaro-android-infrastructure/+spec/build-… , android-build.linaro.org now can indirectly fetch build config stored in a git repository. To achieve that, bootstrap config (as specified in android-build.linaro.org) should contain reference to config's repo/branch/file (configuration variables are modeled on the similar MANIFEST_* ones), e.g.: BUILD_CONFIG_REPO=git://git.linaro.org/people/pfalcon/android/linaro/build-… BUILD_CONFIG_BRANCH=master BUILD_CONFIG_FILENAME=panda-ics-gcc46-tilt-tracking-blob.conf http://android.git.linaro.org/gitweb?p=linaro/build-configs.git;a=summary was created to store configs for the official builds in the Gerrit tree. Sample job is available here: https://android-build.linaro.org/builds/~pfalcon/git-build-config/ (it uses personal repo as a test). -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

14 years, 1 month

February 2012 Kernel Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) and the Linaro Platform Group are excited to announce the availability our February 2012 development snapshot: linux-linaro-3.3-rc3-2012.02-1 As the word "snapshot" implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. We are excited about our first -rc based kernel as we move to a new process that will provide early access to more bleeding edge features on member-supported LEBs. The source tarball is available at: http://launchpad.net/linux-linaro/3.3/3.3-rc3-2012.02/+download/linux-linar… The kernel sources can also be accessed using git at: git://git.linaro.org/people/ynk/linux-linaro-tracking.git tag: linux-linaro-3.3-rc3-2012.02-1 This kernel includes the following changes from the 2011.11 kernel: - Update to 3.3-rc3 - Various patches from Linaro * samsung_cpuidle_l2_retention patch set from the power management WG * thermal_cpu_cooling patch set from the power management WG * irq_domain patch set from Grant L. (cherry-picked from linux-next) * Fix for https://bugs.launchpad.net/bugs/918412 * Basic device tree board support for supported ARM boards (comes from linux-linaro-3.1) * sched: Ensure cpu_power periodic update (Vincent G.) * ARM: kprobes: work around build errors (Arnd B.) * usb: ehci: make HC see up-to-date qh/qtd descriptors ASAP (Ming L.) * Perf: Fallback to /bin/more if less is not found for perf pager (Avik S.) A full change log against the 3.3-rc3 release is available at: http://launchpad.net/linux-linaro/3.3/3.3-rc3-2012.02/+download/CHANGELOG-l… High Priority Known Issues: - None at this time Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

14 years, 1 month

Upstream Patch Attribution and Traceability Errors

by Joey STANFORD

Hi Everyone, I wanted to remind you about two important things to consider when writing your patch comments for Linaro. I've been seeing some occasional upstream patches lately which have problems with a) attributions in the comments and b) traceability. So please... 1) Use your Linaro email address if you have it and also include your member/partner company e.g. Joey Stanford <joey(a)linaro.org> for the Samsung Landing Team e.g. Joey Stanford <joey(a)linaro.org> assigned to Linaro from IBM e.g. Joey Stanford <joey(a)personaladdress.net> for Linaro Currently I see patches submitted as "Joey Stanford <joey(a)canonical.com>" with no reference to Linaro at all. This is a problem firstly because we aren't attributing the code fully and secondly it reduces the awareness in the Open Source community of the benefits Linaro brings to the table. 2) If your work is based upon a bug or blueprint in Launchpad, or any other system for that matter, please: a) Put these in the bzr/git revision log via commit comment. Most of you are doing this and it's great. If you aren't, please do this. b) Consider including that in the comments for traceability. e.g. Fix for audio stack failure on IMX.53 Launchpad Bug #123 e.g. Implement Graphics acceleration on Origen, Google Code Issue #123 Today we are aware of some of our members who are grep'ing patch comments, but not revision logs, to extract this information and are not finding the details of what the patch fixes. I realize this somewhat of an edge case but every bit helps for traceability. Thanks, Joey -- Joey STANFORD Engineering Program Manager Office: +1-303-800-6609 http://www.linaro.org/ Open source software for ARM SoCs

14 years, 1 month

trouble building linux-linaro-3.0-2011.08-0

by John Rigby

I'm having trouble building the Thumb2 kernel on, I actually believe this same code worked some time ago before a toolchain update. There are actually two problems described below. I get past the first with a config change but don't know how to fix the second one. Start with mx51_defconfig, it builds uImage fine: $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- mx51_defconfig $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage Save the working .config to config1 $ cp .config config1 Edit .config and remove this line then run make oldconfig. $ CONFIG_THUMB2_KERNEL is not set $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- oldconfig Answer y to THUMB2_KERNEL and THUMB2_AVOID_R_ARM_THM_JUMP11 Save new Thumb2 enabled config to config2 Here is the diff: $ diff -u config1 config2 --- config1 2011-08-21 14:50:23.014654705 -0600 +++ config2 2011-08-21 14:51:13.164654727 -0600 @@ -339,9 +339,10 @@ CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_HZ=100 -# CONFIG_THUMB2_KERNEL is not set +CONFIG_THUMB2_KERNEL=y +CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y +CONFIG_ARM_ASM_UNIFIED=y CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set CONFIG_HAVE_ARCH_PFN_VALID=y @@ -1417,7 +1418,6 @@ # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set -CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set @@ -1429,7 +1429,6 @@ # CONFIG_SYSCTL_SYSCALL_CHECK is not set # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_C_RECORDMCOUNT=y Attempt to build this: $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage ... LD init/built-in.o LD .tmp_vmlinux1 arch/arm/kernel/built-in.o: In function `get_wchan': early_printk.c:(.text+0x1400): undefined reference to `unwind_frame' arch/arm/kernel/built-in.o: In function `walk_stackframe': early_printk.c:(.text+0x2832): undefined reference to `unwind_frame' make: *** [.tmp_vmlinux1] Error 1 Poke around a bit and it looks like setting ARM_UNWIND could make difference so try that. Edit .config the remove # CONFIG_ARM_UNWIND is not set then run make old config again. $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- oldconfig Call the result config3 $ cp .config config3 So here is the cumulative diff $ diff -u config1 config3 --- config1 2011-08-21 14:50:23.014654705 -0600 +++ config3 2011-08-21 14:54:29.584654811 -0600 @@ -339,9 +339,10 @@ CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_HZ=100 -# CONFIG_THUMB2_KERNEL is not set +CONFIG_THUMB2_KERNEL=y +CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y +CONFIG_ARM_ASM_UNIFIED=y CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set CONFIG_HAVE_ARCH_PFN_VALID=y @@ -1417,7 +1418,6 @@ # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set -CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set @@ -1429,7 +1429,6 @@ # CONFIG_SYSCTL_SYSCALL_CHECK is not set # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_C_RECORDMCOUNT=y @@ -1443,7 +1442,7 @@ # CONFIG_KGDB is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_STRICT_DEVMEM is not set -# CONFIG_ARM_UNWIND is not set +CONFIG_ARM_UNWIND=y # CONFIG_DEBUG_USER is not set CONFIG_DEBUG_LL=y CONFIG_EARLY_PRINTK=y Try building again. $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage ... LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map OBJCOPY arch/arm/boot/Image Kernel: arch/arm/boot/Image is ready AS arch/arm/boot/compressed/head.o arch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2' make[2]: *** [arch/arm/boot/compressed/head.o] Error 1 make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2 make: *** [uImage] Error 2 Here is my gcc version: $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.1-5ubuntu2~ppa1) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And as version: GNU assembler (GNU Binutils for Ubuntu) 2.21.52.20110707 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `arm-linux-gnueabi'. Three configs attached: config1 -- original config from make mx51_defconfig config2 -- config after turning on thumb2 config3 -- config after setting ARM_UNWIND Any help would be appreciated. Thanks John

14 years, 1 month

Initial Linaro+Android kernel for 11.12 is available

by john stultz

Zach reminded me that this month is compressed, so a linaro+android kernel would be needed immediately for 11.12. As Andrey is just ramping up in taking over for the Linaro Android kernel maintenance, I wanted to just get a kernel out, using the older kernel workflow, so that we had something current for 11.12. Anyway. This is straight from Andy Green's linaro-androidization-tracking branch, with a few small build fixes added on that I found in my testing and the base android_*_defconfig files. You can find the tree here: git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.2-agreen-rebase The current sha is tagged as: linux-linaro-3.2-2011.12-0-android-0 Known issues: There seems to be something in the androidization branch that is causing problems on beagle xm and origen. In my testing beagle xm kernel ends up hanging in mid-boot(after ~4 seconds). And the orgien board doesn't show anything past "Uncompressing Linux... done, booting the kernel". If I drop the androidization patches and go back to the v3.2-rc4 base, both kernels boot until the Android userland environment starts and falls over because the android features are missing. I mucked about for awhile on both of these tonight, but wasn't able to solve either of them, so I'd appreciate any help trying to narrow down what is wrong on Origen (beagle is apparently lower priority). Andy, one issue with the re-factored android patch tree: Its not very bisect-able. If I jump back to a topic branch, frequently there are missing dependencies that keep it from building. Any thoughts on how we can better chase down these sorts of issues? thanks -john

14 years, 1 month

Re: [PATCH v2 6/6] mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply

by S, Venkatraman

On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak <rnayak(a)ti.com> wrote: > > MMC1 is not the only instance that can be used/wired for SD. > So remove this assumption from the driver. > > Now that all the mmc id based usage is removed, get rid > of all the DEVID defines and also the 'id' field from the > omap_hsmmc_host structure. > > Signed-off-by: Rajendra Nayak <rnayak(a)ti.com> > Tested-by: Venkatraman S <svenkatr(a)ti.com> > Tested-by: Balaji T K <balajitk(a)ti.com> For the whole series, Acked-by: Venkatraman S <svenkatr(a)ti.com> > --- > drivers/mmc/host/omap_hsmmc.c | 31 ++----------------------------- > 1 files changed, 2 insertions(+), 29 deletions(-) > > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c > index 17e264b..e3eb9d4 100644 > --- a/drivers/mmc/host/omap_hsmmc.c > +++ b/drivers/mmc/host/omap_hsmmc.c > @@ -106,17 +106,6 @@ > #define SOFTRESET (1 << 1) > #define RESETDONE (1 << 0) > > -/* > - * FIXME: Most likely all the data using these _DEVID defines should come > - * from the platform_data, or implemented in controller and slot specific > - * functions. > - */ > -#define OMAP_MMC1_DEVID 0 > -#define OMAP_MMC2_DEVID 1 > -#define OMAP_MMC3_DEVID 2 > -#define OMAP_MMC4_DEVID 3 > -#define OMAP_MMC5_DEVID 4 > - > #define MMC_AUTOSUSPEND_DELAY 100 > #define MMC_TIMEOUT_MS 20 > #define OMAP_MMC_MIN_CLOCK 400000 > @@ -164,7 +153,6 @@ struct omap_hsmmc_host { > void __iomem *base; > resource_size_t mapbase; > spinlock_t irq_lock; /* Prevent races with irq handler > */ > - unsigned int id; > unsigned int dma_len; > unsigned int dma_sg_idx; > unsigned char bus_mode; > @@ -300,7 +288,6 @@ static int omap_hsmmc_set_power(struct device *dev, > int slot, int power_on, > static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host) > { > struct regulator *reg; > - int ret = 0; > int ocr_value = 0; > > mmc_slot(host).set_power = omap_hsmmc_set_power; > @@ -308,15 +295,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host > *host) > reg = regulator_get(host->dev, "vmmc"); > if (IS_ERR(reg)) { > dev_dbg(host->dev, "vmmc regulator missing\n"); > - /* > - * HACK: until fixed.c regulator is usable, > - * we don't require a main regulator > - * for MMC2 or MMC3 > - */ > - if (host->id == OMAP_MMC1_DEVID) { > - ret = PTR_ERR(reg); > - goto err; > - } > } else { > host->vcc = reg; > ocr_value = mmc_regulator_get_ocrmask(reg); > @@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host > *host) > mmc_slot(host).ocr_mask = ocr_value; > } else { > if (!(mmc_slot(host).ocr_mask & ocr_value)) { > - pr_err("MMC%d ocrmask %x is not > supported\n", > - host->id, > mmc_slot(host).ocr_mask); > + pr_err("MMC ocrmask %x is not > supported\n", > + mmc_slot(host).ocr_mask); > mmc_slot(host).ocr_mask = 0; > return -EINVAL; > } > @@ -358,10 +336,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host > *host) > } > > return 0; > - > -err: > - mmc_slot(host).set_power = NULL; > - return ret; > } > > static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host) > @@ -1791,7 +1765,6 @@ static int __init omap_hsmmc_probe(struct > platform_device *pdev) > host->dev->dma_mask = &pdata->dma_mask; > host->dma_ch = -1; > host->irq = irq; > - host->id = pdev->id; > host->slot_id = 0; > host->mapbase = res->start; > host->base = ioremap(host->mapbase, SZ_4K); > -- > 1.7.1 >

14 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev