On 19 August 2013 16:57, Viresh Kumar wrote:
> It wasn't my patch actually.. It only made it visible that's it :)
> The problem is:
> - On suspend all CPUs are removed and so governors are
> stopped.
> - On resume, handle_update() is called for the boot cpu and
> cpu_add_dev for all others.
>
> ha
On 20 August 2013 04:52, Rafael J. Wysocki wrote:
> From my experience, however, it is good to figure out what needs to be
> included
> into your test kernel and configure away everything else. Also, I'd recommend
> to build as much as possible into the kernel image and avoid compiling too
> ma
On 19 August 2013 17:15, Amit Kucheria wrote:
> Why do you create .deb packages to test development kernels? It _is_ slow.
>
> Instead I'd just add a new grub menu entry to /boot/grub/grub.cfg and
> point it to /boot/MyzImage. After a 'make install; make
> modules_install' just link /boot/MyzImage
On Monday, August 19, 2013 04:57:19 PM Viresh Kumar wrote:
> On 18 August 2013 19:36, Rafael J. Wysocki wrote:
>
> > I noticed that the current linux-next branch of linux-pm.git caused the
> > BUG_ON() in lock_policy_rwsem_##mode() to trigger when user space tried to
> > access cpufreq sysfs attr
On Mon, Aug 19, 2013 at 4:57 PM, Viresh Kumar wrote:
> Testing anything on my thinkpad (with ubuntu) is a pain.. it takes
> more than an hour to compile/test a single image... I currently follow
> below steps for doing that, don't know if something much
> simpler/faster is available :)
>
> https:
On 18 August 2013 19:36, Rafael J. Wysocki wrote:
> I noticed that the current linux-next branch of linux-pm.git caused the
> BUG_ON() in lock_policy_rwsem_##mode() to trigger when user space tried to
> access cpufreq sysfs attributes before system suspend and after system
> resume.
Hmm...
> I
On Tuesday, August 06, 2013 10:53:09 PM Viresh Kumar wrote:
> For iterating over all policies currently we are iterating over all CPUs and
> then finding their policies. Lets use the newly created infrastructure
> cpufreq_policy_list.
>
> Signed-off-by: Viresh Kumar
I noticed that the current li
For iterating over all policies currently we are iterating over all CPUs and
then finding their policies. Lets use the newly created infrastructure
cpufreq_policy_list.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
dif
8 matches
Mail list logo
