Hi Pavel, To me, IIO seems really great if you want to have generic, structured access to your sensor's data from userspace, with a single driver supporting a wide variety of use cases. Your system sounds very bespoke, and I’m guessing that you probably have a single, tightly-coupled client for your data. In my opinion, IIO might be a bit much for your situation. If I were you, I would just implement a /dev/ node which returns the queued data from the FPGA on read. Should be a simple fops table and not much else, I’d think. Just my 2¢! Best, Jonah > On Apr 7, 2017, at 9:47 PM, Pavel Roskin <plroskin@xxxxxxxxx> wrote: > > Hi Jonah, > > Thank you for reply! There is no DMA. The ring buffer is implemented > in FPGA. It is mapped to the CPU memory. It has space for 64 messages. > That is, if the userspace doesn't read data for 64/50 = 1.28 seconds, > there will be lost data. It is possible to set up an interrupt as a > certain watermark, e.g. when half of the buffers are utilized. But I > expect that the userspace utility will be polling the driver for new > messages and will read them before the interrupt is triggered. > > I'm not sure if a buffer in the kernel space would be needed. It would > be nice to save the data in case if the userspace software is slow. > But I don't see that as a hard requirement. If the userspace utility > sleeps for over a second, I would be in trouble, with or without > kernel buffering. > > I don't want to do any processing in the kernel space. So the driver > would have one "channel" spitting out 256 byte long opaque packets. > > I'm sure there are tons of ways to get that data to the userspace, I > just want to select a subsystem that would cause less frustration and > "impedance mismatch". > > -- > Regards, > Pavel Roskin -- 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
