sensor provides 12-bit relative humidity and 14-bit temperature
via I2C interface; temperature and linearity compensation is not
implemented (yet)
driver also supports the Si7015, but not the 2nd generation
sensors Si7013/Si7020/Si7021
datasheet is here
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si7005.pdf
v2: (thanks to Lars-Peter Clausen)
* fix coding style
* use devm_iio_device_register()
* change copyright year to 2014
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add Capella Microsystem CM32181 Ambient Light Sensor IIO driver.
This driver will convert raw data to lux value under open-air
condition. Change the calibscale based on the cover material.
Signed-off-by: Kevin Tsai <ktsai@capellamicro.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
New drivers
* HID inclinometer driver.
* DHT11 humidity driver. Note that previous humidity drivers have been in
hwmon, but no one was ever entirely happy with that, and they should find
a more comfortable home in IIO (their original placement in hwmon was my
fault - oops). As this is our first humidity driver, core support is also
added.
New features
* Two of mxs-lradc channels are internally wired to a temperature sensor,
make this explicit in the driver by providing the relevant temperature
channel.
* Add support for blocking IO on buffers.
* Add a data_available call back to the interface between buffer implementations
and the core. This is much cleaner than the old, 'stufftoread' flag.
Implemented in the kfifo buffer.
Cleanups
* Last user of the old event configuration interface is converted and the
old interface dropped. Nice to be rid of this thanks to Lars-Peter's hard
work!
* Replace all remaining instances of the IIO_ST macro with explicit filling
of the scan_type structure within struct iio_chan_spec. This macro was a
bad idea, that rapidly ceased to cover all elements of the structure.
Miss reading of the macro arguements has led to a number of bugs so lets
just get rid of it. The final removal patch is awaiting for some fixes
to make their way into mainline.
In a couple of drivers, no elements of scan_type were even being used so
in those case, it has been dropped entirely.
* Drop a couple of of_match_ptr helper uses in drivers where devicetree is
not optional and hence the structures being protected by this always exist.
* Fix up some cases where data was read from a device in a particular
byte order, but he code placed it into a s16 or similar. These were
highlighted by Sparse.
* Use the new ATTRIBUTE_GROUPS macro to drop some boiler plate in the triggers
core code.
* ad7746 and ad7280a - stop storing buffers on the stack, giving cleaner code
and possibly avoiding issues with i2c bus drivers that assume they can dma
directly into the buffer. Note that this cannot currently happen as the the
i2c_smbus_read_i2c_block_data function has a memcpy from the buffer actually
passed to the bus driver. I missed this element of the commit message
and don't think it is major enough to rebase the iio tree.
* ad5791 and ad5504 stop storing buffers on the stack for an SPI driver.
Unlike the i2c drivers, this is a real issue for SPI drivers which can dma
directly into the buffer supplied.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJStyIbAAoJEFSFNJnE9BaI1goQAL0hKYCYuIl3d1fAy65u2I4h
5mzJs/oJmomq/4BqAopfEQ8CbhZhksAYoR4JndOzZH7n4jVY/fRgyY/bH/Ymj0oI
OpCtfee6IeeBLA0p8CMeEPem/pnwxRhSDzul9jsiwpTrTRKAIC1BPZwrmLpaoUfc
obD8r1ocVZStzfsYBr3DUwkcIpcTQTCVy/Pl8HoKLKKsdYoFhTpNwEHJFOoZdiFi
KKGRkeL9Q8VRWt/otWU0L0VFGZFwI1PWlxrqnbisVcGwSs8FF4wGcQvijfC0mUMg
BdKDM7J4GrourZhj3og566B/8WMtGo6YTJXAe/QvvPp768rQncccDHem4V0Tnu49
OJbjgD4ZGVXt3uBFaYddBIbMEIB8SfA2VYur/MW3gnZ7saSAtDk6TllsvC6CxIkR
+LOOxWylhEGeJFIjyMrFPqRVhrrRNkuDRxPz8ZGTiDc8ovo6DWuTLsJrLSX8EJyZ
O6TN6EEk8TCJaf8V63uTFW0Dlom4IQHyQei6LKhfhzwUQq/ri0esBp5P8lGzI3Uq
wtOSdCDuYyoUEYPYbwjohFmQJ27w1rx9KcS4Y9BGmhTIRXslUg3hr+wA/gKMSDZ0
/AUkLQajcv9otupfGzsp5mIWkthKKsGt/Y50xc5zIodnFtnM3nQGq4AqlP6t8nzP
jucVwVMQLj5KaNH13P6K
=Whfv
-----END PGP SIGNATURE-----
Merge tag 'iio-for-3.14b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
2nd round of new IIO drivers, features and cleanups for the 3.14 cycle.
New drivers
* HID inclinometer driver.
* DHT11 humidity driver. Note that previous humidity drivers have been in
hwmon, but no one was ever entirely happy with that, and they should find
a more comfortable home in IIO (their original placement in hwmon was my
fault - oops). As this is our first humidity driver, core support is also
added.
New features
* Two of mxs-lradc channels are internally wired to a temperature sensor,
make this explicit in the driver by providing the relevant temperature
channel.
* Add support for blocking IO on buffers.
* Add a data_available call back to the interface between buffer implementations
and the core. This is much cleaner than the old, 'stufftoread' flag.
Implemented in the kfifo buffer.
Cleanups
* Last user of the old event configuration interface is converted and the
old interface dropped. Nice to be rid of this thanks to Lars-Peter's hard
work!
* Replace all remaining instances of the IIO_ST macro with explicit filling
of the scan_type structure within struct iio_chan_spec. This macro was a
bad idea, that rapidly ceased to cover all elements of the structure.
Miss reading of the macro arguements has led to a number of bugs so lets
just get rid of it. The final removal patch is awaiting for some fixes
to make their way into mainline.
In a couple of drivers, no elements of scan_type were even being used so
in those case, it has been dropped entirely.
* Drop a couple of of_match_ptr helper uses in drivers where devicetree is
not optional and hence the structures being protected by this always exist.
* Fix up some cases where data was read from a device in a particular
byte order, but he code placed it into a s16 or similar. These were
highlighted by Sparse.
* Use the new ATTRIBUTE_GROUPS macro to drop some boiler plate in the triggers
core code.
* ad7746 and ad7280a - stop storing buffers on the stack, giving cleaner code
and possibly avoiding issues with i2c bus drivers that assume they can dma
directly into the buffer. Note that this cannot currently happen as the the
i2c_smbus_read_i2c_block_data function has a memcpy from the buffer actually
passed to the bus driver. I missed this element of the commit message
and don't think it is major enough to rebase the iio tree.
* ad5791 and ad5504 stop storing buffers on the stack for an SPI driver.
Unlike the i2c drivers, this is a real issue for SPI drivers which can dma
directly into the buffer supplied.
'cm36651_of_match' is always compiled in. Hence the
helper macro is not needed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
IIO_ST is going away as it is a pain to maintain so the simplest path with
this driver is to not specify the unused scan type.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
IIO_ST is going away as it is a pain to maintain so the simplest path with
this driver is to not specify the unused scan type.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
The IIO_ST macro no longer covers all the elements of struct scan_type
and has this has lead to some bugs being introduced.
The drivers are easier to follow with this structure being directly
filled so that is now preferred.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
The IIO_ST macro no longer covers all the elements of struct scan_type
and has this has lead to some bugs being introduced.
The drivers are easier to follow with this structure being directly
filled so that is now preferred.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Note this also sets the endianness to big endian whereas it would
previously have defaulted to the cpu endian. Hence technically
this is a bug fix on LE platforms.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: stable@vger.kernel.org
A single channel in this driver was using the IIO_ST macro.
This does not provide a parameter for setting the endianness of
the channel. Thus this channel will have been reported as whatever
is the native endianness of the cpu rather than big endian. This
means it would be incorrect on little endian platforms.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: stable@vger.kernel.org
A return value of callback have been changed to IIO_VAL_INT.
If not IIO_VAL_INT, driver will print wrong value(*_read_int_time).
A follow up patch will deal with a related bug in the new event handling
code.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
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>
Switch the cm36651 driver to the new IIO event config interface as the old one
is going to be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added usage id processing for Inclinometer 3D. This uses IIO
interfaces for triggered buffer to present data to user
mode.This uses HID sensor framework for registering callback
events from the sensor hub.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
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>
Use new ATTRIBUTE_GROUPS macro to declare attribute groups.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Currently the IIO buffer interface only allows non-blocking reads. This patch
adds support for blocking IO. In blocking mode the thread will go to sleep if no
data is available and will wait for the buffer implementation to signal that new
data is available by waking up the buffers waitqueue.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch implements the data_available() callback for the kfifo buffer instead
of using the stufftoread flag. The kfifo used by the buffer already knows
whether it is empty or not based on the position of its read and write pointer.
Using this makes it a lot easier to tell whether data is available or not and it
is not necessary to take special measures to ensure that no race conditions
between reading and writing from the buffer occur.
Note, that we still have to take the buffers lock to protect against concurrent
resizeing of the kfifo.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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>
Fixes the following warnings from sparse:
drivers/iio/light/vcnl4000.c:88:16: warning: cast to restricted __be16
drivers/iio/light/vcnl4000.c:88:16: warning: cast to restricted __be16
drivers/iio/light/vcnl4000.c:88:16: warning: cast to restricted __be16
drivers/iio/light/vcnl4000.c:88:16: warning: cast to restricted __be16
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fixes the following warnings from sparse:
drivers/iio/adc/ad7266.c:140:16: warning: cast to restricted __be16
drivers/iio/adc/ad7266.c:140:16: warning: cast to restricted __be16
drivers/iio/adc/ad7266.c:140:16: warning: cast to restricted __be16
drivers/iio/adc/ad7266.c:140:16: warning: cast to restricted __be16
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some SPI controllers may not be able to handle transfer buffers that are placed
on the stack.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some SPI controllers may not be able to handle transfer buffers that are placed
on the stack.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
drivers/built-in.o: In function `gp2ap020a00f_thresh_event_handler':
powercap_sys.c:(.text+0x15f90c): undefined reference to `irq_work_queue'
make[1]: *** [vmlinux] Error 1
make[1]: Target `uImage' not remade because of errors.
make: *** [sub-make] Error 2
make: Target `uImage' not remade because of errors.
You need the IRQ work support, but GP2AP020A00F is not selecting this
symbol.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In the original HID sensor hub firmwares all Named array enums were
to 0-based. But the most recent hub implemented as 1-based,
because of the implementation by one of the major OS vendor.
Using logical minimum for the field as the base of enum. So we add
logical minimum to the selector values before setting those fields.
Some sensor hub FWs already changed logical minimum from 0 to 1
to reflect this and hope every other vendor will follow.
There is no easy way to add a common HID quirk for NAry elements,
even if the standard specifies these field as NAry, the collection
used to describe selectors is still just "logical".
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This mostly consists of patches that didn't quite make the last cycle. Lots
of interesting things under review currently.
Core:
- Add devm_iio_device_register/unregister. I took some convincing on whether
there would be many devices that really were simple enough to need no
explicit actions on removal. Turns out there are some.
- Move some stray docs to above the relevant implemenation.
- Drop a redundant repeated check on the fact the trigger has actually changed
when there is a userspace attempt change it.
Drivers:
New drivers
- Freescale MPL3115A2 Pressure / temperature sensor
New functionality
- hid_sensors: add sensitivity support.
DT bindings
- tsl2563
- hmc5843
Cleanups
- Drop unused scan_type from viperboard adc driver.
- devm_iio_device_register used in viperboard, ad5421, ad5755, adis16130,
adxrs450, vcnl4000, adis16220, ad7816, lpc32xx, adt7316, adis16060, isl29018
and ad2s1200. Note that this was proposed in a number of other drivers
and this revealed a number of missorderings in remove functions. Also for
now I have blocked this on any device that any hardware suspend suport on
the basis that we probably want to power down devices if they have no driver
support loaded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSk7pfAAoJEFSFNJnE9BaINEAP/2LKNkK/65BI8DOb3DQcRQWw
yQAjYd43c7OWTW6clx3DRZiESI1qR7B1LeIV3P+jF1kvOS5qdE1WfYI9pQCLW+JL
yRQgqLJknuHnrs+Bzw5CrGRcPDl5Zk31megcs0CcOt76LbQsaQ+w/blq9EiuVioW
s2HfopsbVPQBe/IRA5ajLRG5gQYR4FIEIdzifzmv3Zydzhg9yFy5sk6vpSnzN6zM
bh1Q8OooMDCqrCsKwzG1z5ZT4ki6oEILVQsiCblI9kcbw+GyKb95d63E0ZdlH72o
ymowmRGujB+gS1zBh+1zLVjuaUytLHBUxAcQIFYwpOtbqaAYo68J5HFEyXWh5QpH
aeMWnN4Cd54h83SsBofF05aFPGGK3iM6rioDpPJaLjBzJgFuRvIV87O3t0j1/3/Q
VfXKYboGH4EVHsbARoUaQ4UP/0WlXoDQwX5XfBbsSlL9/U58JmrKAx6+HvmSyvcG
5HKzOsVQNKbZMrSlBlvFzPXtRdJwRuv9TwWLLUatQKZAt66rdBgWcycOvlQv1m/9
Neo/2b22vqoAN1AfyW32Hz7rQCnKxVczbTdex9I5ikNJmIPUfbZ6TAE/660HSVE2
J70ZA6SHGU9Edhm0fkJNBhRanO3my4vQFUwcl457JY9O/BeC0xBhU1ZjvkFGysG0
D/9TEiSaLoURkhxeeN0M
=KZou
-----END PGP SIGNATURE-----
Merge tag 'iio-for-3.14a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First set of new features, drivers and cleanups for IIO in the 3.14 cycle.
This mostly consists of patches that didn't quite make the last cycle. Lots
of interesting things under review currently.
Core:
- Add devm_iio_device_register/unregister. I took some convincing on whether
there would be many devices that really were simple enough to need no
explicit actions on removal. Turns out there are some.
- Move some stray docs to above the relevant implemenation.
- Drop a redundant repeated check on the fact the trigger has actually changed
when there is a userspace attempt change it.
Drivers:
New drivers
- Freescale MPL3115A2 Pressure / temperature sensor
New functionality
- hid_sensors: add sensitivity support.
DT bindings
- tsl2563
- hmc5843
Cleanups
- Drop unused scan_type from viperboard adc driver.
- devm_iio_device_register used in viperboard, ad5421, ad5755, adis16130,
adxrs450, vcnl4000, adis16220, ad7816, lpc32xx, adt7316, adis16060, isl29018
and ad2s1200. Note that this was proposed in a number of other drivers
and this revealed a number of missorderings in remove functions. Also for
now I have blocked this on any device that any hardware suspend suport on
the basis that we probably want to power down devices if they have no driver
support loaded.
The usual mixed bag of fixes.
* 3 cases where kconfig dependencies were missing. We need to keep a closer
eye on this in new drivers.
* hid_sensors was abusing the iio_dev->trigger pointer. We had a round
of clearing this out some time ago but this driver clearly slipped through.
* A misuse of the IIO_ST macro, in mcp3422, which we should really make a
concertive effort to finish removing.
* Avoid a double free introduced by recent buffer reference counting in the
one driver that (quite reasonably!) does things differently (am335x)
* A missing mutex_unlock in kxsd9 that means that driver has been non
functional for some time and no one noticed (including me who for once
actually has one of the supported devices).
* An incorrect assumption about the parameters of sign_extend32 in mcp3422.
So nothing controversial. The only substantial patch is the hid_sensors
one and that is actually just adding a new pointer to the devices private
state then moving the code over to it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSk7SvAAoJEFSFNJnE9BaIRNsQAJnM/WiH1ghfA5nuc0V7JrnB
2Z6Qtm3Stoq4Ul5LYiEMxumo6ckL17YFddxejUF9X4Eq5N8YyAxdPd8JdDJgS2OL
yCM2x6izd9drIGA3YUMMOvZ1BScSK1e5DmXJHp4nuF68uHtf2TM4TGF/2zuqt3TN
2bL7blNF3/5O/TiBRB4XjkH4Sy5c4G2kke+0SckRnWohTn8oE7tWihr84nYPciqt
mu11Nrv9S+sr/5GzRwN8d5SU33yU2/ML32QU/4oQzb/XxBW0W759NJflqY5sSZ89
JQnHcCKKZD7IWBFT0VAMiuEjBpSRGc4vxBbYjsVHtEHzW7v3L0fvob5YqfSrzMlD
rVUiTQJm7fC/4hn7iJUPrxkWsSGsjCvVrLZmZFOK3OYONUfd+Cqg0nliihRZo65s
054/yi4v8xd6OUzqSxtWKIK/ZQjDxa5W2BlRoryShCrUAo/e3Djy+jH32v4Mmgfe
D9aEwdUqa8kPlq6pyQC2QRgWWU1K5+RRrzW5nNNLlmjYtVlfF+8OgcQYGHW8iMur
8AaDXNZwQLEYA4409T/Ar9lNg4gDqc0YZsvNibu0q4Kxfp13dJOwra+xmF+ktECr
KcIFxu5v89SgpE1Rra74OXYFWQ1I4Qy+sJxhQKymthPzmw4nuUidK33mxjtcojwz
TvQJu8f3us8Ea5vQLZo0
=cIMc
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-3.13a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First round of fixes for IIO in the 3.13 cycle.
The usual mixed bag of fixes.
* 3 cases where kconfig dependencies were missing. We need to keep a closer
eye on this in new drivers.
* hid_sensors was abusing the iio_dev->trigger pointer. We had a round
of clearing this out some time ago but this driver clearly slipped through.
* A misuse of the IIO_ST macro, in mcp3422, which we should really make a
concertive effort to finish removing.
* Avoid a double free introduced by recent buffer reference counting in the
one driver that (quite reasonably!) does things differently (am335x)
* A missing mutex_unlock in kxsd9 that means that driver has been non
functional for some time and no one noticed (including me who for once
actually has one of the supported devices).
* An incorrect assumption about the parameters of sign_extend32 in mcp3422.
So nothing controversial. The only substantial patch is the hid_sensors
one and that is actually just adding a new pointer to the devices private
state then moving the code over to it.
