[lkml]   [2010]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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    [W:0.023 / U:56.376 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site