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 are 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; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
