David Brownell wrote: > On Friday 23 March 2007 1:39 pm, Rafael J. Wysocki wrote: > >> After we have frozen tasks, we need to >> call something like device_suspend(some_argument) where the argument should >> tell drivers what to do. > > That parameter can't suffice, since the exact details depend on > system-dependent context. Example, on one system a given sleep > state will allow a given device to issue wakeups ... on another, > it won't. > What do you mean? Capability of h/w to be a wakeup source or design decisions, when wakeup capability of a given device is disabled intentionally for some reason? System may have a number of devices that all are able to wakeup the system from *all* sleep (low power) states the system supports.Normally, such devices should be marked as "can_wakeup" to demonstrate the capability, then, user may select these devices as a wakeup source(s) from a given sleep state. He(she) sets "should_wakeup" flag for this. For example, I may want to wakeup the system via USB, MMC and keypad, but when I put the system into deeper sleep state I may want to wakeup it only via keypad and do not bother it via MMC and USB. So, it is reasonable idea to permit some devices to be wakeup sources for one system-wide state but restrict the wakeup ability for another system-wide state. But, it seems not quite reasonable to hardcode this in platform-specific code, unless your platform is designed for very specific needs. In general, every wakeup source (which is capable to wakeup at any system state) should be available via sysfs (../power/wakeup interface of device) > You seem to have overlooked the clk_must_disable() patches I > recently re-sent. In conjunction with the driver model wakeup > flags, that can solve the problem on every SOC platform I've > had a reason to look at ... see how it works for AT91 USB. As I pointed above, user may want to choose between wakeup sources and he(she) must be sure the choice won't be ignored, but your changes for atmel_serial.c and at91_udc.c, seems restrict user with that. Thanks, Dmitry _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
