Hi!
> > pm_message_t meaning
> >
> > pm_message_t has two fields. event ("major"), and flags. If driver
> > does not know event code, it aborts the request, returning error. Some
> > drivers may need to deal with special cases based on the actual type
> > of suspend operation being done at the system level. This is why
> > there are flags.
> >
> > Event codes are:
>
> We absolutely need to do something about resume too btw... We need to
> know on resume at least if we are unfreezing after snapshot, or
> unfreezing after reboot/S4
That will need to be done, but it can wait... For now drivers should
always do full reinit. (Pretend unfreeze after reboot). Note: even
after reboot hardware may already be initialized if driver is
non-modular, so driver may not rely on hardware being in power-up state.
> > ON -- no need to do anything except special cases like broken
> > HW.
> >
> > FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from
> > scratch. That probably means stop accepting upstream requests, the
> > actual policy of what to do with them beeing specific to a given
> > driver. It's acceptable for a network driver to just drop packets
> > while a block driver is expected to block the queue so no request is
> > lost. (Use IDE as an example on how to do that). FREEZE requires no
> > power state change, and it's expected for drivers to be able to
> > quickly transition back to operating state.
>
> Wether resume has to re-init HW or not should be provided by some
> additional infos to resume, which is why I want to turn it into a
> pm_message_t too. Also, POST_RESUME should be sent to resume(), not to
> suspend().
Hmm, right, POST_RESUME sent as "suspend" message is really strange.
> > All events are:
> >
> > Prepare for suspend -- userland is still running but we are going to
> > enter suspend state. This gives drivers chance to load firmware from
> > disk and store it in memory. event = ON, flags = PREPARE_TO_SUSPEND
>
> Or do other activities taht require operating userland, ability to
> kmalloc GFP_KERNEL, etc... All of these are forbiden once the suspend
> dance is started.
How would you define this if you wanted to make it "event"? It does
not really change state of driver. State of driver is still ON, but
something alocated, etc.
Hmm, maybe that list-based callback is not so bad idea after
all. Because otherwise we'd need to deal with suspend / resume
nesting, and that looks ugly. Oops.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
