-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | Andy Green wrote: |> If Linux does come up in 10ms, no problemo, but I will be surprised to |> see it. | | Based on the various chip timings (i.e., I haven't measured how long | things actually have to take to work), I think something like 10ms | should be feasible. For most interactions, even 100ms would probably | be sufficient for the user not to notice any lag, even for things | like volume control.
What it needs is consistency and responsiveness. If the volume control is physical up-down buttons that goes double -- UI event and reaction has to feel like a direct hardware relationship that can never break. And --> |> If we don't go through the driver resumes we really will have "made |> another U-Boot" though. | | *grin* Well, if we can just turn off all the things we don't care | about, and they stay turned off until we explicitly ask for them, | then we can have something pretty lean and still perfectly general. If you mean that those driver resumes will happen quickly then, fine. If it means going behind the driver model's back somehow then "not fine". We should either resume the CPU normally, or not at all and do it in the MPU. I think when we map it out, we will find that a major requirement to interact with the LCM graphically is the watershed forcing stuff for sure into the Linux side and accepting delay. If we succeeded to move into the MPU the things the user wants to treat as totally predictable hardware operations based off UI events like button press -- that don't use the LCM -- then for the rest actually 200 - 500ms resume while we ramp up the backlight is probably OK for the more complex interactions (especially if what comes up by default is contextually correct already, eg, dialer pad / contacts). | So the call manager would turn off LCM, storage, etc., probably Okay brace for major heresy. I don't think the "call manager" should have the authority to turn off LCMs and so on. Instead, we should have the MPU should establish a regime that BY DEFAULT EVERYTHING IS OFF except itself -- the MPU is an actively miserly guardian of the battery that defaults to saying "no". Device operation of any kind (including CPU) is by default a temporary deviation from "everything off" triggered by some UI / module event. That would also mean Linux can be asked to suspend by the MPU. The CPU is then basically be a peripheral that has a SUSPEND pin, same way that the MPU by default would bring down the backlight after some time with no UI IO. The CPU can override or quench the request based on, eg, open Wifi sockets in LISTEN, but normally, it accepts to suspend. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfzVWoACgkQOjLpvpq7dMpqcwCaAqSTMCtiQI3zG0lrUy4kzz+1 QSYAn06FZby/vthceiGeH0fgisYsVUC6 =+70T -----END PGP SIGNATURE-----
