Specifically a helper for reading the available maximum raw value of a
channel and a helper for forwarding read_avail requests for raw values
from one iio driver to an iio channel that is consumed.
These rather specific helpers are in turn built with generic helpers
making it easy to build more helpers for available values as needed.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Allow access to underlying channel IIO_CHAN_INFO_OFFSET from a consumer.
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add iio_channel_cb_get_iio_dev function to allow getting the
underlying iio_dev. This is useful for setting the trigger of the
consumer ADC device.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some of kernel driver uses the IIO framework to get the sensor
value via ADC or IIO HW driver. The client driver get iio channel
by iio_channel_get_all() and release it by calling
iio_channel_release_all().
Add resource managed version (devm_*) of these APIs so that if client
calls the devm_iio_channel_get_all() then it need not to release it
explicitly, it can be done by managed device framework when driver
get un-binded.
This reduces the code in error path and also need of .remove callback in
some cases.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some of kernel driver uses the IIO framework to get the sensor
value via ADC or IIO HW driver. The client driver get iio channel
by iio_channel_get() and release it by calling iio_channel_release().
Add resource managed version (devm_*) of these APIs so that if client
calls the devm_iio_channel_get() then it need not to release it explicitly,
it can be done by managed device framework when driver get un-binded.
This reduces the code in error path and also need of .remove callback in
some cases.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fix buffer name from kernel doc according to the function parameter.
Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Introduce API for easy in-kernel setting of DAC values.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add iio_read_channel_average_raw to support reading
averaged raw values in consumer drivers.
Signed-off-by: Sebastian Reichel <sre@debian.org>
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>
For iio_channel_get to work with OF based configurations, it needs the
consumer device pointer instead of the consumer device name as argument.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Anton Vorontsov <anton@enomsg.org>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Pass device pointer instead of device name as parameter to iio_channel_get_all
and iio_channel_get_all_cb. This will enable us to use OF information to
retrieve consumer channel information.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Turns out that consumer.h needs to include types.h on some platforms to
build properly (like powerpc).
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This callback buffer is meant to be opaque to users, but basically
adds a very simple pass through buffer to which data may be
pushed when it is inserted into the buffer list.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Used to allow information about a given channel mapping to be passed
through from board files to the consumer drivers.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add a function to read a processed value from a channel. The function will first
attempt to read the IIO_CHAN_INFO_PROCESSED attribute. If that fails it will
read the IIO_CHAN_INFO_RAW attribute and convert the result from a raw value to
a processed value.
The patch also introduces a function to convert raw value to a processed value
and exports it, in case a user needs or wants to do the conversion by itself.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
For the iio_read_channel_raw and iio_read_channel_scale the kerneldoc comment
refers to an argument called "channel", while the argument is called "chan" in
the function signature. This leads to the following warnings from kerneldoc:
Warning(include/linux/iio/consumer.h:71): No description found for parameter 'chan'
Warning(include/linux/iio/consumer.h:71): Excess function parameter 'channel' description in 'iio_read_channel_raw'
Warning(include/linux/iio/consumer.h:109): No description found for parameter 'chan'
Warning(include/linux/iio/consumer.h:109): Excess function parameter 'channel' description in 'iio_read_channel_scale'
This patch fixes the warnings by naming them consistently.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The symbol name for the #ifndef and the #define of the include guard do not
match and thus it becomes quite ineffective. Add the missing '_' to fix this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
These were originally introduced when the plan was to have parallel
IIO cores in and out of staging with a slow move between them.
Now we have reached the point where the whole core has moved,
they need clearing up!
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Step 1 in moving the IIO core out of staging.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>