Re: Problems with PM_FREEZE

[Nigel Cunningham <ncunningham@cyclades.com>]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

Hi.

On Wed, 2005-09-28 at 08:01, Pavel Machek wrote:
> Hi!
> 
> > > > > Later on, when the system wakes up and the image is restored, drivers are 
> > > > > asked to resume the devices.  The problem is that now the drivers think 
> > > > > the devices are in FREEZE when in fact they are really in SUSPEND.  The 
> > > > > difference is significant and it can cause errors in the resume procedure.
> > > > 
> > > > No; devices are in FREEZE if their driver was in kernel, and in some kind
> > > > of power up state when not. Drivers should just handle both.
> > > 
> > > For USB, that "some kind of power up state" will in fact be SUSPEND.
> > 
> > Excuse me taking a step back, but I think you guys might be solving a
> > problem that doesn't exist...
> > 
> > How do USB drivers get into a suspend state? At suspend time, before the
> > atomic copy is made they have been told to FREEZE. At resume time, prior
> > to the atomic restore, they have been told to FREEZE. The state
> 
> They have been told to freeze _if you have usb built in_, and not
> modular. Imagine kernel with usb as a module, doing resume from kernel
> command line. usb will be in "just powered on" state.

Yes, that's true. If the usb modules are loaded when suspending and not
loaded when resuming or vice versa, you'll get inconsistencies:

State at suspend	State at resume		Image state

Built in		Built in		Freeze->Freeze
Loaded modules		Unloaded modules	Undefined->Freeze
Unloaded modules	Loaded modules		Freeze->Undefined

I guess there are three possible solutions:
1) Leave things as they are and say it is the user's problem if they
make the state inconsistent.
2) Keep knowledge of the device states across the atomic restore and use
that information in deciding what to do in device resume/powerup.
3) Make device drivers handle the situation properly without knowledge
of what state the hardware is really in (or check the real state - where
possible - and rely on that in deciding what to do).

2 seems to me to make for the most reliable solution.

Regards,

Nigel
> 								Pavel
-- 



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]