lkml.org 
[lkml]   [2010]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
    Thomas Gleixner <tglx@linutronix.de> wrote:

    > On Tue, 1 Jun 2010, Neil Brown wrote:
    > > And if you are right that the race window cannot be closed, then the whole
    > > suspend-blocker infrastructure is pointless as the purpose of it is simply to
    > > close that window. If it really does not and cannot work, then it would be
    > > best to reject it for that reason rather than for less concrete aesthetic
    > > arguments.
    > > But presumably it does work in practice on Android hardware so ..... confused.
    > >
    > > Having just seen the email from Thomas, maybe you mean that it cannot be
    > > closed on devices using ACPI, but can on other devices. I can sort-of
    > > imagine how that would be the case (I tried reading an ACPI spec once - my
    > > hat is of to those of you who understand it).
    > > That shouldn't prevent us from closing the race window on "sane" hardware
    > > that allows it. This would, I think, be sufficient for Android's needs.
    > >
    > > I'm hoping we can get agreement on:
    > > - there is a race with suspend
    >
    > That's a matter of how you define "suspend".

    I define "suspend" as

    echo mem > /sys/power/state

    >
    > If "suspend" is another deep idle state and the hardware is sane,
    > there is no race at all - assumed that the driver/platform developer
    > got it right. It's not rocket science to transition from "normal" irq
    > delivery to wakeup based delivery raceless (except for PC style x86
    > hardware of today)
    >
    > If "suspend" is the thing we are used to via /sys/power/state then the
    > race will persist forever except for the suspend blocker workaround,
    > which we can express in QoS terms as well w/o adding another suspend
    > related user space API.

    I'm not interested in adding another user-space API if it can possibly be
    avoided, and I think it can. But that is a later step in the process.

    I think you have acknowledged that there is a race with suspend - thanks.
    Next step was "can it be closed".
    You seem to suggest that it can, but you describe it as a "work around"
    rather than a "bug fix"...

    Do you agree that the race is a "bug", and therefore it is appropriate to
    "fix" it assuming an acceptable fix can be found (which I think it can)?

    If you agree that it is appropriate for try to fix this bug, then the next
    step would be to get the Android devs to agree that a fix could - in
    principle - address the need for which they created suspend-blockers.
    Arve: can you confirm that?

    Then, with a clear and agreed goal, we can look at possible fixes.

    Thanks,
    NeilBrown

    >
    > Thanks,
    >
    > tglx



    \
     
     \ /
      Last update: 2010-06-01 04:23    [W:4.287 / U:23.640 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site