6 3) Ensure all desirable features present by adding more devices.
7 Major changes not expected except in response to comments
10 1) Possibly add sysfs exports of constant useful to userspace.
12 2) Support hardware generated interrupts
13 3) Expand device set. Lots of other maxim adc's have very
18 1) Open question of userspace vs kernel space balance when
19 converting to useful light measurements from device ones.
20 2) Add sysfs elements necessary to allow device agnostic
28 Currently minimal driver, would be nice to add:
29 1) Support for all chip generated interrupts (events),
30 basically get support up to level of lis3l02dq driver.
36 1) Testing on devices other than sca3000-e05
39 1) Discussion of approach. Is it general enough?
42 1) Discussion of approach.
43 There are probably better ways of doing this. The
44 intention is to allow for more than one software ring
45 buffer implementation as different users will have
46 different requirements. This one suits mid range
47 frequencies (100Hz - 4kHz).
50 Periodic Timer trigger
51 1) Move to a more general hardware periodic timer request
52 subsystem. Current approach is abusing purpose of RTC.
53 Initial discussions have taken place, but no actual code
54 is in place as yet. This topic will be reopened on lkml
55 shortly. I don't really envision this patch being merged
56 in anything like its current form.
59 1) Add control over the type of interrupt etc. This will
60 necessitate a header that is also visible from arch board
61 files. (avoided at the moment to keep the driver set
62 contained in staging).
65 CC the device-drivers-devel@blackfin.uclinux.org mailing list when
66 e-mailing the normal IIO list (see below).
69 1) Lots of cleanup and expansion.
70 2) Some device require individual docs.
72 Contact: Jonathan Cameron <jic23@kernel.org>.
73 Mailing list: linux-iio@vger.kernel.org