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-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
