Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation
On Tue, Jul 10, 2012 at 12:31 PM, Hongbo Zhang wrote: > > > On 12 May 2012 17:40, Amit Daniel Kachhap wrote: >> >> This patch adds support for generic cpu thermal cooling low level >> implementations using frequency scaling up/down based on the registration >> parameters. Different cpu related cooling devices can be registered by the >> user and the binding of these cooling devices to the corresponding >> trip points can be easily done as the registration APIs return the >> cooling device pointer. The user of these APIs are responsible for >> passing clipping frequency . The drivers can also register to recieve >> notification about any cooling action called. >> >> Signed-off-by: Amit Daniel Kachhap >> --- >> Documentation/thermal/cpu-cooling-api.txt | 60 >> drivers/thermal/Kconfig | 11 + >> drivers/thermal/Makefile |3 +- >> drivers/thermal/cpu_cooling.c | 483 >> + >> include/linux/cpu_cooling.h | 99 ++ >> 5 files changed, 655 insertions(+), 1 deletions(-) >> create mode 100644 Documentation/thermal/cpu-cooling-api.txt >> create mode 100644 drivers/thermal/cpu_cooling.c >> create mode 100644 include/linux/cpu_cooling.h >> >> diff --git a/Documentation/thermal/cpu-cooling-api.txt >> b/Documentation/thermal/cpu-cooling-api.txt >> new file mode 100644 >> index 000..557adb8 >> --- /dev/null >> +++ b/Documentation/thermal/cpu-cooling-api.txt >> @@ -0,0 +1,60 @@ >> +CPU cooling APIs How To >> +=== >> + >> +Written by Amit Daniel Kachhap >> + >> +Updated: 12 May 2012 >> + >> +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) >> + >> +0. Introduction >> + >> +The generic cpu cooling(freq clipping, cpuhotplug etc) provides >> +registration/unregistration APIs to the caller. The binding of the >> cooling >> +devices to the trip point is left for the user. The registration APIs >> returns >> +the cooling device pointer. >> + >> +1. cpu cooling APIs >> + >> +1.1 cpufreq registration/unregistration APIs >> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( >> + struct freq_clip_table *tab_ptr, unsigned int tab_size) >> + >> +This interface function registers the cpufreq cooling device with the >> name >> +"thermal-cpufreq-%x". This api can support multiple instances of >> cpufreq >> +cooling devices. >> + >> +tab_ptr: The table containing the maximum value of frequency to be >> clipped >> +for each cooling state. >> + .freq_clip_max: Value of frequency to be clipped for each allowed >> +cpus. >> + .temp_level: Temperature level at which the frequency clamping >> will >> + happen. >> + .mask_val: cpumask of the allowed cpu's >> +tab_size: the total number of cpufreq cooling states. >> + >> +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device >> *cdev) >> + >> +This interface function unregisters the "thermal-cpufreq-%x" cooling >> device. >> + >> +cdev: Cooling device pointer which has to be unregistered. >> + >> + >> +1.2 CPU cooling action notifier register/unregister interface >> +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, >> + unsigned int list) >> + >> +This interface registers a driver with cpu cooling layer. The driver >> will >> +be notified when any cpu cooling action is called. >> + >> +nb: notifier function to register >> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP >> + >> +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, >> + unsigned int list) >> + >> +This interface registers a driver with cpu cooling layer. The driver >> will >> +be notified when any cpu cooling action is called. >> + >> +nb: notifier function to register >> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index 514a691..d9c529f 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -19,6 +19,17 @@ config THERMAL_HWMON >> depends on HWMON=y || HWMON=THERMAL >> default y >> >> +config CPU_THERMAL >> + bool "generic cpu cooling support" >> + depends on THERMAL && CPU_FREQ >> + help >> + This implements the generic cpu cooling mechanism through >> frequency >> + reduction, cpu hotplug and any other ways of reducing >> temperature. An >> + ACPI version of this already >> exists(drivers/acpi/processor_thermal.c). >> + This will be useful for platforms using the generic thermal >> interface >> + and not the ACPI interface. >> + If you want this support, you should say Y or M here. >> + >> config SPEAR_THERMAL >> bool "SPEAr thermal sensor driver" >> depends on THERMAL >> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >> index a9fff0b..30c456c 100644 >> --- a/drivers/ther
Re: Config check fails for linux-linaro-lt-omap-3.4-3.4.0
Hello, John, On 7/11/2012 2:05 PM, John Rigby wrote: > On Wed, Jul 11, 2012 at 10:35 AM, David Cullen wrote: >> >>> Running config-check for all configurations ... >>> >>> check-config: >>> /tmp/tmp.nh0bAR6k1r/CONFIGS/armel-config.flavour.linaro-lt-omap: loading >>> config >>> check-config: >>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: >>> loading checks >>> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y >>> check-config: 43/44 checks passed -- exit 1 >>> check-config: >>> /tmp/tmp.nh0bAR6k1r/CONFIGS/armhf-config.flavour.linaro-lt-omap: loading >>> config >>> check-config: >>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: >>> loading checks >>> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y >>> check-config: 43/44 checks passed -- exit 1 >>> >>> *** ERROR: 2 config-check failures detected >> > Yes this is expected because that config option is introduced by a > ubuntu patch that is not in this tree. I changed some of the scripts > to make this error non-fatal but the output gives no indication of > that. I will change that so it is clear that this is a warning or I > will make a change to the config checker to only require the option if > it exists. My concern here is that this configuration item was introduced in 2010 to fix a problem with starting a getty on OMAP processors: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/586386 Since I am using the Ubuntu image to work around problems with the Linaro-Ubuntu image, I am concerned that this will break my console getty. Can you offer any reassurance, e.g. by pointing out how more modern kernels solve the problem differently? -- Thank you, David Cullen ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config check fails for linux-linaro-lt-omap-3.4-3.4.0
On Wed, Jul 11, 2012 at 10:35 AM, David Cullen
wrote:
> Hello, John,
>
> On 7/10/2012 5:39 PM, John Rigby wrote:
>> There will shortly be a new kernel
>> linux-linaro-lt-omap-3.4_3.4.0-1.1~120710203036 in the kernel ppa:
>> https://code.launchpad.net/~linaro-maintainers/+archive/kernel
>> with the kernel_build issue fixed.
>>
>> Now we can get back to the original issue.
>
> That did fix the "kernel_build" problem, but I still see this
>
>> Running config-check for all configurations ...
>>
>> check-config:
>> /tmp/tmp.nh0bAR6k1r/CONFIGS/armel-config.flavour.linaro-lt-omap: loading
>> config
>> check-config:
>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce:
>> loading checks
>> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
>> check-config: 43/44 checks passed -- exit 1
>> check-config:
>> /tmp/tmp.nh0bAR6k1r/CONFIGS/armhf-config.flavour.linaro-lt-omap: loading
>> config
>> check-config:
>> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce:
>> loading checks
>> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
>> check-config: 43/44 checks passed -- exit 1
>>
>> *** ERROR: 2 config-check failures detected
>
>
> when I run
>
> # fakeroot debian/rules editconfigs
>
> A search for the configuration item produces no results:
>
>
>> find . -name Kconfig -exec grep -H INIT_PASS_ALL_PARAMS '{}' ';'
>
Yes this is expected because that config option is introduced by a
ubuntu patch that is not in this tree. I changed some of the scripts
to make this error non-fatal but the output gives no indication of
that. I will change that so it is clear that this is a warning or I
will make a change to the config checker to only require the option if
it exists.
thanks
john
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Experimental big.LITTLE MP tree
On Wed, 2012-07-11 at 17:25 +0100, Lorenzo Pieralisi wrote: > On Wed, Jul 11, 2012 at 05:17:44PM +0100, Jon Medhurst (Tixy) wrote: > > On Wed, 2012-07-11 at 17:00 +0100, Viresh Kumar wrote: > > > On 11 July 2012 14:32, Jon Medhurst (Tixy) wrote: > > > On Wed, 2012-07-11 at 10:57 +0100, Viresh Kumar wrote: > > > There's going to be an 'interesting' merge with our TC2 > > > enablement > > > branch. > > > > > > In arch/arm/kernel/topology.c both branches factor out > > > update_siblings_masks(), one of them modifies it. > > > > > > And in the same file, both branches also add functions called > > > parse_dt_topology() with different functionality. In the > > > resolution I'm > > > currently testing, I fixed this by renaming the version from > > > big-LITTLE-MP-v2 to parse_dt_for_cpu_capacity() as that seemed > > > an > > > accurate description of what it did. Is it tool late to also > > > do this in > > > the MP branch? > > > > > > > > > There are two patches doing the same thing (Vincent probably picked > > > this patch from Lorenzo and updated it a bit), > > > > The don't look like they are doing the same thing to me?!? > > > > Lorenzo's patch parses DT for cluster layout. > > > > Vincent's patch parses DT looking for CPU core type and frequency so it > > can set power/capaciy. > > > > I can see no overlap in the CPU node properties that they parse. > > > > Perhaps Lorenzo and Vincent can comment? > > You can drop my patch since it is not strictly needed on TC2. I have to > work out the conflict with Vincent's code, but again for now drop the > patch, it is safe to do that, topology is set-up according to the MPIDR > wiring and it is correct, at least on TC2. I've now dropped that patch from my tracking-armlt-tc2 branch and also taken the opportunity to add clock-frequency values to the device tree for TC2 as required by the big-LITTLE-MP code. My test merge of ARM LT branches and big-LITTLE-MP (with the config fragment to enable that) builds and boots OK on TC2 running Android. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Experimental big.LITTLE MP tree
On 11 July 2012 18:25, Lorenzo Pieralisi wrote: > On Wed, Jul 11, 2012 at 05:17:44PM +0100, Jon Medhurst (Tixy) wrote: >> On Wed, 2012-07-11 at 17:00 +0100, Viresh Kumar wrote: >> > On 11 July 2012 14:32, Jon Medhurst (Tixy) wrote: >> > On Wed, 2012-07-11 at 10:57 +0100, Viresh Kumar wrote: >> > There's going to be an 'interesting' merge with our TC2 >> > enablement >> > branch. >> > >> > In arch/arm/kernel/topology.c both branches factor out >> > update_siblings_masks(), one of them modifies it. >> > >> > And in the same file, both branches also add functions called >> > parse_dt_topology() with different functionality. In the >> > resolution I'm >> > currently testing, I fixed this by renaming the version from >> > big-LITTLE-MP-v2 to parse_dt_for_cpu_capacity() as that seemed >> > an >> > accurate description of what it did. Is it tool late to also >> > do this in >> > the MP branch? >> > >> > >> > There are two patches doing the same thing (Vincent probably picked >> > this patch from Lorenzo and updated it a bit), >> >> The don't look like they are doing the same thing to me?!? >> >> Lorenzo's patch parses DT for cluster layout. >> >> Vincent's patch parses DT looking for CPU core type and frequency so it >> can set power/capaciy. >> >> I can see no overlap in the CPU node properties that they parse. >> >> Perhaps Lorenzo and Vincent can comment? > > You can drop my patch since it is not strictly needed on TC2. I have to > work out the conflict with Vincent's code, but again for now drop the > patch, it is safe to do that, topology is set-up according to the MPIDR > wiring and it is correct, at least on TC2. > Thanks Lorenzo Vincent > Thanks a lot, > Lorenzo > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config check fails for linux-linaro-lt-omap-3.4-3.4.0
Hello, John,
On 7/10/2012 5:39 PM, John Rigby wrote:
> There will shortly be a new kernel
> linux-linaro-lt-omap-3.4_3.4.0-1.1~120710203036 in the kernel ppa:
> https://code.launchpad.net/~linaro-maintainers/+archive/kernel
> with the kernel_build issue fixed.
>
> Now we can get back to the original issue.
That did fix the "kernel_build" problem, but I still see this
> Running config-check for all configurations ...
>
> check-config:
> /tmp/tmp.nh0bAR6k1r/CONFIGS/armel-config.flavour.linaro-lt-omap: loading
> config
> check-config:
> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce:
> loading checks
> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
> check-config: 43/44 checks passed -- exit 1
> check-config:
> /tmp/tmp.nh0bAR6k1r/CONFIGS/armhf-config.flavour.linaro-lt-omap: loading
> config
> check-config:
> /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce:
> loading checks
> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
> check-config: 43/44 checks passed -- exit 1
>
> *** ERROR: 2 config-check failures detected
when I run
# fakeroot debian/rules editconfigs
A search for the configuration item produces no results:
> find . -name Kconfig -exec grep -H INIT_PASS_ALL_PARAMS '{}' ';'
--
Thank you,
David Cullen
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Experimental big.LITTLE MP tree
On Wed, 2012-07-11 at 17:25 +0100, Lorenzo Pieralisi wrote: > On Wed, Jul 11, 2012 at 05:17:44PM +0100, Jon Medhurst (Tixy) wrote: > > On Wed, 2012-07-11 at 17:00 +0100, Viresh Kumar wrote: > > > On 11 July 2012 14:32, Jon Medhurst (Tixy) wrote: > > > On Wed, 2012-07-11 at 10:57 +0100, Viresh Kumar wrote: > > > There's going to be an 'interesting' merge with our TC2 > > > enablement > > > branch. > > > > > > In arch/arm/kernel/topology.c both branches factor out > > > update_siblings_masks(), one of them modifies it. > > > > > > And in the same file, both branches also add functions called > > > parse_dt_topology() with different functionality. In the > > > resolution I'm > > > currently testing, I fixed this by renaming the version from > > > big-LITTLE-MP-v2 to parse_dt_for_cpu_capacity() as that seemed > > > an > > > accurate description of what it did. Is it tool late to also > > > do this in > > > the MP branch? > > > > > > > > > There are two patches doing the same thing (Vincent probably picked > > > this patch from Lorenzo and updated it a bit), > > > > The don't look like they are doing the same thing to me?!? > > > > Lorenzo's patch parses DT for cluster layout. > > > > Vincent's patch parses DT looking for CPU core type and frequency so it > > can set power/capaciy. > > > > I can see no overlap in the CPU node properties that they parse. > > > > Perhaps Lorenzo and Vincent can comment? > > You can drop my patch since it is not strictly needed on TC2. I have to > work out the conflict with Vincent's code, but again for now drop the > patch, it is safe to do that, topology is set-up according to the MPIDR > wiring and it is correct, at least on TC2. Thanks, I'll get onto that immediately then. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Power Meter
On 11 July 2012 02:32, Dave Pigott wrote: > Hey Zach, > > Very nice. Looking forward to having to make space for it in one of the racks. > > Are we going to be having more than one, and connected to different board > types? Just thinking about space planning. We may connect a software controlled power unit to it (so that we mux power to differenent boards). There's also laptop. Note the thing about cooling the box in the NI PXIe-1073 spec (it needs airflow). Also, this sucker is loud. :) > > Thanks > > Dave > > On 11 Jul 2012, at 03:17, Zach Pfeffer wrote: > >> Check out our new NI power meter: >> >> http://www.youtube.com/watch?v=JYRogshDyVo&feature=plcp >> >> We're gonna hook this thing up to LAVA. Its a pretty nice piece of equipment. >> >> Specs: >> NI PXIe-1073 with a NI PXIE-4154 Battery Simulator. >> >> -- >> 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 >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > -- 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Experimental big.LITTLE MP tree
On Wed, Jul 11, 2012 at 05:17:44PM +0100, Jon Medhurst (Tixy) wrote: > On Wed, 2012-07-11 at 17:00 +0100, Viresh Kumar wrote: > > On 11 July 2012 14:32, Jon Medhurst (Tixy) wrote: > > On Wed, 2012-07-11 at 10:57 +0100, Viresh Kumar wrote: > > There's going to be an 'interesting' merge with our TC2 > > enablement > > branch. > > > > In arch/arm/kernel/topology.c both branches factor out > > update_siblings_masks(), one of them modifies it. > > > > And in the same file, both branches also add functions called > > parse_dt_topology() with different functionality. In the > > resolution I'm > > currently testing, I fixed this by renaming the version from > > big-LITTLE-MP-v2 to parse_dt_for_cpu_capacity() as that seemed > > an > > accurate description of what it did. Is it tool late to also > > do this in > > the MP branch? > > > > > > There are two patches doing the same thing (Vincent probably picked > > this patch from Lorenzo and updated it a bit), > > The don't look like they are doing the same thing to me?!? > > Lorenzo's patch parses DT for cluster layout. > > Vincent's patch parses DT looking for CPU core type and frequency so it > can set power/capaciy. > > I can see no overlap in the CPU node properties that they parse. > > Perhaps Lorenzo and Vincent can comment? You can drop my patch since it is not strictly needed on TC2. I have to work out the conflict with Vincent's code, but again for now drop the patch, it is safe to do that, topology is set-up according to the MPIDR wiring and it is correct, at least on TC2. Thanks a lot, Lorenzo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Experimental big.LITTLE MP tree
On Wed, 2012-07-11 at 17:00 +0100, Viresh Kumar wrote: > On 11 July 2012 14:32, Jon Medhurst (Tixy) wrote: > On Wed, 2012-07-11 at 10:57 +0100, Viresh Kumar wrote: > There's going to be an 'interesting' merge with our TC2 > enablement > branch. > > In arch/arm/kernel/topology.c both branches factor out > update_siblings_masks(), one of them modifies it. > > And in the same file, both branches also add functions called > parse_dt_topology() with different functionality. In the > resolution I'm > currently testing, I fixed this by renaming the version from > big-LITTLE-MP-v2 to parse_dt_for_cpu_capacity() as that seemed > an > accurate description of what it did. Is it tool late to also > do this in > the MP branch? > > > There are two patches doing the same thing (Vincent probably picked > this patch from Lorenzo and updated it a bit), The don't look like they are doing the same thing to me?!? Lorenzo's patch parses DT for cluster layout. Vincent's patch parses DT looking for CPU core type and frequency so it can set power/capaciy. I can see no overlap in the CPU node properties that they parse. Perhaps Lorenzo and Vincent can comment? -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Experimental big.LITTLE MP tree
On 11 July 2012 14:32, Jon Medhurst (Tixy) wrote: > On Wed, 2012-07-11 at 10:57 +0100, Viresh Kumar wrote: > There's going to be an 'interesting' merge with our TC2 enablement > branch. > > In arch/arm/kernel/topology.c both branches factor out > update_siblings_masks(), one of them modifies it. > > And in the same file, both branches also add functions called > parse_dt_topology() with different functionality. In the resolution I'm > currently testing, I fixed this by renaming the version from > big-LITTLE-MP-v2 to parse_dt_for_cpu_capacity() as that seemed an > accurate description of what it did. Is it tool late to also do this in > the MP branch? There are two patches doing the same thing (Vincent probably picked this patch from Lorenzo and updated it a bit), So, you can probably drop below patch from linux-arm tree and try a merge. c5833d5 ARM: kernel: build CPU topology from DT I have tested this branch of mine, (big-LITTLE-MP-V2) with TC2 patches from linux-arm and MP task placement patches are working fine. (Obviously I dropped above mentioned patch) -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] cpuidle future and improvements
Daniel Lezcano writes: > On 06/18/2012 08:15 PM, Colin Cross wrote: >> On Mon, Jun 18, 2012 at 1:40 AM, Daniel Lezcano >> wrote: >>> I propose to host a cpuidle-next tree where all these modifications will >>> be and where people can send patches against, preventing last minutes >>> conflicts and perhaps Lenb will agree to pull from this tree. In the >>> meantime, the tree will be part of the linux-next, the patches will be >>> more widely tested and could be fixed earlier. >> >> My coupled cpuidle patches were acked and temporarily in Len's >> next/Linus pull branch, but were later dropped when the first pull >> request to Linus was rejected. I asked Len to either put the coupled >> cpuidle patches into his next branch, or let me host them so people >> could base SoC branches off of them and let Len pull them later, but >> got no response. If you do start a cpuidle for-next branch, can you >> pull my coupled-cpuidle branch: >> >> The following changes since commit 76e10d158efb6d4516018846f60c2ab5501900bc: >> >> Linux 3.4 (2012-05-20 15:29:13 -0700) >> >> are available in the git repository at: >> https://android.googlesource.com/kernel/common.git coupled-cpuidle >> >> Colin Cross (4): >> cpuidle: refactor out cpuidle_enter_state >> cpuidle: fix error handling in __cpuidle_register_device >> cpuidle: add support for states that affect multiple cpus >> cpuidle: coupled: add parallel barrier function >> >> drivers/cpuidle/Kconfig |3 + >> drivers/cpuidle/Makefile |1 + >> drivers/cpuidle/coupled.c | 715 >> + >> drivers/cpuidle/cpuidle.c | 68 - >> drivers/cpuidle/cpuidle.h | 32 ++ >> include/linux/cpuidle.h | 11 + >> 6 files changed, 813 insertions(+), 17 deletions(-) >> create mode 100644 drivers/cpuidle/coupled.c > > > Done. > > http://git.linaro.org/gitweb?p=people/dlezcano/cpuidle-next.git;a=shortlog;h=refs/heads/cpuidle-next Great! Daniel, thanks for tracking this. Are you planning to submit a pull request to Rafael so we finally can get this into linux-next and merged for v3.6? Looks like there will be a slight problem to sort out though. Len's 'next' branch[1] is already included in linux-next and as some version of the coupled CPUidle already merged. I hope we can sort this out in time for v3.6 because this series has been well reviewed, well tested and ready for merge since before the v3.5 merge window. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux next ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Experimental big.LITTLE MP tree
On Wed, 2012-07-11 at 10:57 +0100, Viresh Kumar wrote: > Hi Andrey, > > big-LITTLE-MP-v2 is ready to be pulled in. There's going to be an 'interesting' merge with our TC2 enablement branch. In arch/arm/kernel/topology.c both branches factor out update_siblings_masks(), one of them modifies it. And in the same file, both branches also add functions called parse_dt_topology() with different functionality. In the resolution I'm currently testing, I fixed this by renaming the version from big-LITTLE-MP-v2 to parse_dt_for_cpu_capacity() as that seemed an accurate description of what it did. Is it tool late to also do this in the MP branch? -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Experimental big.LITTLE MP tree
On 4 July 2012 16:09, Amit Kucheria wrote: > Hi all, > > Git Location: > http://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=summary > Branch: big-LITTLE-MP-v1 > > We're announcing a kernel tree to track the various topics of the > big.LITTLE MP project. The aim of this tree is to help consolidate the > various topic patchsets that improve the behaviour of Linux on > asymmetric cores (e.g. big.LITTLE) and make smarter scheduling > decisions possible in order to save power. I'd like to think of it as > a linux-next tree focused on asymmetric support enablement. > > Viresh will recreate this tree when new versions of the topic > patchsets are available. IOW, as the patches are reviewed on the lists > and go through iterations, we'll pull each topic patchset into a topic > branch (e.g. per-task-load-average-v2, arm-asymmetric-support-v3). > Then a merge tree will be created (e.g. big-LITTLE-MP-v1) as needed > based on the latest versions of these topics. This should allow users > to track individual topics or leave out some topics if they so desire. > More topics will be added to this tree as the work becomes available. > > Linaro platform team will take the merge branch (big-LITTLE-MP-v1, > -v2, etc.) and use it for platform enablement work and testing on real > hardware and models. > > Problems should be reported on LKML/LAKML as usual if they are related > to the individual topic trees. If they're related to a bad merge or > config enablement please report on linaro-dev@lists.linaro.org. Hi Andrey, big-LITTLE-MP-v2 is ready to be pulled in. Following is a pull request for it: --8<->8--- The following changes since commit bd0a521e88aa7a06ae7aabaed7ae196ed4ad867a: Linux 3.5-rc6 (2012-07-07 17:23:56 -0700) are available in the git repository at: git://git.linaro.org/arm/big.LITTLE/mp.git big-LITTLE-MP-v2 for you to fetch changes up to ca789c61deb0219cd3fefdb26090bbc9701deada: Merge branches 'arm-asymmetric-support-v3', 'cpuidle-next-v4', 'per-cpu-thread-hotplug-v2', 'task-placement-v1' and 'config-fragments' into big-LITTLE-MP-v3 (2012-07-11 10:51:29 +0100) Ben Segall (1): sched: maintain per-rq runnable averages Colin Cross (4): cpuidle: refactor out cpuidle_enter_state cpuidle: fix error handling in __cpuidle_register_device cpuidle: add support for states that affect multiple cpus cpuidle: coupled: add parallel barrier function Morten Rasmussen (5): sched: Add ftrace events for entity load-tracking sched: entity load-tracking load_avg_ratio sched: load-tracking driven wakeup migration for HMP platforms sched: Forced migration of high load task on HMP platforms sched: Add HMP forced task migration ftrace event Paul E. McKenney (1): rcu: Use smp_hotplug_thread facility for RCUs per-CPU kthread Paul Turner (15): sched: track the runnable average on a per-task entitiy basis sched: aggregate load contributed by task entities on parenting cfs_rq sched: maintain the load contribution of blocked entities sched: add an rq migration call-back to sched_class sched: account for blocked load waking back up sched: aggregate total task_group load sched: compute load contribution by a group entity sched: normalize tg load contributions against runnable time sched: maintain runnable averages across throttled periods sched: replace update_shares weight distribution with per-entity computation sched: refactor update_shares_cpu() -> update_blocked_avgs() sched: update_cfs_shares at period edge sched: make __update_entity_runnable_avg() fast sched: implement usage tracking sched: introduce temporary FAIR_GROUP_SCHED dependency for load-tracking Peter Zijlstra (1): sched, x86: Remove broken power estimation Thomas Gleixner (6): rcu: Yield simpler kthread: Implement park/unpark facility smpboot: Provide infrastructure for percpu hotplug threads softirq: Use hotplug thread infrastructure watchdog: Use hotplug thread infrastructure infiniband: ehca: Use hotplug thread infrastructure Vincent Guittot (4): ARM: topology: Add arch_scale_freq_power function ARM: topology: factorize the update of sibling masks ARM: topology: Update cpu_power according to DT information sched: cpu_power: enable ARCH_POWER Viresh Kumar (3): configs: Add config fragments for big LITTLE MP linaro/configs: Update big LITTLE MP fragment for task placement work Merge branches 'arm-asymmetric-support-v3', 'cpuidle-next-v4', 'per-cpu-thread-hotplug-v2', 'task-placement-v1' and 'config-fragments' into big-LITTLE-MP-v3 arch/arm/Kconfig | 29 + arch/arm/kernel/topology.c| 209 +++- arch/x86/kernel/cpu/Makefile |2 +- arch/x86/kernel/cpu/
Re: Power Meter
Hey Zach, Very nice. Looking forward to having to make space for it in one of the racks. Are we going to be having more than one, and connected to different board types? Just thinking about space planning. Thanks Dave On 11 Jul 2012, at 03:17, Zach Pfeffer wrote: > Check out our new NI power meter: > > http://www.youtube.com/watch?v=JYRogshDyVo&feature=plcp > > We're gonna hook this thing up to LAVA. Its a pretty nice piece of equipment. > > Specs: > NI PXIe-1073 with a NI PXIE-4154 Battery Simulator. > > -- > 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 > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
