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. Use ACPI _DSM table - DONE!
  22
  23 3. Switch the driver to use pm_runtime stuff. Right now, it probes the
  24    existing PMIC code and sensors call it directly.
  25
  26 4. There's a problem at the sensor drivers: when trying to set a video
  27    format, the atomisp main driver calls the sensor drivers with the
  28    sensor turned off. This causes them to fail.
  29
  30    The only exception is the atomisp-ov2880, which has a hack inside it
  31    to turn it on when VIDIOC_S_FMT is called.
  32
  33    The right fix seems to power on the sensor when a video device is
  34    opened (or at the first VIDIOC_ ioctl - except for VIDIOC_QUERYCAP),
  35    powering it down at close() syscall.
  36
  37    Such kind of control would need to be done inside the atomisp driver,
  38    not at the sensors code.
  39
  40 5. There are several issues related to memory management, causing
  41    crashes. The atomisp splits the memory management on three separate
  42    regions:
  43
  44         - dynamic pool;
  45         - reserved pool;
  46         - generic pool
  47
  48    The code implementing it is at:
  49
  50         drivers/staging/media/atomisp/pci/hmm/
  51
  52    It also has a separate code for managing DMA buffers at:
  53
  54         drivers/staging/media/atomisp/pci/mmu/
  55
  56    The code there is really dirty, ugly and probably wrong. I fixed
  57    one bug there already, but the best would be to just trash it and use
  58    something else. Maybe the code from the newer intel driver could
  59    serve as a model:
  60
  61         drivers/staging/media/ipu3/ipu3-mmu.c
  62
  63    But converting it to use something like that is painful and may
  64    cause some breakages.
  65
  66 6. There is some issues at the frame receive logic, causing the
  67    DQBUF ioctls to fail.
  68
  69 7. A single AtomISP driver needs to be implemented to support both
  70    Baytrail (BYT) and Cherrytail (CHT) platforms at the same time.
  71    The current driver is a mechanical and hand combined merge of the
  72    two using several runtime macros, plus some ifdef ISP2401 to select the
  73    CHT version. Yet, there are some ISP-specific headers that change the
  74    driver's behavior during compile time.
  75
  76 8. The file structure needs to get tidied up to resemble a normal Linux
  77    driver.
  78
  79 9. Lots of the midlayer glue. unused code and abstraction needs removing.
  80
  81 10. The AtomISP driver includes some special IOCTLS (ATOMISP_IOC_XXXX_XXXX)
  82     and controls that require some cleanup. Some of those code may have
  83     been removed during the cleanups. They could be needed in order to
  84     properly support 3A algorithms
  85
  86     Such IOCTL interface needs more documentation. The better would
  87     be to use something close to the interface used by the IPU3 IMGU driver.
  88
  89 11. The ISP code has some dependencies of the exact FW version.
  90     The version defined in pci/sh_css_firmware.c:
  91
  92     BYT (isp2400): "irci_stable_candrpv_0415_20150521_0458"
  93
  94     CHT (isp2401): "irci_ecr - master_20150911_0724"
  95
  96     Those versions don't seem to be available anymore. On the tests we've
  97     done so far, this version also seems to work for CHT:
  98
  99                 "irci_stable_candrpv_0415_20150521_0458"
 100
 101     Which can be obtainable from Yocto Atom ISP respository.
 102
 103     but this was not thoroughly tested.
 104
 105     At some point we may need to round up a few driver versions and see if
 106     there are any specific things that can be done to fold in support for
 107     multiple firmware versions.
 108
 109 12. Switch to standard V4L2 sub-device API for sensor and lens. In
 110     particular, the user space API needs to support V4L2 controls as
 111     defined in the V4L2 spec and references to atomisp must be removed from
 112     these drivers.
 113
 114 13. Use LED flash API for flash LED drivers such as LM3554 (which already
 115     has a LED class driver).
 116
 117 14. Switch from videobuf1 to videobuf2. Videobuf1 is being removed!
 118
 119 15. Correct Coding Style. Please refrain sending coding style patches
 120     for this driver until the other work is done, as there will be a lot
 121     of code churn until this driver becomes functional again.
 122
 123 Limitations
 124 ===========
 125
 126 1. To test the patches, you also need the ISP firmware
 127
 128    for BYT: /lib/firmware/shisp_2400b0_v21.bin
 129    for CHT: /lib/firmware/shisp_2401a0_v21.bin
 130
 131    The firmware files will usually be found in /etc/firmware on an Android
 132    device but can also be extracted from the upgrade kit if you've managed
 133    to lose them somehow.
 134
 135 2. Without a 3A library the capture behaviour is not very good. To take a good
 136    picture, you need tune ISP parameters by IOCTL functions or use a 3A library
 137    such as libxcam.
 138
 139 3. The driver is intended to drive the PCI exposed versions of the device.
 140    It will not detect those devices enumerated via ACPI as a field of the
 141    i915 GPU driver.
 142
 143    There are some patches adding i915 GPU support floating at the Yocto's
 144    Aero repository (so far, untested upstream).
 145
 146 4. The driver supports only v2 of the IPU/Camera. It will not work with the
 147    versions of the hardware in other SoCs.