The kfifo's request_update callback will free the current buffer and allocate a
new one if the size has changed. This will remove any samples that might still
be left in the buffer. If the size has not changed the buffer content is
left untouched though. This is a bit inconsistent and might cause an application
to see data from a previous capture. This patch inserts a call to
kfifo_reset_out() when the size did not change. This makes sure that any pending
samples are removed from the buffer.

Note, due to a different bug the buffer is currently always re-allocated, even
if the size did not change. So this patch will not change the behavior. In the
next patch the bug will be fixed and this patch makes sure that the current
behavior is kept.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

It is possible for userspace to concurrently access the buffer from multiple
threads or processes. To avoid corruption of the internal state of the buffer we
need to add proper locking. It is possible for multiple processes to try to read
from the buffer concurrently and it is also possible that one process causes a
buffer re-allocation while a different process still access the buffer. Both can
be fixed by protecting the calls to kfifo_to_user() and kfifo_alloc() by the
same mutex. In iio_read_first_n_kfifo() we also use kfifo_recsize() instead of
the buffers bytes_per_datum to avoid a race that can happen if bytes_per_datum
has been changed, but the buffer has not been reallocated yet.

Note that all access to the buffer from within the kernel is already properly
synchronized, so there is no need for extra locking in iio_store_to_kfifo().
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

We need to free the kfifo when we release the buffer, otherwise the fifos memory
will be leaked.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Since the buffer is accessed by userspace we can not just free the buffers
memory once we are done with it in kernel space. There might still be open file
descriptors and userspace still might be accessing the buffer. This patch adds
support for reference counting to the IIO buffers. When a buffer is created and
initialized its initial reference count is set to 1. Instead of freeing the
memory of the buffer the buffer's _free() function will drop that reference
again. But only after the last reference to the buffer has been dropped the
buffer the buffer's memory will be freed. The IIO device will take a reference
to its primary buffer. The patch adds a small helper function for this called
iio_device_attach_buffer() which will get a reference to the buffer and assign
the buffer to the IIO device. This function must be used instead of assigning
the buffer to the device by hand. The reference is only dropped once the IIO
device is freed and we can be sure that there are no more open file handles. A
reference to a buffer will also be taken whenever the buffer is active to avoid
the buffer being freed while data is still being send to it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Change the type of the 'data' parameter for iio_push_to_buffers() from 'u8 *' to
'const void *'. Drivers typically use the correct type (e.g. __be16 *) for their
data buffer. When passing the buffer to iio_push_to_buffers() it needs to be
cast to 'u8 *' for the compiler to not complain (and also having to add __force
if we want to keep sparse happy as well). Since the buffer implementation should
not care about the data layout (except the size of one sample) using a void
pointer is the correct thing to do. Also make it const as the buffer
implementations are not supposed to modify it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Use wake_up_interruptible_poll() instead of wake_up_interruptible() to only wake
up those threads that listen for input poll notifications.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

__iio_update_buffer updates the buffer's bytes_per_datum and length fields.
But the only user of this function just passes in these exact fields, so the
call basically looks like this:

	buffer->bytes_per_datum = buffer->bytes_per_datum;
	buffer->length = buffer->length;

Which means it is a noop and can be removed. Also remove the function itself,
since it is now unused.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Drop timestamp parameter from buffer store_to callback and subsequently from
iio_push_to_buffer. The timestamp parameter is unused and it seems likely that
it will stay unused in the future, so it should be safe to remove it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This buffer implementation was missing poll support.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: Nsrinivas pandruvada <srinivas.pandruvada@intel.com>

These two elements were originally in the patch
iio:kfifo_buf  Take advantage of the fixed record size used in IIO
but Lars-Peter Clausen pointed out they should not have been
so here they are.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>

By bypassing the standard macros for setting up the kfifo we can
take advantage of the fixed record size implementation without
having to have a type to pass in (from which the size of an element
is normally established).

In IIO we have variable 'scans' as our records in which any element
can be present or not.  They do not however vary when we are
actually filling or reading from the buffer.  Thus we have a fixed
record size whenever we are actually running.  As setup and tear
down are not in the fast path we can take the overhead of reinitializing
the kfifo every time.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>

Take the core support + the kfifo buffer implentation out of
staging.  Whilst we are far from done in improving this subsystem
it is now at a stage where the userspae interfaces (provided by
the core) can be considered stable.

Drivers will follow over a longer time scale.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Step 1 in moving the IIO core out of staging.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Setup the buffer access functions in the buffer allocate function. There is no
need to let each driver handle this on its own.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These callbacks are currently used by the individual buffer implementations to
ensure that the request_update callback is not issued while the buffer is in use.
But the core already provides sufficient measures to prevent this from happening
in the first place. So it is safe to remove them.

There is one functional change due to this patch. Since the buffer is no longer
marked as in use when the chrdev is opened, it is now possible to enable the
buffer while it is opened. This did not work before, because mark_param_change
did fail if the buffer was marked as in use.
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Right now we have a mark_param_change callback in the buffer access
functions struct, which should be called whenever the parameters (length,
bytes per datum) of the buffer change. But it is only called when the user
changes the buffer size, not when the bytes per datum change. Additionally each
buffer implementation already keeps track internally whether its parameters
have changed, making the call to mark_param_change after changing the buffer
length redundant. Since each buffer implementation knows best when one of its
parameters has changed just make tracking of this internal and drop the
mark_param_change callback.
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

n is the number of bytes to read, not the number of samples. So if there is
enough data available we will write to the userspace buffer beyond its bounds.
Fix this by copying n bytes maximum. Also round n down to the next multiple of
the sample size, so we will only read complete samples. If the buffer is too
small to hold at least one sample return -EINVAL.

Also update the documentation of read_first_n to reflect the fact that 'n' is
supposed to be in bytes and not in samples.
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In all existing cases, the calls are coming from a location where
the indio_dev is already available.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There are no known reasons why userspace should want this value.
It can be established from the buffer description anyway.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I really don't want to think about how this bit got
in there.  It allocates some storage - copies something
into it then frees it without making use of it.
Oops.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

They aren't always ring buffers, so just use buffer for all naming.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Sorry all, this one is very invasive, though the driver changes are
just trivial interface fixes. Not all done yet.

V2 - bring the sca3000 with us.
V3 - fix ade7758 bugs in conversion.
V4 - add ad5933
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Nothing other than the implementation needs to know about this.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Looks like this moved into the core at somepoint and kfifo buf got left
behind.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

1) move a generic helper function out of ring_sw. It applies to other buffers as well.
2) Get rid of a lot of left over function definitions.
3) Move all the access functions into static structures.
4) Introduce and use a static structure for the setup functions, preenable etc.

Some driver conversions thanks to Michael Hennerich (pulled out of patches
that would otherwise sit after this).
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

staging:iio:buffering remove unused parameter dead_offset from read_last_n in all buffer implementations.

This element has been usused by the core for quite some time.  sca3000 set it none the less
until the rewrite in the previous patch (and hence didn't work).
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change suggested by Arnd Bergmann, Related patch to remove
pointless (now) dead_offset parameter will have await
proper fix for the sca3000 driver.  That depends on
some intermediate patches so may be a little while.
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A very simple use of a kfifo as an alternative for the ring_sw
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Tested-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>