linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by David Rusling

All, please see https://wiki.linaro.org/OfficeofCTO/2011-01-18 for the minutes of today's meeting and https://wiki.linaro.org/OfficeofCTO for the pages where we keep notes etc. Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH

15 years

armel natty test rebuild

by Matthias Klose

A test rebuild of natty/main for armel is currently running. The regular distribution buildd's are used for the rebuild with the test rebuilds at lowest priority, so it will take a while to finish. The test rebuild archive can be found at https://launchpad.net/ubuntu/+archive/test-rebuild-20110114-arm Build problems at https://launchpad.net/ubuntu/+archive/test-rebuild-20110114-arm/+builds?bui… https://launchpad.net/ubuntu/+archive/test-rebuild-20110114-arm/+builds?bui… An overview of the build status (updated hourly): http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-201101… To compare with other architectures, results for a ix86 test rebuild can be found at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-201101… Matthias

15 years

Re: [PATCH 0/5] mmc: add double buffering for mmc block requests

by Per Forlin

I mistyped the linaro email in this patch series. Sorry for the mess /Per On 12 January 2011 19:13, Per Forlin <per.forlin(a)linaro.org> wrote: > Add support to prepare one MMC request while another is active on > the host. This is done by making the issue_rw_rq() asynchronous. > The increase in throughput is proportional to the time it takes to > prepare 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 U8500 on eMMC shows significant performance gain for DMA on MMC for large > reads. In the PIO case there is some gain in performance for large reads too. > There seems to be no or small performance gain for write, don't have a good > explanation for this yet. > > There are two optional hooks pre_req() and post_req() that the host driver > may implement in order to improve double buffering. In the DMA case pre_req() > may do dma_map_sg() and prepare the dma descriptor and post_req runs the > dma_unmap_sg. > > The mmci host driver implementation for double buffering is not intended > nor ready for mainline yet. It is only an example of how to implement > pre_req() and post_req(). The reason for this is that the basic DMA support > for MMCI is not complete yet. The mmci patches are sent in a separate patch > series "[FYI 0/4] arm: mmci: example implementation of double buffering". > > Issues/Questions for issue_rw_rq() in block.c: > * Is it safe to claim the host for the first MMC request and wait to release > it until the MMC queue is empty again? Or must the host be claimed and > released for every request? > * Is it possible to predict the result from __blk_end_request(). > If there are no errors for a completed MMC request and the > blk_rq_bytes(req) == data.bytes_xfered, will it be guaranteed that > __blk_end_request will return 0? > > Here follows the IOZone results for u8500 v1.1 on eMMC. > The numbers for DMA are a bit to good here due to the fact that the > CPU speed is decreased compared to u8500 v2. This makes the cache handling > even more significant. > > Command line used: ./iozone -az -i0 -i1 -i2 -s 50m -I -f /iozone.tmp -e -R -+u > > Relative diff: VANILLA-MMC-PIO -> 2BUF-MMC-PIO > cpu load is abs diff > random random > KB reclen write rewrite read reread read write > 51200 4 +0% +0% +0% +0% +0% +0% > cpu: +0.1 -0.1 -0.5 -0.3 -0.1 -0.0 > > 51200 8 +0% +0% +6% +6% +8% +0% > cpu: +0.1 -0.1 -0.3 -0.4 -0.8 +0.0 > > 51200 16 +0% -2% +0% +0% -3% +0% > cpu: +0.0 -0.2 +0.0 +0.0 -0.2 +0.0 > > 51200 32 +0% +1% +0% +0% +0% +0% > cpu: +0.1 +0.0 -0.3 +0.0 +0.0 +0.0 > > 51200 64 +0% +0% +0% +0% +0% +0% > cpu: +0.1 +0.0 +0.0 +0.0 +0.0 +0.0 > > 51200 128 +0% +1% +1% +1% +1% +0% > cpu: +0.0 +0.2 +0.1 -0.3 +0.4 +0.0 > > 51200 256 +0% +0% +1% +1% +1% +0% > cpu: +0.0 -0.0 +0.1 +0.1 +0.1 +0.0 > > 51200 512 +0% +1% +2% +2% +2% +0% > cpu: +0.1 +0.0 +0.2 +0.2 +0.2 +0.1 > > 51200 1024 +0% +2% +2% +2% +3% +0% > cpu: +0.2 +0.1 +0.2 +0.5 -0.8 +0.0 > > 51200 2048 +0% +2% +3% +3% +3% +0% > cpu: +0.0 -0.2 +0.4 +0.8 -0.5 +0.2 > > 51200 4096 +0% +1% +3% +3% +3% +1% > cpu: +0.2 +0.1 +0.9 +0.9 +0.5 +0.1 > > 51200 8192 +1% +0% +3% +3% +3% +1% > cpu: +0.2 +0.2 +1.3 +1.3 +1.0 +0.0 > > 51200 16384 +0% +1% +3% +3% +3% +1% > cpu: +0.2 +0.1 +1.0 +1.3 +1.0 +0.5 > > Relative diff: VANILLA-MMC-DMA -> 2BUF-MMC-MMCI-DMA > cpu load is abs diff > random random > KB reclen write rewrite read reread read write > 51200 4 +0% -3% +6% +5% +5% +0% > cpu: +0.0 -0.2 -0.6 -0.1 +0.3 +0.0 > > 51200 8 +0% +0% +7% +7% +7% +0% > cpu: +0.0 +0.1 +0.8 +0.6 +0.9 +0.0 > > 51200 16 +0% +0% +7% +7% +8% +0% > cpu: +0.0 -0.0 +0.7 +0.7 +0.8 +0.0 > > 51200 32 +0% +0% +8% +8% +9% +0% > cpu: +0.0 +0.1 +0.7 +0.7 +0.3 +0.0 > > 51200 64 +0% +1% +9% +9% +9% +0% > cpu: +0.0 +0.0 +0.8 +0.7 +0.8 +0.0 > > 51200 128 +1% +0% +13% +13% +14% +0% > cpu: +0.2 +0.0 +1.0 +1.0 +1.1 +0.0 > > 51200 256 +1% +2% +8% +8% +11% +0% > cpu: +0.0 +0.3 +0.0 +0.7 +1.5 +0.0 > > 51200 512 +1% +2% +16% +16% +17% +0% > cpu: +0.2 +0.2 +2.2 +2.1 +2.2 +0.1 > > 51200 1024 +1% +2% +20% +20% +20% +1% > cpu: +0.2 +0.1 +2.6 +1.9 +2.6 +0.0 > > 51200 2048 +0% +2% +22% +22% +21% +0% > cpu: +0.0 +0.3 +2.3 +2.9 +2.1 -0.0 > > 51200 4096 +1% +2% +23% +23% +23% +1% > cpu: +0.2 +0.1 +2.0 +3.2 +3.1 +0.0 > > 51200 8192 +1% +5% +24% +24% +24% +1% > cpu: +1.4 -0.0 +4.2 +3.0 +2.8 +0.1 > > 51200 16384 +1% +3% +24% +24% +24% +2% > cpu: +0.0 +0.3 +3.4 +3.8 +3.7 +0.1 > > Here follows the IOZone results for u5500 on eMMC. > These numbers for DMA are more as expected. > > Command line used: ./iozone -az -i0 -i1 -i2 -s 50m -I -f /iozone.tmp -e -R -+u > > Relative diff: VANILLA-MMC-DMA -> 2BUF-MMC-MMCI-DMA > cpu load is abs diff > random random > KB reclen write rewrite read reread read write > 51200 128 +1% +1% +10% +9% +10% +0% > cpu: +0.1 +0.0 +1.3 +0.1 +0.8 +0.1 > > 51200 256 +2% +2% +7% +7% +9% +0% > cpu: +0.1 +0.4 +0.5 +0.6 +0.7 +0.0 > > 51200 512 +2% +2% +12% +12% +12% +1% > cpu: +0.4 +0.6 +1.8 +2.4 +2.4 +0.2 > > 51200 1024 +2% +3% +14% +14% +14% +0% > cpu: +0.3 +0.1 +2.1 +1.4 +1.4 +0.2 > > 51200 2048 +3% +3% +16% +16% +16% +1% > cpu: +0.2 +0.2 +2.5 +1.8 +2.4 -0.2 > > 51200 4096 +3% +3% +17% +17% +18% +3% > cpu: +0.1 -0.1 +2.7 +2.0 +2.7 -0.1 > > 51200 8192 +3% +3% +18% +18% +18% +3% > cpu: -0.1 +0.2 +3.0 +2.3 +2.2 +0.2 > > 51200 16384 +3% +3% +18% +18% +18% +4% > cpu: +0.2 +0.2 +2.8 +3.5 +2.4 -0.0 > > Per Forlin (5): > mmc: add member in mmc queue struct to hold request data > mmc: Add a block request prepare function > mmc: Add a second mmc queue request member > mmc: Store the mmc block request struct in mmc queue > mmc: Add double buffering for mmc block requests > > drivers/mmc/card/block.c | 337 ++++++++++++++++++++++++++++++---------------- > drivers/mmc/card/queue.c | 171 +++++++++++++++--------- > drivers/mmc/card/queue.h | 31 +++- > drivers/mmc/core/core.c | 77 +++++++++-- > include/linux/mmc/core.h | 7 +- > include/linux/mmc/host.h | 8 + > 6 files changed, 432 insertions(+), 199 deletions(-) > >

15 years

[FYI 0/4] arm: mmci: example implementation of double buffering

by Per Forlin

The mmci host driver implementation for double buffering is not intended nor ready for mainline yet. It is only an example of how to implement pre_req() and post_req(). The reason for this is that the basic DMA support for MMCI is not complete yet. This patch series depends on "[PATCH 0/5] mmc: add double buffering for mmc block requests" Linus Walleij (1): mmci: add PrimeCell generic DMA to MMCI/PL180 Per Forlin (1): ARM: mmci: add support for double buffering Ulf Hansson (2): mmci: fixup broken_blockend variant patch MMCI: Corrections for DMA drivers/mmc/host/mmci.c | 538 ++++++++++++++++++++++++++++++++++++++------- drivers/mmc/host/mmci.h | 21 ++- include/linux/amba/mmci.h | 16 ++ 3 files changed, 496 insertions(+), 79 deletions(-)

15 years

New problem with BeagleBoard

by Ira Rosen

Hi, After working fine for a while, the board crashed during the weekend, and I am getting the following error: Texas Instruments X-Loader 1.4.4ss (Sep 30 2010 - 14:44:32) Beagle xM Rev A Reading boot sector not there u-boot.bin not found or blank nand contents - attempting serial boot . . . ## Ready for binary (kermit) download to 0x80008000 at 115200 bps.. The SD card was formatted and reinstalled: ./linaro-media-create --mmc /dev/mmcblk0 --dev beagle --binary image/linaro-m-headless-tar-*.tar.gz --hwpack ../hwpack_linaro-omap3_20101105-75_armel_supported.tar.gz but it didn't help. The card seems to be OK: root@idol-laptop:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 144183992 38735348 98124484 29% / none 1574348 372 1573976 1% /dev none 1578568 5204 1573364 1% /dev/shm none 1578568 120 1578448 1% /var/run none 1578568 0 1578568 0% /var/lock none 1578568 0 1578568 0% /lib/init/rw /dev/mmcblk0p2 3731768 360100 3182104 11% /media/rootfs /dev/mmcblk0p1 71133 8481 62653 12% /media/boot ls -l /media/boot/ total 8480 -rwxr-xr-x 1 idol idol 397 2010-11-21 11:39 boot.ini -rwxr-xr-x 1 idol idol 397 2010-11-21 11:39 boot.scr -rwxr-xr-x 1 idol idol 18360 2010-11-21 11:39 MLO -rwxr-xr-x 1 idol idol 192204 2010-11-21 11:39 u-boot.bin -rwxr-xr-x 1 idol idol 3704228 2010-11-21 11:39 uImage -rwxr-xr-x 1 idol idol 4766721 2010-11-21 11:39 uInitrd ls -l /media/rootfs/ total 784 drwxr-xr-x 2 root root 4096 2010-11-21 06:46 bin drwxr-xr-x 2 root root 4096 2010-11-21 11:36 boot drwxr-xr-x 4 root root 4096 2010-11-21 06:42 dev drwxr-xr-x 60 root root 4096 2010-11-21 11:41 etc drwxr-xr-x 2 root root 4096 2010-10-07 11:15 home lrwxrwxrwx 1 root root 39 2010-11-21 11:39 initrd.img -> boot/initrd.img-2.6.35-1006-linaro-omap drwxr-xr-x 10 root root 4096 2010-11-21 06:45 lib drwx------ 2 root root 16384 2010-11-21 11:36 lost+found -rw-r--r-- 1 root root 708215 2010-11-21 06:48 md5sum.txt drwxr-xr-x 2 root root 4096 2010-11-21 06:41 media drwxr-xr-x 2 root root 4096 2010-10-07 11:15 mnt drwxr-xr-x 2 root root 4096 2010-11-21 06:41 opt drwxr-xr-x 2 root root 4096 2010-10-07 11:15 proc drwx------ 2 root root 4096 2010-11-21 11:59 root drwxr-xr-x 2 root root 4096 2010-11-21 11:34 sbin drwxr-xr-x 2 root root 4096 2010-05-09 21:20 selinux drwxr-xr-x 2 root root 4096 2010-11-21 06:41 srv drwxr-xr-x 2 root root 4096 2010-09-25 00:05 sys drwxrwxrwt 2 root root 4096 2010-11-21 11:36 tmp drwxr-xr-x 10 root root 4096 2010-11-21 06:41 usr drwxr-xr-x 13 root root 4096 2010-11-21 06:38 var lrwxrwxrwx 1 root root 36 2010-11-21 11:41 vmlinuz -> boot/vmlinuz-2.6.35-1006-linaro-omap fdisk -l Disk /dev/mmcblk0: 3959 MB, 3959422976 bytes 255 heads, 63 sectors/track, 481 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00042b57 Device Boot Start End Blocks Id System /dev/mmcblk0p1 * 1 9 72261 c W95 FAT32 (LBA) /dev/mmcblk0p2 10 481 3791340 83 Linux Any clue? Thanks, Ira

15 years

[PATCH V2] ARM: SAMSUNG: Add support for clock debugging through debug-fs interface

by Amit Daniel Kachhap

This patch adds support for clock information exposed to debug-fs interface. Signed-off-by: Amit Daniel Kachhap <amit.daniel(a)samsung.com> --- Code modified for V2 version are, a)Inserted the debug-fs code inside macro CONFIG_PM_DEBUG as suggested by yong.shen(a)linaro.org. b)Removed macro CONFIG_PLAT_SAMSUNG and implemented other coding standards as suggested by kgene.kim(a)samsung.com arch/arm/plat-samsung/clock.c | 91 ++++++++++++++++++++++++++++ arch/arm/plat-samsung/include/plat/clock.h | 3 + 2 files changed, 94 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c index e8d20b0..029a49d 100644 --- a/arch/arm/plat-samsung/clock.c +++ b/arch/arm/plat-samsung/clock.c @@ -39,6 +39,9 @@ #include <linux/clk.h> #include <linux/spinlock.h> #include <linux/io.h> +#if defined(CONFIG_DEBUG_FS) +#include <linux/debugfs.h> +#endif #include <mach/hardware.h> #include <asm/irq.h> @@ -447,3 +450,91 @@ int __init s3c24xx_register_baseclocks(unsigned long xtal) return 0; } +#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS) +/* debugfs support to trace clock tree hierarchy and attributes */ + +static struct dentry *clk_debugfs_root; + +static int clk_debugfs_register_one(struct clk *c) +{ + int err; + struct dentry *d, *child, *child_tmp; + struct clk *pa = c->parent; + char s[255]; + char *p = s; + + p += sprintf(p, "%s", c->name); + /*Append id field with name also*/ + if (c->id >= 0) + sprintf(p, ":%d", c->id); + + d = debugfs_create_dir(s, pa ? pa->dent : clk_debugfs_root); + if (!d) + return -ENOMEM; + + c->dent = d; + + d = debugfs_create_u8("usecount", S_IRUGO, c->dent, (u8 *)&c->usage); + if (!d) { + err = -ENOMEM; + goto err_out; + } + d = debugfs_create_u32("rate", S_IRUGO, c->dent, (u32 *)&c->rate); + if (!d) { + err = -ENOMEM; + goto err_out; + } + return 0; + +err_out: + d = c->dent; + list_for_each_entry_safe(child, child_tmp, &d->d_subdirs, d_u.d_child) + debugfs_remove(child); + debugfs_remove(c->dent); + return err; +} + +static int clk_debugfs_register(struct clk *c) +{ + int err; + struct clk *pa = c->parent; + + if (pa && !pa->dent) { + err = clk_debugfs_register(pa); + if (err) + return err; + } + + if (!c->dent) { + err = clk_debugfs_register_one(c); + if (err) + return err; + } + return 0; +} + +static int __init clk_debugfs_init(void) +{ + struct clk *c; + struct dentry *d; + int err; + + d = debugfs_create_dir("clock", NULL); + if (!d) + return -ENOMEM; + clk_debugfs_root = d; + + list_for_each_entry(c, &clocks, list) { + err = clk_debugfs_register(c); + if (err) + goto err_out; + } + return 0; +err_out: + debugfs_remove_recursive(clk_debugfs_root); + return err; +} +late_initcall(clk_debugfs_init); + +#endif /* defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS) */ + diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-samsung/include/plat/clock.h index 0fbcd0e..9a82b88 100644 --- a/arch/arm/plat-samsung/include/plat/clock.h +++ b/arch/arm/plat-samsung/include/plat/clock.h @@ -47,6 +47,9 @@ struct clk { struct clk_ops *ops; int (*enable)(struct clk *, int enable); +#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS) + struct dentry *dent; /* For visible tree hierarchy */ +#endif }; /* other clocks which may be registered by board support */ -- 1.6.2.5

15 years

The linaro-2.6.37 kernel branch now available

by Nicolas Pitre

As described in the Linaro kernel process available here: https://wiki.linaro.org/WorkingGroups/KernelConsolidation/KernelTree the 2.6.37 branch of the Linaro kernel is now open and available here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.37.git;a=summary git://git.linaro.org/kernel/linux-linaro-2.6.37.git This is a stable core 2.6.37 kernel with the latest 2.6.38-ish ARM related patches merged in. More patches will be merged as we move ahead to the actual 2.6.38 release. Again, if you have patches that have gone into mainline, or are on their way for mainline inclusion, you can have them merged in the Linaro tree for early exposure to a wider audience, and packaging in the Linaro distribution. Nicolas

15 years

Notes & Actions: Linaro User Platform Weekly Status Meeting 1/5

by Tom Gall

Greetings, Enclosed you'll find a link to the agenda, notes and actions from the Linaro User Platforms Weekly Status meeting dated January 5th held in #linaro-meeting on irc.freenode.net at 13:00 UTC. This will be the very last User Platform meeting as the new Multimedia and Graphical teams will take it's place. https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2011-01-05 Regards, Tom (tgall_foo) User Platforms Team "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

15 years

agenda for multimedia working group for next week's sprint

by Sachin Gupta

Hi All, I have started putting agenda for sprint next week at location https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia. Can you please add agenda items that you would like to address during next week's sprint. Thanks Sachin

15 years, 1 month

MM working group internal call

by Rajeev Kapoor

Hi , Notes and actions from our wednesday multimedia internal call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-01-05 Please act fast on the actions identified for Wk02 Linaro sprint in Dallas. Also, please try to carry some board/setyup for the Linaro sprint event next week wk02. Thanks, Rajeev

15 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