kernel/drivers/staging/iio/TODO

   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 MXS LRADC driver:
  17 This 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
  23 At least the battery voltage and die temperature feature is required in-kernel
  24 by a driver of the SoC's battery charging unit to avoid any damage to the
  25 silicon and the battery.
  26
  27 TSL2561
  28 Would be nice
  29 1) Open question of userspace vs kernel space balance when
  30 converting to useful light measurements from device ones.
  31 2) Add sysfs elements necessary to allow device agnostic
  32 unit conversion.
  33
  34 LIS3L02DQ core
  35
  36 LIS3L02DQ ring
  37
  38 KXSD9
  39 Currently minimal driver, would be nice to add:
  40 1) Support for all chip generated interrupts (events),
  41 basically get support up to level of lis3l02dq driver.
  42
  43 Ring buffer core
  44
  45 SCA3000
  46 Would be nice
  47 1) Testing on devices other than sca3000-e05
  48
  49 Trigger core support
  50 1) Discussion of approach. Is it general enough?
  51
  52 Ring Buffer:
  53 1) Discussion of approach.
  54 There are probably better ways of doing this. The
  55 intention is to allow for more than one software ring
  56 buffer implementation as different users will have
  57 different requirements.  This one suits mid range
  58 frequencies (100Hz - 4kHz).
  59 2) Lots of testing
  60
  61 Periodic Timer trigger
  62 1) Move to a more general hardware periodic timer request
  63 subsystem. Current approach is abusing purpose of RTC.
  64 Initial discussions have taken place, but no actual code
  65 is in place as yet. This topic will be reopened on lkml
  66 shortly. I don't really envision this patch being merged
  67 in anything like its current form.
  68
  69 GPIO trigger
  70 1) Add control over the type of interrupt etc.  This will
  71 necessitate a header that is also visible from arch board
  72 files. (avoided at the moment to keep the driver set
  73 contained in staging).
  74
  75 ADI Drivers:
  76 CC the device-drivers-devel@blackfin.uclinux.org mailing list when
  77 e-mailing the normal IIO list (see below).
  78
  79 Documentation
  80 1) Lots of cleanup and expansion.
  81 2) Some device require individual docs.
  82
  83 Contact: Jonathan Cameron <jic23@kernel.org>.
  84 Mailing list: linux-iio@vger.kernel.org