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
We are using a generic abx500 hwmon layer, so rename specific ab8500 to generic
abx500 for hwmon device and driver matching.
Signed-off-by: Hongbo Zhang
---
drivers/mfd/ab8500-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd
I am starting to follow cpufreq patches religiously now and so have to come
back to this old thread due to some crash we got :)
Its still not pushed upstream, so better to get it resolved before 3.9.
On Thu, Dec 27, 2012 at 8:25 PM, Fabio Baltieri
wrote:
> diff --git a/drivers/cpufreq/cpufreq_g
On Wed, 2013-01-30 at 12:52 +0800, Viresh Kumar wrote:
> Hi Fabio,
>
> Sorry for waking up very late :)
>
> The reason why i am starting this thread again is due to problem
> reported by Joseph,
> with latest linux-next/master branch (which contains few big patches
> from me :) ):
>
After Viresh
Hi Fabio,
Sorry for waking up very late :)
The reason why i am starting this thread again is due to problem
reported by Joseph,
with latest linux-next/master branch (which contains few big patches
from me :) ):
Reboot is giving following to him:
* Will now halt
[ 193.756068] Disabling non-boot
On 30 January 2013 03:15, Rafael J. Wysocki wrote:
> Please don't add my sign-offs in advance. Yes, I have signed off a *previous*
> version of that patch, but that doesn't apply to *this* version automatically.
>
> While you can do such things with Acked-by or Reviewed-by tags (that's not
> ver
On Tuesday, January 29, 2013 08:00:23 PM Viresh Kumar wrote:
> On 29 January 2013 17:21, Rafael J. Wysocki wrote:
> > On Tuesday, January 29, 2013 10:09:59 AM Viresh Kumar wrote:
> >> With the addition of following patch, related_cpus is required to be set by
> >> cpufreq platform drivers:
> >>
>
On Tuesday, January 29, 2013 08:09:08 PM Viresh Kumar wrote:
> Currently cpufreq_add_dev() firsts allocates policy, calls driver->init() and
> then checks if this cpu is already managed or not. And if it is already
> managed,
> free its policy.
>
> We can save all this if we somehow know cpu is m
Currently cpufreq_add_dev() firsts allocates policy, calls driver->init() and
then checks if this cpu is already managed or not. And if it is already managed,
free its policy.
We can save all this if we somehow know cpu is managed or not in advance.
policy->related_cpus contains list of all valid
On 29 January 2013 17:21, Rafael J. Wysocki wrote:
> On Tuesday, January 29, 2013 10:09:59 AM Viresh Kumar wrote:
>> With the addition of following patch, related_cpus is required to be set by
>> cpufreq platform drivers:
>>
>> commit c1070fd743533efb54e98142252283583f379190
>> Author: Viresh Kuma
> Hi -
>
> We added a bunch of thermal-related bits (different from the thermal bits
> that Linaro PM guys got upstream) to the tilt- kernels. It's support for
> their thermal sensor and TI's "thermal framework" which monitors it and
> messes with the cpu frequency limit.
:) Upstreamed and seen
On Tuesday, January 29, 2013 10:09:59 AM Viresh Kumar wrote:
> With the addition of following patch, related_cpus is required to be set by
> cpufreq platform drivers:
>
> commit c1070fd743533efb54e98142252283583f379190
> Author: Viresh Kumar
> Date: Mon Jan 14 13:23:04 2013 +
>
> cpufr
On 29 January 2013 16:08, Vincent Guittot wrote:
> The nr_busy_cpus field of the sched_group_power is sometime different from 0
> whereas the platform is fully idle. This serie fixes 3 use cases:
> - when some CPUs enter idle state while booting all CPUs
> - when a CPU is unplug and/or replug
P
The function nohz_kick_needed modifies NOHZ_IDLE flag that is used to update
the nr_busy_cpus of the sched_group.
When the sched_domain are updated (during the boot or because of the unplug of
a CPUs as an example) a null_domain is attached to CPUs. We have to test
likely(!on_null_domain(cpu) first
The nr_busy_cpus field of the sched_group_power is sometime different from 0
whereas the platform is fully idle. This serie fixes 3 use cases:
- when some CPUs enter idle state while booting all CPUs
- when a CPU is unplug and/or replug
Change since V1:
- remove the patch for SCHED softirq on a
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 oth
On Mon, 2013-01-28 at 14:32 +0800, Chao Xie wrote:
> hi
> I have seen in the arm website that arm release the VE 5.0. THere is a
> patch named "CPU Migration Patch for version 5.0" for cpu migration.
> Now i have downloaded the source code from
> git.linaro.org/git-ro/landing-teams/working/arm/kern
17 matches
Mail list logo
