Messages in this thread | | | Date | Tue, 01 Jun 2010 09:57:31 +0300 | From | Igor Stoppa <> | Subject | Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) |
| |
Hi,
ext Arve Hjønnevåg wrote:
> It sounded like you were suggesting that initiating suspend from idle > would somehow avoid the race condition with wakeup events. All I'm > saying is that you would need to block suspend in all the same places. > If you don't care about ignoring wakeup events, then sure you can > initiate suspend from idle. >
Sorry if i'm asking something that was already said, but the thread is quite complex and i am not sure i have been able to grasp all of it.
So, regardless of the SW implementation:
-1) are you focusing on "good" HW or do you want to address all at the same time?
-2) would you be ok with addressing "bad" HW as a special case, which requires workarounds and shouldn't dictate the overall design?
-3) do you agree with the assumption that new HW is expected to get reasonably better and therefore workarounds at point 2) will progressively be confined to devices less and less common?
-4) going to the definition of "good" and "bad" (maybe this should have come earlier in the list), can we define "good" HW as HW where: * suspend state and lowest achievable runtime idle state are basically equivalent from both power consumption and latency pov * the HW itself is properly able to track wakeup sources while it is in its deepest power state (as example OMAP3 has few independent wake-capable pads and a "wake ring" where one only gets the information that at least one of the pads belonging to such ring has received a wakeup) * wakeup sources can be dynamically masked at HW level, so that if a peripheral is not interesting, it doesn't wakeup the system (for example the camera button when the camera cover is closed)
-5) HW that is not capable of properly generating asynchronous signal is most likely the cause for extra timers in kernel and it should be considered "bad" - in any other case having recurring in-kernel timers should be treated as bugs, if their existence is not tied to some meaningful work
thanks, igor -- 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/
| |