1NOTE: 2===== 3 4While the driver probes the hardware and reports itself as a 5V4L2 driver, there are still some issues preventing it to 6stream (at least it doesn't with the standard V4L2 applications. 7Didn't test yet with some custom-made app for this driver). 8Solving the related bugs and issues preventing it to work is 9needed (items 6 and 7 from the list below). 10 11TODO 12==== 13 141. 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 212. Use ACPI _DSM table - DONE! 22 233. Switch the driver to use pm_runtime stuff. Right now, it probes the 24 existing PMIC code and sensors call it directly. 25 264. 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 405. 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 666. There is some issues at the frame receive logic, causing the 67 DQBUF ioctls to fail. 68 697. 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 768. The file structure needs to get tidied up to resemble a normal Linux 77 driver. 78 799. Lots of the midlayer glue. unused code and abstraction needs removing. 80 8110. 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 8911. 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 10912. 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 11413. Use LED flash API for flash LED drivers such as LM3554 (which already 115 has a LED class driver). 116 11714. Switch from videobuf1 to videobuf2. Videobuf1 is being removed! 118 11915. 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 123Limitations 124=========== 125 1261. 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 1352. 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 1393. 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 1464. The driver supports only v2 of the IPU/Camera. It will not work with the 147 versions of the hardware in other SoCs. 148