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>

1 files changed, 69 insertions, 0 deletions

diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO
new file mode 100644
index 000000000000..15da0c2bb784
--- /dev/null
+++ b/drivers/staging/iio/TODO
@@ -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.