Messages in this thread | | | Subject | Re: Totally broken PCI PM calls | From | Benjamin Herrenschmidt <> | Date | Tue, 12 Oct 2004 21:27:58 +1000 |
| |
> > In the first case, it makes even sense to keep the driver operating > > while the device is D1, the driver would then just wake the device on an > > incoming request (provided this is allowed by the policy). In the later > > case, the driver state is the only thing that matters. > > Not quite - you have to be able to get the device into a matching state > at resume time. Probably not a problem in most cases, I realise, but > thought it was worth a mention.
Wait, I'm not talking about swsusp here, that's exactly my distinction between driver state and device state :) Only system suspend like swsusp and suspend-to-ram require a completely coherent and frozen memory "image".
All sorts of dynamic PM, including system-wide "idle" can deal with scenarios where the driver can stay functional and decide by itself to wake up the device upon incoming requests.
> [...] > > > Yup, with the exception that it becomes hell when those devices are > > anywhere on the VM path... which makes userspace policy unuseable for > > system suspend. > > A device on the VM path? I don't follow here. Can I have a hand please?
Any block device basically, I don't even want to think about the issues between NFS & suspend :)
That is anything that userspace potentially requires to operate (device on the path to an mmap'd file, swap, whatever)...
Ben.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |