First round of IIO new device support, features and cleanups for the 4.8 cycle.
New device support
- add ads1115 support
* bma220 accelerometer
- new driver
- triggered buffer support.
- add bmm150 support.
- bme280 support with addition of humidity channel.
* max5487 potentiometer
- new driver
* MMA7660FC accelerometer.
- New driver
- support for the lps22hb
* loop trigger.
- This one is *nasty* but we have real applications (parrot drones) where
it is useful. The trigger basically spins as hard as it can firing off
a new trigger each time all triggered devices come back to say they are
done. It doesn't hang a machine even when doing it on a dummy driver.
A lot nicer than having this implemented within lots of device drivers
* Add support to create IIO devices via configfs (similar to we did for
triggers a while back) + docs.
* New channel types
* Couple of MAINTAINERS patches to list the device tree bindings.
* Make trigger ops structure non optional (comment fix). It hasn't been for
an awful long time, but that's not what the description said.
- support adapters that are limited to byte data only by allowing the
emulated block read i2c function that was recently introduced.
- support atlas-ec (electrical conductivity sensor)
- add available frequency and scale attributes to make the driver
more user friendly (and avoid having to read the datasheet to know
what will work).
- move creation to configfs interface. It's not real hardware so we
are not that worried about the ABI breakage ;)
- oversampling ration support
- expose available gains to make life easier for userspace.
- allow use of emulation for SMBus block reads as all the st parts support
- list datasheet names to allow their use by inkernel consumers.
* Various module alias additions to help auto probing. Drop one redundant one
* ad7266, ad7476, ad7887, ad7923, ad799x
- use direct mode claim function rather than open coding it during sensor
read (prevents switching on buffers mid read).
* ad7793, ad7791
- use direct mode claim to prevent frequency changes when buffers running.
* afe440x - These are ABI breaking but the driver requires custom userspace
code to do anything useful anyway and that is still being written and under
control of TI. Ultimately we may have other libraries to do pulse
oximetry with these devices but we aren't aware of any yet.
- kernel-doc format fixes
- drop ifdef fun around of_match_ptr - it's not worth the mess to save
a tiny amount of space.
- drop some unnecessary register initializations.
- drop the weird locked gain modes as they gain us nothing (can just set
all gains separately).
- remove handling of offset attributes seeing as no channels actually have
- Drop the LED3 input channel as it's an alias for ALED2.
- *big one* remove channel names - an experiment that turned out to not
make sense - see patch for details.
- use regmap fields to clean up code.
- tie the tia gain stages to appropriate channels in the ABI as that is
what they really effect. Same with the LED currents.
- cleanout some unused defines and fix a missnamed one.
- reorganise to allow support of other similar parts.
- document supported chips in kconfig help.
- drop an unneeded i2c functionality check for functionality the driver
- simply touch screen registration code.
- remove the touch screen unregister as all devm based now.
- disable only those channels that are masked in hardware stop (others
are already dealt with elsewhere)
- unexport st_sensors_get_buffer_element as nothing outside the st-sensors
core driver uses it.
- fix handling of failure to start up regulators.
- drop an i2c functionality test for features that aren't needed.
- use variable name rather than type in sizeof for clarity.
- use SIMPLE_DEV_PM_OPS helper macro to tidy up a bit.
* Add install / uninstall to makefile. Someone cares, so presumably
some people will find it useful!
- rename to iio_generic_buffer to line up with other tools.
- handle cleanup when receiving signals
- Add a --device-num option and a --trigger-num option rather than
relying on naming which doesn't work if you have two of the same part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
iio:trigger: Experimental kthread tight loop trigger (thread only)
This patch is in response to that of
Gregor Boirie <email@example.com>
who proposed using a tight kthread within a device driver (be it with the
support factored out into a helper library) in order to basically spin as
fast as possible.
It is meant as a talking point rather than a formal proposal of the code
(though we are heading towards that I think).
Also gives people some working code to mess around with.
I proposed that this could be done with a trigger with a few constraints
and this is the proof (be it ugly) of that.
There are some constraints though, some of which we would want to relax
if this were to move forward.
* Will only run the thread part of the registered pollfunc. This is to
avoid the overhead of jumping in and out of interrupt context. Is the
overhead significant? Not certain but feels like it should be!
* This limitation precludes any device that 'must' do some work in
interrupt context. However, that is true of few if any drivers and
I suspect that any that do will be restricted to using triggers they
provide themselves. Usually we have a top half mainly to grab a
timestamp as soon after the dataready type signal as possible.
Signed-off-by: Jonathan Cameron <firstname.lastname@example.org>
Acked-by: Daniel Baluta <email@example.com>
3 files changed