On 8 February 2013 05:03, Rafael J. Wysocki wrote:
> I should have done that before, sorry about it.
np
> Can you please rework this series on top of linux-pm.git/pm-cpufreq and
> try to avoid introducing new issues this time?
Sorry for this. I didn't got any such issues on my system and i trie
On 8 February 2013 04:37, Rafael J. Wysocki wrote:
> BTW, there still are locking problems in linux-next. Why do we need
> to take cpufreq_driver_lock() around driver->init() in cpufreq_add_dev(),
> in particular?
I thought a bit more and realized there is no such limitation on
cpufreq_driver->o
On 8 February 2013 01:09, Artem Savkov wrote:
> Tested out linux-pm.git/linux-next with this patches pulled. It seems
> that my systemd-sleep issue is fixed, however there is a new 'sleeping
> in invalid context' bug during boot:
>
> [ 12.736484] BUG: sleeping function called from invalid contex
On 8 February 2013 05:03, Rafael J. Wysocki wrote:
> I should have done that before, sorry about it.
>
> Can you please rework this series on top of linux-pm.git/pm-cpufreq and
> try to avoid introducing new issues this time?
Even i want to do that, but when i fetch your repo i don't see all appl
On 8 February 2013 04:37, Rafael J. Wysocki wrote:
> On Thursday, February 07, 2013 06:52:20 PM Viresh Kumar wrote:
>> On 7 February 2013 18:35, Rafael J. Wysocki wrote:
>> > I think they all make sense, so applied to linux-next.
>> >
>> > I would prefer not to make any more changes to cpufreq be
Postmortem and lessons learned for Linaro's release 2013.01
https://wiki.linaro.org/Cycles/1301/Release/Review
Highlights and Key Successes
http://www.linaro.org/downloads/1301
http://wiki.linaro.org/Cycles/1301/Release#Release_Information
For the first release of t
Hi, the cpufreq interactive governor computes the maximum target speed of
all CPUs of policy->cpus and sets that speed (at
cpufreq_interactive_speedchange_task). All platform layer cpufreq
implementations (that I know of) do the same thing underneath as well.
Todd
On Mon, Feb 4, 2013 at 3:36 A
On Friday, February 08, 2013 12:33:14 AM Rafael J. Wysocki wrote:
> On Thursday, February 07, 2013 03:57:42 PM Viresh Kumar wrote:
> > Hi Rafael,
> >
> > This is another unplanned patchset for all the platforms that i broke. :)
> >
> > Okay, there are two important fixes (1 & 4) and two general c
On Thursday, February 07, 2013 03:57:42 PM Viresh Kumar wrote:
> Hi Rafael,
>
> This is another unplanned patchset for all the platforms that i broke. :)
>
> Okay, there are two important fixes (1 & 4) and two general cleanups (2 & 3).
> I
> hope most of the issues would be resolved by these and
On Thursday, February 07, 2013 06:52:20 PM Viresh Kumar wrote:
> On 7 February 2013 18:35, Rafael J. Wysocki wrote:
> > I think they all make sense, so applied to linux-next.
> >
> > I would prefer not to make any more changes to cpufreq before v3.9 from now
> > on,
> > except for fixes and maybe
On 7 Feb 2013, at 21:15, Henry Cheang
mailto:henryche...@hotmail.com>> wrote:
Hello, I am running Foundation_v8 with images from Linaro as follows:
./Foundation_v8 --image=img-foundation.axf
--block-device=vexpress64-openembedded_sdk-armv8_20130127-242.img --network=nat
--network-nat-ports=80
Hello, I am running Foundation_v8 with images from Linaro as follows:
./Foundation_v8 --image=img-foundation.axf
--block-device=vexpress64-openembedded_sdk-armv8_20130127-242.img
--network=nat --network-nat-ports=8022=22
I noticed that often when I ssd or scp into the target (ssh -p 8022
This week Linaro held a virtual mini-summit for KVM/QEMU with major
stakeholders for the area participating in it. Main goal for the
mini-summit was to synchronize on the current state of the
Virtualization area, plans and work needed to be done.
As a result of this meeting, Linaro is publishing a
On 7 February 2013 18:35, Rafael J. Wysocki wrote:
> I think they all make sense, so applied to linux-next.
>
> I would prefer not to make any more changes to cpufreq before v3.9 from now
> on,
> except for fixes and maybe the Drik's patchset that I kind of scheduled for
Dirk :)
> merging into
On Thursday, February 07, 2013 03:57:42 PM Viresh Kumar wrote:
> Hi Rafael,
>
> This is another unplanned patchset for all the platforms that i broke. :)
>
> Okay, there are two important fixes (1 & 4) and two general cleanups (2 & 3).
> I
> hope most of the issues would be resolved by these and
In common clock framework (merged in 3.8-rc1) the directory
and attributes are changed, adapt to the new clock entries in
debugfs.
Signed-off-by: Sanjay Singh Rawat
---
clocks.c | 69 ++
1 file changed, 56 insertions(+), 13 deletions(
On Thursday 07 February 2013 04:01 PM, Amit Kucheria wrote:
On Thu, Feb 7, 2013 at 3:59 PM, Sanjay Singh Rawat
wrote:
For common clock framework directory and attributes are changed,
adapt to the new structure.
What version of the kernel did these changes happen in? It would be
useful to note
On Thu, Feb 7, 2013 at 3:59 PM, Sanjay Singh Rawat
wrote:
> For common clock framework directory and attributes are changed,
> adapt to the new structure.
What version of the kernel did these changes happen in? It would be
useful to note that in the commit message here.
> Signed-off-by: Sanjay S
For common clock framework directory and attributes are changed,
adapt to the new structure.
Signed-off-by: Sanjay Singh Rawat
---
clocks.c | 69 ++
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/clocks.c b/clocks.c
i
On multi-policy systems there is a single instance of governor for both the
policies (if same governor is chosen for both policies). With the code update
from following patches:
8eeed09 cpufreq: governors: Get rid of dbs_data->enable field
b394058 cpufreq: governors: Reset tunables only for
cpufr
cpufreq core uses two locks:
- cpufreq_driver_lock: General lock for driver and cpufreq_cpu_data array.
- cpu_policy_rwsemfix locking: per CPU reader-writer semaphore designed to cure
all cpufreq/hotplug/workqueue/etc related lock issues.
These locks were not used properly and are placed against
Because the sibling cpu of any online cpu is identified very early in
cpufreq_add_dev(), below code is never executed. And so can be removed.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/c
On the lines of macro: lock_policy_rwsem, we can create another macro for
unlock_policy_rwsem. Lets do it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/c
Hi Rafael,
This is another unplanned patchset for all the platforms that i broke. :)
Okay, there are two important fixes (1 & 4) and two general cleanups (2 & 3). I
hope most of the issues would be resolved by these and we would be able to push
clean cpufreq core into 3.9.
I have pushed them in
Anton and David,
Sorry there is a typo, symblols should be symbols, what's more I will
send v3 of this patch set, there should be more lines changed in this
ab8500_btemp.c, so let's focus on the coming v3 iteration.
Thanks.
On 6 February 2013 19:10, Hongbo Zhang wrote:
> Export ab8500_btemp_get a
On 7 February 2013 01:54, Guenter Roeck wrote:
> On Wed, Feb 06, 2013 at 07:10:38PM +0800, Hongbo Zhang wrote:
>> 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 ab85
26 matches
Mail list logo
