[lkml]   [2004]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: suspend/resume support for driver requires an external firmware
>> We talked about this in Ottawa a few months ago, and I think this is
>> right approach. Note though, that I think it needs to be more
>> - 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
>> ->suspend().
>> It would be great if you could add these things. Otherwise, I'll add
>> 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
>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
>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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:06    [W:0.032 / U:0.256 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site