-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| the MPU-centric solution doesn't help, and you still have to solve | the general Linux resume problem, or live with the same inconsistent | behaviour we tried to get rid of in the first place. Dunno about any "general Linux resume problem" in this area, what I do know is ---> | Thus, the MPU only needs do things that can't be done sensibly by | the CPU if we assume that the CPU can respond (= wake up, find out | what happened, make a decision, act on it - in our scenario, the | peripherals it needs to talk to quickly are already awake) within, | say, 100ms. ... today the CPU takes way longer than this on our kernels. And tomorrow we inherit a new BSP with drivers we didn't see before with their own resume behaviours. I think we shouldn't bet the farm on it having great resume behaviour but expect it to be cranky -- and for driver-specific reasons not "general" ones. Just because MPU actions can't do everything the CPU can doesn't mean what they can do for us isn't valuable. According to the current plan, the actions are programmable from userspace anyway, if resume becomes lightning fast just turn the MPU actions off and you're sorted. Then we get good snappy behaviour either way. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfz3SMACgkQOjLpvpq7dMp7QwCfRf9+ZxqLE5EohEPkQ7a4lTvn DGMAnj1We/+5gKLQ8xwP7Hf+h26/oW4A =ScBM -----END PGP SIGNATURE-----
