|
|
@@ -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.
|
Jonathan Cameron