c720842e36
With the recently introduced hrtimer based trigger we have a fully functional replacement for the RTC timer trigger that is more flexible and has a better interface to instantiate and manage the trigger instances. The RTC trigger timer could only be instantiated using platform devices which makes it unsuitable for modern devicetree based platforms, while the hrtimer trigger has a configfs based interface that allows creating and deletion of triggers at runtime. In addition since a few years the periodic RTC timer is internally always emulated using a hrtimer using the hrtimer interface directly will yield the same timing precision. So using the RTC timer won't have any advantages on this front either. There is also no evidence that the periodic RTC trigger is currently actually being used on any system. So considering all this remove the driver. Also remove the related item from the TODO list. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
77 lines
2.2 KiB
Plaintext
77 lines
2.2 KiB
Plaintext
2009 8/18
|
|
|
|
Core:
|
|
1) Get reviews
|
|
2) Additional testing
|
|
3) Ensure all desirable features present by adding more devices.
|
|
Major changes not expected except in response to comments
|
|
|
|
Max1363 core:
|
|
1) Possibly add sysfs exports of constant useful to userspace.
|
|
Would be nice
|
|
2) Support hardware generated interrupts
|
|
3) Expand device set. Lots of other maxim adc's have very
|
|
similar interfaces.
|
|
|
|
MXS LRADC driver:
|
|
This is a classic MFD device as it combines the following subdevices
|
|
- touchscreen controller (input subsystem related device)
|
|
- general purpose ADC channels
|
|
- battery voltage monitor (power subsystem related device)
|
|
- die temperature monitor (thermal management)
|
|
|
|
At least the battery voltage and die temperature feature is required in-kernel
|
|
by a driver of the SoC's battery charging unit to avoid any damage to the
|
|
silicon and the battery.
|
|
|
|
TSL2561
|
|
Would be nice
|
|
1) Open question of userspace vs kernel space balance when
|
|
converting to useful light measurements from device ones.
|
|
2) Add sysfs elements necessary to allow device agnostic
|
|
unit conversion.
|
|
|
|
LIS3L02DQ core
|
|
|
|
LIS3L02DQ ring
|
|
|
|
KXSD9
|
|
Currently minimal driver, would be nice to add:
|
|
1) Support for all chip generated interrupts (events),
|
|
basically get support up to level of lis3l02dq driver.
|
|
|
|
Ring buffer core
|
|
|
|
SCA3000
|
|
Would be nice
|
|
1) Testing on devices other than sca3000-e05
|
|
|
|
Trigger core support
|
|
1) Discussion of approach. Is it general enough?
|
|
|
|
Ring Buffer:
|
|
1) Discussion of approach.
|
|
There are probably better ways of doing this. The
|
|
intention is to allow for more than one software ring
|
|
buffer implementation as different users will have
|
|
different requirements. This one suits mid range
|
|
frequencies (100Hz - 4kHz).
|
|
2) Lots of testing
|
|
|
|
GPIO trigger
|
|
1) Add control over the type of interrupt etc. This will
|
|
necessitate a header that is also visible from arch board
|
|
files. (avoided at the moment to keep the driver set
|
|
contained in staging).
|
|
|
|
ADI Drivers:
|
|
CC the device-drivers-devel@blackfin.uclinux.org mailing list when
|
|
e-mailing the normal IIO list (see below).
|
|
|
|
Documentation
|
|
1) Lots of cleanup and expansion.
|
|
2) Some device require individual docs.
|
|
|
|
Contact: Jonathan Cameron <jic23@kernel.org>.
|
|
Mailing list: linux-iio@vger.kernel.org
|