On Friday 18 December 2009, Alan Stern wrote: > On Fri, 18 Dec 2009, Rafael J. Wysocki wrote: > > > I didn't manage to do that, but I was able to mark sd and i8042 as async and > > see the impact of this. > > Apparently this didn't do what you wanted. In the nx6325 > sd+i8042+async+extra log, the 0:0:0:0 device (which is a SCSI disk) was > suspended by the main thread instead of an async thread. Hm, that's odd, because there's a noticeable time difference between the two cases in which the sd is sync and async. I'll look into it further. > There's an important point I neglected to mention before. Your logs > don't show anything for devices with no suspend callbacks at all. > Nevertheless, these devices sit on the device list and prevent other > devices from suspending or resuming as soon as they could. Unless they are async, that is. > For example, the fingerprint sensor (3-1) took the most time to resume. > But other devices were delayed until after it finished because it had > children with no callbacks, and they delayed the devices following > them in the list. > > What would happen if you completed these devices immediately, as part > of the first pass? OK. How do the PM core is supposed to check if a device has null suspend and resume? Check all of the function pointers in the first pass? Rafael -- 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
