different ring buffer usage scenario

different ring buffer usage scenario

[Hennerich, Michael]

Hi Jonathan,

I'm currently working on a high speed ADC driver, that requires a different=
 ring buffer use case scenario.
Let me explain a little bit the setup. I'm running Linux on a Microblaze so=
ftcore inside an Virtex6 FPGA.
Part of the system is a peripheral interface block, we call it the ADC Inte=
rface Module (AIM).
External to the FPGA we connect a single channel high speed ADC AD9649, to =
the AIM signals.

The AIM features a FIFO, with watermark interrupt capabilities. There are t=
wo modes that need to be supported.
Continues Sampling Mode and Single Shot Sample Mode. In Single Shot Sample =
Mode, the user reads an arbitrary
Number of samples from the ADC, and then the sampling stops. This mode does=
 not need to have a ringbuffer at all.
A simple chardev might be sufficient.

Any objections creating a driver private chardev?

In Continues Sampling Mode we store continuously data into the ringbuffer, =
and assume that userspace reader can catch up.
Now looking at the existing sw_ring, we don't need the scan element concept=
s, no timestamps and bytes_per_datum is going to be used in a different fas=
hion.
Ideally bytes_per_datum defaults to the ADC width. However right now it is =
used to set the number of bytes stored into the ring by a call to ring->acc=
ess.store_to().
bytes_per_datum currently must be constant while the ring is enabled.
However we need to store an arbitrary number of elements into the buffer.

Following example:
The AIM internal fifo can hold 512 elements, we set the fifo almost full wa=
termark to 400 elements. In the ISR we read the number of elements that are=
 currently in the fifo. This number will be > the fifo almost full watermar=
k (e.g. 400 elements) but likely less than the fifo size.

Do you think it is possible to modify iio_store_to_sw_ring(), without break=
ing the implementation, to support this kind of use?

Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: different ring buffer usage scenario

[Jonathan Cameron]

On 12/17/10 13:47, Hennerich, Michael wrote:
> Hi Jonathan,
> 
> I'm currently working on a high speed ADC driver, that requires a different ring buffer use case scenario.
> Let me explain a little bit the setup. I'm running Linux on a Microblaze softcore inside an Virtex6 FPGA.
> Part of the system is a peripheral interface block, we call it the ADC Interface Module (AIM).
> External to the FPGA we connect a single channel high speed ADC AD9649, to the AIM signals.
> 
> The AIM features a FIFO, with watermark interrupt capabilities. There are two modes that need to be supported.
> Continues Sampling Mode and Single Shot Sample Mode. In Single Shot Sample Mode, the user reads an arbitrary
> Number of samples from the ADC, and then the sampling stops. This mode does not need to have a ringbuffer at all.
> A simple chardev might be sufficient.
> 
> Any objections creating a driver private chardev?
None at all.
Is it appropriate to maintain the interfaces and buffer description we have for those where there
is a buffer involved?  I think those interfaces are flexible enough... If not we probably
want to make it so they are.

I did think of creating a pass through buffer that would effectively allow other devices
to simulate this behaviour. Basically to the core it would look like a buffer, but it
would only store one scan and then only if someone has the chrdev open. It would support select type
calls. This would be needed for the input bridge to no apply any delay to the data stream.

Not actually done any work on it though.
> 
> In Continues Sampling Mode we store continuously data into the ringbuffer, and assume that userspace reader can catch up.
> Now looking at the existing sw_ring, we don't need the scan element
> concepts, no timestamps and bytes_per_datum is going to be used in a
> different fashion.
Interface wise I'd still like to see the attrs indicate the scan elements etc (though there will only
be one).  That way the userspace code can work with this alongside devices that need that support.
The scan element attributes should obviously be read only.
Certainly no need to support timestamps. Just don't add the relevant scan element attribute.
> Ideally bytes_per_datum defaults to the ADC width.
The datum in this case corresponds to a single reading so I think that would be the case.
> However right now it is used to set the number of bytes stored into the ring by a call to ring->access.store_to().
> bytes_per_datum currently must be constant while the ring is enabled.
> However we need to store an arbitrary number of elements into the buffer.
Ah, I see what you mean. You need a store_n rather than a store_1 facility on the buffer.
> 
> Following example:
> The AIM internal fifo can hold 512 elements, we set the fifo almost
> full watermark to 400 elements. In the ISR we read the number of
> elements that are currently in the fifo. This number will be > the
> fifo almost full watermark (e.g. 400 elements) but likely less than
> the fifo size.
(aside) As a practical point of view I'd be inclined to not bother checking what
is there.  Just read your 400 then wait for the interrupt to occur again. I would
think that will be sufficient to ensure you don't loose data.
> 
> Do you think it is possible to modify iio_store_to_sw_ring(), without breaking the implementation, to support this kind of use?
Lets add a new function for this rather than modifying the current one.
If we add an op to those in the generic buffer structure we can have some buffer implementations support
this and some not.

We really need to replace that ring buffer. I haven't looked at how the unified
ring buffer code (from tracing etc) is going recently. Kfifo would work but is
a little clunky for our normal use cases.

In the meantime I don't think there is any fundamental reason why we can't do
a iio_store_to_sw_ring_n. It does get a bit more complex though as we will
have write sets of records that overlap the loop point of the ring.

This particular case fits rather better than our normal ones into using the kfifo
buffers.  The advantage is we know our record length and it never changes so we
can cleanly use kfifo_in and friends to handle your case.  I did post a proof
of concept for using kfifo a while back but it used dynamic records and hence
wouldn't be suitable here.  Looks like that should be revisited. Perhaps we can get
reasonable support and performance by just using a single byte fifo element and
handling record sizes ourselves.

Jonathan

RE: different ring buffer usage scenario

[Hennerich, Michael]

Jonathan Cameron wrote on 2010-12-17:
> On 12/17/10 13:47, Hennerich, Michael wrote:
>> Hi Jonathan,
>>
>> I'm currently working on a high speed ADC driver, that requires a
>> different ring buffer use case scenario. Let me explain a little bit
>> the setup. I'm running Linux on a Microblaze softcore inside an Virtex6
>> FPGA. Part of the system is a peripheral interface block, we call it
>> the ADC Interface Module (AIM). External to the FPGA we connect a
>> single channel high speed ADC AD9649, to the AIM signals.
>>
>> The AIM features a FIFO, with watermark interrupt capabilities. There
>> are two modes that need to be supported. Continues Sampling Mode and
>> Single Shot Sample Mode. In Single Shot Sample Mode, the user reads an
>> arbitrary Number of samples from the
> ADC, and then the sampling stops. This mode does not need to have a
> ringbuffer at all.
>> A simple chardev might be sufficient.
>>
>> Any objections creating a driver private chardev?
> None at all.
> Is it appropriate to maintain the interfaces and buffer description we
> have for those where there is a buffer involved?  I think those
> interfaces are flexible enough... If not we probably want to make it
> so they are.
>
> I did think of creating a pass through buffer that would effectively
> allow other devices to simulate this behaviour. Basically to the core
> it would look like a buffer, but it would only store one scan and then
> only if someone has the chrdev open. It would support select type
> calls. This would be needed for the input bridge to no apply any delay
> to the data stream.
>
> Not actually done any work on it though.

Hi Jonathan,

For a project I'm currently working on I need such a pass through buffer.

The requirements I have are pretty basic. When user space reads x number of=
 elements
>>From the buffer, the generic pass through buffer implementation calls a reg=
istered
function in the ADC driver, that may sleep until the requested amount of el=
ements are
available.

I wonder if you have something in the make already?

Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Gesch=
aeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret=
 Seif

Re: different ring buffer usage scenario

[Jonathan Cameron]

On 01/13/11 09:20, Hennerich, Michael wrote:
> Jonathan Cameron wrote on 2010-12-17:
>> On 12/17/10 13:47, Hennerich, Michael wrote:
>>> Hi Jonathan,
>>>
>>> I'm currently working on a high speed ADC driver, that requires a
>>> different ring buffer use case scenario. Let me explain a little bit
>>> the setup. I'm running Linux on a Microblaze softcore inside an Virtex6
>>> FPGA. Part of the system is a peripheral interface block, we call it
>>> the ADC Interface Module (AIM). External to the FPGA we connect a
>>> single channel high speed ADC AD9649, to the AIM signals.
>>>
>>> The AIM features a FIFO, with watermark interrupt capabilities. There
>>> are two modes that need to be supported. Continues Sampling Mode and
>>> Single Shot Sample Mode. In Single Shot Sample Mode, the user reads an
>>> arbitrary Number of samples from the
>> ADC, and then the sampling stops. This mode does not need to have a
>> ringbuffer at all.
>>> A simple chardev might be sufficient.
>>>
>>> Any objections creating a driver private chardev?
>> None at all.
>> Is it appropriate to maintain the interfaces and buffer description we
>> have for those where there is a buffer involved?  I think those
>> interfaces are flexible enough... If not we probably want to make it
>> so they are.
>>
>> I did think of creating a pass through buffer that would effectively
>> allow other devices to simulate this behaviour. Basically to the core
>> it would look like a buffer, but it would only store one scan and then
>> only if someone has the chrdev open. It would support select type
>> calls. This would be needed for the input bridge to no apply any delay
>> to the data stream.
>>
>> Not actually done any work on it though.
> 
> Hi Jonathan,
> 
> For a project I'm currently working on I need such a pass through buffer.
> 
> The requirements I have are pretty basic. When user space reads x number of elements
>>>From the buffer, the generic pass through buffer implementation calls a registered
> function in the ADC driver, that may sleep until the requested amount of elements are
> available.
> 
> I wonder if you have something in the make already?
Interesting, that's not a case I'd thought of previously.

You could get fairly close by using the ring buffer with 2x the number of elements
then do a blocking read on the event (for a 50% full event). It would be a bit ugly
if the number x changes regularly though so far from ideal.

So all in all it will probably need a custom buffer.  Quickest option is probably to
use the kfifo implementation and play games in the rip lots function. Depending on how
big x typically is, you could either add a waitqueue that makes iio_rip_kfifo wake
up every time any new data is added to the kfifo, or you could set a value in the buffer
and check how many elements are in the buffer in iio_store_to_kfifo and only signal iio_rip_kfifo
when it is bigger than your threshold. I guess you may want to flush the kfifo as well
though that will IIRC require some careful locking. Might actually be quicker to just
eat the existing contents at the beginning of iio_rip_kfifo (if ugly).

I think this would need to be a separate implementation from kfifo, but I guess you could
do it as a couple of 'variant functions' and supply a separate iio_kfifo_register_funcs
in the header.

Should be relatively straight forward to get something that works. I'm sure there are more
efficient ways of doing it, but this is probably the easiest to implement.

Jonathan
> 
> Greetings,
> Michael

RE: different ring buffer usage scenario

[Hennerich, Michael]

Jonathan Cameron wrote on 2011-01-13:
> On 01/13/11 09:20, Hennerich, Michael wrote:
>> Jonathan Cameron wrote on 2010-12-17:
>>> On 12/17/10 13:47, Hennerich, Michael wrote:
>>>> Hi Jonathan,
>>>>
>>>> I'm currently working on a high speed ADC driver, that requires a
>>>> different ring buffer use case scenario. Let me explain a little bit
>>>> the setup. I'm running Linux on a Microblaze softcore inside an
>>>> Virtex6 FPGA. Part of the system is a peripheral interface block, we
>>>> call it the ADC Interface Module (AIM). External to the FPGA we
>>>> connect a single channel high speed ADC AD9649, to the AIM signals.
>>>>
>>>> The AIM features a FIFO, with watermark interrupt capabilities.
>>>> There are two modes that need to be supported. Continues Sampling
>>>> Mode and Single Shot Sample Mode. In Single Shot Sample Mode, the
>>>> user reads an arbitrary Number of samples from the
>>> ADC, and then the sampling stops. This mode does not need to have a
>>> ringbuffer at all.
>>>> A simple chardev might be sufficient.
>>>>
>>>> Any objections creating a driver private chardev?
>>> None at all.
>>> Is it appropriate to maintain the interfaces and buffer description
>>> we have for those where there is a buffer involved?  I think those
>>> interfaces are flexible enough... If not we probably want to make
>>> it so they are.
>>>
>>> I did think of creating a pass through buffer that would effectively
>>> allow other devices to simulate this behaviour. Basically to the core
>>> it would look like a buffer, but it would only store one scan and then
>>> only if someone has the chrdev open. It would support select type
>>> calls. This would be needed for the input bridge to no apply any delay
>>> to the data stream.
>>>
>>> Not actually done any work on it though.
>>
>> Hi Jonathan,
>>
>> For a project I'm currently working on I need such a pass through
>> buffer.
>>
>> The requirements I have are pretty basic. When user space reads x
>> number of elements
>>> From the buffer, the generic pass through buffer implementation
>>> calls a registered
>> function in the ADC driver, that may sleep until the requested
>> amount of elements are available.
>>
>> I wonder if you have something in the make already?
> Interesting, that's not a case I'd thought of previously.
>
> You could get fairly close by using the ring buffer with 2x the number
> of elements then do a blocking read on the event (for a 50% full
> event). It would be a bit ugly if the number x changes regularly
> though so far from ideal.

That's not what I need.
User space triggers the sampling process by reading from the buffer chardev=
.
The device samples @ 20MHz, so the time the read() may sleep is in the
range of micro seconds. My idea is basically to use the infrastructure in
industrialio-ring.c to allocate the buffer_access_chrdev.
Theoretically I don't need the buffer_event_chrdev at all, but in order to =
keep consistency
I should send a 100_FULL event.

> So all in all it will probably need a custom buffer.  Quickest option
> is probably to use the kfifo implementation and play games in the rip
> lots function. Depending on how big x typically is, you could either
> add a waitqueue that makes iio_rip_kfifo wake up every time any new
> data is added to the kfifo,

Data is added to the buffer in one shot - I receive sampling done interrupt=
,
and then may use Core or DMA to transfer the data from the device internal =
fifo
to some local buffer which is then copied to the user.
For now the maximum number of samples that can be read in one shot must be =
less or equal
the hardware fifo size.

> or you could set a value in the buffer and
> check how many elements are in the buffer in iio_store_to_kfifo and
> only signal iio_rip_kfifo when it is bigger than your threshold. I
> guess you may want to flush the kfifo as well though that will IIRC
> require some careful locking. Might actually be quicker to just eat
> the existing contents at the beginning of iio_rip_kfifo (if ugly).
>
> I think this would need to be a separate implementation from kfifo,
> but I guess you could do it as a couple of 'variant functions' and
> supply a separate iio_kfifo_register_funcs in the header.
>
> Should be relatively straight forward to get something that works. I'm
> sure there are more efficient ways of doing it, but this is probably
> the easiest to implement.

Well - I think I don't need an additional software fifo at all.
The device I'm interfacing has a built-in
FIFO, and some controls that allow me the set the number of samples that ar=
e captured.
I'll probably do something similar to the sca3000_ring.c driver, and add my=
 own buffer
implementation.

Thanks

Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Gesch=
aeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret=
 Seif

Re: different ring buffer usage scenario

[Jonathan Cameron]

On 01/13/11 12:17, Hennerich, Michael wrote:
> Jonathan Cameron wrote on 2011-01-13:
>> On 01/13/11 09:20, Hennerich, Michael wrote:
>>> Jonathan Cameron wrote on 2010-12-17:
>>>> On 12/17/10 13:47, Hennerich, Michael wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> I'm currently working on a high speed ADC driver, that requires a
>>>>> different ring buffer use case scenario. Let me explain a little bit
>>>>> the setup. I'm running Linux on a Microblaze softcore inside an
>>>>> Virtex6 FPGA. Part of the system is a peripheral interface block, we
>>>>> call it the ADC Interface Module (AIM). External to the FPGA we
>>>>> connect a single channel high speed ADC AD9649, to the AIM signals.
>>>>>
>>>>> The AIM features a FIFO, with watermark interrupt capabilities.
>>>>> There are two modes that need to be supported. Continues Sampling
>>>>> Mode and Single Shot Sample Mode. In Single Shot Sample Mode, the
>>>>> user reads an arbitrary Number of samples from the
>>>> ADC, and then the sampling stops. This mode does not need to have a
>>>> ringbuffer at all.
>>>>> A simple chardev might be sufficient.
>>>>>
>>>>> Any objections creating a driver private chardev?
>>>> None at all.
>>>> Is it appropriate to maintain the interfaces and buffer description
>>>> we have for those where there is a buffer involved?  I think those
>>>> interfaces are flexible enough... If not we probably want to make
>>>> it so they are.
>>>>
>>>> I did think of creating a pass through buffer that would effectively
>>>> allow other devices to simulate this behaviour. Basically to the core
>>>> it would look like a buffer, but it would only store one scan and then
>>>> only if someone has the chrdev open. It would support select type
>>>> calls. This would be needed for the input bridge to no apply any delay
>>>> to the data stream.
>>>>
>>>> Not actually done any work on it though.
>>>
>>> Hi Jonathan,
>>>
>>> For a project I'm currently working on I need such a pass through
>>> buffer.
>>>
>>> The requirements I have are pretty basic. When user space reads x
>>> number of elements
>>>> From the buffer, the generic pass through buffer implementation
>>>> calls a registered
>>> function in the ADC driver, that may sleep until the requested
>>> amount of elements are available.
>>>
>>> I wonder if you have something in the make already?
>> Interesting, that's not a case I'd thought of previously.
>>
>> You could get fairly close by using the ring buffer with 2x the number
>> of elements then do a blocking read on the event (for a 50% full
>> event). It would be a bit ugly if the number x changes regularly
>> though so far from ideal.
> 
> That's not what I need.
> User space triggers the sampling process by reading from the buffer chardev.
> The device samples @ 20MHz, so the time the read() may sleep is in the
> range of micro seconds. My idea is basically to use the infrastructure in
> industrialio-ring.c to allocate the buffer_access_chrdev.
> Theoretically I don't need the buffer_event_chrdev at all, but in order to keep consistency
> I should send a 100_FULL event.
I wouldn't bother. Not all buffer types send events anyway. We certainly don't guarantee them.
> 
>> So all in all it will probably need a custom buffer.  Quickest option
>> is probably to use the kfifo implementation and play games in the rip
>> lots function. Depending on how big x typically is, you could either
>> add a waitqueue that makes iio_rip_kfifo wake up every time any new
>> data is added to the kfifo,
> 
> Data is added to the buffer in one shot - I receive sampling done interrupt,
> and then may use Core or DMA to transfer the data from the device internal fifo
> to some local buffer which is then copied to the user.
> For now the maximum number of samples that can be read in one shot must be less or equal
> the hardware fifo size.
Sounds sensible.

> 
>> or you could set a value in the buffer and
>> check how many elements are in the buffer in iio_store_to_kfifo and
>> only signal iio_rip_kfifo when it is bigger than your threshold. I
>> guess you may want to flush the kfifo as well though that will IIRC
>> require some careful locking. Might actually be quicker to just eat
>> the existing contents at the beginning of iio_rip_kfifo (if ugly).
>>
>> I think this would need to be a separate implementation from kfifo,
>> but I guess you could do it as a couple of 'variant functions' and
>> supply a separate iio_kfifo_register_funcs in the header.
>>
>> Should be relatively straight forward to get something that works. I'm
>> sure there are more efficient ways of doing it, but this is probably
>> the easiest to implement.
> 
> Well - I think I don't need an additional software fifo at all.
> The device I'm interfacing has a built-in
> FIFO, and some controls that allow me the set the number of samples that are captured.
> I'll probably do something similar to the sca3000_ring.c driver, and add my own buffer
> implementation.
That is probably the best bet.