Jonathan Cameron | ff460c3 | 2009-08-18 18:06:33 +0100 | [diff] [blame] | 1 | 2009 8/18 |
| 2 | |
| 3 | Core: |
| 4 | 1) Get reviews |
| 5 | 2) Additional testing |
| 6 | 3) Ensure all desirable features present by adding more devices. |
| 7 | Major changes not expected except in response to comments |
| 8 | |
| 9 | Max1363 core: |
| 10 | 1) Possibly add sysfs exports of constant useful to userspace. |
| 11 | Would be nice |
| 12 | 2) Support hardware generated interrupts |
| 13 | 3) Expand device set. Lots of other maxim adc's have very |
| 14 | similar interfaces. |
| 15 | |
| 16 | TSL2561 |
| 17 | Would be nice |
| 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 |
| 21 | unit conversion. |
| 22 | |
| 23 | LIS3L02DQ core |
| 24 | |
| 25 | LIS3L02DQ ring |
| 26 | |
| 27 | KXSD9 |
| 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. |
| 31 | |
| 32 | Ring buffer core |
| 33 | |
| 34 | SCA3000 |
| 35 | Would be nice |
| 36 | 1) Testing on devices other than sca3000-e05 |
| 37 | |
| 38 | Trigger core support |
| 39 | 1) Discussion of approach. Is it general enough? |
| 40 | |
| 41 | Ring Buffer: |
| 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). |
| 48 | 2) Lots of testing |
| 49 | |
| 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. |
| 57 | |
| 58 | GPIO trigger |
| 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). |
| 63 | |
Mike Frysinger | 6f125f1 | 2010-10-27 21:43:48 -0400 | [diff] [blame^] | 64 | ADI Drivers: |
| 65 | CC the device-drivers-devel@blackfin.uclinux.org mailing list when |
| 66 | e-mailing the normal IIO list (see below). |
| 67 | |
Jonathan Cameron | ff460c3 | 2009-08-18 18:06:33 +0100 | [diff] [blame] | 68 | Documentation |
| 69 | 1) Lots of cleanup and expansion. |
| 70 | 2) Some device require indvidual docs. |
| 71 | |
| 72 | Contact: Jonathan Cameron <jic23@cam.ac.uk>. |
Jonathan Cameron | de6c37a | 2010-06-07 20:54:07 +0100 | [diff] [blame] | 73 | Mailing list: linux-iio@vger.kernel.org |