Hi Viresh,
On Tue, Oct 23, 2012 at 10:55:51AM +0530, Viresh Kumar wrote:
> Hi Fengguang,
>
> Thanks for your mail. Few things i learnt from it:
> - Rafael has already applied my patches :)
> - I haven't used sparse in my life till this point. Now i know how to use it.
Good to know that! :-)
> O
Hi Francesco,
I found out more points about this issue.
[1]
cdev should be ready when get_max_state callback be called, otherwise
parameter cdev is useless, imagine there may be cases that
get_max_state call back is shared by more than one cooling devices of
same kind, like this:
common_get_max_st
>> diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
>> index bf02225..ff64dd4 100644
>> --- a/drivers/power/ab8500_fg.c
>> +++ b/drivers/power/ab8500_fg.c
>> @@ -22,15 +22,16 @@
[...]
>>
>> #define MILLI_TO_MICRO 1000
>> #define FG_LSB_IN_MA
Hi all,
Due to Amazon EC2/EBS issues last night, ci.linaro.org and
android-build.linaro.org have been partially unresponsive.
While everything is supposed to be back already, we are hitting problems
with Amazon EC2 capacity, which jenkins doesn't handle in the most
graceful way.
We apologize for
A checkpoint for the big.LITTLE MP project.
Delivered Cards
http://cards.linaro.org/browse/CARD-34
http://cards.linaro.org/browse/CARD-35
Delivered Blueprints
==
https://blueprints.launchpad.net/linaro-power-kernel/+spec/sched-add-asymmetric-cpu-s
Greetings All,
More and more of people are getting interested in the subject of power
(energy) consumption monitoring. We have some external tools like
"battery simulators", energy probes etc., but some targets can measure
their power usage on their own.
Traditionally such data should be exposed
On 10/23/12 19:30, the mail apparently from Pawel Moll included:
Greetings All,
More and more of people are getting interested in the subject of power
(energy) consumption monitoring. We have some external tools like
"battery simulators", energy probes etc., but some targets can measure
their po
Hey everyone!
Just wanted to send out a remote participation invite to our upcoming
Linaro Connect (or in-person participation if you can manage it). All
of these sessions will support remote participation via IRC and Google
Hangouts, so you can be part of the action, even if you're not in
Copenha
Hi,
On 10/23/2012 10:23 AM, Hongbo Zhang wrote:
> Hi Francesco,
> I found out more points about this issue.
>
> [1]
> cdev should be ready when get_max_state callback be called, otherwise
> parameter cdev is useless, imagine there may be cases that
> get_max_state call back is shared by more than
Hi,
On 10/23/2012 11:20 AM, Rajanikanth HV wrote:
>>> diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
>>> index bf02225..ff64dd4 100644
>>> --- a/drivers/power/ab8500_fg.c
>>> +++ b/drivers/power/ab8500_fg.c
>>> @@ -22,15 +22,16 @@
> [...]
>>>
>>> #define MILLI_TO_MICRO
On Tue, 2012-10-23 at 18:30 +0100, Pawel Moll wrote:
>
> === Option 1: Trace event ===
>
> This seems to be the "cheapest" option. Simply defining a trace event
> that can be generated by a hwmon (or any other) driver makes the
> interesting data immediately available to any ftrace/perf user. Of
On Tue, Oct 23, 2012 at 06:30:49PM +0100, Pawel Moll wrote:
> Greetings All,
>
> More and more of people are getting interested in the subject of power
> (energy) consumption monitoring. We have some external tools like
> "battery simulators", energy probes etc., but some targets can measure
> the
Please take a look at:
https://wiki.linaro.org/Platform/Android/Meetings/2012-10-24
Feel free to add to the agenda and join us in #linaro-meeting on
irc.freenode.net at 13:00 UTC on 2012/10/24.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software f
On Tuesday 23 of October 2012 10:55:51 Viresh Kumar wrote:
> Hi Fengguang,
>
> Thanks for your mail. Few things i learnt from it:
> - Rafael has already applied my patches :)
Yes, I have. I didn't have the time to let all the people whose patches
were applied know individually, however.
> - I h
Hi,
On Tuesday, October 23, 2012 06:30:49 PM Pawel Moll wrote:
> Greetings All,
>
> More and more of people are getting interested in the subject of power
> (energy) consumption monitoring. We have some external tools like
> "battery simulators", energy probes etc., but some targets can measure
>
Hi,
On Tuesday, October 23, 2012 06:30:49 PM Pawel Moll wrote:
> Greetings All,
>
> More and more of people are getting interested in the subject of power
> (energy) consumption monitoring. We have some external tools like
> "battery simulators", energy probes etc., but some targets can measure
>
On 24 October 2012 06:13, Francesco Lavra wrote:
> Hi,
> On 10/23/2012 10:23 AM, Hongbo Zhang wrote:
>> Hi Francesco,
>> I found out more points about this issue.
>>
>> [1]
>> cdev should be ready when get_max_state callback be called, otherwise
>> parameter cdev is useless, imagine there may be c
When working on low level kernel code, the indication that something
went wrong is often noticed as a kernel oops, or even a totally silent
system. This usually implies a modify-recompile-reboot cycle which can
become very very annoying if the reboot step implies popping out an SD
card from t
On 23 October 2012 02:51, Francesco Lavra wrote:
> On 10/22/2012 02:02 PM, Hongbo Zhang wrote:
> [...]
+static irqreturn_t prcmu_low_irq_handler(int irq, void *irq_data)
+{
+ struct db8500_thermal_zone *pzone = irq_data;
+ struct db8500_thsens_platform_data *ptrips;
>>>
On 22 October 2012 14:16, Viresh Kumar wrote:
> On 20 October 2012 01:42, Viresh Kumar wrote:
>> Initially ondemand governor was written and then using its code conservative
>> governor is written. It used a lot of code from ondemand governor, but copy
>> of
>> code was created instead of using
On 24 October 2012 06:03, Rafael J. Wysocki wrote:
> On Tuesday 23 of October 2012 10:55:51 Viresh Kumar wrote:
>> @Rafael: Most of these are due to mixed use of u64 and cputime64_t. Both of
>> which are u64 if i am not wrong. Any specific reason that we used cputime64_t
>> instead of u64? Or can
Nice article!
On 24 October 2012 08:26, Nicolas Pitre wrote:
>
> When working on low level kernel code, the indication that something
> went wrong is often noticed as a kernel oops, or even a totally silent
> system. This usually implies a modify-recompile-reboot cycle which can
> become very ve
22 matches
Mail list logo
