From: Jonathan Cameron Date: Tue, 18 Aug 2009 17:06:33 +0000 (+0100) Subject: Staging: IIO: Add todo list for staging X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=ff460c39ea80f4a66e47990d82211c14379d9e8a;p=GitHub%2Fmt8127%2Fandroid_kernel_alcatel_ttab.git Staging: IIO: Add todo list for staging Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman --- 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 . +Mailing list: LKML.