Hi Jonathan, I appreciate your response. On Sat, Apr 8, 2017 at 7:36 AM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > On 08/04/17 07:13, Pavel Roskin wrote: >> Jonah, I appreciate your advice. >> >> I'm still considering using IIO, as I would need some ways to >> configure the hardware (set interrupt watermark, set some other >> configuration registers). But it's good to understand why the >> resulting driver would be unlike all others. > The primary reason for the existence of a subsystem is to > provide a consistent userspace interface. In some ways it doesn't > matter what goes on within the kernel at all. > > Now it may be possible to do this for your device, but that would > only make sense if we were to describe the data in your ring buffer. > It could be implemented as a hardware ring buffer with no software > buffer. I can describe the data. My concern is that I don't see way to read unparsed blocks of data. realbits and storagebits are described by u8, which limits them to 255 bits or 63 bytes. The main userspace consumer of the data will need whole blocks of data captures at the same time. > Whilst we fairly recently move the sca3000 driver away from this, > as in that case an intermediate software buffer made more sense, > that driver used to do this. > Jumping back an arbitrary distance: > https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/drivers/staging/iio/accel/sca3000_ring.c?h=iio-for-4.7a&id=486294f184c05cff116160bb731cbb679f047621 > I believe there are drivers in analog devices out of mainline tree > that do it as well. One example there is the spi offload engine > support which uses the hardware buffer stuff, but that is somewhat > cryptic so the sca3000 driver above is probably a better starting > point. Thank you for the example! The driver is quite large, it will take me a while to process. Do you have any documentation about buffers? It's good to have iio_simple_dummy_buffer.c, but it doesn't have a hardware buffer mode. > Then we come to the question of how to describe the data. If you > don't do this of course you can use IIO out of mainline, but there > will be little interest in merging it. > > If you describe the data using normal IIO channels it is up to you > whether you then use your own userspace stack or something more > general. What we are interested in from a subsystem point of view > is ensuring you 'could' use standard userspace code. > > So what is actually in this magic data dump? Sensor data by the > sound of it, so it could be described? Without that description > I'm not going to be keen to have it mainline IIO. Yes, it can be described. It's sensor data, nothing unusual. > p.s. When replying to a thread, please keep all relevant previous > emails in there! Makes it a lot easier for those of us running > a bit behind to catch up. My bad, I just realized gmail can do the right thing. Jonathan, please ignore the personal reply, my email setup is new to me. Pavel -- 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
