hardware buffer enabling

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

Hi Jonathan,

The Android user space has some capability to ask the supported hardware 
to enable buffering in hardware.
I don't think that we can achieve this by current ABI.  Do you want me 
to propose new ABI?

"
Android batch mode:
batch(int handle, int flags, int64_t period_ns, int64_t max_report_latency)

Enabling batch mode for a given sensor sets the delay between events. 
max_report_latency sets the maximum time by which events can be delayed 
and batched together before being reported to the applications. A value 
of zero disables batch mode for the given sensor. The period_ns 
parameter is equivalent to calling setDelay() -- this function both 
enables or disables the batch mode AND sets the event's period in 
nanoseconds. See setDelay() for a detailed explanation of the period_ns 
parameter.

In non-batch mode, all sensor events must be reported as soon as they 
are detected. For example, an accelerometer activated at 50Hz will 
trigger interrupts 50 times per second.
While in batch mode, sensor events do not need to be reported as soon as 
they are detected. They can be temporarily stored and reported in 
batches, as long as no event is delayed by more than maxReportingLatency 
nanoseconds. That is, all events since the previous batch are recorded 
and returned at once. This reduces the amount of interrupts sent to the 
SoC and allows the SoC to switch to a lower power mode (idle) while the 
sensor is capturing and batching data.

setDelay() is not affected and it behaves as usual.

Each event has a timestamp associated with it. The timestamp must be 
accurate and correspond to the time at which the event physically happened.

Batching does not modify the behavior of poll(): batches from different 
sensors can be interleaved and split. As usual, all events from the same 
sensor are time-ordered.
"


Thanks,
Srinivas


[-- Attachment #2: Type: text/html, Size: 2884 bytes --]