Given Linus announced a 4.8rc coming up, hopefully time for one more
lot of IIO patches this cycle. Some of these are actually
improvements / fixes for patches earlier in the cycle.
New device support
* st_accel driver - support devices with 8 bit channels.
Cleanup
* A general cleanup of the iio tools under /tools/ from Hartmut.
I'm more than a little embarassed by how bad some of these were! Are well,
much more refined and less bug prone now.
These cover lots of stuff like unhandled error returns, memory leaks as
well as general refactoring to tidy the code up.
* iio_simple_dummy - fix memory leaks in the init functions, drop some
pointless error returns from functions that never generate errors and
make the module parameter explicitly unsigned.
* More buffer handling reworks from Lars-Peter, this time targetting hardware
buffers (a little used corner that looks likely to get more use in the near
future). Specifically:
- Always compute the masklength as inkernel buffer users may need it.
- Add a means of labeling which buffer modes a given buffer implementation
supports.
- In the case of hardware buffers, require strict scan matching rather than
matching to a superset. Currently the demux is bypassed by these drivers
(this may well not change for efficiency reasons) so allowing a superset
of channels to be selected would otherwise lead to more data than requested
confusing userspace.
Driver funcationality improvments
* mmc35240 - adds a compensation to the raw values as borrowed form Memsic's
own input driver.
* mma8452
- event support
- event debouncing
- high pass filter configuration
- triggers
* vf610 - allow conversion mode to be adjusted
Fixlets
* mmc35240
- Off by one error that by coincidence had no real effect.
- i2c_device_name should be lowercase.
- Lack of null terminator at end of attributes array.
- Avoid computing the fractional part of the magnetic field by moving
the scaling into userspace where floating point is available to simplify
the maths.
- Use a smaller sleep before assuming the measurement is done. This is
safe and improves the possible polling rate.
- Fix sensitivity on z-axis - datasheet disagrees with Memsic's releasedd
code and the value used in the code seems to be correct.
* stk3310 - make a local variable signed to ensure error handling works.
* twl4030
- fix calculation of the temperature sense current - bug unlikely
to have ever been noticed as the difference is small.
- Fix errors in descriptions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVdgz8AAoJEFSFNJnE9BaIMSoP/RYq9yzkRtQ+T7ZnxdW0uaVK
W8zhcg9W62dKbu0ccMVI+ESv9bg+3Ti/ZHE2251olYzXER5qrUUqB7llpgJeoni+
ft1RyOZYYTWqv/2fx9Jdn+h4792tv4nykdgY3YhxR3anPD5Tb3PcRryCJ739d6xL
c8HZedMP9znbC7BiEzRcLBPiyiv+NFKHF0T6LCkwlTGoe6q+8yaW1blmxTRmtpnD
Wpf08/vafBmbjUmxfcvtgyOr73D6/kNOk9xYtvbQguD5nG5oHRe96nlaTtW7//hi
ybP0q+UPV7Hss1pgufEZufPfWglsqOpIWJ7diUyXzvf9x7FAUd2nuiAHKybUg4bT
yC2dSCVgRAa1zLEwcTub5MNtjkcfM0l9wsnCCIssD5p9s4EEenge1UjHsV7zm/KA
JzBKBRz98Mo6m+F2gWZkkpuIb9UbI99oLBVDzhFBYf77b1L8curJ+pBH2lcICMun
K5+WC3itkl7QImbyrCXdHmu9/oWS2+MSVHsmmL4omMFb071/C1iAUCIJahJrbgcy
jIjaNJp3WgOplQp4tlP6WtsbzHh0DzjjLj+RKFv2mqYMlHhhAFdoH68qXPxG3kYo
IxyGh7sH7ic5BQyt4B8/GhxakDuf55O/kyS7t01B3c5JbJp/IAbobfWkpCtuICYV
GIIZTKI5kJb1Q8P7AbUD
=sNVc
-----END PGP SIGNATURE-----
Merge tag 'iio-for-v4.2c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Third round of new IIO drivers, cleanups and functionality for the 4.2 cycle.
Given Linus announced a 4.8rc coming up, hopefully time for one more
lot of IIO patches this cycle. Some of these are actually
improvements / fixes for patches earlier in the cycle.
New device support
* st_accel driver - support devices with 8 bit channels.
Cleanup
* A general cleanup of the iio tools under /tools/ from Hartmut.
I'm more than a little embarassed by how bad some of these were! Are well,
much more refined and less bug prone now.
These cover lots of stuff like unhandled error returns, memory leaks as
well as general refactoring to tidy the code up.
* iio_simple_dummy - fix memory leaks in the init functions, drop some
pointless error returns from functions that never generate errors and
make the module parameter explicitly unsigned.
* More buffer handling reworks from Lars-Peter, this time targetting hardware
buffers (a little used corner that looks likely to get more use in the near
future). Specifically:
- Always compute the masklength as inkernel buffer users may need it.
- Add a means of labeling which buffer modes a given buffer implementation
supports.
- In the case of hardware buffers, require strict scan matching rather than
matching to a superset. Currently the demux is bypassed by these drivers
(this may well not change for efficiency reasons) so allowing a superset
of channels to be selected would otherwise lead to more data than requested
confusing userspace.
Driver funcationality improvments
* mmc35240 - adds a compensation to the raw values as borrowed form Memsic's
own input driver.
* mma8452
- event support
- event debouncing
- high pass filter configuration
- triggers
* vf610 - allow conversion mode to be adjusted
Fixlets
* mmc35240
- Off by one error that by coincidence had no real effect.
- i2c_device_name should be lowercase.
- Lack of null terminator at end of attributes array.
- Avoid computing the fractional part of the magnetic field by moving
the scaling into userspace where floating point is available to simplify
the maths.
- Use a smaller sleep before assuming the measurement is done. This is
safe and improves the possible polling rate.
- Fix sensitivity on z-axis - datasheet disagrees with Memsic's releasedd
code and the value used in the code seems to be correct.
* stk3310 - make a local variable signed to ensure error handling works.
* twl4030
- fix calculation of the temperature sense current - bug unlikely
to have ever been noticed as the difference is small.
- Fix errors in descriptions.
For each buffer type specify the supported device modes for this buffer.
This allows us for devices which support multiple different operating modes
to pick the correct operating mode based on the modes supported by the
attached buffers.
It also prevents that buffers with conflicting modes are attached
to a device at the same time or that a buffer with a non-supported mode is
attached to a device (e.g. in-kernel callback buffer to a device only
supporting hardware mode).
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Check whether the allocation of a new kfifo buffer failed or not before
setting the update_needed flag to false. This will make
iio_request_update_kfifo() try to allocate a new buffer the next time a
buffer update is requested.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Currently the IIO buffer blocking read only wait until at least one
data element is available.
This patch makes the reader sleep until enough data is collected before
returning to userspace. This should limit the read() calls count when
trying to get data in batches.
Co-author: Yannick Bedhomme <yannick.bedhomme@mobile-devices.fr>
Signed-off-by: Josselin Costanzi <josselin.costanzi@mobile-devices.fr>
[rebased and remove buffer timeout]
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio kfifo allocate/free gained their devm_ wrappers.
Signed-off-by: Karol Wrona <k.wrona@samsung.com>
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
indio_dev was unused in function body plus some small style fix - add new
lines after "if(sth) return sth" and before the last return statement.
The argument was removed also in its client.
Signed-off-by: Karol Wrona <k.wrona@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We already do have the length field in the struct iio_buffer which is
expected to be in sync with the current size of the buffer. And currently
all implementations of the get_length callback either return this field or a
constant number.
This patch removes the get_length callback and replaces all occurrences in
the IIO core with directly accessing the length field of the buffer.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
All buffers want at least the length and the enable attribute. Move the
creation of those attributes to the core instead of having to do this in
each individual buffer implementation. This allows us to get rid of some
boiler-plate code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
There haven't been any users of the get_bytes_per_datum() callback for a
while. The core assumes that the number of bytes per datum can be calculated
based on the enabled channels and the storage size of the channel and
iio_compute_scan_bytes() is used to compute this number. So remove the
callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch implements the data_available() callback for the kfifo buffer instead
of using the stufftoread flag. The kfifo used by the buffer already knows
whether it is empty or not based on the position of its read and write pointer.
Using this makes it a lot easier to tell whether data is available or not and it
is not necessary to take special measures to ensure that no race conditions
between reading and writing from the buffer occur.
Note, that we still have to take the buffers lock to protect against concurrent
resizeing of the kfifo.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
update_needed is used to decide whether the kfifo buffer needs to be
re-allocated. It is set to true whenever the size of the buffer is changed. It
is never set to false though, causing the buffer to always be re-allocated.
Setting update_needed to false after the new buffer has been allocated fixes the
problem.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan 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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan 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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan 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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan 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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan 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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan 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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan 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: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
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: Jonathan Cameron <jic23@kernel.org>
Tested-by: Lars-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: Jonathan Cameron <jic23@kernel.org>
Tested-by: Lars-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: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
