drivers/staging/media/atomisp/TODO

   1 /*(DEBLOBBED)*/
   2
   3 NOTE:
   4 =====
   5
   6 This driver currently doesn't work with most V4L2 applications,
   7 as there are still some issues with regards to implementing
   8 certain APIs at the standard way.
   9
  10 Also, currently only USERPTR streaming mode is working.
  11
  12 In order to test, it is needed to know what's the sensor's
  13 resolution. This can be checked with:
  14
  15 $ v4l2-ctl --get-fmt-video
  16   Format Video Capture:
  17         Width/Height      : 1600/1200
  18         ...
  19
  20 It is known to work with:
  21
  22 - v4l2grab at contrib/test directory at https://git.linuxtv.org/v4l-utils.git/
  23
  24   The resolution should not be bigger than the max resolution
  25   supported by the sensor, or it will fail. So, if the sensor
  26   reports:
  27
  28   The driver can be tested with:
  29
  30   v4l2grab -f YUYV -x 1600 -y 1200 -d /dev/video2 -u
  31
  32 - NVT at https://github.com/intel/nvt
  33
  34   $ ./v4l2n -o testimage_@.raw \
  35                  --device /dev/video2 \
  36                  --input 0 \
  37                  --exposure=30000,30000,30000,30000 \
  38                  --parm type=1,capturemode=CI_MODE_PREVIEW \
  39                  --fmt type=1,width=1600,height=1200,pixelformat=YUYV \
  40                  --reqbufs count=2,memory=USERPTR \
  41                  --parameters=wb_config.r=32768,wb_config.gr=21043,wb_config.gb=21043,wb_config.b=30863 \
  42                  --capture=20
  43
  44   As the output is in raw format, images need to be converted with:
  45
  46   $ for i in $(seq 0 19); do
  47         name="testimage_$(printf "%03i" $i)"
  48         ./raw2pnm -x$WIDTH -y$HEIGHT -f$FORMAT $name.raw $name.pnm
  49         rm $name.raw
  50     done
  51
  52 TODO
  53 ====
  54
  55 1.  Fix support for MMAP streaming mode. This is required for most
  56     V4L2 applications;
  57
  58 2.  Implement and/or fix V4L2 ioctls in order to allow a normal app to
  59     use it;
  60
  61 3.  Ensure that the driver will pass v4l2-compliance tests;
  62
  63 4.  Get manufacturer's authorization to redistribute the binaries for
  64     the firmware files;
  65
  66 5.  remove VIDEO_ATOMISP_ISP2401, making the driver to auto-detect the
  67     register address differences between ISP2400 and ISP2401;
  68
  69 6.  Cleanup the driver code, removing the abstraction layers inside it;
  70
  71 7.  The atomisp doesn't rely at the usual i2c stuff to discover the
  72     sensors. Instead, it calls a function from atomisp_gmin_platform.c.
  73     There are some hacks added there for it to wait for sensors to be
  74     probed (with a timeout of 2 seconds or so). This should be converted
  75     to the usual way, using V4L2 async subdev framework to wait for
  76     cameras to be probed;
  77
  78 8.  Switch to standard V4L2 sub-device API for sensor and lens. In
  79     particular, the user space API needs to support V4L2 controls as
  80     defined in the V4L2 spec and references to atomisp must be removed from
  81     these drivers.
  82
  83 9.  Use LED flash API for flash LED drivers such as LM3554 (which already
  84     has a LED class driver).
  85
  86 10. Migrate the sensor drivers out of staging or re-using existing
  87     drivers;
  88
  89 11. Switch the driver to use pm_runtime stuff. Right now, it probes the
  90     existing PMIC code and sensors call it directly.
  91
  92 12. There's a problem on sensor drivers: when trying to set a video
  93     format, the atomisp main driver calls the sensor drivers with the
  94     sensor turned off. This causes them to fail.
  95
  96     This was fixed at atomisp-ov2880, which has a hack inside it
  97     to turn it on when VIDIOC_S_FMT is called, but this has to be
  98     cheked on other drivers as well.
  99
 100     The right fix seems to power on the sensor when a video device is
 101     opened (or at the first VIDIOC_ ioctl - except for VIDIOC_QUERYCAP),
 102     powering it down at close() syscall.
 103
 104     Such kind of control would need to be done inside the atomisp driver,
 105     not at the sensors code.
 106
 107 13. There are several issues related to memory management, that can
 108     cause crashes and/or memory leaks. The atomisp splits the memory
 109     management on three separate regions:
 110
 111         - dynamic pool;
 112         - reserved pool;
 113         - generic pool
 114
 115     The code implementing it is at:
 116
 117         drivers/staging/media/atomisp/pci/hmm/
 118
 119     It also has a separate code for managing DMA buffers at:
 120
 121         drivers/staging/media/atomisp/pci/mmu/
 122
 123     The code there is really dirty, ugly and probably wrong. I fixed
 124     one bug there already, but the best would be to just trash it and use
 125     something else. Maybe the code from the newer intel driver could
 126     serve as a model:
 127
 128         drivers/staging/media/ipu3/ipu3-mmu.c
 129
 130     But converting it to use something like that is painful and may
 131     cause some breakages.
 132
 133 14. The file structure needs to get tidied up to resemble a normal Linux
 134     driver.
 135
 136 15. Lots of the midlayer glue. Unused code and abstraction needs removing.
 137
 138 16. The AtomISP driver includes some special IOCTLS (ATOMISP_IOC_XXXX_XXXX)
 139     and controls that require some cleanup. Some of those code may have
 140     been removed during the cleanups. They could be needed in order to
 141     properly support 3A algorithms.
 142
 143     Such IOCTL interface needs more documentation. The better would
 144     be to use something close to the interface used by the IPU3 IMGU driver.
 145
 146 17. The ISP code has some dependencies of the exact FW version.
 147     The version defined in pci/sh_css_firmware.c:
 148
 149     BYT (isp2400): "irci_stable_candrpv_0415_20150521_0458"
 150
 151     CHT (isp2401): "irci_ecr - master_20150911_0724"
 152
 153     Those versions don't seem to be available anymore. On the tests we've
 154     done so far, this version also seems to work for CHT:
 155
 156                 "irci_stable_candrpv_0415_20150521_0458"
 157
 158     Which can be obtainable from Yocto Atom ISP respository.
 159
 160     but this was not thoroughly tested.
 161
 162     At some point we may need to round up a few driver versions and see if
 163     there are any specific things that can be done to fold in support for
 164     multiple firmware versions.
 165
 166
 167 18. Switch from videobuf1 to videobuf2. Videobuf1 is being removed!
 168
 169 19. Correct Coding Style. Please refrain sending coding style patches
 170     for this driver until the other work is done, as there will be a lot
 171     of code churn until this driver becomes functional again.
 172
 173 20. Remove the logic which sets up pipelines inside it, moving it to
 174     libcamera and implement MC support.
 175
 176
 177 Limitations
 178 ===========
 179
 180 1. To test the patches, you also need the ISP firmware
 181
 182    for BYT: /lib/firmware//*(DEBLOBBED)*/
 183    for CHT: /lib/firmware//*(DEBLOBBED)*/
 184
 185    The firmware files will usually be found in /etc/firmware on an Android
 186    device but can also be extracted from the upgrade kit if you've managed
 187    to lose them somehow.
 188
 189 2. Without a 3A library the capture behaviour is not very good. To take a good
 190    picture, you need tune ISP parameters by IOCTL functions or use a 3A library
 191    such as libxcam.
 192
 193 3. The driver is intended to drive the PCI exposed versions of the device.
 194    It will not detect those devices enumerated via ACPI as a field of the
 195    i915 GPU driver.
 196
 197    There are some patches adding i915 GPU support floating at the Yocto's
 198    Aero repository (so far, untested upstream).
 199
 200 4. The driver supports only v2 of the IPU/Camera. It will not work with the
 201    versions of the hardware in other SoCs.