linaro-dev December 2011

linaro-dev@lists.linaro.org

139 participants
148 discussions

First RC of Android 11.12 toolchain: ICS compatible

by Bernhard Rosenkränzer

Hi, I've just built the first RC of the Android 11.12 toolchain. https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.… The big news is that it can successfully compile ICS, and the resulting ICS build actually works. Earlier workarounds like linking a couple of files w/ the linker from the 11.11 release are no longer required. Also, TOOLCHAIN_TRIPLET=arm-linux-androideabi is safe to use now, no need to use arm-eabi anymore. It's currently based on the 11.11 toolchain WG release because of https://bugs.launchpad.net/linaro-android/+bug/900426 This has already been fixed earlier today, so we'll update to the 11.12 gcc branch later today or tomorrow. I'll start moving our builds. Happy ICSing! bero

14 years

[PATCH] thermal: anatop thermal driver for imx6 platform

by Ying-Chun Liu (PaulLiu)

From: "Ying-Chun Liu (PaulLiu)" <paul.liu(a)linaro.org> Dear all, Please help me to review this thermal driver. It uses Intel's thermal (drivers/thermal/thermal_sys.c) interface. But looking into drivers/thermal I didn't find other drivers there. I'm also thinking to put this driver into drivers/hwmon. However, this driver doesn't create files in /sys/class/hwmon. There are some discussions in http://lists.linaro.org/pipermail/linaro-dev/2010-November/001626.html There's currently no maintainers for drivers/thermal in MAINTAINERS in kernel tree. So I send this mail to public mailing lists. Please give me some comments. Yours Sincerely, Paul Ying-Chun Liu (PaulLiu) (1): thermal: Add anatop thermal driver drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 1 + drivers/thermal/anatop_driver.h | 146 +++++++ drivers/thermal/anatop_thermal.c | 825 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 983 insertions(+), 0 deletions(-) create mode 100644 drivers/thermal/anatop_driver.h create mode 100644 drivers/thermal/anatop_thermal.c -- 1.7.7.3

14 years

Beagle will not go EOL in January! (Was: Re: [EOL] Request for End Of Life - Beagleboard and Beagleboard-xM)

by Alexander Sack

Hi all, this mail did not follow the proper EOL process that is currently discussed. In particular, this notice should not have been send out without explaining and discussing our new (RFC) EOL that explicitly encourage community maintenance of boards first. So, please consider this mail void and stay tuned for future mails on this topic. To make things clear: this means that beagle will not go EOL in January. Sorry for any confusion and have a great christmas time and a happy new year. On Thu, Dec 1, 2011 at 8:14 PM, David Zinman <david.zinman(a)linaro.org>wrote: > A request has been received to discontinue Linaro's support for the > Beagleboard and Beagleboard-xM hardware. > > The following conditions will be applied for the 2012.01 release cycle: > * There will be no more LEB or Linaro Developer builds. > * No more testing will be applied by Linaro to the boards at all, > and no quality assurance will be performed. > * No more bugs will be filed against these boards assigned to > Linaro resources. > * All currently filed bugs will be re-targeted to the appropriate > community resource. > * Landing team support is no longer needed or expected. > * Linaro Release notes will no longer refer to Beagleboard. > > -- > David Zinman > Linaro Release Manager | Project Manager > Linaro.org | Open source software for ARM SoCs > -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

14 years

by Stephen Doel

Hi All, I'm delighted to announce that our new and improved** registration process for Linaro Connect Q1.12 is now open. As a reminder, the event will be held from 6 - 10 February at the Sofitel Hotel, Redwood City, CA and will be themed around the roadmap set by Linaro Members with a focus on continuous integration, consolidation and future ARM architectures. Click on the "Register Now" button at http://connect.linaro.org/lcq1-12/, which also has full event details and the special delegate accommodation rates we have secured at the hotel Or just go straight to the registration process here: http://connect.linaro.org/register-connect/ I'm particularly excited that Linaro Connect will be at the same hotel as Android Builders Summit and ELC, which will be running the following week. So, this is a great opportunity a) to combine attendance at these premier industry events and b) to invite people who are going to these other events to participate in Linaro Connect and the future of Linux on ARM ** Following feedback at previous Linaro Connect events, the registration process now includes a) registration on Launchpad so you only have to go through the registration process once b) ability to save and complete later c) e-mail with details of where to locate your registration form d) opportunity to amend your details at any time by clicking on the Register Now button again (even after completing registration). See you in February! Thx Stephen Doel Chief Operating Officer T: +44 1223 45 00 23 │ M: +44 77 66 014 247 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro/155974581091106> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog

14 years

[PATCH v3 0/5] common clk framework

by Mike Turquette

Hi all, A quick refresher: the clock framework APIs in include/linux/clk.h have allowed platforms to develop their own platform-specific implementations to manage clocks; this meant that everyone had their own definition of struct clk, duplicated much code and contributed negatively to the on-going quest for The One Image to Rule Them All. The common clk framework is an attempt to define a generic struct clk which most platforms can use to build a clk tree and perform a well-defined set of operations against. These five patches are the next iteration of the common clk framework. Since the V2 submission back in late September I ported the OMAP4 portion of OMAP's platform-specific clk framework and actively developed the generic code on a Panda board which revealed many bugs in V2. The patches are based on Linus' v3.2-rc1 tag and can be pulled from: git://git.linaro.org/people/mturquette/linux.git http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=ref… A great deal of this work was first done by Jeremy Kerr, who in turn based his patches off of work by Ben Herrenschmidt (https://lkml.org/lkml/2011/5/20/81). Many others contributed to those patches and promptly had their work stolen by me. Thanks to all for their past contributions. What to expect in this version: .the most notable change is the removal of struct clk_hw. This extra layer of abstraction is only necessary if we want hide the definition of struct clk from platform code. Many developers expressed the need to know some details of the generic struct clk in the platform layer, and rightly so. Now struct clk is defined in include/linux/clk.h, protected by #ifdef CONFIG_GENERIC_CLK. .flags have been introduced to struct clk, with several of them defined and used in the common code. These flags protect against changing clk rates or switching the clk parent while that clk is enabled; another flag is used to signal to clk_set_rate that it should ask the parent to change it's rate too. .speaking of which, clk_set_rate has been overhauled and is now recursive. *collective groan*. clk_set_rate is still simple for the common case of simply setting a single clk's rate. But if your clk has the CLK_PARENT_SET_RATE flag and the .round_rate callback recommends changing the parent rate, then clk_set_rate will recurse upwards to the parent and try it all over again. In the event of a failure everything unwinds and all the clks go out for drinks. .clk_register has been replaced by clk_init, which does NOT allocate memory for you. Platforms should allocate their own clk_hw_whatever structure which contains struct clk. clk_init is still necessary to initialize struct clk internals. clk_init also accepts struct device *dev as an argument, but does nothing with it. This is in anticipation of device tree support. .Documentation! I'm sure somebody reads it. .sysfs support. Visualize your clk tree at /sys/clk! Where would be a better place to put the clk tree besides the root of /sys/? When a consensus on this is reached I'll submit the proper changes to Documentation/ABI/testing/. What's missing? .per tree locking. I implemented this at the Linaro Connect conference but the implementation was unpopular, so it didn't make the cut. There needs to be better understanding of everyone's needs for this to work. .rate change notifications. I simply didn't want to delay getting these patches to the list any longer, so the notifiers didn't make it in. I'll submit them to the list soon, or roll them into the V4 patchset. There are comments in the clk API definitions for where PRECHANGE, POSTCHANGE and ABORT propagation will go. .basic mux clk, divider and dummy clk implementations. I think others have some code lying around to implement these, so I left them out. .device tree support. I haven't looked much at the on-going discussions on the dt clk bindings. How compatible (or not) are the device tree clk bindings and the way these patches want to initialize clks? .what is the overlap between common clk and clkdev? We're essentially tracking the clks in two places (common clk's tree and clkdevs's list), which feels a bit wasteful. What else? .OMAP4 support will be posted to LOML and LAKML in a separate patchset, since others might be interested in seeing a full port. It is a total hack, and is not ready for a formal submission. Mike Turquette (5): clk: Kconfig: add entry for HAVE_CLK_PREPARE Documentation: common clk API clk: introduce the common clock framework clk: basic gateable and fixed-rate clks clk: export tree topology and clk data via sysfs Documentation/clk.txt | 312 +++++++++++++++++++++++++++ drivers/clk/Kconfig | 24 ++ drivers/clk/Makefile | 5 +- drivers/clk/clk-basic.c | 208 ++++++++++++++++++ drivers/clk/clk-sysfs.c | 199 +++++++++++++++++ drivers/clk/clk.c | 541 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/clk.h | 199 +++++++++++++++++- 7 files changed, 1484 insertions(+), 4 deletions(-) create mode 100644 Documentation/clk.txt create mode 100644 drivers/clk/clk-basic.c create mode 100644 drivers/clk/clk-sysfs.c create mode 100644 drivers/clk/clk.c -- 1.7.4.1

14 years

Linaro 11.12 Preview Release Candidate 2 Out

by Zach Pfeffer

All, I've gotten together preview releases, all running ICS, all unaccelerated (working on it). Enjoy! Instructions for how to use each build are listed on the build pages. The tests that are running and pass are listed below the build sites. As always, feel free to email/Tweet/G+/FB/IRC at #linaro-android if you have any questions. Enjoy! Snowball https://android-build.linaro.org/builds/~linaro-android/staging-snowball-11… Testshttps://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAa… Origenhttps://android-build.linaro.org/builds/~linaro-android/staging-orige… Tests https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadHlNN… iMX53https://android-build.linaro.org/builds/~linaro-android/staging-imx53-… Tests https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadHlNN… Panda (4430 and 4460, Linaro kernel)https://android-build.linaro.org/builds/~linaro-android/staging-pand… Tests https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadHlNN… Woot! -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams 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

LAVA upgrade and deployment change

by Zygmunt Krynicki

Hi LAVA users, The Linaro Validation Team is preparing to change the way we deploy LAVA in production. We expect this will require 1 hour of downtime or less on Monday beginning at 22:00 UTC. This upgrade will streamline our deployment process, allowing us to deploy changes more frequently and quickly deliver incremental improvements. This change will also allow others to deploy LAVA in the same way, for development or production purposes. As the API will not be working during the downtime, there is the chance that some automatically-submitted jobs (e.g. from android-build) will be lost. We hope to work soon on an approach that will avoid this risk. Cheers, The Validation Team

14 years

Android Build seeded builds report

by Paul Sokolovsky

Hello, We launched "seeded" builds on Linaro Android Build System (https://android-build.linaro.org) more than a week ago with the aim to improve build performance and stability, following Android ICS import which overloaded our previous build infrastructure, and looking forward into making Android RC preparation to be comfortable instead of stressful it became due to infra overload. From the very first builds it was clear that it is huge relief for problems we have, but it took entire Android team involvement to prove that they're working as expected. And now, almost 2 weeks later, we even enough stats materials to assess how much improvement they actually did. So, I wrote a blog article about that, which includes nice build time chart which vividly shows it all: http://www.linaro.org/linaro-blog/2011/12/01/improving-performance-of-linar… The seeded builds launch effort was a big success in cooperation between Infrastructure and Android team, led by Platform Director, and I would like to thank everyone for you discussion, involvement, peer review! One last thing I would like to add though is that we essentially just *started* deployment of the seeded builds, they will require more time to uncover their full potential and made be well maintainable, so work on that continues thru 11.12 Thanks, 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

Static Library startup

by Tom Gall

I probably know the answer to this already but ... For shared libs one can define and use something like: void __attribute__ ((constructor)) my_init(void); void __attribute__ ((destructor)) my_fini(void); Which of course allows your lib to run code just after the library is loaded and just before the library is going to be unloaded. This helps keep out cruft such as the following out of your design: PleaseCallThisLibraryFunctionFirstOrThereWillBeAnErrorWhichYouWillHitCausingYouToPostToTheMailingListAskingTheSameQuestionThatHasBeenAsked1000sOfTimes(); Yeah .. you know the function. I don't like it either. Unfortunately this doesn't work when people link in the .a from your lib. Libs like libjpeg-turbo in theory should never ever need to be linked in that fashion but consider the browsers who link to the universe instead of using system shared libs. If we accept that linking .a's valid use, and we don't want to promote the use of the function that won't be named in the design and use of libraries, then I'd like to think for the good of humanity the toolchain should allow for the use of __attribute__ ((constructor)) and __attribute__ ((destructor)) to continue to work in the static link case. Maybe this has already been solved, in which case where is that fine manual as I clearly have some reading to do! Thoughts? Thanks! Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years

Bus framework

by Richard Zhao

Hi Amit, Is there anyone working on a SoC bus framework? The bus framework can manage the bus fabric, ddr, OCRAM clocks. When a device driver become working, it tells bus framework, cpu may access me (ip bus and related bus fabric on), I'm also a bus master, may access ddr (ddr dma access +1 ). For bus framework, if ddr dma access request is zero, ddr clk can be disabled in WFI/wait mode. The bus framework manage the SoC bus topology. If a bus switch use count is zero, it can be disabled. It may even adjust the bus freq dynamically according to bus request. Thanks Richard

14 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev December 2011