> (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
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
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
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
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
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
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
