This adds TI's tlc4541 16-bit ADC driver. Which is a single channel
ADC. Supports raw and trigger buffer access.
Also supports the tlc3541 14-bit device, which has not been tested.
Implementation of the tlc3541 is fairly straight forward thou.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Add device tree bindings documentation for Maxim MAX11100 single-channel
ADC

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Add iio driver for Maxim MAX11100 single-channel ADC.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Replace the types with the actual variable names when using the
sizeof() operator.  This is kernel preferred style as it's
more obvious that it is correct.

Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

When CONFIG_PM_SLEEP is disabled, we get a harmless warning

drivers/iio/light/cm3605.c:292:12: error: 'cm3605_pm_resume' defined but not used [-Werror=unused-function]
drivers/iio/light/cm3605.c:281:12: error: 'cm3605_pm_suspend' defined but not used [-Werror=unused-function]

Marking the functions as possibly unused avoids the warning without
needing to add an #ifdef.

Fixes: 8afa505c ("iio: light: add driver for Capella CM3605")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Driver was checking for direct mode before changing oversampling
ratios, but was not locking it.  Use the claim/release helper
functions to guarantee the device stays in direct mode while the
oversampling ratios are being updated.  Continue to use the drivers
private state lock to protect against conflicting direct mode access
of the state data.

Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Driver was checking for direct mode but not locking it.  Use the
claim/release helper functions to guarantee the device stays in
direct mode during raw reads of proximity data.

Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Reviewed-by: Vlad Dogaru <ddvlad@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during raw writes.

Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This changes the reference voltage regulator matching string from "refin"
to "vref". This is to be consistent with other A/DC chips that also use
"vref-supply" in their device tree bindings.

Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This drops the "ti-" prefix from the module name. It makes the module name
consistent with other iio ti-ads* drivers and it makes the driver work
with device tree (the spi subsystem drops the "ti," prefix when matching
compatible strings from device tree).

Tested working on LEGO MINDSTORMS EV3 with the following device tree node:

	adc@3 {
		compatible = "ti,ads7957";
		reg = <3>;
		#io-channel-cells = <1>;
		spi-max-frequency = <10000000>;
		vref-supply = <&adc_ref>;
	};

Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This adds device tree bindings for the TI ADS7950 family of A/DC chips.

Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

At the end of the delay loop timeout will always be zero
and hence the check for !timeout will always be true. Remove
the redundant check and the redundant return 0 at the end of
the function.

Fixes CoverityScan CID#1357168 ("Logically dead code")

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

To follow iio guidelines Where possible we stick to the raw SI unit, so
specify meters for proximity.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Add support to STM LSM6DS3-LSM6DSM 6-axis (acc + gyro) Mems sensor

http://www.st.com/resource/en/datasheet/lsm6ds3.pdf
http://www.st.com/resource/en/datasheet/lsm6dsm.pdf



- continuous mode support
- i2c support
- spi support
- sw fifo mode support
- supported devices: lsm6ds3, lsm6dsm

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

When a consumer calls iio_read_channel_processed() the IIO core
tries to apply scaling to the value, but if the channel only
supports reading raw values, we should return that raw value
to the cosumer instead of an error.

This is what userspace is expected to do with sensors only
providing raw values so the kernel should do the same, so as to
avoid adding scaling boilerplate to drivers for hardware that
actually return processed values from raw reads.

A sensor not providing a scale, but providing a _raw attribute
could be valid if for example the scale is the default of 1,
but an offset needs to be applied to convert to the _processed
form.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This patch adds support for TI TMP007 - 16 bit IR thermopile sensor with integrated Math engine.
Sensor takes care of calculating the object temperature with the help of calibrated constants stored in non-volatile memory,
thereby reducing the calculation overhead.

Signed-off-by: Manivannan Sadhasivam <manivannanece23@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Another one of these that we missed previously which prevents test builds
of this driver on 32 bit platforms as it gives an undefined __divdi3 warning.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>

It is meant to be long and is only added to an s64.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Rama Krishna Phani A <rphani@codeaurora.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

A simple do_div call works here as all the signed 64 bit is
actually small and unsigned at this point, and the numerator is
u32.

Introduce a temporary u64 variable to avoid type comparison warnings
on some architectures.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Rama Krishna Phani A <rphani@codeaurora.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This is the IIO driver for AVIA HX711 ADC which is mostly used in weighting
cells.

The protocol is quite simple and using GPIOs:
One GPIO is used as clock (SCK) while another GPIO is read (DOUT)

The raw value read from the chip is delivered.
To get a weight one needs to subtract the zero offset and scale it.

Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Add DT bindings for avia,hx711
Add vendor avia to vendor list

Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

For some reason the axp288_adc driver was modifying the
AXP288_ADC_TS_PIN_CTRL register, changing bits 0-1 depending on
whether the GP_ADC channel or another channel was written.

These bits control when a bias current is send to the TS_PIN, the
GP_ADC has its own pin and a separate bit in another register to
control the bias current.

Not only does changing when to enable the TS_PIN bias current
(always or only when sampling) when reading the GP_ADC make no sense
at all, the code is modifying these bits is writing the entire register,
assuming that all the other bits have their default value.

So if the firmware has configured a different bias-current for either
pin, then that change gets clobbered by the write, likewise if the
firmware has set bit 2 to indicate that the battery has no thermal sensor,
this will get clobbered by the write.

This commit fixes all this, by simply removing all writes to the
AXP288_ADC_TS_PIN_CTRL register, they are not needed to read the
GP_ADC pin, and can actually be harmful.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Fixes style issue where Alignment doesn't match open parenthesis

Signed-off-by: Scott Matheina <scott@matheina.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
$

After this patch:

$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
alias:          of:N*T*Cfsl,imx25-gcqC*
alias:          of:N*T*Cfsl,imx25-gcq

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

buffer.h supplies everything needed for devices using buffers.
buffer_impl.h supplies access to the internals as needed to write
a buffer implementation.

This was really motivated by the mess that turned up in the
kernel-doc documentation pulled in by the new sphinx docs.
It made it clear that our logical separations in headers were
generally terrible.  The buffer case was easy to sort out without
greatly effecting drivers so here it is.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

It's bad practice and only done in this fake driver + it breaks my
attempt to take struct buffer opaque. Not worth an access function
as it shouldn't be done anyway.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

This is a precursor to the splitting of buffer.h into parts relevant
to buffer implementation vs those for devices using buffers.
struct buffer is about to become opaque as far as the header is
concerned.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

These were only getting access to the internals of struct iio_dev via
the include of iio.h within buffer.h.  This should always have been
explicitly included by the buffer implementations themselves.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

As a precursor to splitting buffer.h, lets make sure all drivers
include the relevant headers rather than relying on picking them
up from kfifo_buf.h.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Wrong start of kernel doc comment /* -> /**

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Ancient legacy of me doing it wrong which it is nice to clear
up whilst we are here.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Nothing uses it outside of core code.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

This is a necessary step in taking the buffer implementation
opaque.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

This should make it easier to see how the structure is split into
public and private parts - reflected in the generated documentation.

Deliberately use /* instead of /** for the private elements to avoid
warnings when kernel-doc script runs.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Nothing outside of indiustrialio-buffer.c should be using this.
Requires a large amount of juggling of functions to avoid a
forward definition.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

The earlier deployed LIS3LV02DL driver had already defined a few
DT bindings that need to be supported by the new more generic
driver and listed as compatible but deprecated bindings in the
documentation.

After this we can start to activate the new driver with the old
systems where applicable.

As part of this enablement: make us depend on the old drivers
not being in use so we don't get a kernel with two competing
drivers.

Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Eliminate the non-standard attributes in_voltage_range and
in_voltage_range_available. Implement in_voltage_scale_available in place
of these attributes and update the SCALE accordingly. The array
scale_avail is introduced to hold the available scale values.

Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Fixes a warning flagged by checkpatch.pl

Signed-off-by: rishabh hardas <rishabheudyptula@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Gravity sensor is a soft sensor, which derives value from
standard accelerometer device by filtering out the acceleration
which is not caused by gravity.

Gravity sensor provides a three dimensional vector indicating
the direction and magnitude of gravity. Typically, this sensor
is used to determine the device's relative orientation in space.
The units and the coordinate system is the same as the one used by
the acceleration sensor.
When a device is at rest, the output of the gravity sensor should
be identical to that of the accelerometer.

More information can be found in:
http://www.usb.org/developers/hidpage/HUTRR59_-_Usages_for_Wearables.pdf



Gravity sensor and accelerometer have similar channels and
share channel usage ids. So the most of the code for accel_3d
can be reused.

Signed-off-by: Song Hongyan <hongyan.song@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>