linaro-dev January 2011

linaro-dev@lists.linaro.org

81 participants
84 discussions

Reminder: Weekly Linaro Release Meeting tomorrow

by Jamie Bennett

Hi, The weekly Linaro Release Meeting will be held at 17:00 UTC tomorrow (Thursday). Please note the change of day which is due to a resolution in meeting conflicts meaning the release meeting can return to its normal slot. The agenda for the meeting can be found at: https://wiki.linaro.org/Releases/WeeklyReleaseMeeting/2011-01-20 Regards, Jamie. -- Linaro Release Manager

13 years, 11 months

camera on Freescale i.MX51

by Claudiu Covaci

Hi, I'm have trouble receiving a video stream on the Freescale i.MX51 processor. I've tried everything I could think, so I'm trying my luck here. I'm using a 2.6.31 kernel with some modifications: the camera capture driver [1] and the IPU (Image Processing Unit) driver [2] from the Freescale BSP 2010.11. As for the camera driver, it's written by me. I'm at a point where I can open the /dev/video0 device and can (at least try to) read frames, but it fails at dequeueing the video buffers (VIDIOC_DQBUF) with the message: <3>ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 Unable to dequeue buffer (62). - I've double-checked the IPU registers and they seem properly configured, but I don't get any interrupt (at end-of-frame). - The relevant IOMUX pins are also configured. - the video signal appears at the i.MX pins (so it gets there) - I've also tried activating the internal picture generator, but still nothing happens. Is there anything I overlooked? Is there a way to find out where the problem is? Any hints will be greatly appreciated. Thanks! Claudiu [1] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;f=driver… [2] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=tree;f=driver…

13 years, 11 months

gdb-multiarch

by Loïc Minier

Hey Based on an idea by Ulrich Weigand, I've uploaded a new gdb to natty today which adds a gdb-multiarch binary package. It's about 19 MB and once you install it, you will get a new /usr/bin/gdb-multiarch which can debug any target that gdb knows about, including ARM! So you could debug an ARM "/bin/ls" from a local chroot with qemu-arm-static by running gdb-multiarch and then running: (gdb) file /arm-chroot/bin/ls "/arm-chroot/bin/ls": not in executable format: File format is ambiguous. Matching formats: elf32-littlearm elf32-littlearm-symbian elf32-littlearm-vxworks. Use "set gnutarget format-name" to specify the format. (gdb) set gnutarget elf32-littlearm (gdb) file /arm-chroot/bin/ls In the chroot, run: qemu-arm-static -g 1234 /bin/ls and in gdb-multiarch: target remote localhost:1234 and you can now use gdb as usual, setting breakpoints, single-stepping etc. (It obviously also works with remote debugging of a real, network-connected ARM board; use gdbserver instead of qemu) Would people be interested in backports? Cheers, PS: the package is in NEW and will show up soon in natty; in the mean time, you can get it from my natty PPA: https://launchpad.net/~lool/+archive/ppa/+sourcepub/1446500/+listing-archiv… -- Loïc Minier

13 years, 11 months

Infrastructure Team Weekly Report

by Ian Smith

Infrastructure Team * Period: (20110113-20110119) * PM: Ian Smith <ian.smith(a)linaro.org <mailto:ian.smith@linaro.org>> * Past reports : https://wiki.linaro.org/Platform/Infrastructure * Burndown information : http://status.linaro.org <http://status.linaro.org/> Key Points for wider discussion * ImproveLinaroMediaCreate completed. * Team Highlights * ImproveLinaroMediaCreate completed. * Following bugs resolved on ImproveLinaroMediaCreate: #702645 (l-m-c and hwpacks need to be updated for latest x-loader deb), #697824 (linaro omap3 image: serial device name change breaks serial console), #701462 (mkfs.vfat should be added to the dependency list), #702650 (l-m-c fails when device partitions don't follow the /dev/sdNN naming pattern) * Fixed several problems which occurred after the django-restricted-resource changes. Changes have been submitted and are awaiting review comments. Upcoming Deliverables * No immediate milestones due. Stakeholder Process * ImproveLinaroMediaCreate is complete. Blueprint Milestones * No immediate milestones due Risks / Issues * None to be highlighted. Miscellaneous * Guilherme Salgado on leave/ public holiday 20th & 21st January * Michael Hudson has a public holiday on 24th January * Deepti Kalakeri has a public holiday on 26th January

13 years, 11 months

ARM: iMX51 BBG: add clock debug information

by yong.shen＠linaro.org

To utilize powerdebug tool developed by power management group of Linaro, we need this patch in kernel to expose clock information. Yong

13 years, 11 months

[ACTIVITY] week 2 2010 (2011-01-10 - 2011-01-14)

by Dave Martin

== [ACTIVITY] [dave-martin-arm] Activity report for week 2 2010 (2011-01-10 - 2011-01-14) == (Linaro 11.05 mid-cycle rally week, Dallas) === Activity === ==== hardware-n-kernel-standard-architecture ==== * Clarified work item assignments with Paul McKenney. * Rebased omap patches for Thumb-2 against mailine v2.6.37. * Posted generic function-body copying patch to help with Thumb-2 compatibility of low-level BSP code in omap. * Some discussion of the missing debug single-step emulation in the kernel for Thumb-2. Concluded that this feature should not be implemented: it's not robust even for ARM. * All platform-indepedent Thumb-2 fixes were merged in v2.6.37. ==== hardware-n-bsp-investigations ==== * No activity. ==== performance-linaro-n-memory-footprint ==== * Discussed with Steve Langasek how to take this forward. ==== other-linaro-n-gdbserver-integration ==== * No activity (Steve Langasek expects that this will likely be assigned to someone else.) ==== miscellaneous ==== * Acquired Panda board :) (thanks kiko). * Some logistics to help get the new assignees up and running. === Plans === * Build and test a Thumb-2 kernel on Panda. * Discuss prioritisation for outstanding kernel tasks. * Write up the output from the Freescale i.MX BSP review discussion, and post for comment. * Write up methodology for performance-linaro-n-memory- footprint. === Absences === None planned.

13 years, 11 months

Office of the CTO / meeting minutes

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

13 years, 11 months

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

13 years, 11 months

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(-) > >

13 years, 11 months

[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(-)

13 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev January 2011