|| ||Arve Hjønnevåg <arve-AT-android.com>|
|| ||Pavel Machek <pavel-AT-ucw.cz>|
|| ||Re: [PATCH 01/13] PM: Add wake lock api.|
|| ||Thu, 5 Feb 2009 16:28:28 -0800|
|| ||ncunningham-AT-crca.org.au, u.luckas-AT-road.de, swetland-AT-google.com,
|| ||Article, Thread
On Thu, Feb 5, 2009 at 1:11 AM, Pavel Machek <email@example.com> wrote:
> On Wed 2009-02-04 18:50:14, Arve Hj??nnev??g wrote:
>> +A locked wakelock, depending on its type, prevents the system from entering
>> +suspend or other low-power states. When creating a wakelock, you can select
>> +if it prevents suspend or low-power idle states. If the type is
>> set to
> idle states are very different from suspend. Mixing them does not look
> like good idea... and IIRC we already have API somewhere to prevent
> deep idle states. Intel did it for their wireless cards IIRC.
If you are talking about the pm_qos interface, then yes there is some
overlap. We did not use the pm_qos interface since it does a linear
scan for a string every time you change a requirement, and it only let
you specify the latency you need not the power level. We have
interrupts that stop working at the lowest power level and this does
not easily translate into a latency value.
>> + Key pressed Key released
>> + | |
>> +keypad-scan ++++++++++++++++++
>> +input-event-queue +++ +++
>> +process-input-events +++ +++
> I'm not sure if keyboard scanning example is good here. It is very
> t-mobile G1 specific.
There is no G1 specific code in the keypad driver. I also don't
remember seeing any development boards without a similar keypad. I
like this example since it show how an event can be passed from the
kernel to user-space.
to post comments)