Most ST MEMS Sensors that support interrupts can also handle sending
an active low interrupt, i.e. going from high to low on data ready
(or other interrupt) and thus triggering on a falling edge to the
interrupt controller.
Set up logic to inspect the interrupt line we get for a sensor: if
it is triggering on rising edge, leave everything alone, but if it
triggers on falling edges, set up active low, and if unsupported
configurations appear: warn with errors and reconfigure the interrupt
to a rising edge, which all interrupt generating sensors support.
Create a local header for st_sensors_core.h to share functions
between the sensor core and the trigger setup code.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Make IIO value formating function globally available to allow IIO drivers
to output values as the core does.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This exported element needs to be accesible to all drivers using configfs
within IIO. Previously it was in the sw_trig.h file which only convered one
such usecase. This also fixes a sparse warning as it is now in a header
that makes sense to include from industrialio-configfs.c
Signed-off-by: Jonathan Cameron < jic23@kernel.org>
A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for handling software triggers.
Software interrupts sources are kept in a iio_trigger_types_list and
registered separately when the associated kernel module is loaded.
Software triggers can be created directly from drivers or from user
space via configfs interface.
To sum up, this dynamically creates "triggers" group to be found under
/config/iio/triggers and offers the possibility of dynamically
creating trigger types groups. The first supported trigger type is
"hrtimer" found under /config/iio/triggers/hrtimer.
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
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>
The traditional approach used in IIO to implement buffered capture requires
the generation of at least one interrupt per sample. In the interrupt
handler the driver reads the sample from the device and copies it to a
software buffer. This approach has a rather large per sample overhead
associated with it. And while it works fine for samplerates in the range of
up to 1000 samples per second it starts to consume a rather large share of
the available CPU processing time once we go beyond that, this is
especially true on an embedded system with limited processing power. The
regular interrupt also causes increased power consumption by not allowing
the hardware into deeper sleep states, which is something that becomes more
and more important on mobile battery powered devices.
And while the recently added watermark support mitigates some of the issues
by allowing the device to generate interrupts at a rate lower than the data
output rate, this still requires a storage buffer inside the device and
even if it exists it is only a few 100 samples deep at most.
DMA support on the other hand allows to capture multiple millions or even
more samples without any CPU interaction. This allows the CPU to either go
to sleep for longer periods or focus on other tasks which increases overall
system performance and power consumption. In addition to that some devices
might not even offer a way to read the data other than using DMA, which
makes DMA mandatory to use for them.
The tasks involved in implementing a DMA buffer can be divided into two
categories. The first category is memory buffer management (allocation,
mapping, etc.) and hooking this up the IIO buffer callbacks like read(),
enable(), disable(), etc. The second category of tasks is to setup the
DMA hardware and manage the DMA transfers. Tasks from the first category
will be very similar for all IIO drivers supporting DMA buffers, while the
tasks from the second category will be hardware specific.
This patch implements a generic infrastructure that take care of the former
tasks. It provides a set of functions that implement the standard IIO
buffer iio_buffer_access_funcs callbacks. These can either be used as is or
be overloaded and augmented with driver specific code where necessary.
For the DMA buffer support infrastructure that is introduced in this series
sample data is grouped by so called blocks. A block is the basic unit at
which data is exchanged between the application and the hardware. The
application is responsible for allocating the memory associated with the
block and then passes the block to the hardware. When the hardware has
captured the amount of samples equal to size of a block it will notify the
application, which can then read the data from the block and process it.
The block size can freely chosen (within the constraints of the hardware).
This allows to make a trade-off between latency and management overhead.
The larger the block size the lower the per sample overhead but the latency
between when the data was captured and when the application will be able to
access it increases, in a similar way smaller block sizes have a larger per
sample management overhead but a lower latency. The ideal block size thus
depends on system and application requirements.
For the time being the infrastructure only implements a simple double
buffered scheme which allocates two blocks each with half the size of the
configured buffer size. This provides basic support for capturing
continuous uninterrupted data over the existing file-IO ABI. Future
extensions to the DMA buffer infrastructure will give applications a more
fine grained control over how many blocks are allocated and the size of
each block. But this requires userspace ABI additions which are
intentionally not part of this patch and will be added separately.
Tasks of the second category need to be implemented by a device specific
driver. They can be hooked up into the generic infrastructure using two
simple callbacks, submit() and abort().
The submit() callback is used to schedule DMA transfers for blocks. Once a
DMA transfer has been completed it is expected that the buffer driver calls
iio_dma_buffer_block_done() to notify. The abort() callback is used for
stopping all pending and active DMA transfers when the buffer is disabled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds a enable and disable callback that is called when the
buffer is enabled/disabled. This can be used by buffer implementations that
need to do some setup or teardown work. E.g. a DMA based buffer can use
this to start/stop the DMA transfer.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
For buffers which have a fixed wake-up watermark the watermark attribute
should be read-only. Add a new FIXED_WATERMARK flag to the
struct iio_buffer_access_funcs, which can be set by a buffer
implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Support triggered events.
This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This adds a debugfs hook to read/write registers in the ST
sensors using debugfs. Proved to be awesome help when trying
to debug why IRQs do not arrive.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add inverse unit conversion macro to convert from standard IIO units to
units that might be used by some devices.
Those are useful in combination with scale factors that are specified as
IIO_VAL_FRACTIONAL. Typically the denominator for those specifications will
contain the maximum raw value the sensor will generate and the numerator
the value it maps to in a specific unit. Sometimes datasheets specify those
in different units than the standard IIO units (e.g. degree/s instead of
rad/s) and so we need to do a unit conversion.
From a mathematical point of view it does not make a difference whether we
apply the unit conversion to the numerator or the inverse unit conversion
to the denominator since (x / y) / z = x / (y * z). But as the denominator
is typically a larger value and we are rounding both the numerator and
denominator to integer values using the later method gives us a better
precision (E.g. the relative error is smaller if we round 8000.3 to 8000
rather than rounding 8.3 to 8).
This is where in inverse unit conversion macros will be used.
Marked for stable as used by some upcoming fixes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
When compile iio related driver the following warning shown:
include/linux/iio/trigger.h:35:34: warning: 'struct iio_trigger'
declared inside parameter list
int (*set_trigger_state)(struct iio_trigger *trig, bool state);
include/linux/iio/trigger.h:38:18: warning: 'struct iio_dev'
declared inside parameter list
struct iio_dev *indio_dev);
'struct iio_dev' and 'struct iio_trigger' was used before declaration,
forward declaration for these structs to fix warning.
Signed-off-by: Pengyu Ma <pengyu.ma@windriver.com>
Acked-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fix kernel doc for the iio_dev_attr structure by adding its missing field.
Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.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>
This patch permits to configure the WhoAmI register address
because some device could have not a standard address for
this register.
Signed-off-by: Giuseppe Barba <giuseppe.barba@st.com>
Reviewed-by: Denis Ciocca <denis.ciocca@st.com>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch renames the top half handler and the bottom half handler
of iio_triggered_buffer_setup() in accordance with their usage.
The bottom half has been renamed to reflect the fact that it is a
thread based call, compliant with iio_alloc_pollfunc().
The names of the parameters were swapped, thus creating confusion.
Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
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>
Add a high pass filter attribute for measurements
(like the existing low pass)
Also add both high and low pass attributes for events.
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some magnetometers can perform a number of repetitions in HW
for each measurement to increase accuracy. One example is
Bosch BMC150:
http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf.
Introduce an interface to set the oversampling ratio
for these devices.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some devices have hardware buffers that can store a number of samples
for later consumption. Hardware usually provides interrupts to notify
the processor when the FIFO is full or when it has reached a certain
watermark level. This helps with reducing the number of interrupts to
the host processor and thus it helps decreasing the power consumption.
This patch enables usage of hardware FIFOs for IIO devices in
conjunction with software device buffers. When the hardware FIFO is
enabled the samples are stored in the hardware FIFO. The samples are
later flushed to the device software buffer when the number of entries
in the hardware FIFO reaches the hardware watermark or when a flush
operation is triggered by the user when doing a non-blocking read
on an empty software device buffer.
In order to implement hardware FIFO support the device drivers must
implement the following new operations: setting and getting the
hardware FIFO watermark level, flushing the hardware FIFO to the
software device buffer. The device must also expose information about
the hardware FIFO such it's minimum and maximum watermark and if
necessary a list of supported watermark values. Finally, the device
driver must activate the hardware FIFO when the device buffer is
enabled, if the current device settings allows it.
The software device buffer watermark is passed by the IIO core to the
device driver as a hint for the hardware FIFO watermark. The device
driver can adjust this value to allow for hardware limitations (such
as capping it to the maximum hardware watermark or adjust it to a
value that is supported by the hardware). It can also disable the
hardware watermark (and implicitly the hardware FIFO) it this value is
below the minimum hardware watermark.
Since a driver may support hardware FIFO only when not in triggered
buffer mode (due to different semantics of hardware FIFO sampling and
triggered sampling) this patch changes the IIO core code to allow
falling back to non-triggered buffered mode if no trigger is enabled.
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>
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>
MAX520 and MAX521 are protocol-compatible with the already supported
chips, just have more channels.
Signed-off-by: Antonio Fiol <antonio@fiol.es>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
After UAPI header file split [1] all user-kernel interfaces were
placed under include/uapi/.
This patch moves IIO user specific API from:
* include/linux/iio/events.h => include/uapi/linux/iio/events.h
* include/linux/types.h => include/uapi/linux/types.h
Now there is no need for nasty tricks to compile userspace programs
(e.g iio_event_monitor). Just installing the kernel headers with
make headers_install command does the job.
[1] http://lwn.net/Articles/507794/
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The pedometer needs to filter out false steps that might be generated by
tapping the foot, sitting, etc. To do that it computes the number of
steps that occur in a given time and decides the user is moving only
if this value is over a threshold. E.g.: the user starts moving only
if he takes 4 steps in 3 seconds. This filter is applied only when
the user starts moving.
A device that has such pedometer functionality is Freescale's MMA9553L:
http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf.
To export this feature, this patch introduces IIO_CHAN_INFO_DEBOUNCE_COUNT
and IIO_CHAN_INFO_DEBOUNCE_TIME. For the pedometer, in_steps_debounce_count
will specify the number of steps that need to occur in
in_steps_debounce_time seconds so that the pedometer decides the user is
moving.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Sensorhub is MCU dedicated to collect data and manage several sensors.
Sensorhub is a spi device which provides a layer for IIO devices. It provides
some data parsing and common mechanism for sensorhub sensors.
Adds common sensorhub library for sensorhub driver and iio drivers
which uses sensorhub MCU to communicate with sensors.
Signed-off-by: Karol Wrona <k.wrona@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
By introducing IIO_EV_TYPE_CHANGE, IIO_EV_TYPE_INSTANCE becomes redundant.
The effect of IIO_EV_TYPE_INSTANCE can be obtained by using IIO_EV_TYPE_CHANGE
with IIO_EV_INFO_VALUE set to 1.
Remove all instances of IIO_EV_TYPE_INSTANCE and replace them with
IIO_EV_TYPE_CHANGE where needed.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
A step detector will generate an interrupt each time N step are detected.
A device that has such pedometer functionality is Freescale's MMA9553L:
http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf.
Introduce IIO_EV_TYPE_CHANGE event type for events that are generated
when the channel passes a threshold on the absolute change in value.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some devices need the weight of the user to compute other
parameters. One of this devices is Freescale's MMA9553L
(http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
that needs the weight of the user to compute the number of calories burnt.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some devices export the current speed value of the user.
One of this devices is Freescale's MMA9553L
(http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
that computes the speed of the user based on the number of steps and
stride length.
Introduce a new channel type VELOCITY and a modifier for the magniture or
norm of the velocity vector, IIO_MOD_ROOT_SUM_SQUARED_X_Y_Z.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some devices export an estimation of the distance the user has covered
since the last reset.
One of this devices is Freescale's MMA9553L
(http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
that computes the distance based on the stride length and step rate.
Introduce a new channel type DISTANCE to export these values.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Human activity sensors report the energy burnt by the user.
One of this devices is Freescale's MMA9553L
(http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
that computes the number of calories based on weight and step rate.
Introduce a new channel type ENERGY to export these values.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
There was a need for non triggered software buffer type. It can be used when
triggered model does not fit and INDIO_BUFFER_HARDWARE causes confusion because
the data stream can be obtained not directly form hardware backend.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Karol Wrona <k.wrona@samsung.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Updated pull request with Daniel's fix on top for the power management
Kconfig changes that had snuck in since last update of the IIO tree
worked it's way through from mainline.
Original pull message
New device support
* jsa1212 proxmity / ambient light sensor
* SM08500 supported added to the kxcjk-1013 accelerometer driver
* KMX61 Accelerometer/Magnetometer. This took a somewhat rocky path
being first merged, then reverted for a rewrite after a discussion of
how to support additional functionality and finally being merged prior
to some last reviews coming in, with resultant follow up patches.
* Freescale mma9551l driver (minor follow up warning supression patch).
* Semtech SX9500 proximity device driver.
* ak8975 gains support for ak09911 and ak09912 and drop the standalone driver
for the ak09911.
New functionality
* Dummy driver gains some virtual registers making it more flexible.
* IIO_ACTIVITY channel types, with modifiers running, walking etc. This is
to support on chip motion clasifiers. As such it is in the form of a
confidence percentage. The only devices so far only do binary decisions
but this gives us room when other devices give more nuanced clasification.
* IIO_EV_DIR_NONE type for events where there is no obvious direction.
First case is step detection.
* IIO_STEPS channel type for pedometers.
* ENABLE mask element used to control turning on counting types such as
the pedometer that need a 'start point'.
* INSTANCE event type to support things that happen once.
* info element for height calibration (used in various motion estimation
algorithms). Note heigh tof use
* dummy driver demonstration of the use of all the new bits above.
* event monitor support for the new events.
* inv_mpu6050 gains an i2c mux to allow bypassing the device to access
additional devices connected on the other side of it. Note that in
Windows these are handled by firmware on the device and not exposed
directly.
* inv_mpu6050 gains ACPI enumeration.
* inkern interface gains iio_write_channel_raw to allow in kernel users
of DAC functionality via a simple wrapper.
* Document input current readings in the ABI docs.
* Add an error message when we get an out of range error in device tree
processing for the in kernel interfaces. Basically a device tree debugging
aid.
* Add a sanity check that a scan index for a channel is unique during
registration. There to help catch bugs as this should never happen
in a bug free driver.
Cleanups and fixlets
A rework of buffer registration from Lars - a precursor to some other
upcoming new stuff (a few patches from others rolled in here as well).
* Ensure all drivers register the same channels for the device and buffer.
* Move buffer registration into the core rather than using the old
two step approach. Now we have simple ways of using a unified set channels
for both without requiring channels be exposed by both interface, this
removes a fair bit of boilerplate.
* Stop sca3000 and ad5933 (both in staging) enabling buffer channels by
default. It has long be convention in IIO to startup with no channels
enabled and leave it up to userspace to say what goes in the buffer.
Getting rid of these allows us to drop export of iio_scan_mask_set.
* Drop get_bytes_per_datum from iio_buffer_access_funcs as not been used
for a while.
* Allocate standard buffer attributes in the core rather than in every
driver with a buffer.
* Make the length attribute read only when a driver is not able to set
the length.
* Drop the get_length callback for buffers as it is already available in
struct iio_buffer.
* Drop an unused arguement form iio_kfifo_allocate and add devm allocator
for it.
* some kconfig entries gain anotation with the resulting module name.
* Fix a resulting compile issue in dummy driver due to a stub taking
wrong parameters as a result of the above rework.
* Fix an off by 2 error in copying the core assigned buffer attributes.
Other cleanups,
* Trivial space before comma fixups.
* ak8975 fixlets - none critical. Rework to allow more device support.
* Drop unnecessary sizeof(u8) calls.
* bmp280 - refactor the compensation code to reduce copy operations and
code length. A second patch futher optimized this and performed some
other minor cleanups.
* kxcjk-1013 - various power control cleanups to avoid unnecessary enable
/ disable of device. Make sure it is only controlled at all if CONFIG_PM
is enabled. Also som cleanups of error paths.
* Small cleanups in adf4530 driver - pointless message and unnecessary braces.
* Clarifiy the proximity ABI docs to make it clear it should get bigger
as we move futher away.
* Drop a misleading comment form industrialio-core.c
* Trivial white space cleanups.
* sca3000 looses an unused debug function.
* Fix char unsigned ordering in ad8366
* Increase the sleep time in ad9523 to make it predictable (value didn't
really matter so make it more than 20 msecs)
* mxs-lradc touchscreen property cleanups in device tree are fixed to ensure
the meet all the 'interesting' documentation.
* A couple of cleanups for the staging ad5933 driver to avoid unnecessary
conversion to a processed temperature vlaue in kernel and remove
platform data form the state structure as not needed after probe.
* Fix a wrong scale factor in the docs.
Misc
* Add IIO include files to the maintainers entry.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJUvtDlAAoJEFSFNJnE9BaIaNMQAI9ZYOrOmvSpxPV4ab71it9z
gi03VG8+iJl0dPgwcSHeFZvSDiNAOWSX/XdWLoxFAdpjpsnytIp01s9+c3ogz58j
pYbjxuOT2Qcf+36REuaFkQPFV2ppXMvwDwFUUNeFVupu+bVUKeZuNafBDp00aN1c
o4MPDwoS1EcTHL+77iCg06exL8LozOwLabfUTRVIRkhIqikemghcmubQHH06m+dk
EMddtNcXTVR4cJLX076nkKsNDHgmfoBYL9Hy/OvQbjWYAxoZg+q90ZX8yCy0Z5oW
otChj5XpoYRIa7X6xvP5kTebD4iiR/COWer83EyqFosXhmQ/27rWasST42j1K3q/
mU40skbscDef4F6COMlgBtVh1FhKUm9AHPAGk5swW792Qjpd4xdt+GShU5bJCa4O
OOZYk8ulraELeWVz2IK+CrOvJYeTSrNQR6VA6sBjWRHeqxtB0yOJkhxX9NUcSIgJ
GwM8qNTrQUkvI7OGvFGvf8hp9cboJTKEfzC+yspj+OJSjgJgNWw2pOjzJjsexxaL
nT2rKhPg46hC+FR4IvPPjhGihCtMSgBWkwbHSeXH+TgRfbbTUh6y6sqEUZraVhnQ
LKde54G0aH1XBFIM6fwWIPgdWBWsI3b3pFuBRMzhORdcCuAUOvDSyc5hVcaA8qb5
UZghapUruB556xjoMV3n
=LlJD
-----END PGP SIGNATURE-----
Merge tag 'iio-for-3.20a_take2' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-testing
Jonathan writes:
First round of IIO new drivers, cleanups and functionality for the 3.20 cycle take 2
Updated pull request with Daniel's fix on top for the power management
Kconfig changes that had snuck in since last update of the IIO tree
worked it's way through from mainline.
Original pull message
New device support
* jsa1212 proxmity / ambient light sensor
* SM08500 supported added to the kxcjk-1013 accelerometer driver
* KMX61 Accelerometer/Magnetometer. This took a somewhat rocky path
being first merged, then reverted for a rewrite after a discussion of
how to support additional functionality and finally being merged prior
to some last reviews coming in, with resultant follow up patches.
* Freescale mma9551l driver (minor follow up warning supression patch).
* Semtech SX9500 proximity device driver.
* ak8975 gains support for ak09911 and ak09912 and drop the standalone driver
for the ak09911.
New functionality
* Dummy driver gains some virtual registers making it more flexible.
* IIO_ACTIVITY channel types, with modifiers running, walking etc. This is
to support on chip motion clasifiers. As such it is in the form of a
confidence percentage. The only devices so far only do binary decisions
but this gives us room when other devices give more nuanced clasification.
* IIO_EV_DIR_NONE type for events where there is no obvious direction.
First case is step detection.
* IIO_STEPS channel type for pedometers.
* ENABLE mask element used to control turning on counting types such as
the pedometer that need a 'start point'.
* INSTANCE event type to support things that happen once.
* info element for height calibration (used in various motion estimation
algorithms). Note heigh tof use
* dummy driver demonstration of the use of all the new bits above.
* event monitor support for the new events.
* inv_mpu6050 gains an i2c mux to allow bypassing the device to access
additional devices connected on the other side of it. Note that in
Windows these are handled by firmware on the device and not exposed
directly.
* inv_mpu6050 gains ACPI enumeration.
* inkern interface gains iio_write_channel_raw to allow in kernel users
of DAC functionality via a simple wrapper.
* Document input current readings in the ABI docs.
* Add an error message when we get an out of range error in device tree
processing for the in kernel interfaces. Basically a device tree debugging
aid.
* Add a sanity check that a scan index for a channel is unique during
registration. There to help catch bugs as this should never happen
in a bug free driver.
Cleanups and fixlets
A rework of buffer registration from Lars - a precursor to some other
upcoming new stuff (a few patches from others rolled in here as well).
* Ensure all drivers register the same channels for the device and buffer.
* Move buffer registration into the core rather than using the old
two step approach. Now we have simple ways of using a unified set channels
for both without requiring channels be exposed by both interface, this
removes a fair bit of boilerplate.
* Stop sca3000 and ad5933 (both in staging) enabling buffer channels by
default. It has long be convention in IIO to startup with no channels
enabled and leave it up to userspace to say what goes in the buffer.
Getting rid of these allows us to drop export of iio_scan_mask_set.
* Drop get_bytes_per_datum from iio_buffer_access_funcs as not been used
for a while.
* Allocate standard buffer attributes in the core rather than in every
driver with a buffer.
* Make the length attribute read only when a driver is not able to set
the length.
* Drop the get_length callback for buffers as it is already available in
struct iio_buffer.
* Drop an unused arguement form iio_kfifo_allocate and add devm allocator
for it.
* some kconfig entries gain anotation with the resulting module name.
* Fix a resulting compile issue in dummy driver due to a stub taking
wrong parameters as a result of the above rework.
* Fix an off by 2 error in copying the core assigned buffer attributes.
Other cleanups,
* Trivial space before comma fixups.
* ak8975 fixlets - none critical. Rework to allow more device support.
* Drop unnecessary sizeof(u8) calls.
* bmp280 - refactor the compensation code to reduce copy operations and
code length. A second patch futher optimized this and performed some
other minor cleanups.
* kxcjk-1013 - various power control cleanups to avoid unnecessary enable
/ disable of device. Make sure it is only controlled at all if CONFIG_PM
is enabled. Also som cleanups of error paths.
* Small cleanups in adf4530 driver - pointless message and unnecessary braces.
* Clarifiy the proximity ABI docs to make it clear it should get bigger
as we move futher away.
* Drop a misleading comment form industrialio-core.c
* Trivial white space cleanups.
* sca3000 looses an unused debug function.
* Fix char unsigned ordering in ad8366
* Increase the sleep time in ad9523 to make it predictable (value didn't
really matter so make it more than 20 msecs)
* mxs-lradc touchscreen property cleanups in device tree are fixed to ensure
the meet all the 'interesting' documentation.
* A couple of cleanups for the staging ad5933 driver to avoid unnecessary
conversion to a processed temperature vlaue in kernel and remove
platform data form the state structure as not needed after probe.
* Fix a wrong scale factor in the docs.
Misc
* Add IIO include files to the maintainers entry.
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>
Originally device and buffer registration were kept as separate operations
in IIO to allow to register two distinct sets of channels for buffered and
non-buffered operations. This has since already been further restricted and
the channel set registered for the buffer needs to be a subset of the
channel set registered for the device. Additionally the possibility to not
have a raw (or processed) attribute for a channel which was registered for
the device was added a while ago. This means it is possible to not register
any device level attributes for a channel even if it is registered for the
device. Also if a channel's scan_index is set to -1 and the channel is
registered for the buffer it is ignored.
So in summary it means it is possible to register the same channel array for
both the device and the buffer yet still end up with distinctive sets of
channels for both of them. This makes the argument for having to have to
manually register the channels for both the device and the buffer invalid.
Considering that the vast majority of all drivers want to register the same
set of channels for both the buffer and the device it makes sense to move
the buffer registration into the core to avoid some boiler-plate code in the
device driver setup path.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Individual drivers should not be messing with the scan mask that contains
the list of enabled channels. This is something that is supposed to be
managed by the core.
Now that the last few drivers that used it to configure a default scan mask
have been updated to not do this anymore we can unexport the function.
Note, this patch also requires moving a few functions around so they are all
declared before the first internal user.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Daniel Baluta <daniel.baluta@intel.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>
Some devices need the height of the user to compute various
parameters. One of this devices is Freescale's MMA9553L
(http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
that needs the height of the user to compute the stride length which
is used further to determine distance, speed and activity type.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
These changes are needed to support the functionality of a pedometer.
A pedometer has two basic functionalities: step counter and step detector.
The step counter needs to be enabled and then it will count the steps
in its hardware register. Whenever the application needs to check
the step count, it will read the step counter register. To support the
step counter a new channel type STEPS is added. Since the pedometer needs
to be enabled first so that the hardware can count and store the steps,
we need a specific ENABLE channel info mask.
The step detector will generate an interrupt each time a step is detected.
To support this functionality we add a new event type INSTANCE.
For more information on the Android requirements for step counter and step
detector see:
http://source.android.com/devices/sensors/composite_sensors.html#counter
and http://source.android.com/devices/sensors/composite_sensors.html#detector.
A device that has the pedometer functionality this interface needs to
support is Freescale's MMA9553L:
http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
For some events (e.g.: step detector) a direction does not make sense.
Add IIO_EV_DIR_NONE to be used with such events and generate sysfs event
attributes that do not contain direction.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This channel will be used for exposing information about
activity composite sensors. Activities supported so far:
* running
* jogging
* walking
* still
THRESHOLD event is used to signal a change in the activity
state.
We associate a confidence interval for each activity expressed
as a percentage from 0 to 100.
* 0, means the sensor IS NOT reporting that activity.
* 100, means the sensor IS reporting that activity.
Users of this interface have two possible means to gather
information about the ongoing activities.
1. Event based, via event file descriptor
* sensor may report an event when ENTERING an activity or LEAVING
an activity based on a threshold value.
* drivers will wake up applications waiting data on the event fd
2. Polling, by reading the sysfs associated attribute files:
* /sys/bus/iio/devices/iio:device0/in_activity_running_input
expressed as percentage confidence value from 0 to 100.
This will offer an interface for Android significant motion
composite sensor defined here:
http://source.android.com/devices/sensors/composite_sensors.html
Activities listed above are supported by Freescale's MMA9553 sensor:
http://freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The direction field is set on 7 bits, thus we need to AND it with 0111 111 mask
in order to retrieve it, that is 0x7F, not 0xCF as it is now.
Fixes: ade7ef7ba (staging:iio: Differential channel handling)
Signed-off-by: Cristina Ciocan <cristina.ciocan@intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
New drivers / supported parts
* rockchip - rk3066-tsadc variant
* si7020 humidity and temperature sensor
* mcp320x - add mcp3001, mcp3002, mcp3004, mcp3008, mcp3201, mcp3202
* bmp280 pressure and temperature sensor
* Qualcomm SPMI PMIC current ADC driver
* Exynos_adc - support exynos7
New features
* vf610-adc - add temperature sensor support
* Documentation of current attributes, scaled pressure, offset and
scaled humidity, RGBC intensity gain factor and scale applied to
differential voltage channels.
* Bring iio_event_monitor up to date with newer modifiers.
* Add of_xlate function to allow for complex channel mappings from the
device tree.
* Add -g parameter to generic_buffer example to allow for devices with
directly fed (no trigger) buffers.
* Move exynos driver over to syscon for PMU register access.
Cleanups, fixes for new drivers
* lis3l02dq drop an unneeded else.
* st sensors - renam st_sensors to st_sensor_settings (for clarity)
* st sensors - drop an unused parameter from all the probe utility
functions.
* vf610 better error handling and tidy up.
* si7020 - cleanups following merge
* as3935 - drop some unnecessary semicolons.
* bmp280 - fix the pressure calculation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUWnZBAAoJEFSFNJnE9BaIZAAQAJpkot0ZAYPwtIkmtV1JqrLQ
EZRkBN+cIf3q5zp/TnQTqfyhKbpHbJ9/Pnb0zHvn7Yh3WpZod2tyoC3xb8JAlX2h
3tJRrA7plkdMjtwO/ryOxrVJYrm6rCeqKpciwMpDf4E/4fhU5CU++TpmWbhn04qB
7PEZJN5dkmdnQYSIyNle11MYN+NpCAB4zqDvRJoJHpqZV6zAqygJy03H1PqXFS/S
iNBL3jS8/PTbeUURUFOQTiqnJw5KuDke7OoXxUfvCpUwQfNLD8mOTrVrEoId1cM0
Y2fmasfHteh83KP34/MOTwNA3EezM8iQOMzJnXtOpxpySPDrDSP68FDAJs15TUJm
je8E1xxxdjOWuzgSd9djNm9qhlBkoYgbRwzc8wSAHMK7mCV7pP485WZk5E8rRX2z
gMFgUmu4LkiZ2V9glGTAcHqnjhLNDTRCp1Nl/sMVgssFBBNjgR5+nZjUFqDR2QpD
eo4ReIzev7Rzxe2lACRjnRrCnO+KKcjiDkyCdM3X2zdTddQRVrP5Uz+jgnvGAeMO
hCYDHSOiMzV/r5emVfmNG9w8P9a6rZqu4KqcM/KjSzAfHFQTqmfr4Tkfn/hbeUjY
h/zzB18EM4kUSxm3E6+CbFRWcfC7b/PLcUOwSitdujb9cYaX72gdesO2/P3jNFAK
2bjoLRr5l4M4n/DeHae4
=BDOo
-----END PGP SIGNATURE-----
Merge tag 'iio-for-3.19a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First round of new drivers, features and cleanups for IIO in the 3.19 cycle.
New drivers / supported parts
* rockchip - rk3066-tsadc variant
* si7020 humidity and temperature sensor
* mcp320x - add mcp3001, mcp3002, mcp3004, mcp3008, mcp3201, mcp3202
* bmp280 pressure and temperature sensor
* Qualcomm SPMI PMIC current ADC driver
* Exynos_adc - support exynos7
New features
* vf610-adc - add temperature sensor support
* Documentation of current attributes, scaled pressure, offset and
scaled humidity, RGBC intensity gain factor and scale applied to
differential voltage channels.
* Bring iio_event_monitor up to date with newer modifiers.
* Add of_xlate function to allow for complex channel mappings from the
device tree.
* Add -g parameter to generic_buffer example to allow for devices with
directly fed (no trigger) buffers.
* Move exynos driver over to syscon for PMU register access.
Cleanups, fixes for new drivers
* lis3l02dq drop an unneeded else.
* st sensors - renam st_sensors to st_sensor_settings (for clarity)
* st sensors - drop an unused parameter from all the probe utility
functions.
* vf610 better error handling and tidy up.
* si7020 - cleanups following merge
* as3935 - drop some unnecessary semicolons.
* bmp280 - fix the pressure calculation.
When #iio-cells is greater than '0', the driver could provide
a custom of_xlate function that reads the *args* and returns
the appropriate index in registered IIO channels array.
Add simple translation function, suitable for the most 1:1
mapped channels in IIO chips, and use it when driver did not
provide custom implementation.
Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch change structure name and related variables names.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Instead of a void function, return the trigger pointer.
Whilst not in of itself a fix, this makes the following set of
7 fixes cleaner than they would otherwise be.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Stable@vger.kernel.org
Pull timer and time updates from Thomas Gleixner:
"A rather large update of timers, timekeeping & co
- Core timekeeping code is year-2038 safe now for 32bit machines.
Now we just need to fix all in kernel users and the gazillion of
user space interfaces which rely on timespec/timeval :)
- Better cache layout for the timekeeping internal data structures.
- Proper nanosecond based interfaces for in kernel users.
- Tree wide cleanup of code which wants nanoseconds but does hoops
and loops to convert back and forth from timespecs. Some of it
definitely belongs into the ugly code museum.
- Consolidation of the timekeeping interface zoo.
- A fast NMI safe accessor to clock monotonic for tracing. This is a
long standing request to support correlated user/kernel space
traces. With proper NTP frequency correction it's also suitable
for correlation of traces accross separate machines.
- Checkpoint/restart support for timerfd.
- A few NOHZ[_FULL] improvements in the [hr]timer code.
- Code move from kernel to kernel/time of all time* related code.
- New clocksource/event drivers from the ARM universe. I'm really
impressed that despite an architected timer in the newer chips SoC
manufacturers insist on inventing new and differently broken SoC
specific timers.
[ Ed. "Impressed"? I don't think that word means what you think it means ]
- Another round of code move from arch to drivers. Looks like most
of the legacy mess in ARM regarding timers is sorted out except for
a few obnoxious strongholds.
- The usual updates and fixlets all over the place"
* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (114 commits)
timekeeping: Fixup typo in update_vsyscall_old definition
clocksource: document some basic timekeeping concepts
timekeeping: Use cached ntp_tick_length when accumulating error
timekeeping: Rework frequency adjustments to work better w/ nohz
timekeeping: Minor fixup for timespec64->timespec assignment
ftrace: Provide trace clocks monotonic
timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC
seqcount: Add raw_write_seqcount_latch()
seqcount: Provide raw_read_seqcount()
timekeeping: Use tk_read_base as argument for timekeeping_get_ns()
timekeeping: Create struct tk_read_base and use it in struct timekeeper
timekeeping: Restructure the timekeeper some more
clocksource: Get rid of cycle_last
clocksource: Move cycle_last validation to core code
clocksource: Make delta calculation a function
wireless: ath9k: Get rid of timespec conversions
drm: vmwgfx: Use nsec based interfaces
drm: i915: Use nsec based interfaces
timekeeping: Provide ktime_get_raw()
hangcheck-timer: Use ktime_get_ns()
...
No idea why iio needs wall clock based time stamps, but we can avoid
the timespec conversion dance by using the new interfaces.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Added the rotation from north usage attributes to the iio modifier enum and to the iio modifier names array.
Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The iio sysfs ABI defines a way to specify period for roc and thresholds.
What: /sys/.../events/in_accel_x_thresh_rising_period
What: /sys/.../events/in_accel_x_thresh_falling_period
what: /sys/.../events/in_accel_x_roc_rising_period
What: /sys/.../events/in_accel_x_roc_falling_period
But there is no way to add period with the current event info enum.
Added IIO_EV_INFO_PERIOD and corresponding string.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The I2C devices that make up the STMicroelectronics MEMS sensors
may be sneakily enabled by cleverly giving the device node the same
name as a string match from the platform device ID table. However
the right method is to use the compatible string.
On detection, the ST sensors use the ID string to probe and
instatiate the right sensor driver, so pass the kernel-internal ID
string in the .data field of the OF match table, and set the I2C
client name to this name when a compatible match is used.
This avoids having misc Linux-specific strings floating around in
the device tree.
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
By using the info_mask_shared_by_all element of the channel spec, acce
to the sampling frequency becomes available to in kernel users of the
driver. It also shortens and simplifies the code.
This particular conversion was made more complicated by the shared library
and the fact that a number of the drivers do not actually have support for
setting or reading the sampling frequency. The hardware, in those cases
investigated supports it. It's just never been implemented.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Hartmut Knaack <knaack.h@gmx.de>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
This allows in kernel client drivers to access this
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reviewed-by: Hartmut Knaack <knaack.h@gmx.de>
This patch adds IIO driver for KXCJK 1013 triaxis accelerometer sensor.
The specifications for this driver is downloaded from:
http://www.kionix.com/sites/default/files/KXCJK-1013%20Specifications%20Rev%202.pdf
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
argument has been ignored; adjust drivers accordingly
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
useful for contactless temperature sensors to distinguish
between the ambient temperature and the temperature of the object
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added quaternion in the list of supported modifiers.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The current scan element type uses the following format:
[be|le]:[s|u]bits/storagebits[>>shift].
To specify multiple elements in this type, added a repeat value.
So new format is:
[be|le]:[s|u]bits/storagebitsXr[>>shift].
Here r is specifying how may times, real/storage bits are repeating.
When X is value is 0 or 1, then repeat value is not used in the format,
and it will be same as existing format.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This callback is introduced to overcome some limitations of existing
read_raw callback. The functionality of both existing read_raw and
read_raw_multi is similar, both are used to request values from the
device. The current read_raw callback allows only two return values.
The new read_raw_multi allows returning multiple values. Instead of
passing just address of val and val2, it passes length and pointer
to values. Depending on the type and length of passed buffer, iio
client drivers can return multiple values.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Currently the pressure sensor has code to retrieve and enable two
regulators for Vdd and Vdd IO, but actually these voltage inputs
are found on all of these ST sensors, so move the regulator
handling to the core and make sure all the ST sensors call these
functions on probe() and remove() to enable/disable power.
Here also mover over to obtaining the regulator from the *parent*
device of the IIO device, as the IIO device is created on-the-fly
in this very subsystem it very unlikely evert have any regulators
attached to it whatsoever. It is much more likely that the parent
is a platform device, possibly instantiated from a device tree,
which in turn have Vdd and Vdd IO supplied assigned to it.
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
This macro no longer allows all the elements of the scan_type structure
to be set. Missinterpretation of the parameters also caused a couple of
recent bugs. No mainline drivers now use this macro so drop it.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Now that all drivers have been converted to the new event config interface we
can remove for the legacy event config interface. Also drop the '_new' suffix
for the event config interface callbacks, since those are the only callbacks
now.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
There are already humidity sensors in the hwmon subsystem,
so we use their unit (milli percent) here as well.
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds a new data_available() callback to the iio_buffer_access_funcs
struct. The callback is used to indicate whether data is available in the buffer
for reading. It is meant to replace the stufftoread flag from the iio_buffer
struct. The reasoning for this is that the buffer implementation usually can
determine whether data is available rather easily based on its state, on the
other hand it can be rather tricky to update the stufftoread flag in a race free
way.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Documentation related to function should be placed above
its implementation. Move it accordingly.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The functionality implemented by iio_sw_buffer_preenable() is now done directly
in the IIO core and previous users of iio_sw_buffer_preenable() have all been
updated to not use it anymore. It is unused now and can be remove.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
For some devices it is possible to configure a hysteresis for threshold (or
similar) events. This patch adds a new hysteresis event info type which allows
for easy creation and read/write handling of the sysfs attribute.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The event configuration interface of the IIO framework has not been getting the
same attention as other parts. As a result it has not seen the same improvements
as e.g. the channel interface has seen with the introduction of the channel spec
struct. Currently all the event config callbacks take a u64 (the so called event
code) to pass all the different information about for which event the callback
is invoked. The callback function then has to extract the information it is
interested in using some macros with rather long names. Most information encoded
in the event code comes straight from the iio_chan_spec struct the event was
registered for. Since we always have a handle to the channel spec when we call
the event callbacks the first step is to add the channel spec as a parameter to
the event callbacks. The two remaining things encoded in the event code are the
type and direction of the event. Instead of passing them in one parameter, add
one parameter for each of them and remove the eventcode from the event
callbacks. The patch also adds a new iio_event_info parameter to the
{read,write}_event_value callbacks. This makes it possible, similar to the
iio_chan_info_enum for channels, to specify additional properties other than
just the value for an event. Furthermore the new interface will allow to
register shared events. This is e.g. useful if a device allows configuring a
threshold event, but the threshold setting is the same for all channels.
To implement this the patch adds a new iio_event_spec struct which is similar to
the iio_chan_spec struct. It as two field to specify the type and the direction
of the event. Furthermore it has a mask field for each one of the different
iio_shared_by types. These mask fields holds which kind of attributes should be
registered for the event. Creation of the attributes follows the same rules as
the for the channel attributes. E.g. for the separate_mask there will be a
attribute for each channel with this event, for the shared_by_type there will
only be one attribute per channel type. The iio_chan_spec struct gets two new
fields, 'event_spec' and 'num_event_specs', which is used to specify which the
events for this channel. These two fields are going to replace the channel's
event_mask field.
For now both the old and the new event config interface coexist, but over the
few patches all drivers will be converted from the old to the new interface.
Once that is done all code for supporting the old interface will be removed.
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>
The power to some of the sensors are controlled by regulators. In most
cases these are 'always on', but if not they will fail to work until
the regulator is enabled using the relevant APIs. This patch allows for
the Vdd_IO power supply to be specified by either platform data or
Device Tree.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The power to some of the sensors are controlled by regulators. In most
cases these are 'always on', but if not they will fail to work until
the regulator is enabled using the relevant APIs. This patch allows for
the Vdd power supply to be specified by either platform data or Device
Tree.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Drivers using software buffers often store the timestamp in their data buffer
before calling iio_push_to_buffers() with that data buffer. Storing the
timestamp in the buffer usually involves some ugly pointer arithmetic. This
patch adds a new helper function called iio_push_buffers_with_timestamp() which
is similar to iio_push_to_buffers but takes an additional timestamp parameter.
The function will help to hide to uglyness in one central place instead of
exposing it in every driver. If timestamps are enabled for the IIO device
iio_push_buffers_with_timestamp() will store the timestamp as the last element
in buffer, before passing the buffer on to iio_push_buffers(). The buffer needs
large enough to hold the timestamp in this case. If timestamps are disabled
iio_push_buffers_with_timestamp() will behave just like iio_push_buffers().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com>
Cc: Josh Wu <josh.wu@atmel.com>
Cc: Denis Ciocca <denis.ciocca@gmail.com>
Cc: Manuel Stahl <manuel.stahl@iis.fraunhofer.de>
Cc: Ge Gao <ggao@invensense.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Marek Vasut <marex@denx.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>
These two additional info_mask bitmaps should allow all 'standard'
numeric attributes to be handled using the read_raw and write_raw
callbacks. Whilst this should reduce code, the more important element
is that this makes these values easily accessible to in kernel users
of IIO devices.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Introduce an enum to specify whether the attribute is separate or
shared.
Factor out the bitmap handling for loop into a separate function.
Tidy up error handling and add a NULL assignment to squish a false
positive warning from GCC.
Change ext_info shared type from boolean to enum and update in all
drivers.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Somehow this got missed when dropping all the code that used it
prior to the split. Remove it now, there are no users.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
At the moment the number of channels specified is dictated by the first
sensor supported by the driver. As we add support for more sensors this
is likely to vary. Instead of using the ARRAY_SIZE() of the LPS331AP's
channel specifier we'll use a new adaptable 'struct st_sensors' element
instead.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Integration time is in seconds; it controls the measurement
time and influences the gain of a sensor.
There are two typical ways that scaling is implemented in a device:
1) input amplifier,
2) reference to the ADC is changed.
These both result in the accuracy of the ADC varying (by applying its
sampling over a more relevant range).
Integration time is a way of dealing with noise inherent in the analog
sensor itself. In the case of a light sensor, a mixture of photon noise
and device specific noise. Photon noise is dealt with by either improving
the efficiency of the sensor, (more photons actually captured) which is not
easily varied dynamically, or by integrating the measurement over a longer
time period. Note that this can also be thought of as an averaging of a
number of individual samples and is infact sometimes implemented this way.
Altering integration time implies that the duration of a measurement changes,
a fact the device's user may be interested in.
Hence it makes sense to distinguish between integration time and simple
scale. In some devices both types of control are present and whilst they
will have similar effects on the amplitude of the reading, their effect
on the noise of the measurements will differ considerably.
Used by adjd_s311, tsl4531, tcs3472
The following drivers have similar controls (and could be adapted):
* tsl2563 (integration time is controlled via CALIBSCALE among other things)
* tsl2583 (has integration_time device_attr, but driver doesn't use channels yet)
* tsl2x7x (has integration_time attr)
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Jon Brenner <jon.brenner@ams.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add a resource managed devm_iio_trigger_alloc()/devm_iio_triger_free()
to automatically clean up triggers allocated by IIO drivers, thus
leading to simplified IIO drivers code.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Kyunmin Park <kyungmin.park@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add a resource managed devm_iio_device_alloc()/devm_iio_device_free()
to automatically clean up any allocations made by IIO drivers,
thus leading to simplified IIO drivers code.
In addition, this will allow IIO drivers to use other devm_*() API
(like devm_request_irq) and don't care about the race between
iio_device_free() and the release of resources by Device core
during driver removing.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com>
Tested-by: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
There are no users of this macro left and we have come to the conclusion that it
is not a good idea to expose the raw chip reset to userspace so the macro is
very unlikely to be used in new drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch add support to redirect the DRDY interrupt on INT1 or INT2
on accelerometer and pressure sensors.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
When using more than one trigger consumer it can happen that multiple threads
perform a read-modify-update cycle on 'use_count' concurrently. This can cause
updates to be lost and use_count can get stuck at non-zero value, in which case
the IIO core assumes that at least one thread is still running and will wait for
it to finish before running any trigger handlers again. This effectively renders
the trigger disabled and a reboot is necessary before it can be used again. To
fix this make use_count an atomic variable. Also set it to the number of
consumers before starting the first consumer, otherwise it might happen that
use_count drops to 0 even though not all consumers have been run yet.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Since the info_mask split, iio_channel_has_info() is not working correctly.
info_mask_separate and info_mask_shared_by_type, it is not possible to compare
them directly with the iio_chan_info_enum enum. Correct that bit using the BIT()
macro.
Cc: <stable@vger.kernel.org> # 3.10.x
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch introduce num_data_channels variable on st_sensors struct
to manage different type of channels (size or number) in
st_sensors_get_buffer_element function.
Removed ST_SENSORS_NUMBER_DATA_CHANNELS and ST_SENSORS_BYTE_FOR_CHANNEL
and used struct iio_chan_spec const *ch to catch data.
Added 3 byte channel data support on one-shot reads.
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
