linaro-dev May 2011

linaro-dev@lists.linaro.org

122 participants
116 discussions

by Per Forlin

Hi, I am trying to run wl12xx_sdio_test but I get: "mmc1:0001:2: could not wake up chip". What am I missing? In Kconfig wl12xx_sdio_test depends on wl12xx_sdio. Does the test really depend on the wl12xx_sdio driver? The test module is a sdio driver too. I use the latest linux-linaro-2.6.38 together with defconfig from beta-2 (hwpack_linaro-panda_20110426-0_armel_supported.tar.gz): I downloaded firmware according to http://elinux.org/Panda_How_to_kernel_2_6_39#Wlan. On the pandaboard: rmmod wl12xx_sdio modprobe wl12xx_sdio_test wl12xx_sdio_test mmc1:0001:2: could not wake up chip wl12xx_sdio_test: probe of mmc1:0001:2 failed with error 1 Thanks, Per

14 years, 10 months

Mainlining android fastboot support to upstream u-boot

by John Rigby

On Tue, Apr 19, 2011 at 12:33 PM, Wolfgang Denk <wd(a)denx.de> wrote: > Dear Jim Huang, > > In message <BANLkTi=yNnA9nBxWNG_1mfwfd6G_O09GOA(a)mail.gmail.com> you wrote: >> >> My idea is that we require abstract 'bootloader' component in Android >> device/linaro/common, and (patched) 'u-boot' would be the provider of >> 'bootloader' component in >> device/linaro/Linaro-Evaluation-Build-Hardware. Also, supporting > > If you are discussing requirements for U-Boot, and plan to get these > merged in to mainlineU-Boot one day, it would probably be a good idea > to discuss these plans on the U-Boot mailing list as well - ideally > before any design is cast in iron. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > The management question ... is not _whether_ to build a pilot system > and throw it away. You _will_ do that. The only question is whether > to plan in advance to build a throwaway, or to promise to deliver the > throwaway to customers. - Fred Brooks, "The Mythical Man Month" > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > Wolfgang, As you can see from this discussion, Linaro is considering applying resources (probably me) to upstreaming Android Fastboot features into mainline u-boot. What suggestions do you have for making this process as painless as possible? The topic came up briefly here last year: http://lists.denx.de/pipermail/u-boot/2010-August/076343.html An implementation exists for omap4/panda on gitorious: git://gitorious.org/pandaboard/u-boot.git in the omap4_panda_es2.0 branch. There is also a version for omap3 somewhere else on gitorious. To bring this to mainline one would have to: 1) Bring code up to current mainline revision. 2) Fix any coding standards issues. 3) Document the new features. What else? I know one issue maybe why does this need to exist when other solutions exist. I think that since Android uses it, it is somewhat of a de facto standard. All comments welcome, John

14 years, 10 months

[PATCH v3 00/12] mmc: use nonblock mmc requests to minimize latency

by Per Forlin

How significant is the cache maintenance over head? It depends, the eMMC are much faster now compared to a few years ago and cache maintenance cost more due to multiple cache levels and speculative cache pre-fetch. In relation the cost for handling the caches have increased and is now a bottle neck dealing with fast eMMC together with DMA. The intention for introducing none blocking mmc requests is to minimize the time between a mmc request ends and another mmc request starts. In the current implementation the MMC controller is idle when dma_map_sg and dma_unmap_sg is processing. Introducing none blocking mmc request makes it possible to prepare the caches for next job parallel with an active mmc request. This is done by making the issue_rw_rq() none blocking. The increase in throughput is proportional to the time it takes to prepare (major part of preparations is dma_map_sg and dma_unmap_sg) a request and how fast the memory is. The faster the MMC/SD is the more significant the prepare request time becomes. Measurements on U5500 and Panda on eMMC and SD shows significant performance gain for for large reads when running DMA mode. In the PIO case the performance is unchanged. There are two optional hooks pre_req() and post_req() that the host driver may implement in order to move work to before and after the actual mmc_request function is called. In the DMA case pre_req() may do dma_map_sg() and prepare the dma descriptor and post_req runs the dma_unmap_sg. Details on measurements from IOZone and mmc_test: https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req Under consideration: * Make pre_req and post_req private to core.c. * Generalize implementation and make it available for SDIO. Changes since v2: * Fix compile warnings in core.c and block.c * Simplify max transfer size in mmc_test * set TASK_RUNNING in queue.c before issue_req() Per Forlin (12): mmc: add none blocking mmc request function mmc: mmc_test: add debugfs file to list all tests mmc: mmc_test: add test for none blocking transfers mmc: add member in mmc queue struct to hold request data mmc: add a block request prepare function mmc: move error code in mmc_block_issue_rw_rq to a separate function. mmc: add a second mmc queue request member mmc: add handling for two parallel block requests in issue_rw_rq mmc: test: add random fault injection in core.c omap_hsmmc: use original sg_len for dma_unmap_sg omap_hsmmc: add support for pre_req and post_req mmci: implement pre_req() and post_req() drivers/mmc/card/block.c | 493 +++++++++++++++++++++++++++-------------- drivers/mmc/card/mmc_test.c | 340 +++++++++++++++++++++++++++- drivers/mmc/card/queue.c | 180 ++++++++++------ drivers/mmc/card/queue.h | 31 ++- drivers/mmc/core/core.c | 132 ++++++++++- drivers/mmc/core/debugfs.c | 5 + drivers/mmc/host/mmci.c | 146 +++++++++++- drivers/mmc/host/mmci.h | 8 + drivers/mmc/host/omap_hsmmc.c | 90 +++++++- include/linux/mmc/core.h | 9 +- include/linux/mmc/host.h | 13 +- lib/Kconfig.debug | 11 + 12 files changed, 1174 insertions(+), 284 deletions(-) -- 1.7.4.1

14 years, 10 months

[PATCH v6 1/5] arm/dt: Make __vet_atags also accept a dtb image

by Grant Likely

The dtb is passed to the kernel via register r2, which is the same method that is used to pass an atags pointer. This patch modifies __vet_atags to not clear r2 when it encounters a dtb image. v2: fixed bugs pointed out by Nicolas Pitre Tested-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> --- arch/arm/kernel/head-common.S | 24 ++++++++++++++++++------ arch/arm/kernel/head.S | 8 ++++---- 2 files changed, 22 insertions(+), 10 deletions(-) diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S index c84b57d..854bd22 100644 --- a/arch/arm/kernel/head-common.S +++ b/arch/arm/kernel/head-common.S @@ -15,6 +15,12 @@ #define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2) #define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2) +#ifdef CONFIG_CPU_BIG_ENDIAN +#define OF_DT_MAGIC 0xd00dfeed +#else +#define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */ +#endif + /* * Exception handling. Something went wrong and we can't proceed. We * ought to tell the user, but since we don't have any guarantee that @@ -28,20 +34,26 @@ /* Determine validity of the r2 atags pointer. The heuristic requires * that the pointer be aligned, in the first 16k of physical RAM and - * that the ATAG_CORE marker is first and present. Future revisions + * that the ATAG_CORE marker is first and present. If CONFIG_OF_FLATTREE + * is selected, then it will also accept a dtb pointer. Future revisions * of this function may be more lenient with the physical address and * may also be able to move the ATAGS block if necessary. * * Returns: - * r2 either valid atags pointer, or zero + * r2 either valid atags pointer, valid dtb pointer, or zero * r5, r6 corrupted */ __vet_atags: tst r2, #0x3 @ aligned? bne 1f - ldr r5, [r2, #0] @ is first tag ATAG_CORE? - cmp r5, #ATAG_CORE_SIZE + ldr r5, [r2, #0] +#ifdef CONFIG_OF_FLATTREE + ldr r6, =OF_DT_MAGIC @ is it a DTB? + cmp r5, r6 + beq 2f +#endif + cmp r5, #ATAG_CORE_SIZE @ is first tag ATAG_CORE? cmpne r5, #ATAG_CORE_SIZE_EMPTY bne 1f ldr r5, [r2, #4] @@ -49,7 +61,7 @@ __vet_atags: cmp r5, r6 bne 1f - mov pc, lr @ atag pointer is ok +2: mov pc, lr @ atag/dtb pointer is ok 1: mov r2, #0 mov pc, lr @@ -61,7 +73,7 @@ ENDPROC(__vet_atags) * * r0 = cp#15 control register * r1 = machine ID - * r2 = atags pointer + * r2 = atags/dtb pointer * r9 = processor ID */ __INIT diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index c9173cf..a5e5c5b 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -59,7 +59,7 @@ * * This is normally called from the decompressor code. The requirements * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0, - * r1 = machine nr, r2 = atags pointer. + * r1 = machine nr, r2 = atags or dtb pointer. * * This code is mostly position independent, so if you link the kernel at * 0xc0008000, you call this at __pa(0xc0008000). @@ -91,7 +91,7 @@ ENTRY(stext) #endif /* - * r1 = machine no, r2 = atags, + * r1 = machine no, r2 = atags or dtb, * r8 = phys_offset, r9 = cpuid, r10 = procinfo */ bl __vet_atags @@ -339,7 +339,7 @@ __secondary_data: * * r0 = cp#15 control register * r1 = machine ID - * r2 = atags pointer + * r2 = atags or dtb pointer * r4 = page table pointer * r9 = processor ID * r13 = *virtual* address to jump to upon completion @@ -376,7 +376,7 @@ ENDPROC(__enable_mmu) * * r0 = cp#15 control register * r1 = machine ID - * r2 = atags pointer + * r2 = atags or dtb pointer * r9 = processor ID * r13 = *virtual* address to jump to upon completion *

14 years, 10 months

[PATCH] of: clock: Avoid a NULL pointer dereference

by Rajendra Nayak

Quite often in the kernel, there are instances of clk_get calls being made with a NULL struct device pointer being passed. Not checking for such cases could lead to a NULL pointer dereference. Signed-off-by: Rajendra Nayak <rnayak(a)ti.com> --- based on git://git.secretlab.ca/git/linux-2.6 devicetree/test drivers/of/clock.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/of/clock.c b/drivers/of/clock.c index a49f79f..cbca319 100644 --- a/drivers/of/clock.c +++ b/drivers/of/clock.c @@ -91,7 +91,7 @@ static struct clk *__of_clk_get_from_provider(struct device_node *np, const char struct clk *of_clk_get(struct device *dev, const char *id) { - struct device_node *provnode; + struct device_node *provnode, *of_node; u32 provhandle; int sz; struct clk *clk; @@ -103,7 +103,8 @@ struct clk *of_clk_get(struct device *dev, const char *id) dev_dbg(dev, "Looking up %s-clock from device tree\n", id); snprintf(prop_name, 32, "%s-clock", id ? id : "bus"); - prop = of_get_property(dev->of_node, prop_name, &sz); + of_node = dev ? dev->of_node : NULL; + prop = of_get_property(of_node, prop_name, &sz); if (!prop || sz < 4) return NULL; -- 1.7.0.4

14 years, 10 months

[PATCH v4] sdio: optimized SDIO IRQ handling for single irq

by Per Forlin

Optimize performance for single irq Changes since v2. * Rebase on mmc-next, change of line numbers no code changes. Stefan Nilsson XK (1): sdio: optimized SDIO IRQ handling for single irq drivers/mmc/core/sdio_irq.c | 33 ++++++++++++++++++++++++++++++++- include/linux/mmc/card.h | 1 + 2 files changed, 33 insertions(+), 1 deletions(-) -- 1.7.4.1

14 years, 10 months

[PATCH v3] sdio: optimized SDIO IRQ handling for single irq

by Per Forlin

Optimize performance for single irq Changes since v2. * Clarify comment in process_sdio_pending_irqs * Simplify sdio_single_irq if-condition Stefan Nilsson XK (1): sdio: optimized SDIO IRQ handling for single irq drivers/mmc/core/sdio_irq.c | 33 ++++++++++++++++++++++++++++++++- include/linux/mmc/card.h | 1 + 2 files changed, 33 insertions(+), 1 deletions(-) -- 1.7.4.1

14 years, 10 months

Linaro@UDS: MM summit starts at *2pm* today

by Loïc Minier

Hey This is a quick heads up that MM summit starts at *2pm* today (in 15mn) and not at 3pm. The schedule is incorrect because we can't overlap the plenaries, but discussion will start at 2pm. See you there! -- Loïc Minier

14 years, 10 months

Linaro Technical Showcase

by Stephen Doel

Hi All, As a reminder, please make sure you head to the Linaro Technical Showcase in the Grand Ballroom on Tuesday from 7pm. Here are 3 great reasons to be there: 1. Opportunity to see and chat about at least 19 Linaro based demos (https://wiki.linaro.org/Events/2011-05-LDS/Showcase#Demo_list) . BTW - if you'd still like to do a demo, its not too late. Just let me, Arwen or Michael Opdenacker know before 4pm Tuesday 2. Vote for your favourite demo - the first 50 voters get a $50 discount voucher to purchase a Freescale Quick Start board 3. See our illustrious VP Engineering in a tuxedo! Have a great evening. Thx Stephen Doel Chief Operating Officer Linaro Ltd +44 77 66 014 247

14 years, 10 months

Issues with Android toolchain build

by Paul Sokolovsky

(sorry, first time sent from wrong email, don't know if that'll get thru) Hello Android team, I was working on making Android toolchain buildable using Android build service, and finally I was able to do successful and reproducible builds - of AOSP pristine bare-matal toolchain so far (https://android-build.linaro.org/builds/~pfalcon/aosp-toolchain/). There were few issues which needed to be investigated and resolved, and which I would like to discuss here: 1. make -jN breakage Android build service builds on EC2 XLARGE instances with 16 concurrent make jobs (-j16). This invariably leads to build failure sooner or later (exact location depends on other options and maybe non-deterministic at all). The failure is "error: Link tests are not allowed after GCC_NO_EXECUTABLES." which somehow sends issue-hunting the wrong trail (like sysroot issues, etc.) but after some experiments I reduced this to exactly -j >1 being used, with -j1 it went past usual failure points reliably. 2. Lack of DESTDIR support There's standard GNU autotools variable "DESTDIR" to install package into other directory besides $prefix. It is supported for gcc, binutils, etc., but not for Android's own toolchain/build project. The usual local-use trick is just to pass another prefix just for make install target, and that's what toolchain/build's README suggests. My only concern is "cleanroomness" of the results - suppose make install suddenly wants to rebuild something (libtool used to have such habit), then new prefix may be embedded into some executable, and then hit beyond the usual usage pattern (like, with non-English locale). Still, this is more a theoretical risk, which I as a build engineer should note, but not something to much worry about. 3. libstdc++v3 build toolchain/build's README says that the default is not to build libstdc++v3 and it must be enabled explicitly. But in the current master I found that not to be the case - it gets enabled by default. And its build requires sysroot, so I had to disable it explicitly for bare-metal build. 4. sysroot source So, to build full-fledged toolchain, we need to supply sysroot. What should be source of it? Android build service script I started from extracts it from an official Android SDK release. Is that good enough source? I guess we'd miss some non-released optimizations that way (byteswap ARMv6 optimizations come to mind). Otherwise, what should be used instead? Obvious choice is to build Android target images, then build toolchain on that tree. But that would be too long and expensive. Should we prepare and tar sysroot and provide it as extra build artifact for Android target builds? Also, can there be any machine-specificity, or it's for sure one generic sysroot for specific Android version (with arch-specific things handled via #ifdef's)? Of these 4, first 3 are upstream-related bugreports with known workarounds. I wanted to write them down, but I'm not sure if more can be done about them - if you think it would be useful to submit them as bugs at lp/linaro-android (or directly to upstream?), I can do it. Sysroot issue of course requires input/discussion - in mail or at some LDS session. Thanks, Paul mailto:pmiscml@gmail.com -- Best Regards, Paul

14 years, 10 months

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev May 2011