ff460c39ea
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
70 lines
1.9 KiB
Plaintext
70 lines
1.9 KiB
Plaintext
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.
|