linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

big.LITTLE MP status Oct 9, 2012

by David Zinman

https://wiki.linaro.org/projects/big.LITTLE.MP Blueprint updates ================ https://blueprints.launchpad.net/linaro-power-kernel/+spec/sched-cooperatio… - slow progress https://blueprints.launchpad.net/linaro-qa/+spec/task-placement-testing https://blueprints.launchpad.net/linaro-qa/+spec/sched-test-porting-to-andr… - Both still blocked due to the TC2 hardware not available to the QA engineer. https://blueprints.launchpad.net/linaro-qa/+spec/bl-agitator-simultaneous-s… - in progress https://blueprints.launchpad.net/linaro-qa/+spec/bl-hotplug-tests - Blocked on bL MP development work Roadmap Cards ============== No updates this week General Items ============== The agenda for the big.LITTLE mini summit at LCE has been posted: http://summit.linaro.org/lce12/2012-11-01/ Ryan has a fix for UEFI so that LAVA boards can be booted with cpufreq/cpuidle enabled. Work is being done to get this deployed on LAVA. Issues ====== The TC2 hardware is still not in the hands of the Linaro QA engineer, it is currently hung up in customs. Linaro is attempting to expedite delivery. Little progress since last week. Testing infrastructure deployment has been progressing and we anticipate testing to begin on both TC2 and RTSM platforms shortly. The issues holding up execution are bootwrapper support for RTSM and hardware delivery for TC2. The project plan is at https://docs.google.com/a/linaro.org/document/d/1XI9FaEd6dYfCEDezboF7gWtrTO… -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs

13 years, 1 month

[Query]: CPUFREQ: Affected and related cpus in cpufreq

by viresh kumar

Hi All, Sorry for asking one of the most basic question of cpufreq :( I couldn't get the difference between affected (policy->cpus) and related cpus (policy->related_cpus) in cpufreq... As per Documentation/code: affected_cpus(policy->cpus): - List of CPUs that require software coordination of frequency. - Processors part of affected_cpus share policy struct - Policy limits the frequencies that the processor can work with. related_cpus(policy->related_cpus): - List of CPUs that need some sort of frequency coordination, whether software or hardware. - Processors part of related_cpus share governer. - Governer sets the rules, about when to change limits specified by policy. Correct? So, now comes the real question: - In which scenario's should we populate affected and related cpus? - Should related cpus will always be a superset of affected cpus? -- Viresh

13 years, 1 month

[PULL REQUEST]: ARM: perf: multi-PMU support v2

by Sudeep KarkadaNagesha

Hi Viresh, Please pull the following changes(v2) for the multiple CPU PMU support (re-based to v3.6). Changes v1->v2: 1. Incorporated review comments from Will for few patches(which he will be queuing for v3.8) 2. Dropped "ARM: perf: register the init functions with the bindings", still looking for alternate to list in implementation. 3. Added per-process event tracking support on multi-PMUs. Re-factored the original patch "ARM: perf: add support for per-cluster/multiple PMUs" 4. Fixed the bug reported by Tixy for non-FDT case ---------------------------------------------------------------- The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9: Linux 3.6 (2012-09-30 16:47:46 -0700) are available in the git repository at: ssh://username@pdsw-ci.cambridge.arm.com:29418/kernel.git multi_pmu_v2 for you to fetch changes up to bd7fc4c65bd8ed994ded5aa0feeef91190fbd7be: ARM: perf: save/restore pmu registers in pm notifier (2012-10-09 18:20:45 +0100) ---------------------------------------------------------------- Axel Lin (1): ARM: ux500: Fix build error due to missing include of asm/pmu.h in cpu-db8500.c Jon Hunter (1): ARM: PMU: Add runtime PM Support Lorenzo Pieralisi (1): ARM: kernel: provide cluster to logical cpu mask mapping API Marc Zyngier (1): ARM: perf: add guest vs host discrimination Mark Rutland (1): ARM: perf: register cpu_notifier at driver init Sudeep KarkadaNagesha (11): ARM: pmu: remove arm_pmu_type enumeration ARM: perf: move irq registration into pmu implementation ARM: perf: allocate CPU PMU dynamically at probe time ARM: perf: consistently use struct perf_event in arm_pmu functions ARM: perf: check ARMv7 counter validity on a per-pmu basis ARM: perf: replace global CPU PMU pointer with per-cpu pointers ARM: perf: register CPU PMUs with idr types ARM: perf: set cpu affinity to support multiple PMUs ARM: perf: set cpu affinity for the irqs correctly ARM: perf: remove spaces in CPU PMU names ARM: perf: save/restore pmu registers in pm notifier Will Deacon (8): ARM: perf: add devicetree bindings for 11MPcore, A5, A7 and A15 PMUs ARM: pmu: remove unused reservation mechanism ARM: perf: remove mysterious compiler barrier ARM: perf: probe devicetree in preference to current CPU ARM: perf: prepare for moving CPU PMU code into separate file ARM: perf: move CPU-specific PMU handling code into separate file ARM: perf: return NOTIFY_DONE from cpu notifier when no available PMU ARM: perf: consistently use arm_pmu->name for PMU name Documentation/devicetree/bindings/arm/pmu.txt | 7 + MAINTAINERS | 1 - arch/arm/Kconfig | 8 +- arch/arm/include/asm/perf_event.h | 14 +- arch/arm/include/asm/pmu.h | 111 +++---- arch/arm/include/asm/topology.h | 3 + arch/arm/kernel/Makefile | 3 +- arch/arm/kernel/perf_event.c | 444 +++++++------------------ arch/arm/kernel/perf_event_cpu.c | 380 +++++++++++++++++++++ arch/arm/kernel/perf_event_v6.c | 134 ++++---- arch/arm/kernel/perf_event_v7.c | 307 +++++++++-------- arch/arm/kernel/perf_event_xscale.c | 163 ++++----- arch/arm/kernel/pmu.c | 36 -- arch/arm/kernel/topology.c | 27 ++ arch/arm/mach-bcmring/arch.c | 3 +- arch/arm/mach-omap2/devices.c | 3 +- arch/arm/mach-pxa/devices.c | 3 +- arch/arm/mach-realview/realview_eb.c | 3 +- arch/arm/mach-realview/realview_pb1176.c | 3 +- arch/arm/mach-realview/realview_pb11mp.c | 3 +- arch/arm/mach-realview/realview_pba8.c | 3 +- arch/arm/mach-realview/realview_pbx.c | 3 +- arch/arm/mach-tegra/devices.c | 3 +- arch/arm/mach-ux500/cpu-db8500.c | 4 +- arch/arm/mach-vexpress/ct-ca9x4.c | 3 +- arch/arm/plat-iop/pmu.c | 3 +- arch/arm/plat-samsung/devs.c | 3 +- 27 files changed, 942 insertions(+), 736 deletions(-) create mode 100644 arch/arm/kernel/perf_event_cpu.c delete mode 100644 arch/arm/kernel/pmu.c -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

13 years, 1 month

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, 1 month

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, 1 month

[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, 1 month

[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, 1 month

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, 1 month

[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, 1 month

[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, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev