blob: 898cba1c939f939299ac16ab3f8dc152662bf01d (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
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: linux-iio@vger.kernel.org
|
