linaro-dev October 2012

linaro-dev@lists.linaro.org

76 participants
108 discussions

2012-10-10 Android Platform Team Meeting Agenda Posted

by Zach Pfeffer

Please take a look at: https://wiki.linaro.org/Platform/Android/Meetings/2012-10-10 Feel free to add to the agenda and join us in #linaro-meeting on irc.freenode.net at 13:00 UTC on 2012/10/10. -- 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

13 years

Questions about linux-linaro-tracking.git asked on IRC

by Andrey Konovalov

> (12:25:28 PM) hongbo_: amitk: good afternoon. need I push u8500 thermal driver to linux-linaro?> > problems I found is that both the AmitDK's generic cpu cooling code and the generic thermal layer code > are so old in this tree, if u8500 thermal driver has to be pushed into this tree, I have to edit it to > an relevant old and useless version. > (12:27:16 PM) amitk: fabo: which build (and corresponding kernel) currently has the best enablement across various > member HW. LLCT doesn't work on some hardware and is blocking michaelh|away from creating a PM-QA > summary view for us > (12:27:25 PM) amitk: andrey_konovalov: ^ hongbo_ could try linux-linaro instead of linux-linaro-core-tracking. > (12:28:02 PM) amitk: hongbo_: the idea is never to go with older patchsets, but to refresh the depending patchset to > a newer version. > (12:28:10 PM) hongbo_: amitk: my opinion is that both generic cooling and thermal framework should be update first, > and then push u8500 codes later > (12:29:16 PM) hongbo_: amitk: who is responsible for refreshing generic cooling code? Amit DK has left. > (12:29:17 PM) amitk: hongbo_: correct, so can you ask andrey_konovalov to remove the old thermal fwk code (where do > you find it, btw?) and supply him with a new version of the patchset (3.6+) > (12:29:25 PM) amitk: hongbo_: now you are :) > (12:31:12 PM) hongbo_: amitk: andrey_konovalov: I found the old thermal fwk here: > http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=dr… Wrong tree. This is *v3.4 based* linux-linaro-tracking (aka LLT) tree (git branch to be exact). It should not be used to develop new common code (this tree is created from LT's trees; there are no common topics in llt). There is a short description of the linux-linaro-tracking.git branches here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=summary - and the link to https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess Thanks, Andrey

13 years

[PATCH v2 0/3] bootwrapper: Add support for big.LITTLE models

by Jon Medhurst (Tixy)

This mostly boils down to initialising the Cache Coherent Interconnect (CCI). We do this by looking in the device-tree for a CCI node, that way the same semihosting bootwrapper binary can be used on both the big.LITTLE models and on the A15 models which don't have a CCI. Changes sinces v1: - Added in-source comment to configure_from_fdt() - Reworded commit message for patch 2 [PATCH v2 1/3] bootwrapper: Allow for multiple clusters in boot CPU [PATCH v2 2/3] bootwrapper: Factor out parsing of fdt #address-cells [PATCH v2 3/3] bootwrapper: Initialise CCI device if found in the

13 years

[PATCH] cpufreq: vexpress_bl: Optimize vexpress_cpufreq_of_init()

by Viresh Kumar

This patch tries to optimize vexpress_cpufreq_of_init() routine of vexpress_bl cpufreq driver. Following are the optimizations: - No need to allocate freq table array and copy it into struct cpufreq_frequency_table. This removes the need of _cpufreq_copy_table_from_array() routine too. - Use global freq_table variable instead of creating local copy freqtable. - replace kzalloc with kmalloc, as we are updating all the fields. - free_mem: path expects the clusters to be defined in ascending order, which shouldn't be enforced. Instead try to free freq_table for all clusters. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Hi Sudeep, I was going through cpufreq framework and took vexpress_bL_cpufreq.c as an reference. While going through its code, i realized it can be optimized. So this patch. This is compiled tested only as i didn't had TC2 with me today. Can you please see if it looks fine? Then we can ask Tixy to get this into his tree. -- viresh drivers/cpufreq/vexpress_bL_cpufreq.c | 50 +++++++++++++---------------------- 1 file changed, 18 insertions(+), 32 deletions(-) diff --git a/drivers/cpufreq/vexpress_bL_cpufreq.c b/drivers/cpufreq/vexpress_bL_cpufreq.c index 2c71b24..9af38cf 100644 --- a/drivers/cpufreq/vexpress_bL_cpufreq.c +++ b/drivers/cpufreq/vexpress_bL_cpufreq.c @@ -146,28 +146,14 @@ static unsigned int vexpress_cpufreq_get(unsigned int cpu) return freq_table[cur_cluster][freq_tab_idx].frequency; } -/* translate the integer array into cpufreq_frequency_table entries */ -static inline void _cpufreq_copy_table_from_array(uint32_t *table, - struct cpufreq_frequency_table *freq_table, int size) -{ - int i; - for (i = 0; i < size; i++) { - freq_table[i].index = i; - freq_table[i].frequency = table[i] / 1000; /* in kHZ */ - } - freq_table[i].index = size; - freq_table[i].frequency = CPUFREQ_TABLE_END; -} - static int vexpress_cpufreq_of_init(void) { - uint32_t cpu_opp_num; - struct cpufreq_frequency_table *freqtable[VEXPRESS_MAX_CLUSTER]; - uint32_t *cpu_freqs; - int ret = 0, cluster_id = 0, len; struct device_node *cluster = NULL; const struct property *pp; + uint32_t cpu_opp_num; + int ret = 0, cluster_id = 0, len, i = -1; const u32 *hwid; + const __be32 *val; while ((cluster = of_find_node_by_name(cluster, "cluster"))) { hwid = of_get_property(cluster, "reg", &len); @@ -175,33 +161,33 @@ static int vexpress_cpufreq_of_init(void) cluster_id = be32_to_cpup(hwid); pp = of_find_property(cluster, "freqs", NULL); - if (!pp) + if (!pp || !pp->value || !pp->length) return -EINVAL; + cpu_opp_num = pp->length / sizeof(u32); if (!cpu_opp_num) return -ENODATA; - cpu_freqs = kzalloc(sizeof(uint32_t) * cpu_opp_num, GFP_KERNEL); - freqtable[cluster_id] = - kzalloc(sizeof(struct cpufreq_frequency_table) * - (cpu_opp_num + 1), GFP_KERNEL); - if (!cpu_freqs || !freqtable[cluster_id]) { + freq_table[cluster_id] = kmalloc(sizeof(**freq_table) * + (cpu_opp_num + 1), GFP_KERNEL); + if (!freq_table[cluster_id]) { ret = -ENOMEM; goto free_mem; } - of_property_read_u32_array(cluster, "freqs", - cpu_freqs, cpu_opp_num); - _cpufreq_copy_table_from_array(cpu_freqs, - freqtable[cluster_id], cpu_opp_num); - freq_table[cluster_id] = freqtable[cluster_id]; - kfree(cpu_freqs); + val = pp->value; + while (++i < cpu_opp_num) { + freq_table[cluster_id][i].index = i; + freq_table[cluster_id][i].frequency = + be32_to_cpup(val++) / 1000; /* in kHZ */ + } + freq_table[cluster_id][i].index = i; + freq_table[cluster_id][i].frequency = CPUFREQ_TABLE_END; } return ret; free_mem: - while (cluster_id >= 0) - kfree(freqtable[cluster_id--]); - kfree(cpu_freqs); + for (i = 0; i < VEXPRESS_MAX_CLUSTER; i++) + kfree(freq_table[i]); return ret; } -- 1.7.12.rc2.18.g61b472e

13 years

LAVA down time

by Dave Pigott

Hi All, Finally, after months of delays, our leased line is stable and usable. I have the router configured and ready to switch over, which I plan to do on Monday. As a consequence, I will be putting all the boards in LAVA offline on Sunday morning (UK time). Currently running jobs will be allowed to complete, but any new jobs will get queued, and not run until the switchover is complete. While the lab is down, I will also be upgrading control to precise and attaching the WiFi AP so that it has access to the outside world. Obviously, with the switch over, the IP address of v.l.o will change, and this will take some time to permeate through to DNS. I will make sure that this has happened before bringing all the boards back online, but it will probably mean that LAVA will not be running jobs until Tuesday morning, and that v.l.o will actually disappear for a couple of hours on Monday. Once the transition has happened, we should see a significant improvement in the response time when accessing v.l.o and utilising LAVA. Of course, if anyone sees anything wrong or odd, please alert me immediately. Thanks Dave Dave Pigott Validation Engineer T: +44 1223 40 00 63 | M +44 7940 45 93 44 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

13 years

[PATCH v4 0/3] devfreq: Add support for devices which can idle

by Rajagopal Venkat

This patchset updates devfreq core to add support for devices which can idle. When device idleness is detected perhaps through runtime-pm, need some mechanism to suspend devfreq load monitoring and resume when device is back online. patch 1 introduce core design changes - per device work, decouple delayed work from core and event based interaction. patch 2 add devfreq suspend and resume apis. patch 3 add new sysfs attribute for governor predicted next target frequency and callback for current device frequency. The existing devfreq apis are kept intact. Two new apis devfreq_suspend_device() and devfreq_resume_device() are added to support suspend/resume of device devfreq. Changes since v1: - revised locking mechanism - added kerneldoc comments for load monitoring helper functions - fixed minor review comments Changes since v2: - added new helper function for polling interval update - handled work suspend/resume contention between devfreq driver and sysfs Changes since v3: - added additonal checks in suspend/resume to avoid invalid usage of apis - added check in devfreq_monitor_start, not to start monitoring when polling_ms is set to zero. -- Rajagopal Venkat (3): devfreq: Core updates to support devices which can idle devfreq: Add suspend and resume apis devfreq: Add current freq callback in device profile Documentation/ABI/testing/sysfs-class-devfreq | 15 +- drivers/devfreq/devfreq.c | 481 ++++++++++++-------------- drivers/devfreq/governor.h | 13 + drivers/devfreq/governor_performance.c | 16 +- drivers/devfreq/governor_powersave.c | 16 +- drivers/devfreq/governor_simpleondemand.c | 33 ++ drivers/devfreq/governor_userspace.c | 23 +- include/linux/devfreq.h | 49 +-- 8 files changed, 353 insertions(+), 293 deletions(-) -- 1.7.11.3

13 years

[PATCH 0/4] Implement device tree support for ab8500 BM Devices

by Rajanikanth H.V

From: "Rajanikanth H.V" <rajanikanth.hv(a)stericsson.com> This patch-set adds device tree support for ab8500 battery-managed devices. This removes the redundant platform structure maintained across bm devices and implements common DT probe routine across all the modules. Rajanikanth H.V (4): mfd: ab8500: add devicetree support for fuelgauge mfd: ab8500: add devicetree support for Btemp mfd: ab8500: add devicetree support for charger mfd: ab8500: add devicetree support for charging algorithm Documentation/devicetree/bindings/mfd/ab8500.txt | 27 +- .../bindings/power_supply/ab8500/btemp.txt | 29 ++ .../bindings/power_supply/ab8500/chargalg.txt | 36 ++ .../bindings/power_supply/ab8500/charger.txt | 44 ++ .../devicetree/bindings/power_supply/ab8500/fg.txt | 86 +++ arch/arm/boot/dts/dbx5x0.dtsi | 40 +- drivers/mfd/ab8500-core.c | 4 + drivers/power/Kconfig | 6 - drivers/power/Makefile | 2 +- drivers/power/ab8500_bmdata.c | 549 ++++++++++++++++++++ drivers/power/ab8500_btemp.c | 57 +- drivers/power/ab8500_charger.c | 65 ++- drivers/power/ab8500_fg.c | 76 ++- drivers/power/abx500_chargalg.c | 62 ++- include/linux/mfd/abx500.h | 37 +- include/linux/mfd/abx500/ab8500-bm.h | 7 + 16 files changed, 1028 insertions(+), 99 deletions(-) create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/charger.txt create mode 100644 Documentation/devicetree/bindings/power_supply/ab8500/fg.txt create mode 100644 drivers/power/ab8500_bmdata.c -- 1.7.9.5

13 years

Linaro Release 12.09 Postmortem Summary

by David Zinman

Postmortem and lessons learned for Linaro's release 2012.09 https://wiki.linaro.org/Cycles/1209/Release/Review Highlights and Key Successes ============================ The 12.09 release cycle saw some early work on minimal ARMv8 bootstrap, with a very minimal rootfs to help other developers that want to get involved with porting. This work is critical for the future of Linux on ARMv8, as the major GNU/Linux distributions can use it as base to bootstrap and support this new architechture. Registration (http://connect.linaro.org/wp-login.php?redirect_to=/register-connect/) is open for Linaro Connect (LCE 12 Copenhagen) which will be held from 29 Oct to 2 Nov at the Bella Center in Copenhagen, Demark. In addition to the regular track sessions, LCE 12 will host three mini summits: an ARMv8 (64-bit) mini-summit on the Tuesday, an Android mini-summit on the Wednesday and a big.LITTLE mini-summit on the Thursday. Postmortem and Lessons Learned ============================== Development and delivery planning continues to be a high priority as Linaro continues to grow. The platform team has instituted a release week standup meeting to coordinate development and release planning for the upcoming cycle and consolidate QA status for the cycle. As Linaro expands we will be reviewing our processes to determine the best and most effiecient way to move forward. Blueprints ========= The number of high or essential priority blueprints that missed the cycle: Android 3 out of 12 Developer Platform 4 out of 6 Infrastructure 1 out of 5 Lava 0 out of 2 QA 1 out of 3 Total 9 out of 28 32% of high or essential priority blueprints scheduled for this cycle were not delivered. Total blueprints: 22 out of 53 missed the cycle. High priority missed blueprints recap: 12.05: 19 out of 48, 39% 12.06: 13 out of 31, 42% 12.07: 14 out of 31, 45% 12.08: 6 out of 26, 23% 12.09: 9 out of 28, 32% * Not included is data from working groups and landing teams Source: https://docs.google.com/spreadsheet/ccc?key=0AjEaTwrvj1bidGVXTlFYQUJJcnMxa1… -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs

13 years

Test Result Summary of Calendar Week 40 for Linaro ubuntu.

by Botao Sun

Calendar Week 40: Here is test result summary for Linaro ubuntu image on following boards: 1) ARM Versatile Express A9; 2) Samsung Origen; 3) TI Panda Board 4430; 4) TI Panda Board 4460. Synopsis: No change on feature status for vexpress A9 & Samsung Origen boards. For Panda board, both 4430 & 4460 failed on display, neither HDMI nor DVI-D works. More details can be found in bug 1060032. 1. vexpress A9 + ubuntu (Column AC): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFNmV… Features' status is exactly same as previous week. There are 2 major issues there, 480p video playback & device tree. For device tree, it's blocked by a UEFI defect, which Ryan is working on that. For 480p video playback, it has been unavailable for 12 weeks, hopefully someone will take a look at it. 2. Origen + ubuntu (Column X): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEowN… Command "dd" doesn't work for SD card flashing this week, and Linaro Image Tools finally works after a quick fix on bug 1059501. For features, they remain the same status as previous week. Perhaps it's time to start work on those important unavailable features, such like WiFi, Bluetooth, video playback and HDMI. 3. Panda 4430 + ubuntu (Column Z): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ… Display failed, neither HDMI nor DVI-D works. This problem blocks all tests related to system UI. Also, system crashes at the second time to run power management test command "# lava-test run pwrmgmt". 4. Panda 4460 + ubuntu (Column Y): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ… Display failed, same as Panda 4430, neither HDMI nor DVI-D works. The different thing is power management works well on this board, not like what happened on Panda 4430. All command line based test works well. For the previous week (Calendar week 39 - Linaro 12.09 Release) summary, please refer to attachment. Thank you. Best Regards Botao Sun

13 years, 1 month

sched: modify timer and workqueue framework to allow migration

by Viresh Kumar

Hi Guys, I have been working on this activity since some time and V2 of patches is up for review over kernel mailing list. If any of us is interested in using these patches, can pick them from: http://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=shortlog;h=refs/head… Patches are applied over a merge of v3.6 and workqueue-for-3.7 branch from tejun. Blueprint of this activity: https://blueprints.launchpad.net/linaro-power-kernel/+spec/timer-workqueue-… NOTE: This branch isn't merged into big LITTLE MP merge branch till now. Waiting for feedback from mainline. -- viresh

13 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev October 2012