On Sunday, October 03, 2010, Alan Stern wrote: > On Sun, 3 Oct 2010, Rafael J. Wysocki wrote: > > > On Saturday, October 02, 2010, Alan Stern wrote: > > > On Fri, 1 Oct 2010, Rafael J. Wysocki wrote: > > ... > > > > At the moment it suspends when the network cable is removed from the > > > > device > > > > and the hack I mentioned is used during the resume after the cable has > > > > been > > > > reinserted (it checks if the cable is still there and schedules suspend > > > > if not). > > > > > > That does seem like a strange hack. Instead of scheduling a suspend, > > > why not simply do a suspend as soon as you learn that the cable has > > > been removed again? Is there a problem about the connection status > > > bouncing? > > > > I don't remember 100%, but ISTR there was a problem with that. > > Regardless, it seems like the sort of thing autosuspend would handle > easily with no need for idle notifications. Just call > pm_runtime_mark_last_busy when the cable is plugged in, then do the > runtime resume, and then call pm_request_autosuspend. The check for > the cable being disconnected would have to move from the runtime_idle > callback to the runtime_suspend callback -- but then the runtime_idle > callback wouldn't have to be present at all.
It would be necessary because of the PCI bus type's implementation of it. Anyway, I'll have a look, but I don't use the hardware any more, so testing would be rather hard. :-) Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
