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