kernel/git/stable/linux.git/drivers/iio/accel, branch linux-4.8.y

iio: st_sensors: fix scale configuration for h3lis331dl

2016-11-18T09:51:48+00:00

commit d304286abbbe7ed6228a553a56ba054e900907eb upstream. fix scale configuration/parsing for h3lis331dl accel driver when sensitivity is higher than 1(m/s^2)/digit Signed-off-by: Lorenzo Bianconi Fixes: 1e52fefc9b0c ("iio: accel: Add support for the h3lis331dl accelerometer") Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: accel: kxsd9: Fix scaling bug

2016-09-03T17:30:45+00:00

All the scaling of the KXSD9 involves multiplication with a fraction number < 1. However the scaling value returned from IIO_INFO_SCALE was unpredictable as only the micros of the value was assigned, and not the integer part, resulting in scaling like this: $cat in_accel_scale -1057462640.011978 Fix this by assigning zero to the integer part. Cc: stable@vger.kernel.org Tested-by: Jonathan Cameron Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron

iio: accel: bmc150: reset chip at init time

2016-09-03T16:26:14+00:00

In at least one known setup, the chip comes up in a state where reading the chip ID returns garbage unless it's been reset, due to noise on the wires during system boot. All supported chips have the same reset method, and based on the datasheets they all need 1.3 or 1.8ms to recover after reset. So, do the conservative thing here and always reset the chip. Signed-off-by: Olof Johansson Reviewed-by: Srinivas Pandruvada Cc: Signed-off-by: Jonathan Cameron

iio: accel: kxsd9: Fix raw read return

2016-08-21T19:42:16+00:00

Any readings from the raw interface of the KXSD9 driver will return an empty string, because it does not return IIO_VAL_INT but rather some random value from the accelerometer to the caller. Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron

iio: add Kconfig selects needed for triggered buffer compiles

2016-08-15T14:42:04+00:00

Select IIO_BUFFER and IIO_TRIGGERED_BUFFER to compile. Remove IIO_TRIGGER if present since IIO_BUFFER selects it. Signed-off-by: Alison Schofield Cc: Daniel Baluta Signed-off-by: Jonathan Cameron

iio: accel: bma220_spi: set up buffer timestamps for non-zero values

2016-08-15T14:39:18+00:00

Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield Cc: Daniel Baluta Reviewed-By: Tiberiu Breana Cc: Signed-off-by: Jonathan Cameron

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

2016-07-14T03:05:29+00:00

Jonathan writes: Third set of IIO new device support, features and cleanups for the 4.8 cycle. New core features - Selection of the clock source for IIO timestamps. This is done per device as it makes little sense to have events in one timebase and data timestamped on another. Biggest reason for this is that we currently use a clock source which is non monotonic which can result in 'interesting' data sets. (Includes export for get_monotonic_corse64 which Thomas Gleixner didn't mind in an earlier version.) - MAINTAINERS add the git tree to the list for IIO. New device support + a kind of indirect staging graduation. * Broadcom iproc-static-adc - new driver * mcp4531 - support for MCP454x, MCP456x, MCP464x and MCP466x potentiometers * mpu6050 - support the IC20608 6 axis motion tracking device * st-sensors - support the lis3l02dq + drop the lis3l02dq driver from staging. The general purpose driver is missing event support, but good to get rid of this driver which was rather long in the tooth. New driver features * ak8975 - Add vid regulator support and refactor handling in general. - Allow a delay after enabling regulators. - Runtime and system PM. * bmg160 - filter frequency control support. * bmp280 - SPI device support. - EOC interrupt support for the BMP085 - power management support. - supply regulator support. - reset gpio support - dt bindings for reset gpio and regulators. - of table to support device tree registration * max1363 - Device tree bindings. * mcp4531 - Device tree bindings. * st-pressure - temperature channels as part of triggered buffer (previously not due probably to alignment issues - see below). - lps22hb open drain interrupt support. - lps22hb temperature channel support Cleanups and reworkings. * numerous ADC drivers - ensure the iio_dev->dev.of_node is set to the parent dev.of_node so as to allow client bindings to find the device. * ak8975 - Fix incorrect handling of missing regulator - make sure power is down and remove. * bmp280 - read the calibration data only once as it doesn't change. * isl29125 - Use a few macros to make code a touch more readable. * mma8452 - fix a memory leak on error. - drop an unecessary bit of return value handling. * potentiometer kconfig - typo fix. * st-pressure - drop some uninformative default assignments of elements of the channel array structure (aids readability). * st-sensors - Harden interrupt handling considerably. These are actually all using level interrupts, but at least two known boards have them wired to edge only interrupt chips. Hence a slightly interesting bit of handling is needed in which we first allow for the easy option (level triggered) and secondly check the status registers before reenabling edge interrupts and fall back to a tight loop in the thread until we successfully clear the interrupt. No harm is done if we never succeed in doing so. It's an odd patch that has been through a lot of revisions to reach a consensus on how to handle what is basically broken hardware (which the previous defaults allowed to kind of work). - Fix alignment to defined storagebytes boundaries. - Ensure alignment of power of 2 byte boundaries. This has always in theory been part of the ABI of IIO, but we missed a few that snuck in that need fixing. The effect was minor as they were only followed by timestamp channels which were correctly aligned, - Add some docs to explain the gain calculations.

drivers:iio:accel:mma8452: removed unwanted return statements

2016-07-05T20:05:01+00:00

Removed unwanted return statements from the function mma8452_set_freefall_mode. Signed-off-by: Bijosh Thykkoottathil Acked-by: Martin Kepplinger Signed-off-by: Jonathan Cameron

drivers:iio:accel:mma8452: added cleanup provision in case of failure.

2016-07-05T20:03:40+00:00

mma8452_set_freefall_mode can return -ve value in case if i2c_smbus_read_byte_data fails. This function is called from mma8452_probe, and returning -ve value from probe indicates probe failure. Need to call iio_triggered_buffer_cleanup & iio_trigger_cleanup in this case. Signed-off-by: Bijosh Thykkoottathil Acked-by: Martin Kepplinger Signed-off-by: Jonathan Cameron

iio: accel: st_accel: Add lis3l02dq support

2016-07-04T17:07:44+00:00

Time to finally kill off the venerable (it was one of my first drivers) lis3l02dq driver in favour of adding support in the st sensors framework. This does loose us the event support that driver always had, but I think that will reappear at some point and in the meantime the maintenance advantages of dropping the 'special' driver for this one part outweigh the issues. It's worth noting this part is ancient and I may well be the only person who still has any on hardware running recent kernels. It has a few 'quirks'. - No WAI register so that just became optional. - A BDU option that really does block updates. Completely. Whatever you do, you don't get any more data with it set. It is documented the same as more modern parts but I presume they are actually clearing for updates after a read of both bytes! - Fixed scale. - It's too quick. Even at slowest rate (280Hz) I can't read out fast enough on my board (stargate 2) to beat new data coming in. Linus' repeat read patch doesn't help in this case. It just means I get 10 readings before dying... So in reality this will get used with software triggers only unless someone has this long out of production device on a quick board. Signed-off-by: Jonathan Cameron Reviewed-by: Linus Walleij Cc: Denis CIOCCA Cc: Crestez Dan Leonard Signed-off-by: Jonathan Cameron