Staging: IIO: Add todo list for staging
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit is contained in:
parent
c57f1ba732
commit
ff460c39ea
69
drivers/staging/iio/TODO
Normal file
69
drivers/staging/iio/TODO
Normal file
|
@ -0,0 +1,69 @@
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
Periodic Timer trigger
|
||||||
|
1) Move to a more general hardware periodic timer request
|
||||||
|
subsystem. Current approach is abusing purpose of RTC.
|
||||||
|
Initial discussions have taken place, but no actual code
|
||||||
|
is in place as yet. This topic will be reopened on lkml
|
||||||
|
shortly. I don't really envision this patch being merged
|
||||||
|
in anything like its current form.
|
||||||
|
|
||||||
|
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).
|
||||||
|
|
||||||
|
Documentation
|
||||||
|
1) Lots of cleanup and expansion.
|
||||||
|
2) Some device require indvidual docs.
|
||||||
|
|
||||||
|
Contact: Jonathan Cameron <jic23@cam.ac.uk>.
|
||||||
|
Mailing list: LKML.
|
Loading…
Reference in a new issue