user/sven/linux.git/drivers/iio/buffer, branch v5.13

iio: kfifo: add devm_iio_triggered_buffer_setup_ext variant

2021-03-25T19:13:52Z

This is similar to the {devm_}iio_triggered_buffer_setup_ext variants added via commit 5164c7889857 ("iio: triggered-buffer: add {devm_}iio_triggered_buffer_setup_ext variants"). These can be used to pass extra buffer attributes to the buffer object. This is a bit of temporary mechanism (hopefully) so that drivers that want to allocate a kfifo buffer with extra buffer attributes, don't need to include 'buffer_impl.h' directly. This can also become an API function (in it's own right, unfortunately), but it may be a little less bad vs drivers having to include 'buffer_impl.h'. So, far the drivers that want to pass buffer attributes, all have to do with some HW FIFO attributes, so there may be a chance of unifying them into IIO core somehow (as some standard API). But, until that happens, we just need to let them register their HW FIFO attributes directly (without having to let them include 'buffer_impl.h' directly). Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210311091042.22417-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron

iio: buffer: kfifo_buf: kernel-doc, typo in function name.

2021-03-25T19:13:51Z

Should have been _kfifo_ and was _fifo_ Signed-off-by: Jonathan Cameron Acked-by: Alexandru Ardelean Reviewed-by: Lars-Peter Clausen Link: https://lore.kernel.org/r/20210314164655.408461-9-jic23@kernel.org

iio: kfifo: mask flags without zero-check in devm_iio_kfifo_buffer_setup()

2021-03-25T19:13:49Z

As pointed by Lars, this doesn't require a zero-check. Also, while looking at this a little closer at it (again), the masking can be done later, as there is a zero-check for 'mode_flags' anyway, which returns -EINVAL. And we only need the 'mode_flags' later in the logic. This change is more of a tweak. Fixes: e36db6a06937 ("iio: kfifo: add devm_iio_kfifo_buffer_setup() helper") Cc: Lars-Peter Clausen Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210306162834.7339-1-ardeleanalex@gmail.com Signed-off-by: Jonathan Cameron

iio: buffer: introduce support for attaching more IIO buffers

2021-03-11T20:47:05Z

With this change, calling iio_device_attach_buffer() will actually attach more buffers. Right now this doesn't do any validation of whether a buffer is attached twice; maybe that can be added later (if needed). Attaching a buffer more than once should yield noticeably bad results. The first buffer is the legacy buffer, so a reference is kept to it. At this point, accessing the data for the extra buffers (that are added after the first one) isn't possible yet. The iio_device_attach_buffer() is also changed to return an error code, which for now is -ENOMEM if the array could not be realloc-ed for more buffers. To adapt to this new change iio_device_attach_buffer() is called last in all place where it's called. The realloc failure is a bit difficult to handle during un-managed calls when unwinding, so it's better to have this as the last error in the setup_buffer calls. At this point, no driver should call iio_device_attach_buffer() directly, it should call one of the {devm_}iio_triggered_buffer_setup() or devm_iio_kfifo_buffer_setup() or devm_iio_dmaengine_buffer_setup() functions. This makes iio_device_attach_buffer() a bit easier to handle. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210215104043.91251-20-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron

iio: buffer: dmaengine: obtain buffer object from attribute

2021-03-11T20:47:04Z

The reference to the IIO buffer object is stored on the attribute object. So we need to unwind it to obtain it. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210215104043.91251-16-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron

iio: buffer-dma,adi-axi-adc: introduce devm_iio_dmaengine_buffer_setup()

2021-03-11T20:47:02Z

This change does a conversion of the devm_iio_dmaengine_buffer_alloc() to devm_iio_dmaengine_buffer_setup(). This will allocate an IIO DMA buffer and attach it to the IIO device, similar to devm_iio_triggered_buffer_setup() (though the underlying code is different, the final logic is the same). Since the only user of the devm_iio_dmaengine_buffer_alloc() was the adi-axi-adc driver, this change does the replacement in a single go in the driver. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210215104043.91251-7-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron

iio: kfifo: un-export devm_iio_kfifo_allocate() function

2021-03-11T20:47:01Z

At this point all drivers should use devm_iio_kfifo_buffer_setup() instead of manually allocating via devm_iio_kfifo_allocate() and assigning ops and modes. With this change, the devm_iio_kfifo_allocate() will be made private to the IIO core, since all drivers should call either devm_iio_kfifo_buffer_setup() or devm_iio_triggered_buffer_setup() to create a kfifo buffer. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210215104043.91251-6-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron

iio: kfifo: add devm_iio_kfifo_buffer_setup() helper

2021-03-11T20:47:01Z

This change adds the devm_iio_kfifo_buffer_setup() helper/short-hand, which groups the simple routine of allocating a kfifo buffers via devm_iio_kfifo_allocate() and calling iio_device_attach_buffer(). The mode_flags parameter is required, as the IIO kfifo supports 2 modes: INDIO_BUFFER_SOFTWARE & INDIO_BUFFER_TRIGGERED. The setup_ops parameter is optional. This function will be a bit more useful when needing to define multiple buffers per IIO device. The naming for this function has been inspired from iio_triggered_buffer_setup() since that one does a kfifo alloc + a pollfunc alloc. So, this should have a more familiar ring to what it is. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210215104043.91251-3-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron

iio: buffer: Return error if no callback is given

2020-12-03T19:32:40Z

Return error in case no callback is provided to `iio_channel_get_all_cb()`. There's no point in setting up a buffer-cb if no callback is provided. Signed-off-by: Nuno Sá Reviewed-by: Olivier Moysan Link: https://lore.kernel.org/r/20201121161457.957-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron

iio: triggered-buffer: add {devm_}iio_triggered_buffer_setup_ext variants

2020-11-21T14:53:09Z

This change adds a parameter to the {devm_}iio_triggered_buffer_setup() functions to assign the extra sysfs buffer attributes that are typically assigned via iio_buffer_set_attrs(). The functions also get renamed to iio_triggered_buffer_setup_ext() & devm_iio_triggered_buffer_setup_ext(). For backwards compatibility the old {devm_}iio_triggered_buffer_setup() functions are now macros wrap the new (renamed) functions with NULL for the buffer attrs. The aim is to remove iio_buffer_set_attrs(), so in the iio_triggered_buffer_setup_ext() function the attributes are assigned directly to 'buffer->attrs'. When adding multiple IIO buffers per IIO device, it can be pretty cumbersome to first allocate a set of buffers, then to dig them out of IIO to assign extra attributes (with iio_buffer_set_attrs()). Naturally, the best way would be to provide them at allocation time, which is what this change does. At this moment, buffers allocated with {devm_}iio_triggered_buffer_setup() are the only ones in mainline IIO to call iio_buffer_set_attrs(). Signed-off-by: Alexandru Ardelean Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200929125949.69934-4-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron