lkml.org 
[lkml]   [2010]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Attempted summary of suspend-blockers LKML thread, take three
On Thu, Aug 12, 2010 at 07:46:03PM +0300, Felipe Contreras wrote:

> All the Android community had to do is push the drivers *without*
> suspend blockers, then the Android kernel wouldn't be so different and
> thus wouldn't be considered a fork. AFAIU the kernel side wakelocks
> are already in the kernel, so there's no excuse not to merge the
> drivers.

What's there is not good enough, because it's missing the statistics
and reporting so that badly behaved kernel and userspace drivers that
take wakelocks can be found.

I have a similar problem with the whole pm_qos subsystem, as I've said
earlier. If some badly behaved application claims to want 0us
wireless latency, and keeps the radio on all the time, there is no way
for me to find out which is the badly behaved application --- even
though I'm the owner of the laptop, and at the end of the day *I*
should be able to say, no, battery lifetime is more important than
what the application might think is its "minimum wireless latency".
Not only can I not override the application, I can't even find out
which application is at fault! ***FAIL***

In some ways, this is exactly the same problem as the "which badly
Maemo application is causing my causing my N770 to have its battery
laptop drop in half?".

- Ted


\
 
 \ /
  Last update: 2010-08-12 20:25    [from the cache]
©2003-2011 Jasper Spaans