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