On Mon, 2008-04-14 at 01:08 +0200, Rafael J. Wysocki wrote: > > Well, if we put ->prepare() before the freezer, what can it actually do? > Certainly nothing that will block any (user space) task, because the freezer > won't work after that. So, all of the significant suspend work, like blocking > tasks using the device etc., will have to be done by ->suspend(). Will that be > convenient? I'm not sure. I'm not even sure that would be _doable_ at all. Most of the actual suspending of requests queues etc... has to be done in suspend. Nothing changed here. I don't see why it would change. prepare() is a way to preallocate things when needed, cache things when needed, etc... and possibly interact user space. At least that how I see it. It -is- acceptable to stop servicing user space after prepare() in some well defined cases such as the DRM, as long as in-kernel users aren't affected. But that's not necessarily what I have in mind. In the case us userspace for example, the idea here is to perform the migration of all the dirty data in the VRAM (that will be lost during suspend) out to main memory (or AGP memory). That doesn't mean necessarily that the DRM will stop servicing anything from there, it can still perform things. It might mean that user space would have to disable some accelerations that rely on dirty data in VRAM though until complete() is called. > The point of view depends on what you think ->prepare() should be used for > and I'm sure you have some specific cases in mind. However, are they generic > enough? request_firmware() & caching the resulting firmware so that the driver can resume & start operating right away is an example (think about NFS over wireless here for example, or iSCSI). the DRM example above. In general, any driver that needs to interact with user space, perform large allocations, muck around with the VM, etc... prepare() isn't intended to stop operations, but to preload/cache/prepare and have userspace available for drivers where this is needed. In some case, that might need the driver will continue operating in some degraded mode (for example, a multiqueue driver can degrade to a single queue with one pre-allocated request to avoid relying on allocations). I would expect most simple drivers not to need it of course. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
