Use the new adis library for the adis16209 driver. This allows us to completely
scrap the adis16209 buffer and trigger code and more than half of the core
driver code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use the new adis library for the adis16204 driver. This allows us to completely
scrap the adis16204 buffer and trigger code and more than half of the core
driver code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use the new adis library for the adis16203 driver. This allows us to completely
scrap the adis16203 buffer and trigger code and more than half of the core
driver code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use the new adis library for the adis16201 driver. This allows us to completely
scrap the adis16201 buffer and trigger code and more than half of the core
driver code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
A lot of the devices from the ADIS family use the same methods for accessing
registers, sampling data and trigger handling. They also have similar register
layout for the control registers.
This patch adds a common library for these devices. The library implements
functions for reading and writing registers as buffer and trigger management. It
also provides a set functions for accessing the control registers and for
running the devices internal self-test. Having this common library code will
allow us to remove a lot of duplicated code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We had assigned the return value to 'ret' but ignored it when
return from isl29018_write_raw(), it's better to return 'ret'
instead of 0.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In tsl_2563_write_interrupt_config and tsl2562_remove, interrupts are not
disabled where they should be. This seems to be from a mistake of using |=
instead of &= in 2 lines of code.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The function is expected to return the number of bytes consumed and as long as
not all bytes have been consumed the function will be called again. Currently
the function returns 'ret', which will always be 0 in this case, so we end up in
a endless loop since the caller will assume that no bytes have been consumed. So
instead return len as it is supposed to.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
For historical reasons the regulator handling was a little clunky. This
patch brings it inline with a more standard ordering wrt to allocation
of the iio_device.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
For a long while now the max1363 core has selected the
buffer anyway. For a while I meant to make the separation
work again, but given how long it has been it is probably
time to conclude it will never happen and settle for tidying
up what we have.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Route all buffer writes through the demux.
Addition or removal of a buffer results in tear down and
setup of all the buffers for a given device.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Tested-by: srinivas pandruvada <srinivas.pandruvada@intel.com>
The driver does not expose any custom API to userspace and none of the standard
static code checker tools report any issues, so move it out of staging.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use the passed in chan spec in ad7887_read_raw instead of alawys using the first
chan spec entry from the chip info data. Since all channels have the same shift
and realbits from a functional point of view it does not matter which chan spec
is used, but the patch makes the a bit more clear.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
While it is not recommended to use the internal reference in two channel mode in
order to obtain optimal performance it is still possible to use it.
While we are at it also get rid of the duplicate tx_cmd_buf entries. There are
only two unique entries. One for channel 1 and one for channel 2.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use proper kernel doc to document the platform data struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The recent cleanups have decimated the drivers code size by quite a bit. It is
only a few hundred lines in total now and we also always build buffer support,
so there really is no need to spread the driver out over multiple files. Putting
everything into one file also allows to reduce the code size a bit more by
removing a few lines of boilerplate code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Rework the regulator handling of the ad7887 driver to match more closely what we
do for other drivers. Only request the regulator if a external reference is
used, but treat it as an error if requesting the regulator fails. Also remove
the possibility to specify the reference voltage via platform data and always
use the regulator for this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We know that the sample buffer will at most need to hold two 16 bit samples and
the 64 bit aligned 64 bit timestamp. Preallocate a buffer large enough to hold
this instead of allocating and freeing it each time a sample is read.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The adis16334 has the PROD_ID register so set the PROD_ID flag in its chip info.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The ADIS1360 and ADIS13605 are very similar and do have the same software
interface. The only difference is the contents of the PROD_ID register. Since we
now read the product id from the device name instead of the chip_info struct we
can use the same chip_table entry for both the ADIS1360 and ADIS13605.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The product id check currently ANDs the read id with 0xF000 and compares the
result to the product id from the chip info. Since none of the product ids in
the chip info table end in 0x000 the check will always fail. Furthermore it is
also wrong, the product id in the PROD_ID register will always match the part
number of the device.
Some of the ADIS16XXX devices are identical from a software point of
view with the product id register having a different content. If we keep the
current scheme of storing the product id in the chip info table this would
require us to have multiple almost identical chip info table entries. So instead
this patch changes the code to parse the product id from the device name.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Setting the sampling frequency for the adis16334 differs from the other devices.
This patch introduces two new callback functions to the adis16400 chip_info
struct which are used to specify how to read and write the current sample rate.
The patch also introduces the proper implementations for these callbacks for the
adis16334.
Related to this is that the adis16334 has no slow mode and so we do not limit
the SPI clock rate to 300kHz during initialization. The patch adds a new flag
for devices which do have a slow mode.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The driver leaves the device in power-down state anyway,
so there is nothing to do on suspend.
On resume, we just have to make sure the range and ADC
values are updated in the device since it may have been
powered down in suspend.
Signed-off-by: Bryan Freed <bfreed@chromium.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
remove unnecessary semicolon from the macro definition
Signed-off-by: Kumar Amit Mehta <gmate.amit@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The adt7310 is the SPI version of the adt7410, so there is no need to have a
separate driver for it. The register map layout is a bit different, i.e. the
addresses of the register differ, but the individual register layouts are
identical. We solve this by adding a small look-up table, which translates
adt7410 register addresses to ad7310 register addresses.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This resolves the conflict with:
drivers/staging/comedi/drivers/amplc_dio200.c
and syncs up the changes that happened in the staging directory for
3.7-rc3.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following error from coccicheck:
drivers/staging/iio/adc/lpc32xx_adc.c:153:43-46: ERROR: Missing resource_size with res
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Roland Stigge <stigge@antcom.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The temperature channel has a calibbias attribute which it should not have, but
the offset attribute is missing.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Temperature scale and offset differ between the different devices supported by
this driver. Right now the driver always reports the temperature scale and
offset of the adis16400 regardless of which chip variant is used. This patch
adds two new attributes to the chip_info struct, one for the temperature scale
and one for the temperature offset.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Most of the channel offsets and scales in the adis16400 are incorrect:
* Voltage scale is off by a factor of 1000
* Temperature scale is off by a factor of 1000
* Temperature offset is completely wrong
* Some of the acceleration scales are either completely wrong or have the
wrong unit
* Some of the angular velocity scale are either completely wrong or have
the wrong unit
This patch fixes these issues. For consistency it also converts scales which are
correct to use the IIO_G_TO_M_S_2 and IIO_DEGREE_TO_RAD macro. This makes it
much easier to compare it to the value given in the datasheet.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Most of the channel offsets and scales in the adis16260 are incorrect:
* Temperature scale is off by a factor of 1000
* Voltage scale is off by a factor of 1000
* Temperature offset is completely wrong
This patch fixes these issues. Also use the IIO_DEGREE_TO_RAD for the angle
velocity since this makes it much easier to compare it to the value given in the
datasheet.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Most of the channel offsets and scales in the adis16240 are incorrect:
* Temperature scale is of by a factor of 1000
* Voltage scale is of by a factor of 1000
* Temperature offset is completely wrong
* Peak scale is completely wrong
This patch fixes these issues. Also use the IIO_G_TO_M_S_2 macro for the
acceleration scale since this makes it much easier to compare it to the value
given in the datasheet.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Most of the channel offsets and scales in the adis16220 are incorrect:
* Temperature scale is off by a factor of 1000
* Voltage scale is off by a factor of 1000
* Acceleration seems to have a typo "187042" since it should be instead of
"1887042"
* Temperature offset is completely wrong
This patch fixes these issues.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Most of the channel offsets and scales in the adis16209 are incorrect:
* Temperature scale is of by a factor of 1000
* Voltage scale is of by a factor of 1000
* Temperature offset is completely wrong
* Rotational position scale is missing
This patch fixes these issues. Also use the IIO_G_TO_M_S_2 macro for the
acceleration scale since this makes it much easier to compare it with the value
given in the datasheet.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Most of the channel offsets and scales in the adis16204 are incorrect:
* Temperature scale is off by a factor of 1000
* Voltage scale is off by a factor of 1000
* Acceleration is scale is in g instead of m/(s**2)
* Temperature offset is completely wrong
This patch fixes these issues.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fixes the following coccicheck warnings:
drivers/staging/iio/accel/lis3l02dq_ring.c:240:5-10: WARNING: Comparison to bool
drivers/staging/iio/iio_dummy_evgen.c:111:6-25: WARNING: Comparison to bool
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
probably not the most important patch in the world
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Cc: manuel.stahl@iis.fraunhofer.de
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The driver has not been building for some time after the
irq_to_gpio function has been removed from the kernel.
The only board in the upstream kernel that provides
this device is the "Stargate 2", which is also maintained
by Jonathan Cameron. Rather than working around the problem
by adding new platform data for this driver, this patch
uses the of_gpio framework to get to the gpio number.
However, the stargate2 code does not (yet) use DT based
probing, so it is still broken, but at least building
allyesconfig works again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some drivers define a DRIVER_NAME, but never use the define. This patch removes
defines.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r1@
statement S;
position p,p1;
@@
S@p1;@p
@script:python r2@
p << r1.p;
p1 << r1.p1;
@@
if p[0].line != p1[0].line_end:
cocci.include_match(False)
@@
position r1.p;
@@
-;@p
// </smpl>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Most of the channel offsets and scales in the adis16203 are incorrect:
* Temperature scale is off by a factor of 1000
* Voltage scale is off by a factor of 1000
* Temperature offset is completely wrong
This patch fixes these issues.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Most of the channel offsets and scales in the adis16201 are incorrect:
* Temperature scale is off by a factor of 1000
* Voltage scale is off by a factor of 1000
* Acceleration scale is in g instead of m/(s**2)
* Temperature offset is completely wrong
This patch fixes these issues.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
If the config contains CONFIG_IIO_BUFFER=y and CONFIG_IIO_SIMPLE_DUMMY_BUFFER=n
iio_simple_dummy_configure_buffer() is stubbed out and iio_buffer_register() is
not. As a result we try to register a buffer which has not been configured.
This will causes a NULL pointer deref in iio_buffer_register. To solve this
issue move the iio_buffer_register() call to iio_simple_dummy_configure_buffer(),
so it will only be called if iio_simple_dummy_configure_buffer() has been called.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The ad7170/ad7171 have a software interface similar to the ad7780. They do not
have an external pin which allows to change the internal gain and the what is
used for the gain bit in the ad7780/ad7781 becomes part of the check pattern.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
