12009 8/18
2
3Core:
41) Get reviews
52) Additional testing
63) Ensure all desirable features present by adding more devices.
7   Major changes not expected except in response to comments
8
9Max1363 core:
101) Possibly add sysfs exports of constant useful to userspace.
11Would be nice
122) Support hardware generated interrupts
133) Expand device set. Lots of other maxim adc's have very
14   similar interfaces.
15
16MXS LRADC driver:
17This is a classic MFD device as it combines the following subdevices
18 - touchscreen controller (input subsystem related device)
19 - general purpose ADC channels
20 - battery voltage monitor (power subsystem related device)
21 - die temperature monitor (thermal management)
22
23At least the battery voltage and die temperature feature is required in-kernel
24by a driver of the SoC's battery charging unit to avoid any damage to the
25silicon and the battery.
26
27TSL2561
28Would be nice
291) Open question of userspace vs kernel space balance when
30converting to useful light measurements from device ones.
312) Add sysfs elements necessary to allow device agnostic
32unit conversion.
33
34LIS3L02DQ core
35
36LIS3L02DQ ring
37
38KXSD9
39Currently minimal driver, would be nice to add:
401) Support for all chip generated interrupts (events),
41basically get support up to level of lis3l02dq driver.
42
43Ring buffer core
44
45SCA3000
46Would be nice
471) Testing on devices other than sca3000-e05
48
49Trigger core support
501) Discussion of approach. Is it general enough?
51
52Ring Buffer:
531) Discussion of approach.
54There are probably better ways of doing this. The
55intention is to allow for more than one software ring
56buffer implementation as different users will have
57different requirements.  This one suits mid range
58frequencies (100Hz - 4kHz).
592) Lots of testing
60
61Periodic Timer trigger
621) Move to a more general hardware periodic timer request
63subsystem. Current approach is abusing purpose of RTC.
64Initial discussions have taken place, but no actual code
65is in place as yet. This topic will be reopened on lkml
66shortly. I don't really envision this patch being merged
67in anything like its current form.
68
69GPIO trigger
701) Add control over the type of interrupt etc.  This will
71necessitate a header that is also visible from arch board
72files. (avoided at the moment to keep the driver set
73contained in staging).
74
75ADI Drivers:
76CC the device-drivers-devel@blackfin.uclinux.org mailing list when
77e-mailing the normal IIO list (see below).
78
79Documentation
801) Lots of cleanup and expansion.
812) Some device require individual docs.
82
83Contact: Jonathan Cameron <jic23@kernel.org>.
84Mailing list: linux-iio@vger.kernel.org
85