drivers/staging/media/atomisp/TODO

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