linux-toradex.git/drivers/iio/buffer/industrialio-buffer-dmaengine.c, branch v5.14

iio: buffer-dmaengine: simplify __devm_iio_dmaengine_buffer_free()

2021-05-17T12:49:06+00:00

Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.

Signed-off-by: Yicong Yang 
Reviewed-by: Lars-Peter Clausen 
Reviewed-by: Nuno Sa 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/1617881896-3164-3-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Jonathan Cameron

iio: buffer: introduce support for attaching more IIO buffers

2021-03-11T20:47:05+00:00

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:04+00:00

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:02+00:00

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: buffer: dmaengine: unwrap the use of iio_buffer_set_attrs()

2020-11-21T14:52:57+00:00

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 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200929125949.69934-2-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: remove non managed alloc/free

2020-09-29T16:27:06+00:00

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 
Link: https://lore.kernel.org/r/20200923121810.944075-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: adjust `bytes_used` with residue info

2020-09-03T18:40:58+00:00

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 
Signed-off-by: Lars-Peter Clausen 
Link: https://lore.kernel.org/r/20200826052011.13348-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: add dev-managed calls for buffer alloc

2020-04-19T15:56:22+00:00

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 
Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: use %zu specifier for sprintf(align)

2020-04-19T15:56:21+00:00

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 
Signed-off-by: Alexandru Ardelean 
Signed-off-by: Jonathan Cameron

iio: buffer: rename 'read_first_n' callback to 'read'

2019-12-29T15:20:09+00:00

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 
Signed-off-by: Alexandru Ardelean 
Signed-off-by: Jonathan Cameron