Re: [linux-pm] [PATCH] - race-free suspend. Was: Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Thu, Jun 3, 2010 at 6:36 AM, mark gross <640e9920@xxxxxxxxx> wrote:
> On Wed, Jun 02, 2010 at 11:12:39PM -0700, Brian Swetland wrote:
>> On Wed, Jun 2, 2010 at 11:04 PM, mark gross <640e9920@xxxxxxxxx> wrote:
>> >>
>> >> There are many wakeup events possible in a typical system --
>> >> keypresses or other input events, network traffic, telephony events,
>> >> media events (fill audio buffer, fill video decoder buffer, etc), and
>> >> I think requiring that all wakeup event processing bottleneck through
>> >> a single userspace process is non-optimal here.
>> >
>> > Um doesn't the android framework bottleneck the user mode lock
>> > processing through the powermanager and any wake up event processing
>> > eventually has to grab a lock through this bottleneck anyway?
>>
>> For "high level" framework/application level wakelocks, yes, but lower
>> level components beneath the java api layer use the kernel interface
>> directly.
>>
> Oh. ÂI thought everything went through
> hardware/libhardware_legacy/power/power.c
> who else is hitting /sys/power/* in the android user mode then?

I believe everything does -- that's the thin wrapper around the kernel
interface (which will have to change slightly to meet the
suspend_blocker device/fd vs wakelock proc/sys interface, etc), which
is used by the powermanager service, the RIL, and any other low level
code.  At the App/Service level, wakelocks are provided by a java
level API that is a remote interface to the powermanager.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/