Messages in this thread | | | Subject | RE: suspend/resume support for driver requires an external firmware | Date | Fri, 24 Sep 2004 19:52:51 +0800 | From | "Li, Shaohua" <> |
| |
>> We talked about this in Ottawa a few months ago, and I think this is the >> right approach. Note though, that I think it needs to be more complete: >> >> - There needs to be restore_state() to be symmetic. >> - There needs to be the proper failure recovery >> If save_state() or suspend() fails, every device that has had their >> state saved needs to be restored. >> - It needs to be called for all power management requests. >> - The PCI implementation should call pci_save_state() in it, instead of >in >> ->suspend(). >> >> It would be great if you could add these things. Otherwise, I'll add it >to >> my TODO list.. > >Additionally, for devices like the above that need either to rely on >userland for firmware download or to allocate large amounts of memory >for firmware backup/restore, I think we need to revive the pre-suspend >and post-resume notifiers ... Of course, if a device that needs userland >to reload a firmware is on the swap patch, then we have a chicken & egg >problem, but there is no easy solution for that one, unless the driver >uses the pre-suspend callback to pre-load the firmware that it will need >for resume I somewhat think choice 2 is better. The pre-load can be invoked in any order instead of in the device tree hierarchy order. And currently only few devices need it, is it worth adding it in the device core? In addition, the notifiers have better flexibility. We can easily add more notifier types if needed, such as adding a callback between the sysdev resume and regular devices resume. To tell the truth, we actually have the case. An ACPI link device must resume before regular devices but must be with IRQ enabled. I'm considering add a call back between sysdev and regular devices resume for the issue. I guess the MTRR driver in SMP has the same requirement. Anyway, notifier solution sounds like easier to extend, but we can't extend device core casually.
Thanks, Shaohua - 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/
| |