diff options
Diffstat (limited to 'drivers/staging/iio/TODO')
-rw-r--r-- | drivers/staging/iio/TODO | 69 |
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. |