linaro-dev August 2011

linaro-dev@lists.linaro.org

126 participants
239 discussions

by Patrik Ryd

Hi, Linaro Android has now moved up to 2.3.5. The daily builds (https://android-build.linaro.org/index) are now based on the linaro_android_2.3.5 branch of the manifest. Please rebase any dev_branches you have to 2.3.5. The linaro_android_2.3.4 branch will no longer be supported. Regards Patrik

13 years, 4 months

Android Testing Session at LinuxCon - Live Video Stream Available

by Zach Pfeffer

Here's the general info I got from the Linux Foundation: Can't make it to Vancouver this week for LinuxCon, the leading technical conference for All Matters Linux? You can still take advantage of the amazing content this event has to offer. Live video streaming will be available for all of our keynote sessions, Wednesday, August 17th - Friday, August 19th, at no cost! View List of Keynotes: http://events.linuxfoundation.org/events/linuxcon/schedule Click Here To Register: http://events.linuxfoundation.org/events/linuxcon/live-video-streaming Live video streaming will be broadcast beginning at 9:00am Pacific Daylight Time. The Linux Foundation Please click here to no longer receive emails promoting Linux Foundation events: https://office.linuxfoundation.org/crm/index.php?entryPoint=removeme&identi…

13 years, 4 months

[RFC PATCH 00/17] ARM: common idle infrastructure

by Lorenzo Pieralisi

This patchset is a first attempt at providing a consolidation of idle code for the ARM processor architecture and a request for comment on the provided methodology. It relies and it is based on kernel features such as suspend/resume, pm notifiers and common code for cpu_reset(). It integrates latest patches from ALKML for cpu pm notifiers and a cpu_reset function hook. Patches are included in the patchset for completeness. The patchset depends on the following patches, whose links are provided for completeness: https://patchwork.kernel.org/patch/882892/ https://patchwork.kernel.org/patch/873692/ https://patchwork.kernel.org/patch/873682/ https://patchwork.kernel.org/patch/873672/ The idle framework defines a common entry point in [sr_entry.S] cpu_enter_idle(cstate, rstate, flags) where: C-state [CPU state]: 0 - RUN MODE 1 - STANDBY 2 - DORMANT (not supported by this patch) 3 - SHUTDOWN R-state [CLUSTER state] 0 - RUN 1 - STANDBY (not supported by this patch) 2 - L2 RAM retention 3 - SHUTDOWN flags: SR_SAVE_L2: L2 registers saved and restored on shutdown SR_SAVE_SCU: SCU reset on cluster wake-up The assembly entry point checks the targeted state and executes wfi, entering a shallow c-state or call into the sr framework to put the cpu and cluster in low-power state. If the target is a deep low-power state it saves the current stack pointer and registers on the stack for the resume path. On deep-power state entry, since the CPU is hitting the off state, the code switches page tables (cloned from init_mm at boot) to cater for 1:1 mapping of kernel code, data, and uncached reserved memory pages obtained from platform code through a hook: platform_context_pointer(size) Every platform using the framework should implement this hook to return reserved memory pages that are going to be mapped as uncached and 1:1 mapped to cater for the MMU off resume path. This decision has been made in order to avoid fiddling with L2 when CPU enters low-power (context should be flushed to L3 so that a CPU can fetch it from memory when the MMU is off). On the resume path the CPU loads a non-cacheable stack pointer to cater for the MMU enabling path, and after switching page tables returns to the OS. The non-cacheable stack simplifies the L2 management in that, since for single CPU shutdown the L2 is still enabled, on MMU resume some stack used before the MMU is turned on might still be present and valid in L2 leading to corruption. After MMU is enabled a few bytes of the stack frame are copied back to the Linux stack and execution resumes. Generic subsystem save/restore is triggered by cpu pm notifiers, to save/restore GIC, VFP, PMU state automatically. The patchset introduces a new notifier chain which notifies listeners of a required platform shutdown/wakeup. Platform code should register to the chain and execute all actions required to put the system in low-power mode when called. It is called within a virtual address space cloned from init_mm at arch_initcall. On cluster shutdown L2 cache memory should be either cleaned (complete shutdown) or just save L2 logic (L2 RAM retained). This is a major issue since on power-down the stack points to cacheable memory that must be cleaned from L2 before disabling the L2 controller. Current code performing that action is a hack and provides ground for discussions. The stack might be switched to non-cacheable on power down but by doing this code relying on thread_info is broken unless that struct is copied across the stack switch. Atomicity of the code is provided by strongly ordered locking algorithm (Lamport's Bakery) since when CPUs are out of coherency and the D$ look-up are disabled normal spinlocks based on ldrex/strex are not functional. Atomicity of L2 clean/invalidate L2 and reset of SCU are fundamental to guarantee system stability. Lamport's bakery code is provided for completeness and it can be ignored; please refer to the patch commit note. Entry on low-power mode is performed by a function pointer (*sr_sleep), to allow platforms to override the default behaviour (and possibly execute from different memory spaces). Tested on dual-core A9 Cluster through all system low-power states supported by the patchset. A8, A5 support compile tested. Colin Cross (3): ARM: Add cpu power management notifiers ARM: gic: Use cpu pm notifiers to save gic state ARM: vfp: Use cpu pm notifiers to save vfp state Lorenzo Pieralisi (13): ARM: kernel: save/restore kernel IF ARM: kernel: save/restore generic infrastructure ARM: kernel: save/restore v7 assembly helpers ARM: kernel: save/restore arch runtime support ARM: kernel: v7 resets support ARM: kernel: save/restore v7 infrastructure support ARM: kernel: add support for Lamport's bakery locks ARM: kernel: add SCU reset hook ARM: mm: L2x0 save/restore support ARM: kernel: save/restore 1:1 page tables ARM: perf: use cpu pm notifiers to save pmu state ARM: PM: enhance idle pm notifiers ARM: kernel: save/restore build infrastructure Will Deacon (1): ARM: proc: add definition of cpu_reset for ARMv6 and ARMv7 cores arch/arm/Kconfig | 18 ++ arch/arm/common/gic.c | 212 +++++++++++++++++++++++ arch/arm/include/asm/cpu_pm.h | 69 ++++++++ arch/arm/include/asm/lb_lock.h | 34 ++++ arch/arm/include/asm/outercache.h | 22 +++ arch/arm/include/asm/smp_scu.h | 3 +- arch/arm/include/asm/sr_platform_api.h | 28 +++ arch/arm/kernel/Makefile | 5 + arch/arm/kernel/cpu_pm.c | 265 ++++++++++++++++++++++++++++ arch/arm/kernel/lb_lock.c | 85 +++++++++ arch/arm/kernel/perf_event.c | 22 +++ arch/arm/kernel/reset_v7.S | 109 ++++++++++++ arch/arm/kernel/smp_scu.c | 33 ++++- arch/arm/kernel/sr.h | 162 +++++++++++++++++ arch/arm/kernel/sr_api.c | 197 +++++++++++++++++++++ arch/arm/kernel/sr_arch.c | 74 ++++++++ arch/arm/kernel/sr_context.c | 23 +++ arch/arm/kernel/sr_entry.S | 213 +++++++++++++++++++++++ arch/arm/kernel/sr_helpers.h | 56 ++++++ arch/arm/kernel/sr_mapping.c | 78 +++++++++ arch/arm/kernel/sr_platform.c | 48 +++++ arch/arm/kernel/sr_power.c | 26 +++ arch/arm/kernel/sr_v7.c | 298 ++++++++++++++++++++++++++++++++ arch/arm/kernel/sr_v7_helpers.S | 47 +++++ arch/arm/mm/cache-l2x0.c | 63 +++++++ arch/arm/mm/proc-v6.S | 5 + arch/arm/mm/proc-v7.S | 7 + arch/arm/vfp/vfpmodule.c | 40 +++++ 28 files changed, 2238 insertions(+), 4 deletions(-) create mode 100644 arch/arm/include/asm/cpu_pm.h create mode 100644 arch/arm/include/asm/lb_lock.h create mode 100644 arch/arm/include/asm/sr_platform_api.h create mode 100644 arch/arm/kernel/cpu_pm.c create mode 100644 arch/arm/kernel/lb_lock.c create mode 100644 arch/arm/kernel/reset_v7.S create mode 100644 arch/arm/kernel/sr.h create mode 100644 arch/arm/kernel/sr_api.c create mode 100644 arch/arm/kernel/sr_arch.c create mode 100644 arch/arm/kernel/sr_context.c create mode 100644 arch/arm/kernel/sr_entry.S create mode 100644 arch/arm/kernel/sr_helpers.h create mode 100644 arch/arm/kernel/sr_mapping.c create mode 100644 arch/arm/kernel/sr_platform.c create mode 100644 arch/arm/kernel/sr_power.c create mode 100644 arch/arm/kernel/sr_v7.c create mode 100644 arch/arm/kernel/sr_v7_helpers.S -- 1.7.4.4

13 years, 4 months

engineering resources feedback

by Andy Doan

The Engineering Resources team is trying to solicit feedback from the community. Our goal is to make it as easy as possible for you to get your job done. With that in mind, we'd like to check in with you and get your thoughts on what hasn't worked well for you. This is intended to be an open-ended question. However, here are some specifics to help get you going: 1) What were the biggest obstacles you faced when you started? 2) What are the biggest obstacles you face now? 3) How do go about getting help? What format do you prefer it in (websites, videos, etc). Feel free to respond either privately or to the list. Thanks, -andy

13 years, 4 months

Proposed change to https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation

by Dave Martin

Can anyone see a reason not to make this change? On a couple of occasions I've had people come to me with problems after failing to do apt-get update and then installing (old) linaro tools packages, when following the installation instructions on the linaro wiki. It's harmless (and probably necessary) just to run it every time. Cheers ---Dave {{{ $ sudo add-apt-repository ppa:linaro-maintainers/tools -$ sudo apt-get install linaro-image-tools -}}} -At present, this PPA only provides compatible packages for Ubuntu 10.10. For earlier Ubuntu releases, you will need to use a tarball release or the development tree; see below. - -For Ubuntu 10.04.2 LTS, executing the following commands also install linaro-image-tools successfully, and qemu-user-static will be installed automatically. - -{{{ -$ sudo add-apt-repository ppa:linaro-maintainers/tools $ sudo apt-get update $ sudo apt-get install linaro-image-tools }}}

13 years, 4 months

Fwd: [PATCH] net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back

by Eric Miao

Guys, The patch below fixed the recent ethernet not working issue due to absence of MAC address. It's Acked-by the original guilty commit author, please consider merging into next release of u-boot. The real problem, however, is that kernel ethernet driver has an incorrect assumption on a correct configuration of registers of the MAC address by the boot loader, which isn't always true. So the next fix would be the kernel driver to be independent of the boot loader. Still figuring the correct way for this though. ---------- Forwarded message ---------- From: Eric Miao <eric.miao(a)linaro.org> Date: Wed, Aug 17, 2011 at 1:33 PM Subject: [PATCH] net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back To: u-boot(a)lists.denx.de Cc: Simon Glass <sjg(a)chromium.org>, Eric Miao <eric.miao(a)linaro.org> Ignore the return value of eth_getenv_enetaddr_by_index(), and if it fails, fall back to use dev->enetaddr, which could be filled up by the ethernet device driver. Actually, this is the original behavior, and was later changed by commit 48506a2cde2458fa1f8c5993afc98e5a4617e1d3. Signed-off-by: Eric Miao <eric.miao(a)linaro.org> --- net/eth.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/net/eth.c b/net/eth.c index a34fe59..c4fbe11 100644 --- a/net/eth.c +++ b/net/eth.c @@ -195,8 +195,7 @@ int eth_write_hwaddr(struct eth_device *dev, const char *base_name, unsigned char env_enetaddr[6]; int ret = 0; - if (!eth_getenv_enetaddr_by_index(base_name, eth_number, env_enetaddr)) - return -1; + eth_getenv_enetaddr_by_index(base_name, eth_number, env_enetaddr); if (memcmp(env_enetaddr, "\0\0\0\0\0\0", 6)) { if (memcmp(dev->enetaddr, "\0\0\0\0\0\0", 6) && -- 1.7.4.1

13 years, 4 months

ARM Porting Jam today (14:00 - 18:00 UTC)

by Riku Voipio

Dear ARM fans, Linaro Developer Platform team organises every week (Wednesday 14:00 - 18:00 UTC) an ARM porting Jam. The idea is to gather all developers together to fix userspace portability issues across the board. The list of bugs being worked on is at launchpad: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby… Interested in making the software in Ubuntu run better on ARM? Join us on the #linaro channel on irc.linaro.org (aka freenode) today! Cheers, Riku

13 years, 4 months

Android toolchain 11.08 RC

by Bernhard Rosenkranzer

Hi, here's the first attempt at an RC for the Android 11.08 toolchain: https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.… Please give it a try with your builds and let me know if anything goes wrong. To be on the safe side, this build still uses gcc 11.07, it just updates the remaining tools and build process, enables OpenMP support and TLS, etc. The next step is updating gcc to the toolchain WG's current bzr tip - the primary purpose of this build is to have something to fall back to if we run into problems that can't be solved in time. ttyl bero

13 years, 4 months

[PATCH v3] usb: gadget: storage_common: make FSG_NUM_BUFFERS variable size

by Per Forlin

FSG_NUM_BUFFERS is set to 2 as default. Usually 2 buffers are enough to establish a good buffering pipeline. The number may be increased in order to compensate a for bursty VFS behaviour. Here follows a description of system that may require more than 2 buffers. * CPU ondemand governor active * latency cost for wake up and/or frequency change * DMA for IO Use case description. * Data transfer from MMC via VFS to USB. * DMA shuffles data from MMC and to USB. * The CPU wakes up every now and then to pass data in and out from VFS, which cause the bursty VFS behaviour. Test set up * Running dd on the host reading from the mass storage device * cmdline: dd if=/dev/sdb of=/dev/null bs=4k count=$((256*100)) * Caches are dropped on the host and on the device before each run Measurements on a Snowball board with ondemand_govenor active. FSG_NUM_BUFFERS 2 104857600 bytes (105 MB) copied, 5.62173 s, 18.7 MB/s 104857600 bytes (105 MB) copied, 5.61811 s, 18.7 MB/s 104857600 bytes (105 MB) copied, 5.57817 s, 18.8 MB/s FSG_NUM_BUFFERS 4 104857600 bytes (105 MB) copied, 5.26839 s, 19.9 MB/s 104857600 bytes (105 MB) copied, 5.2691 s, 19.9 MB/s 104857600 bytes (105 MB) copied, 5.2711 s, 19.9 MB/s There may not be one optimal number for all boards. This is why the number is added to Kconfig. Signed-off-by: Per Forlin <per.forlin(a)linaro.org> Acked-by: Michal Nazarewicz <mina86(a)mina86.com> --- Change log. v2: Update after proofreading comments from Michal Nazarewicz v3: Clarify the description of this patch based on input from Alan Stern drivers/usb/gadget/Kconfig | 14 ++++++++++++++ drivers/usb/gadget/storage_common.c | 7 +++++-- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 029e288..24d3ef5 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -96,6 +96,20 @@ config USB_GADGET_VBUS_DRAW This value will be used except for system-specific gadget drivers that have more specific information. +config USB_GADGET_STORAGE_NUM_BUFFERS + int "Number of storage pipeline buffers" + range 2 4 + default 2 + help + Usually 2 buffers are enough to establish a good buffering + pipeline. The number may be increased in order to compensate + for a bursty VFS behaviour. For instance there may be cpu wake up + latencies that makes the VFS to appear bursty in a system with + an cpu on-demand governor. Especially if DMA is doing IO to + offload the CPU. In this case the CPU will go into power + save often and spin up occasionally to move data within VFS. + If unsure, say 2. + config USB_GADGET_SELECTED boolean diff --git a/drivers/usb/gadget/storage_common.c b/drivers/usb/gadget/storage_common.c index 1fa4f70..683c972 100644 --- a/drivers/usb/gadget/storage_common.c +++ b/drivers/usb/gadget/storage_common.c @@ -262,8 +262,11 @@ static struct fsg_lun *fsg_lun_from_dev(struct device *dev) #define EP0_BUFSIZE 256 #define DELAYED_STATUS (EP0_BUFSIZE + 999) /* An impossibly large value */ -/* Number of buffers we will use. 2 is enough for double-buffering */ -#define FSG_NUM_BUFFERS 2 +/* + * Number of buffers we will use. + * 2 is usually enough for good buffering pipeline + */ +#define FSG_NUM_BUFFERS CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS /* Default size of buffer length. */ #define FSG_BUFLEN ((u32)16384) -- 1.7.4.1

13 years, 4 months

Toolchain builders utilisation

by Michael Hope

Your distraction for the day... Toolchain has four PandaBoards that are used for building GCC, GDB, and other interesting programs. Here's a graph of how busy they are: http://ex.seabright.co.nz/misc/utilisation/ursas.png The green line is how many boards are currently running jobs. The blue line is how many jobs are queued up. The spike at day 3 is the end-of-week build of the upstream branches. The drop to three boards at day 7 is me reserving one for benchmarking. The spike at day 8 is the start of our release week where many commits and the final tarballs are built and tested. All boards were busy for seven days out of eight. I think I might need a few more... -- Michael

13 years, 4 months

← Newer
1
...
14
15
16
17
18
19
20
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2011