Frederic Weisbecker writes:
> 2013/2/21 Frederic Weisbecker :
>> 2013/2/21 Kevin Hilman :
>>> Subject: [PATCH 2/5] kernel_cpustat: convert to atomic 64-bit accessors
>>>
>>> Use the atomic64_* accessors for all the kernel_cpustat fields to
>>> ensure atomic access on non-64 bit platforms.
>>>
>>>
On 11 February 2013 13:19, Viresh Kumar wrote:
> This is targetted for 3.10-rc1 or linux-next just after the merge window.
Hi Rafael,
I have pushed this patch again with the modifications/fixups i posted:
cpufreq-for-3.10
Also i have swapped patch 3 & 4, in case you decide to drop that Kconfig
On 22 February 2013 07:59, Rafael J. Wysocki wrote:
> On Friday, February 22, 2013 07:44:23 AM Viresh Kumar wrote:
>> If you don't like this one then we can add another entry
>> into struct policy like: gov_sysfs_parent.
>
> I don't know. This is going to look kind of ugly this way or another I
On 22 February 2013 08:03, Rafael J. Wysocki wrote:
> On Friday, February 22, 2013 07:47:44 AM Viresh Kumar wrote:
>> On 22 February 2013 05:15, Rafael J. Wysocki wrote:
>> > Why did you change all of the lines of this macro instead of changing just
>> > the
>> > one line you needed to change?
>
On 22 February 2013 05:05, Rafael J. Wysocki wrote:
> Why don't you use different values here?
>
> If you need only one value, one #define should be sufficient.
This is the fixup i have for this, I will push all patches again to
cpufreq-for-3.10 branch:
--
On Friday, February 22, 2013 07:47:44 AM Viresh Kumar wrote:
> On 22 February 2013 05:15, Rafael J. Wysocki wrote:
> > Why did you change all of the lines of this macro instead of changing just
> > the
> > one line you needed to change?
>
> I didn't like the indentation used within the macro. So
On 11 February 2013 13:20, Viresh Kumar wrote:
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> #define CPUFREQ_PRECHANGE (0)
> @@ -183,11 +197,10 @@ static inline unsigned long cpufreq_scale(unsigned long
> old, u_int div, u_int mu
> #define CPUFREQ_GOV_STOP 2
>
On Friday, February 22, 2013 07:44:23 AM Viresh Kumar wrote:
> On 22 February 2013 05:23, Rafael J. Wysocki wrote:
> > On Monday, February 11, 2013 01:20:02 PM Viresh Kumar wrote:
>
> >> +config CPU_FREQ_HAVE_MULTIPLE_POLICIES
> >> + bool
> >> +
> >
> > So I suppose some architectures will se
On 22 February 2013 07:51, Rafael J. Wysocki wrote:
> On Friday, February 22, 2013 07:38:12 AM Viresh Kumar wrote:
>> No. These are used atleast for ondemand & conservative.
>
> They will be after the next patch, you mean? :-)
> Well, it appeared so from the next patch ...
Yes :)
__
On 22 February 2013 05:15, Rafael J. Wysocki wrote:
> Why did you change all of the lines of this macro instead of changing just the
> one line you needed to change?
I didn't like the indentation used within the macro. So did it.
> Please don't do that.
Okay.
__
On Friday, February 22, 2013 07:38:12 AM Viresh Kumar wrote:
> On 22 February 2013 05:05, Rafael J. Wysocki wrote:
> > On Monday, February 11, 2013 01:20:00 PM Viresh Kumar wrote:
>
> >> This patch is inclined towards providing this infrastructure. Because we
> >> are
> >> required to allocate g
On 22 February 2013 05:23, Rafael J. Wysocki wrote:
> On Monday, February 11, 2013 01:20:02 PM Viresh Kumar wrote:
>> +config CPU_FREQ_HAVE_MULTIPLE_POLICIES
>> + bool
>> +
>
> So I suppose some architectures will select this, right?
Yes. And they have to enable have_multiple_policies too fr
On 22 February 2013 05:05, Rafael J. Wysocki wrote:
> On Monday, February 11, 2013 01:20:00 PM Viresh Kumar wrote:
>> This patch is inclined towards providing this infrastructure. Because we are
>> required to allocate governor's resources dynamically now, we must do it at
>> policy creation and
On Monday, February 11, 2013 01:20:02 PM Viresh Kumar wrote:
> have_multiple_policies is required by platforms having multiple clock-domains
> for cpus, i.e. supporting multiple policies for cpus. This patch adds in a
> Kconfig option for enabling execution of this code.
>
> Reported-by: Borislav
On Monday, February 11, 2013 01:20:03 PM Viresh Kumar wrote:
> We don't need to keep two structures for file attributes, global_attr and
> freq_attr. Lets use freq_attr only for cpufreq core and drivers.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/acpi-cpufreq.c | 9 -
> dri
On Monday, February 11, 2013 01:20:00 PM Viresh Kumar wrote:
> Currently, there can't be multiple instances of single governor_type. If we
> have
> a multi-package system, where we have multiple instances of struct policy (per
> package), we can't have multiple instances of same governor. i.e. We
2013/2/21 Russell King - ARM Linux :
> On Thu, Feb 21, 2013 at 10:53:07PM +0100, Frederic Weisbecker wrote:
>> That too should be kcpustat_this_cpu_set(), or kcpustat_this_cpu_add()
>> FWIW. But we probably don't need the overhead of atomic_add() that
>> does a LOCK.
>> atomic_set(var, atomic_read(
On Thu, Feb 21, 2013 at 10:53:07PM +0100, Frederic Weisbecker wrote:
> That too should be kcpustat_this_cpu_set(), or kcpustat_this_cpu_add()
> FWIW. But we probably don't need the overhead of atomic_add() that
> does a LOCK.
> atomic_set(var, atomic_read(var) + delta) would be better. All we need
2013/2/21 Frederic Weisbecker :
> 2013/2/21 Kevin Hilman :
>> Subject: [PATCH 2/5] kernel_cpustat: convert to atomic 64-bit accessors
>>
>> Use the atomic64_* accessors for all the kernel_cpustat fields to
>> ensure atomic access on non-64 bit platforms.
>>
>> Thanks to Mats Liljegren for CGROUP_CP
2013/2/21 Kevin Hilman :
> Subject: [PATCH 2/5] kernel_cpustat: convert to atomic 64-bit accessors
>
> Use the atomic64_* accessors for all the kernel_cpustat fields to
> ensure atomic access on non-64 bit platforms.
>
> Thanks to Mats Liljegren for CGROUP_CPUACCT related fixes.
>
> Cc: Mats Liljeg
Kevin Hilman writes:
> Use the atomic64_* accessors for all the kernel_cpustat fields to
> ensure atomic access on non-64 bit platforms.
>
> Thanks to Mats Liljegren for CGROUP_CPUACCT related fixes.
>
> Cc: Mats Liljegren
> Signed-off-by: Kevin Hilman
The kbuild test bot reported some build e
Namhyung Kim writes:
> Hi Kevin,
>
> On Wed, Feb 20, 2013 at 11:41:41AM -0800, Kevin Hilman wrote:
>> For the nsec resolution conversions to be useful on non 64-bit
>> architectures, do_div() needs to be used for the 64-bit divisions.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>> include/asm-gen
Hi Kevin,
On Wed, Feb 20, 2013 at 11:41:41AM -0800, Kevin Hilman wrote:
> For the nsec resolution conversions to be useful on non 64-bit
> architectures, do_div() needs to be used for the 64-bit divisions.
>
> Signed-off-by: Kevin Hilman
> ---
> include/asm-generic/cputime_nsecs.h | 51
> +
2013/2/20 Kevin Hilman :
> For the nsec resolution conversions to be useful on non 64-bit
> architectures, do_div() needs to be used for the 64-bit divisions.
>
> Signed-off-by: Kevin Hilman
> ---
The patch looks good. I'll run and apply it if everything's fine.
_
On 21 February 2013 16:34, Amit Kucheria wrote:
> I don't have a strong preference one way or another about switching
> from linaro-dev to linaro-kernel.
>
> Don't forget to update
> https://wiki.linaro.org/Resources/HowTo/Git/GitSendEmail
Done.
___
l
On Thu, Feb 21, 2013 at 4:27 PM, Viresh Kumar wrote:
> On 18 February 2013 23:50, Serge Broslavsky
> wrote:
>> On 18.02.13 12:20 -0500, Nicolas Pitre wrote:
>>> For the record, I think what Peter is suggesting is reasonable. There
>>> must be better ways for people to find out what Linaro is par
On 18 February 2013 23:50, Serge Broslavsky wrote:
> On 18.02.13 12:20 -0500, Nicolas Pitre wrote:
>> For the record, I think what Peter is suggesting is reasonable. There
>> must be better ways for people to find out what Linaro is participating in
>> other than scaring them away from linaro-dev
Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500
chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for
all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this designed
structure, other chip specific files can be added simply using the
Guenter,
Please check this v3 patches, thanks.
Anton Vorontsov and David Woodhouse,
Please have a look at this 1/3 and 2/3 patches, thanks.
v2 -> v3 changes:
- Add interface for converting voltage to temperature
- Remove temp5 sensor since we cannot offer temperature read interface of it
- Update
Make ab8500_btemp_get_temp() public, so that ab8500 hwmon driver can use it.
Signed-off-by: Hongbo Zhang
---
drivers/power/ab8500_btemp.c | 2 +-
include/linux/mfd/abx500/ab8500-bm.h | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/power/ab8500_btemp.c b/d
These NTC resistance to temperature tables should be public, so others such as
ab8500 hwmon driver can look up these tables to convert NTC resistance to
temperature.
Signed-off-by: Hongbo Zhang
---
drivers/power/ab8500_bmdata.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff
On Thursday 21 February 2013 02:31 PM, Daniel Lezcano wrote:
On 02/21/2013 07:19 AM, Santosh Shilimkar wrote:
On Tuesday 19 February 2013 11:51 PM, Daniel Lezcano wrote:
On 02/19/2013 07:10 PM, Thomas Gleixner wrote:
On Tue, 19 Feb 2013, Daniel Lezcano wrote:
I am working on identifying the d
On 02/21/2013 07:19 AM, Santosh Shilimkar wrote:
> On Tuesday 19 February 2013 11:51 PM, Daniel Lezcano wrote:
>> On 02/19/2013 07:10 PM, Thomas Gleixner wrote:
>>> On Tue, 19 Feb 2013, Daniel Lezcano wrote:
I am working on identifying the different wakeup sources from the
interrupts and
On my smp platform which is made of 5 cores in 2 clusters, I have the
nr_busy_cpu field of sched_group_power struct that is not null when the
platform is fully idle. The root cause seems to be:
During the boot sequence, some CPUs reach the idle loop and set their
NOHZ_IDLE flag while waiting for ot
34 matches
Mail list logo
