[lkml]   [2004]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Help port swsusp to ppc.
    On Tue, 2004-01-20 at 04:56, Nigel Cunningham wrote:
    > Hi.
    > On Tue, 2004-01-20 at 00:39, Benjamin Herrenschmidt wrote:
    > > I see no reason why this would be needed on ppc, only the last step,
    > > that is the actual CPU state save, should matter.
    > Besides saving the CPU state, the code copies the original kernel back.
    > It sort of defeats the purpose to remove that code :>

    Ok, you mean copying the memory pages back down ? That should be done
    with hand-made assembly or C code located specifically elsewhere then.
    I do not want to see any kind of this ugly C-generated assembly in

    > Well, the whole things is pretty hairy :> But I don't think there's
    > anything wrong with assuming the boot and restored kernels are
    > identical. After all, we're calling it suspending and resuming, not
    > kexec. It does sound nice to do it all from the bootloader without
    > kernel help.

    I think that's a wrong assumption. I see personally _NO_ reason to
    assume the boot and restored kernel are the same. They absolutely
    don't need to do at all.

    > It is a well defined interface: a section of memory marked nosave, with
    > variables given the matching attribute. Not my idea, by the way. If you
    > have a problem, you should be taking it up with Pavel or Linus. We
    > should also note that the interface can't be too well defined - there
    > has to be room for development over time.

    Still... That makes assumptions about how it's located and organised
    that plain wrong (c). Please get rid of that, at least I won't let a PPC
    version do that. Depending on how much time I can spare, I'll try to
    work on that PPC port later this week. If you need something like clock
    calibration data down to the loaded kernel, then either re-calculate it
    in the wakeup code path, or pass it via some _sane_ interface (at
    _least_ a versioned data structure, better, a tagged list of values like
    some bootloaders do).

    > Yes. we device_suspend. Regarding the similarities with kexec, I fully
    > agree. In fact, there is also LKCD to think off. There should be a
    > synergy here.

    device_suspend is, imho, hairy too. We have some semantics that need
    cleanup here, I'll have to talk to Patrick about them. Putting devices
    to an idle state is what you need and what kexec need, and doesn't mean
    putting them to _sleep_. Or maybe we could pass a specific state to
    device_suspend for that. For example, it makes little sense to spin down
    the hard disk at this stage, or to power off the video chip...


    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 14:00    [W:0.046 / U:63.836 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site