Re: device model documentation 2/3

Re: device model documentation 2/3

[Pavel Machek]

Hi!

> > > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > > stops transactions, or what it should do with unfinished transactions
> > > is a policy of the driver. After this call, the driver should not
> > > accept any other I/O requests.
> > 
> > Does this mean that memory allocations in the suspend/resume
> > implementations must be made with GFP_NOIO respectively
> > GFP_ATOMIC ?
> > It would seem so.
> 
> Why would you allocate memory on a resume transition? 
> 
> As for suspending, this is something that has been discussed a few times 
> before. No definitive decision has come out of it because it hasn't been 
> implemented yet. It hasn't been implemented yet because the infrastructure 
> isn't complete. It's real close, but still not quite there. 

swsusp works for me (tm). SO structure should be there ;-)

> Nonetheless, you have to do one of a couple things: use GFP_NOIO or
> special case the swap device(s) so they don't stop I/O when everything
> else does. (Of course, you have to eventually stop it)

Special casing swap is not enough -- you can well have memory full of data
for regular filesystem.

								Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: device model documentation 2/3

[Oliver Neukum]

> Whether suspend is called with a given level is a policy of the
> platform. Some levels may be omitted; drivers must not assume the
> reception of any level. However, all levels must be called in the
> order above; i.e. notification will always come before disabling;
> disabling the device will come before suspending the device.
>
> All calls are made with interrupts enabled, except for the
> SUSPEND_POWER_DOWN level.

This is a slight problem for USB. We need to switch on interupts
to send a message to the device. Is this provided for ?

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: device model documentation 2/3

[Oliver Neukum]

> SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> stops transactions, or what it should do with unfinished transactions
> is a policy of the driver. After this call, the driver should not
> accept any other I/O requests.

Does this mean that memory allocations in the suspend/resume
implementations must be made with GFP_NOIO respectively
GFP_ATOMIC ?
It would seem so.

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: device model documentation 2/3

[Patrick Mochel]

On Wed, 5 Jun 2002, Oliver Neukum wrote:

> 
> > Whether suspend is called with a given level is a policy of the
> > platform. Some levels may be omitted; drivers must not assume the
> > reception of any level. However, all levels must be called in the
> > order above; i.e. notification will always come before disabling;
> > disabling the device will come before suspending the device.
> >
> > All calls are made with interrupts enabled, except for the
> > SUSPEND_POWER_DOWN level.
> 
> This is a slight problem for USB. We need to switch on interupts
> to send a message to the device. Is this provided for ?

Well, it all depends on what you want to do with USB devices during a 
suspend transition. I missed some of the discussion in the last few days, 
and I know you guys talked about it a little (I'm on the hotplug list, but 
I don't always pay attention ;) It's also been talked about before, though 
I don't think anything has come out of it. 

IIRC, USB device state won't be saved across power transitions. It will 
look like a "disconnect", and "reconnect" on resume. (Forgive me if that's 
not the right USB terminology; I'm just guessing). In that case, when the 
controller gets the SUSPEND_DISABLE call, it can shutdown all the 
devices, and you're done. Right?

	-pat


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: device model documentation 2/3

[Patrick Mochel]

On Wed, 5 Jun 2002, Oliver Neukum wrote:

> 
> > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > stops transactions, or what it should do with unfinished transactions
> > is a policy of the driver. After this call, the driver should not
> > accept any other I/O requests.
> 
> Does this mean that memory allocations in the suspend/resume
> implementations must be made with GFP_NOIO respectively
> GFP_ATOMIC ?
> It would seem so.

Why would you allocate memory on a resume transition? 

As for suspending, this is something that has been discussed a few times 
before. No definitive decision has come out of it because it hasn't been 
implemented yet. It hasn't been implemented yet because the infrastructure 
isn't complete. It's real close, but still not quite there. 

Nonetheless, you have to do one of a couple things: use GFP_NOIO or
special case the swap device(s) so they don't stop I/O when everything
else does. (Of course, you have to eventually stop it)

Check the archives; there are lots of ideas there wrt this topic. But, 
there are bigger fish to fry in the meantime ;)

	-pat


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: device model documentation 2/3

[Oliver Neukum]

> IIRC, USB device state won't be saved across power transitions. It will
> look like a "disconnect", and "reconnect" on resume. (Forgive me if that's
> not the right USB terminology; I'm just guessing). In that case, when the
> controller gets the SUSPEND_DISABLE call, it can shutdown all the
> devices, and you're done. Right?

IIRC some USB devices can do power saving. At least the pwc module
has a module parameter to that effect.

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: device model documentation 2/3

[Oliver Neukum]

Am Mittwoch, 5. Juni 2002 21:11 schrieb Patrick Mochel:
> On Wed, 5 Jun 2002, Oliver Neukum wrote:
> > > SUSPEND_DISABLE tells the device to stop I/O transactions. When it
> > > stops transactions, or what it should do with unfinished transactions
> > > is a policy of the driver. After this call, the driver should not
> > > accept any other I/O requests.
> >
> > Does this mean that memory allocations in the suspend/resume
> > implementations must be made with GFP_NOIO respectively
> > GFP_ATOMIC ?
> > It would seem so.
>
> Why would you allocate memory on a resume transition?

We need to send messages to the device to restore state, don't we ?
Any activity on USB can allocate memory. We've had to change the API
to fix deadlock problems due to this already.

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel