Re: Problems with PM_FREEZE

[Pavel Machek <pavel@ucw.cz>]

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

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.

								Pavel

-- 
if you have sharp zaurus hardware you don't need... you know my address

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