drivers/staging/media/atomisp/TODO

   1 NOTE:
   2 =====
   3
   4 While the driver probes the hardware and reports itself as a
   5 V4L2 driver, there are still some issues preventing it to
   6 stream (at least it doesn't with the standard V4L2 applications.
   7 Didn't test yet with some custom-made app for this driver).
   8 Solving the related bugs and issues preventing it to work is
   9 needed (items 6 and 7 from the list below).
  10
  11 TODO
  12 ====
  13
  14 1. The atomisp doesn't rely at the usual i2c stuff to discover the
  15    sensors. Instead, it calls a function from atomisp_gmin_platform.c.
  16    There are some hacks added there for it to wait for sensors to be
  17    probed (with a timeout of 2 seconds or so).
  18    This should be converted to the usual way, using V4L2 async subdev
  19    framework to wait for cameras to be probed;
  20
  21 2. Support for newer board-specific data (like Asus T101HA support) uses a
  22    DMI match table to retrieve sensor's data, using hard-coded values.
  23    It sounds feasible to retrieve those data directly from ACPI via _DSM
  24    tables (like this one, associated with CAM1 at the above mentioned
  25    hardware):
  26
  27             Name (C1CD, Buffer (0x0220){})
  28             Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
  29             {
  30                 If ((Arg0 == ToUUID ("dc2f6c4f-045b-4f1d-97b9-882a6860a4be")))
  31                 {
  32                     Local0 = Package (0x12)
  33                         {
  34                             "CamId",
  35                             "ov2680",
  36                             "CamType",
  37                             "1",
  38                             "CsiPort",
  39                             "0",
  40                             "CsiLanes",
  41                             "1",
  42                             "CsiFmt",
  43                             "15",
  44                             "CsiBayer",
  45                             "0",
  46                             "CamClk",
  47                             "1",
  48                             "Regulator1p8v",
  49                             "0",
  50                             "Regulator2p8v",
  51                             "0"
  52                         }
  53                     Return (Local0)
  54                 }
  55
  56    The code there at atomisp_gmin_platform has an EFI parser, but it
  57    assumes that the information would be stored on a different way.
  58
  59    As the Kernel has support for reading data from _DSM, via
  60    acpi_evaluate_dsm(), it sounds doable to use such infra and remove the
  61    DMI match, at least for some devices. This will likely allow covering
  62    more devices that could also be using the same EFI UUID.
  63
  64 3. Switch the driver to use pm_runtime stuff. Right now, it probes the
  65    existing PMIC code and sensors call it directly.
  66
  67 4. There's a problem at the sensor drivers: when trying to set a video
  68    format, the atomisp main driver calls the sensor drivers with the
  69    sensor turned off. This causes them to fail.
  70
  71    The only exception is the atomisp-ov2880, which has a hack inside it
  72    to turn it on when VIDIOC_S_FMT is called.
  73
  74    The right fix seems to power on the sensor when a video device is
  75    opened (or at the first VIDIOC_ ioctl - except for VIDIOC_QUERYCAP),
  76    powering it down at close() syscall.
  77
  78    Such kind of control would need to be done inside the atomisp driver,
  79    not at the sensors code.
  80
  81 5. There are several issues related to memory management, causing
  82    crashes. The atomisp splits the memory management on three separate
  83    regions:
  84
  85         - dynamic pool;
  86         - reserved pool;
  87         - generic pool
  88
  89    The code implementing it is at:
  90
  91         drivers/staging/media/atomisp/pci/hmm/
  92
  93    It also has a separate code for managing DMA buffers at:
  94
  95         drivers/staging/media/atomisp/pci/mmu/
  96
  97    The code there is really dirty, ugly and probably wrong. I fixed
  98    one bug there already, but the best would be to just trash it and use
  99    something else. Maybe the code from the newer intel driver could
 100    serve as a model:
 101
 102         drivers/staging/media/ipu3/ipu3-mmu.c
 103
 104    But converting it to use something like that is painful and may
 105    cause some breakages.
 106
 107 6. There is some issues at the frame receive logic, causing the
 108    DQBUF ioctls to fail.
 109
 110 7. A single AtomISP driver needs to be implemented to support both
 111    Baytrail (BYT) and Cherrytail (CHT) platforms at the same time.
 112    The current driver is a mechanical and hand combined merge of the
 113    two using several runtime macros, plus some ifdef ISP2401 to select the
 114    CHT version. Yet, there are some ISP-specific headers that change the
 115    driver's behavior during compile time.
 116
 117 8. The file structure needs to get tidied up to resemble a normal Linux
 118    driver.
 119
 120 9. Lots of the midlayer glue. unused code and abstraction needs removing.
 121
 122 10. The AtomISP driver includes some special IOCTLS (ATOMISP_IOC_XXXX_XXXX)
 123     and controls that require some cleanup. Some of those code may have
 124     been removed during the cleanups. They could be needed in order to
 125     properly support 3A algorithms
 126
 127     Such IOCTL interface needs more documentation. The better would
 128     be to use something close to the interface used by the IPU3 IMGU driver.
 129
 130 11. The ISP code has some dependencies of the exact FW version.
 131     The version defined in pci/sh_css_firmware.c:
 132
 133     BYT (isp2400): "irci_stable_candrpv_0415_20150521_0458"
 134
 135     CHT (isp2401): "irci_ecr - master_20150911_0724"
 136
 137     Those versions don't seem to be available anymore. On the tests we've
 138     done so far, this version also seems to work for CHT:
 139
 140                 "irci_stable_candrpv_0415_20150521_0458"
 141
 142     Which can be obtainable from Yocto Atom ISP respository.
 143
 144     but this was not thoroughly tested.
 145
 146     At some point we may need to round up a few driver versions and see if
 147     there are any specific things that can be done to fold in support for
 148     multiple firmware versions.
 149
 150 12. Switch to standard V4L2 sub-device API for sensor and lens. In
 151     particular, the user space API needs to support V4L2 controls as
 152     defined in the V4L2 spec and references to atomisp must be removed from
 153     these drivers.
 154
 155 13. Use LED flash API for flash LED drivers such as LM3554 (which already
 156     has a LED class driver).
 157
 158 14. Switch from videobuf1 to videobuf2. Videobuf1 is being removed!
 159
 160 15. Correct Coding Style. Please refrain sending coding style patches
 161     for this driver until the other work is done, as there will be a lot
 162     of code churn until this driver becomes functional again.
 163
 164 Limitations
 165 ===========
 166
 167 1. To test the patches, you also need the ISP firmware
 168
 169    for BYT: /lib/firmware/shisp_2400b0_v21.bin
 170    for CHT: /lib/firmware/shisp_2401a0_v21.bin
 171
 172    The firmware files will usually be found in /etc/firmware on an Android
 173    device but can also be extracted from the upgrade kit if you've managed
 174    to lose them somehow.
 175
 176 2. Without a 3A library the capture behaviour is not very good. To take a good
 177    picture, you need tune ISP parameters by IOCTL functions or use a 3A library
 178    such as libxcam.
 179
 180 3. The driver is intended to drive the PCI exposed versions of the device.
 181    It will not detect those devices enumerated via ACPI as a field of the
 182    i915 GPU driver.
 183
 184    There are some patches adding i915 GPU support floating at the Yocto's
 185    Aero repository (so far, untested upstream).
 186
 187 4. The driver supports only v2 of the IPU/Camera. It will not work with the
 188    versions of the hardware in other SoCs.