linaro-dev November 2011

linaro-dev@lists.linaro.org

122 participants
130 discussions

by Zygmunt Krynicki

W dniu 11.11.2011 03:55, Adilson Oliveira pisze: Hi. I'm re-posting a question from a canonical folk about Efika MX, I think the audience here will be more capable of helping out. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello > > I got an Efika MX and I wondered if anyone qwas able to instrall a > more recent Ubuntu on it. I tried Linaro's image but the SD is not > recognized at boot time. Am I missing something or was the SD supposed > to be detected automatically? > > TIA > > Adilson. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk68jroACgkQYaKG37RGLIp/pACdFvTB3hVssnVCeXNL9EulVb9Z > UccAn3z3YUvON/ji1gdRDaRuHq/IZrA1 > =73EU > -----END PGP SIGNATURE-----

14 years, 10 months

[Activity] Power Management WG Weekly Status report for week ending 2011-11-11

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report & meeting minutes for the Power Management working group for the week ending 2011-11-11 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-11-10 == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-11-09 == Summary == (For details, see the Weekly Status Report and Meeting Minutes ) * Most of the PMWG team has attended Linaro Connect, many good sessions, discussion and hacking has happened https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Orlando * sched_mc * Presented sched_mc findings at Connect see the presentation at https://wiki.linaro.org/Events/LinaroConnectQ4.11 * Start discussing load balance and ARM topology * Cpuidle * It was decided to to fix the core cpuidle first, which makes porting to the platforms much easier. Will collaborate with Deepthi to clean up the cpuidle core code. * Studying SMP cpuidle, so far the thought is changes to menu governor may be needed. * Common clock framework * Last issue for common clock framework is resolved. *Panda is now 100% converted to use Common Clock Framework.* * Some platform work is happening to convert to the new framework. * Thermal Manager * Started working on upstreaming i.MX6 temperature sensor and thermal driver. Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

14 years, 10 months

[PATCH] pinctrl: Add explicit gpio_disable_free pinmux_op

by Stephen Warren

Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a completely different manner than they select which function to mux out of that pin. In order to support a single "free" pinmux_op, the driver would need to maintain a per-pin state of requested-for-gpio vs. requested-for- function. However, that's a lot of work when the core already has explicit separate paths for gpio request/free and function request/free. So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free() call it when appropriate. When doing this, I noticed that when calling pin_request(): !!gpio == (gpio_range != NULL) ... and so I collapsed those two parameters in both pin_request(), and when adding writing the new code in pin_free(). Also, for pin_free(): !!free_func == (gpio_range != NULL) However, I didn't want pin_free() to know about the GPIO function naming special case, so instead, I reworked pin_free() to always return the pin's previously requested function, and now pinmux_free_gpio() calls kfree(function). This is much more balanced with the allocation having been performed in pinmux_request_gpio(). Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- drivers/pinctrl/pinmux.c | 39 +++++++++++++++++++++++++-------------- include/linux/pinctrl/pinmux.h | 3 +++ 2 files changed, 28 insertions(+), 14 deletions(-) diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c index a5467f8..8a95e45 100644 --- a/drivers/pinctrl/pinmux.c +++ b/drivers/pinctrl/pinmux.c @@ -98,12 +98,11 @@ struct pinmux_hog { * @function: a functional name to give to this pin, passed to the driver * so it knows what function to mux in, e.g. the string "gpioNN" * means that you want to mux in the pin for use as GPIO number NN - * @gpio: if this request concerns a single GPIO pin * @gpio_range: the range matching the GPIO pin if this is a request for a * single GPIO pin */ static int pin_request(struct pinctrl_dev *pctldev, - int pin, const char *function, bool gpio, + int pin, const char *function, struct pinctrl_gpio_range *gpio_range) { struct pin_desc *desc; @@ -152,7 +151,7 @@ static int pin_request(struct pinctrl_dev *pctldev, * If there is no kind of request function for the pin we just assume * we got it by default and proceed. */ - if (gpio && ops->gpio_request_enable) + if (gpio_range && ops->gpio_request_enable) /* This requests and enables a single GPIO pin */ status = ops->gpio_request_enable(pctldev, gpio_range, pin); else if (ops->request) @@ -182,29 +181,39 @@ out: * pin_free() - release a single muxed in pin so something else can be muxed * @pctldev: pin controller device handling this pin * @pin: the pin to free - * @free_func: whether to free the pin's assigned function name string + * @gpio_range: the range matching the GPIO pin if this is a request for a + * single GPIO pin */ -static void pin_free(struct pinctrl_dev *pctldev, int pin, int free_func) +static const char *pin_free(struct pinctrl_dev *pctldev, int pin, + struct pinctrl_gpio_range *gpio_range) { const struct pinmux_ops *ops = pctldev->desc->pmxops; struct pin_desc *desc; + const char *func; desc = pin_desc_get(pctldev, pin); if (desc == NULL) { dev_err(&pctldev->dev, "pin is not registered so it cannot be freed\n"); - return; + return NULL; } - if (ops->free) + /* + * If there is no kind of request function for the pin we just assume + * we got it by default and proceed. + */ + if (gpio_range && ops->gpio_disable_free) + ops->gpio_disable_free(pctldev, gpio_range, pin); + else if (ops->free) ops->free(pctldev, pin); spin_lock(&desc->lock); - if (free_func) - kfree(desc->mux_function); + func = desc->mux_function; desc->mux_function = NULL; spin_unlock(&desc->lock); module_put(pctldev->owner); + + return func; } /** @@ -234,7 +243,7 @@ int pinmux_request_gpio(unsigned gpio) if (!function) return -EINVAL; - ret = pin_request(pctldev, pin, function, true, range); + ret = pin_request(pctldev, pin, function, range); if (ret < 0) kfree(function); @@ -252,6 +261,7 @@ void pinmux_free_gpio(unsigned gpio) struct pinctrl_gpio_range *range; int ret; int pin; + const char *func; ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range); if (ret) @@ -260,7 +270,8 @@ void pinmux_free_gpio(unsigned gpio) /* Convert to the pin controllers number space */ pin = gpio - range->base; - pin_free(pctldev, pin, true); + func = pin_free(pctldev, pin, range); + kfree(func); } EXPORT_SYMBOL_GPL(pinmux_free_gpio); @@ -350,7 +361,7 @@ static int acquire_pins(struct pinctrl_dev *pctldev, /* Try to allocate all pins in this group, one by one */ for (i = 0; i < num_pins; i++) { - ret = pin_request(pctldev, pins[i], func, false, NULL); + ret = pin_request(pctldev, pins[i], func, NULL); if (ret) { dev_err(&pctldev->dev, "could not get pin %d for function %s " @@ -360,7 +371,7 @@ static int acquire_pins(struct pinctrl_dev *pctldev, /* On error release all taken pins */ i--; /* this pin just failed */ for (; i >= 0; i--) - pin_free(pctldev, pins[i], false); + pin_free(pctldev, pins[i], NULL); return -ENODEV; } } @@ -390,7 +401,7 @@ static void release_pins(struct pinctrl_dev *pctldev, return; } for (i = 0; i < num_pins; i++) - pin_free(pctldev, pins[i], false); + pin_free(pctldev, pins[i], NULL); } /** diff --git a/include/linux/pinctrl/pinmux.h b/include/linux/pinctrl/pinmux.h index 3c430e7..350e32a 100644 --- a/include/linux/pinctrl/pinmux.h +++ b/include/linux/pinctrl/pinmux.h @@ -73,6 +73,9 @@ struct pinmux_ops { int (*gpio_request_enable) (struct pinctrl_dev *pctldev, struct pinctrl_gpio_range *range, unsigned offset); + void (*gpio_disable_free) (struct pinctrl_dev *pctldev, + struct pinctrl_gpio_range *range, + unsigned offset); }; /* External interface to pinmux */ -- 1.7.0.4

14 years, 10 months

[Activity] Kernel WG Weekly Status report for week ending 2011-11-11

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status & Individual Activity reports for the kernel working group for the week ending 2011-11-11 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-11-10 == Individual Activity Report == https://wiki.linaro.org/WorkingGroups/Kernel/ActivityReports/2011-11-04 == Summary == (For more details, refer to the Weekly Status & Individual Activity Reports) * Most of the KWG team has attended Linaro Connect, many good sessions, discussion and hacking has happened. Deepak has summarized the event for KWG: http://www.linaro.org/linaro-blog/2011/11/09/kernel-working-group-a-linaro-… * Due to Thanksgiving holiday, this month's Linaro kernel release will be as follows: Freeze on Monday 2011-11-14 and release on Thursday 2011-11-17. * Based on discussions at LCQ4.11 Connect in Orlando, there will be a new process for the Kernel WG, new sub-team will be designated for each major area. * Device Tree * Submitted rebased version of the samsung's sdhci driver DT patches. * Regulator core DT patches Acked by Mark. Some more minor comments from Olof, will need another final repost. * Initial omap hsmmc DT patches posted. * Pinctrl * Linus Torvalds has pulled the pinctrl subssystem for Linux v3.2. * All GPIO cleanups initially started in the Cambourne sprint in cooperation with Ben Dooks, have been pulled into Linus Torvalds' tree. Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

14 years, 10 months

Patches for SMSC LAN911X driver on UBoot and QEMU

by Cachet Bertrand

Hi, I have made some modification to the SMSC LAN911X driver for both UBoot and QEMU in order to be able to use SMSC LAN9X based network drivers during the u-boot stage. 1) U-Boot In UBoot, when the LAN911X device is reseted, the READY bit is checked and device is wake up by writing onto the TEST_BYTE register if the READY bit cleared (0b). But from the datasheet of the SMSC LAN9118/LAN9115/LAN9220 in the section Power Management (3.10), it is said that READY bit is cleared when PM_MODE is set to D1 or D2 and set only when in D0 mode. 3.10.2 Functional Description There is one normal operating power state, D0 and there are two power saving states: D1, and D2. Upon entry into either of the two power saving states, only the PMT_CTRL register is accessible for read operations. In either of the power saving states the READY bit in the PMT_CTRL register will be cleared. Reads of any other addresses are forbidden until the READY bit is set. All writes, with the exception of the wakeup write to BYTE_TEST, are also forbidden until the READY bit is set. Only when in the D0 (Normal) state, when the READY bit is set, can the rest of the device be accessed. So I modified the code (drivers/net/smc911x.h) to wake up the device only if the READY bit is cleared (0b). If it is set (1b) then we just do nothing. Patch is contained in following commit : https://bitbucket.org/bca/u-boot-linaro-stable/changeset/b870326105da 2) QEMU In the driver for the SMSC LAN9118 device (hw/lan9118.c), I modify the code to update the PM_CTRL register (switch PM_MODE bits to D0 and set (1b) READY bit ) when writing to the BYTE_TEST register. Writing to PM_CTRL was not permitted before this modification => raise an harware error => QEMU crash when happen. So when you try to perform network connection in u-boot stage in QEMU, QEMU crashed. Patch is contained in the following commit : https://bitbucket.org/bca/qemu-linaro/changeset/0aa1f76e5141 If you have any question, or if you find any mistake in my understanding, please feel free to contact me. Hope it helps others and a bit thanks for the Linaro initiative -- Bertrand Cachet, Ingénieur CPE (Lyon, France) Institut REDS, Reconfigurable & Embedded Digital Systems Tél : +41 24/55 77 372 Email : bertrand.cachet(a)heig-vd.ch<mailto:bertrand.cachet@heig-vd.ch> Internet: http://www.reds.ch HEIG-VD, Haute Ecole d'Ingénierie et de Gestion du Canton de Vaud Rte de Cheseaux 1 CH-1401 Yverdon-les-Bains Internet: http://www.heig-vd.ch

14 years, 10 months

android powertop is always segment fault

by Jello huang

Hi Tony when i start up the latest powertop ,and it always complaint # powertop {LINUX} init: untracked pid 1298 exited Cannot load results from file /data/local/powertop/saved_results.powertop Cannot load parameters from file /data/local/powertop/saved_parameters.powertop [1]+ Stopped (signal) powertop # [1]+ Segmentation fault powertop # powertop -v Cannot load results from file /data/local/powertop/saved_results.powertop Cannot load parameters from file /data/local/powertop/saved_parameters.powertop {LINUX} init: untracked pid 1307 exited [1]+ Stopped (signal) powertop -v # [1]+ Segmentation fault powertop -v # strace -f -v -T powertop execve("/system/bin/powertop", ["powertop"], ["EXTERNAL_STORAGE=/mnt/sdcard", "LD_LIBRARY_PATH=/system/lib:/lib"..., "OLDPWD=/system/lib", "ANDROID_ASSETS=/system/app", "BOOTCLASSPATH=/system/framework/"..., "ANDROID_DATA=/data", "PATH=/system/sbin:/system/bin:/s"..., "ANDROID_ROOT=/system", "ASEC_MOUNTPOINT=/mnt/asec", "PWD=/system/bin", "ANDROID_PROPERTY_WORKSPACE=9,327"..., "ANDROID_BOOTLOGO=1"]{LINUX} init: untracked pid 1312 exited ) = 0 <0.001495> -- JUST DO IT,NOTHING IS IMPOSSIBLE

14 years, 10 months

Re: LAVA server going down in 30 minutes

by Paul Larson

Here's a quick status update on the server upgrade we performed today. The major things we were doing were: * Memory upgrades - we now have about 7.5x the memory we had previously, things are *much* faster now * OS updates - We're now running on the latest version of Ubuntu Server * LAVA updates If you take a look at http://validation.linaro.org, you will now see the version we had in staging last week at the connect, with more Linaro theming, menu improvements, and bug fixes. Jobs are running again, and we've mostly cleared the backlog but seem to be having some network problems that are unrelated to the upgrades, causing failures in some of the jobs. The validation team is currently looking at what can be done to improve this soon. Thanks, Paul Larson On Thu, Nov 10, 2011 at 2:31 AM, Dave Pigott <dave.pigott(a)linaro.org> wrote: > Hi all, > > Just a reminder that validation.linaro.org will be taken down in 30 > minutes, at 09:00 UTC. > > Thanks > > Dave Pigott > Validation Engineer > T: +44 1223 45 00 24 | M +44 7940 45 93 44 > Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM > SoCs**** > Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter<http://twitter.com/#%21/linaroorg> > | Blog <http://www.linaro.org/linaro-blog/> > >

14 years, 10 months

error handling and reporting in the dispatcher

by Michael Hudson-Doyle

I'm working on the dispatcher again, and as usual I'm getting a bit grumpy. Partly this is because the abstractions I added a couple of weeks ago aren't really working, but that's my problem. What I want to complain about is the error handling. I've always found the error handling in the dispatcher to be a little strange, so in this mail I'm going to try to set out the issue and maybe propose a solution. A lot of the confusion comes from the fact that there are many things that could be called an error in the dispatcher, and some overloading in the way we try to handle and report errors. Kinds of error that I can think of immediately: 1) Flat out bugs in the dispatcher 2) Errors in the job file (e.g. typoing an action name) 3) Failing tests 4) Tests that fail to even run 5) The board hanging at some point 6) Infrastructure failures, like l-m-c or deployment failing 7) Recoverable errors, e.g. where we want to be in the master image but might be in the linaro image Category 1 bugs we can't really do *too* much about -- if we have incorrect code, who's to say that the error handling code will be correct? -- but in general dispatcher bugs should IMO cause the dispatcher to exit with an exit code != 0 (we talked at the connect about having the scheduler display jobs that exited like this differently). Currently because we have lots of "except:"s all over the place, I think we risk swallowing genuine bugs (indeed, we had one of these for a while, where we said "self.in_master_shell()" instead of "self.client.in_master_shell()" but the AttributeError was caught). If we hit this sort of thing, I don't think we should try to continue to execute other actions and in particular I'm not too bothered if this kind of error does not result in a bundle being submitted to the dashboard. Category 2 -- errors in the job file -- we should try to detect as early as possible. Maybe we should even create the action objects and do a simple argument check before doing anything else? I think this sort of error should also result in an exit code != 0. To the extent that its reasonable, invalid job files should be rejected by the submit_job api call. As for bugs, I don't think we should try to continue to execute other actions and I'm not too bothered if this kind of error does not result in a bundle being submitted to the dashboard. Category 3 -- failing tests -- is not something the dispatcher itself should care about, at all. Category 4 -- tests that fail to run, I guess this includes things like lava-test hanging or crashing -- I think this should result in a failure in the magic 'lava' test run of the submitted bundle (and I think this is the case today). If this happens, I don't know if we should try to continue to execute other actions (apart from submit_results I guess). Category 5 -- things like the board hanging at some point -- I guess this depends a bit when this happens. If it's during deployment say, that's pretty bad -- certainly we shouldn't try to execute other non-reporting actions if this happens. Category 6 -- infrastructure failures -- seem to fall into the same kind of area as the previous 2: we should report a failure and stop executing any other actions. Category 7 -- recoverable failures -- are a bit different. We should log that they have happened and continue. After all this thinking and typing I think I've come to some conclusions: 1) There is a category of error where we should just stop. As far as I know, this isn't really handled today. 2) There is another category of error where we should report failure, but not execute any other actions. This makes me thing that having 'report results' as an action is a bit strange -- perhaps the dashboard and bundle stream should really be directly in the job, rather than an action? 3) I need to write another, probably equally long, email about dependencies between actions :-) Cheers, mwh

14 years, 10 months

[ACTIVITY] Android Platform Team 2011-10-31 to 2011-11-06

by Tony Mansson

Key Points for wider discussion =============================== * Toolchain build modified to generate both arm-eabi and arm-linux-androideabi toolchains Team Highlights =============================== * ALmost all Team members attended Connect * Progress on Androidizing Snowball GLK3.1 kernel * Workaround created for gdbserver crash on startup * All board kernels generates config.gz by default * A bot metrics script to determine the bot's contributions to gerrit done * Solution to LAVA test iMX53, Origen and Snowball on review * Progress on video recording bug * libpng 1.5.5 integration issues solved * Android builds on tool chain tip build * Progress on linphone on panda. Miscellaneous =============================== * New members Amit Pundir and Prashanth Srinivasan Issues =============================== * Slow progress on "Build the Non-Proprietary Igloo Android A Release with Linaro Tools" Blueprints =============================== https://launchpad.net/linaro-android/+milestone/11.11

14 years, 10 months

test files defined in src/com/android/mediaframeworktest/MediaNames.java

by yong qin

Hello, All Does anyone who know where to get the test files defined in file src/com/android/mediaframeworktest/MediaNames.java. or how to generate those files. like public static final String MP3CBR = "/sdcard/media_api/music/MP3_256kbps_2ch.mp3"; public static final String MP3VBR = "/sdcard/media_api/music/MP3_256kbps_2ch_VBR.mp3"; public static final String SHORTMP3 = "/sdcard/media_api/music/SHORTMP3.mp3"; public static final String MIDI = "/sdcard/media_api/music/ants.mid"; public static final String WMA9 = "/sdcard/media_api/music/WMA9.wma"; public static final String WMA10 = "/sdcard/media_api/music/WMA10.wma"; public static final String WAV = "/sdcard/media_api/music/rings_2ch.wav"; public static final String AMR = "/sdcard/media_api/music/test_amr_ietf.amr"; public static final String OGG = "/sdcard/media_api/music/Revelation.ogg"; public static final String SINE_200_1000 = "/sdcard/media_api/music/sine_200+1000Hz_44K_mo.wav"; public static String[] MP3FILES = { "/sdcard/media_api/music_perf/MP3/NIN_56kbps_32khz_stereo_VBR_MCA.MP3", "/sdcard/media_api/music_perf/MP3/NIN_80kbps_32khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_80kbps_44.1khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_80kbps_48khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_112kbps_32khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_112kbps_44.1khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_112kbps_48khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_192kbps_32khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_192kbps_44.1khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_192kbps_48khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_256kbps_44.1khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/NIN_256kbps_48khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/PD_112kbps_32khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/PD_112kbps_44.1khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/PD_112kbps_48khz_stereo_VBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/PD_192kbps_32khz_mono_CBR_DPA.mp3", "/sdcard/media_api/music_perf/MP3/PD_256kbps_44.1khz_mono_CBR_DPA.mp3", "/sdcard/media_api/music_perf/MP3/PD_256kbps_48khz_mono_CBR_MCA.mp3", "/sdcard/media_api/music_perf/MP3/WC_256kbps_44.1khz_mono_CBR_DPA.mp3", "/sdcard/media_api/music_perf/MP3/WC_256kbps_48khz_mono_CBR_DPA.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Apologize.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Because_Of_You.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Complicated.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Glamorous.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Im_With_You.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Smile.mp3", "/sdcard/media_api/music_perf/regular_album_photo/Suddenly_I_See.mp3", "/sdcard/media_api/music_perf/regular_album_photo/When You Say Nothing At All.mp3", "/sdcard/media_api/music_perf/regular_album_photo/my_happy_ending.mp3"}; Thanks, Yongqin Liu

14 years, 10 months

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev November 2011