user/sven/linux.git/include/linux/iio/common, branch v3.16.42

iio: st_sensors: move regulator retrieveal to core

2014-04-26T10:52:42Z

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 Cc: Denis CIOCCA Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron

iio: pressure-core: st: Provide support for the Vdd_IO power supply

2013-09-23T19:17:58Z

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

iio: pressure-core: st: Provide support for the Vdd power supply

2013-09-23T19:17:54Z

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

iio: pressure-core: st: Allow for number of channels to vary

2013-09-14T20:17:17Z

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

iio: Added ST-sensors platform data to select the DRDY interrupt pin

2013-08-03T17:40:28Z

This patch add support to redirect the DRDY interrupt on INT1 or INT2 on accelerometer and pressure sensors. Signed-off-by: Denis Ciocca Signed-off-by: Jonathan Cameron

iio:common: Removed stuff macros, added num_data_channels on st_sensors struct and added support on one-shot sysfs reads to 3 byte channel

2013-06-05T17:41:23Z

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

iio:common: ST_SENSORS_LSM_CHANNELS macro changed

2013-06-04T17:53:56Z

Signed-off-by: Denis Ciocca Signed-off-by: Jonathan Cameron

Merge tag 'iio-for-3.10a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next

2013-03-25T17:50:03Z

Jonathan writes: First set of IIO new drivers and cleanup for the 3.10 cycle. New stuff 1) Add OF support for specifying mappings between iio devices and their in kernel consumers. 2) Driver for AD7923 (extra functionality and support for ad7904, ad7914 and ad7924 added later in series) 3) Driver for Exynos adc (dt suppor for phy added later in series). 4) Make iio_push_event save IRQ context - necessary if it is to be used within an interrupt handler. Users of this functionality to follow. 5) For iio use the device tree node name to provide the hwmon name attribute if available. Removal and moves out of staging 1) Drop the adt7410 driver from IIO now that there is a hmwon driver with equivalent support. This device is very much targeted at hardware monitoring so hwmon is a more appropriate host for the driver. 2) Move iio_hwmon driver to drivers/hwmon. Cleanups 1) Minor cleanup in ST common library. 2) Large set of patches to break the info_mask element which previously used odd and even bits to specify if a channel attribute was either shared across similar channels or specific to only one. Now we have two bitmaps, one for those parameters that are specific to this channel and one for those shared by all channels with the same type as this one. This has no effect on the userspace abi. It simplifies the core code and provides more space for new channel parameters. It has been on the todo list for a long time! Conflicts: drivers/iio/dac/ad5064.c

iio:st_sensors move to info_mask_(shared_by_type/separate)

2013-03-17T19:49:23Z

The original info_mask is going away in favour of the broken out versions. Signed-off-by: Jonathan Cameron Acked-by: Denis Ciocca

iio: Fix build error seen if IIO_TRIGGER is defined but IIO_BUFFER is not

2013-03-02T16:31:21Z

If CONFIG_IIO_TRIGGER is defined but CONFIG_IIO_BUFFER is not, the following build error is seen. drivers/iio/common/st_sensors/st_sensors_trigger.c:21:5: error: redefinition of ‘st_sensors_allocate_trigger’ In file included from drivers/iio/common/st_sensors/st_sensors_trigger.c:18:0: include/linux/iio/common/st_sensors.h:239:19: note: previous definition of ‘st_sensors_allocate_trigger’ was here drivers/iio/common/st_sensors/st_sensors_trigger.c:65:6: error: redefinition of ‘st_sensors_deallocate_trigger’ In file included from drivers/iio/common/st_sensors/st_sensors_trigger.c:18:0: include/linux/iio/common/st_sensors.h:244:20: note: previous definition of ‘st_sensors_deallocate_trigger’ was here This occurs because st_sensors_deallocate_trigger is built if CONFIG_IIO_TRIGGER is defined, but the dummy function is compiled if CONFIG_IIO_BUFFER is defined. Signed-off-by: Guenter Roeck Acked-by: Denis Ciocca Signed-off-by: Jonathan Cameron