summaryrefslogtreecommitdiff
path: root/drivers/iio/buffer/industrialio-buffer-dmaengine.c
AgeCommit message (Collapse)Author
2021-03-11iio: buffer: introduce support for attaching more IIO buffersAlexandru Ardelean
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 <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-20-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: buffer: dmaengine: obtain buffer object from attributeAlexandru Ardelean
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 <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-16-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-11iio: buffer-dma,adi-axi-adc: introduce devm_iio_dmaengine_buffer_setup()Alexandru Ardelean
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 <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20210215104043.91251-7-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-11-21iio: buffer: dmaengine: unwrap the use of iio_buffer_set_attrs()Alexandru Ardelean
The iio_buffer_set_attrs() helper will be removed in this series. So, just assign the attributes of the DMAEngine buffer logic directly. This is IIO buffer core context, so there is direct access to the buffer->attrs object. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-2-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-29iio: buffer-dmaengine: remove non managed alloc/freeAlexandru Ardelean
This is to encourage the use of devm_iio_dmaengine_buffer_alloc(). Currently the managed version of the DMAEngine buffer alloc is the only function used from this part of the framework. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200923121810.944075-1-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-09-03iio: buffer-dmaengine: adjust `bytes_used` with residue infoAlexandru Ardelean
A transfer may fall shorter than the bytes in the block. This information is available in the residue from the DMA engine, so we can compute actual `bytes_used` with that by subtracting the residue. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20200826052011.13348-1-lars@metafoo.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-19iio: buffer-dmaengine: add dev-managed calls for buffer allocAlexandru Ardelean
Currently, when using a 'iio_dmaengine_buffer_alloc()', an matching call to 'iio_dmaengine_buffer_free()' must be made. With this change, this can be avoided by using 'devm_iio_dmaengine_buffer_alloc()'. The buffer will get free'd via the device's devres handling. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-19iio: buffer-dmaengine: use %zu specifier for sprintf(align)Alexandru Ardelean
The 'size_t' type behaves differently on 64-bit architectures, and causes compiler a warning of the sort "format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}'". This change adds the correct specifier for the 'align' field. Fixes: 4538c18568099 ("iio: buffer-dmaengine: Report buffer length requirements") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: buffer: rename 'read_first_n' callback to 'read'Lars-Peter Clausen
It is implied that 'read' will read the first n bytes and not e.g. bytes only from offsets within the buffer that are a prime number. This change is non-functional, mostly just a rename. A secondary intent with this patch is to make room later to add a write callback. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: buffer-dmaengine: Report buffer length requirementsLars-Peter Clausen
The dmaengine buffer has some length alignment requirements that can differ from platform to platform. If the length alignment requirements are not met unexpected behavior like dropping of samples can occur. Currently these requirements are not reported and applications need to know the requirements of the platform by some out-of-band means. Add a new buffer attribute that reports the length alignment requirements called `length_align_bytes`. The reported length alignment is in bytes that means the buffer length alignment in sample sets depends on the number of enabled channels and the bytes per channel. Applications using this attribute to determine the buffer size requirements need to consider this. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: buffer-dmaengine: Add module informationLars-Peter Clausen
Make sure that the industrialio-buffer-dmaengine has proper license information so it can be build as a module and loaded without tainting the kernel. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-11-16iio: buffer-dmaengine: Use dma_request_chan() directly for channel requestPeter Ujfalusi
dma_request_slave_channel_reason() is: dma_request_chan(dev, name) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 149Thomas Gleixner
Based on 1 normalized pattern(s): licensed under the gpl 2 or later extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 82 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190524100845.150836982@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-13iio: buffer-dmaengine: Add missing header buffer_impl.hPhil Reid
Add buffer_impl.h as buffer.h was split into interface for using and for internals. Without this industrialio-buffer-dmaengine.c fails to compile. Fixes: commit 33dd94cb972175249258329c4aaffddcc82c2005 ("iio:buffer.h - split into buffer.h and buffer_impl.h") Signed-off-by: Phil Reid <preid@electromag.com.au> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-02-09iio: buffer-dmaengine: Use dmaengine_terminate_sync()Lars-Peter Clausen
The DMAengine framework gained support for synchronized transfer termination. Use the new dmaengine_terminate_sync() function instead of dmaengine_terminate_all(), this avoids a potential race condition when disabling the buffer. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-25iio: Add a DMAengine framework based bufferLars-Peter Clausen
Add a generic fully device independent DMA buffer implementation that uses the DMAegnine framework to perform the DMA transfers. This can be used by converter drivers that whish to provide a DMA buffer for converters that are connected to a DMA core that implements the DMAengine API. Apart from allocating the buffer using iio_dmaengine_buffer_alloc() and freeing it using iio_dmaengine_buffer_free() no additional converter driver specific code is required when using this DMA buffer implementation. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>