hardware buffer enabling

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

Quoted 7 lines · Srinivas Pandruvada

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?

This is closely related to watershed events on buffers, both software and hardware. We had these back in the early days but the interface was fiddly. It used a couple of iio events to tell user space the watershed was passed.

One suggestion from Arnd Bergmann was to use one of the less commonly used poll types to indicate this to user space. It was in a long system wide review he did not long after we entered staging. Looked like a neat idea as could coexist nicely with existing interfaces on the same buffer. Would definitely require a fair bit of documentation. Thread in question is around about:
https://lkml.org/lkml/2011/3/16/190

Also note we already have hardware buffered devices pushing into software
buffers (without a trigger) which effectively handle the same use case using existing interfaces. See the ti_am335x_adc driver.

There is definitely room for something more controllable but it shouldn't be too focused on hardware buffering as makes sense for software buffers too!

So to take a stab in the air we need some means of setting the watershed level (and a callback to pass this on to the hardware if that makes sense).

The fiddly cases are going to be the corner cases such as when the length changes.

what do you think?

Quoted 16 lines

"
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

Quoted 1 line

parameter.

Hmm. Max latency would just be a timeout on the poll. Period is a trigger characteristic
or a hardware one if no explicit trigger is present.

There is clearly ad

Quoted 28 lines

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.
"

Quoted 4 lines

Thanks,
Srinivas

Quoted 26 lines · Jonathan Cameron

Quoted 7 lines · Srinivas Pandruvada

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?

This is closely related to watershed events on buffers, both software and hardware. We had these back in the early days but the interface was fiddly. It used a couple of iio events to tell user space the watershed was passed.

One suggestion from Arnd Bergmann was to use one of the less commonly used poll types to indicate this to user space. It was in a long system wide review he did not long after we entered staging. Looked like a neat idea as could coexist nicely with existing interfaces on the same buffer. Would definitely require a fair bit of documentation. Thread in question is around about:
https://lkml.org/lkml/2011/3/16/190

Also note we already have hardware buffered devices pushing into software
buffers (without a trigger) which effectively handle the same use case using existing interfaces. See the ti_am335x_adc driver.

Quoted 5 lines

There is definitely room for something more controllable but it shouldn't be too focused on hardware buffering as makes sense for software buffers too!

So to take a stab in the air we need some means of setting the watershed level (and a callback to pass this on to the hardware if that makes sense).

I think so. We need a watermark level and an event. We can use poll flags to allow prioritized event.

Quoted 19 lines

The fiddly cases are going to be the corner cases such as when the length changes.

what do you think?

Quoted 16 lines

"
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

Quoted 5 lines

Quoted 1 line

parameter.

Hmm. Max latency would just be a timeout on the poll. Period is a trigger characteristic
or a hardware one if no explicit trigger is present.

Correct. But this value can be used to infer the watermark level.

Quoted 23 lines

There is clearly ad

Quoted 22 lines

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.

Quoted 6 lines

Quoted 6 lines

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.
"

I will do some experiments with one device which I will get with a large Fifo.

Thanks,
Srinivas

Quoted 5 lines

Quoted 4 lines

Thanks,
Srinivas

--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html