[lkml]   [2001]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] New Driver Model for 2.5
    >> I forgot to mention to disable interrupts after the SUSPEND_NOTIFY call.
    >> The idea is to allocate all memory in the first pass, disable interrupts,
    >> then save state. Would that work? Or, should some of the state saving take
    >> place with interrupts enabled?
    >That looks ugly, because you'd need to add DONT_SUSPEND_NOTIFY, called
    >when SUSPEND_NOTIFY fails.
    > Pavel

    No, interrupts have to be shut down between SUSPEND_SAVE_STATE and
    SUSPEND_POWER_DOWN, I beleive.

    SUSPEND_SAVE_STATE must run with interrupts enabled, as it's supposed
    to both block new incoming IOs and wait for pending ones to complete (*).
    It would be sub-efficient to force drivers to implement polled IOs for
    this case.

    SUSPEND_POWER_DOWN itself should perfectly be able to run with interrupts
    disabled, I beleive, as must of the actual suspend sequence can be done
    in SUSPEND_SAVE_STATE on most chips.

    There is no problem with failure there. Just call RESUME_POWER_ON if
    SUSPEND_POWER_DOWN failed (or later), then RESUME_RESTORE_STATE in
    all cases. The driver knows from which state it comes from anyway,
    and we don't have, I beleive, that strick VM need of separating
    suspend from free's. Well... let's think more about it... we might
    actually need to allocate memory in RESUME_RESTORE_STATE to create
    new requests or whatever the driver need... but we can also do that
    earlier, inside SUSPEND_NOTIFY (or just use whatever memory we
    pre-allocated to save state). So it might make sense to have the
    resume process be an exact mirror of the wakeup one, or not, maybe
    just a matter of taste.

    In most cases, keep in mind that most drivers won't need to implement
    all of these.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:18    [W:0.022 / U:6.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site