Re: hardware buffer enabling

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

On 05/07/2014 01:03 PM, Jonathan Cameron wrote:
>
>
> On May 6, 2014 5:56:00 PM GMT+01:00, Srinivas Pandruvada 
> <srinivas.pandruvada@linux.intel.com> wrote:
>> 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).
I think so. We need a watermark level and an event. We can use poll 
flags to allow prioritized event.
> The fiddly cases are going to be the corner cases such as when the 
> length changes.
>
> what do you think?
>>
>> "
>> 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.
>
> 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.
> There is clearly ad
>>
>> 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.
>> "
I will do some experiments with one device which I will get with a large 
Fifo.

Thanks,
Srinivas
>>
>>
>> Thanks,
>> Srinivas
>