diff options
Diffstat (limited to 'drivers/staging/media/atomisp/TODO')
-rw-r--r-- | drivers/staging/media/atomisp/TODO | 147 |
1 files changed, 147 insertions, 0 deletions
diff --git a/drivers/staging/media/atomisp/TODO b/drivers/staging/media/atomisp/TODO new file mode 100644 index 000000000000..6987bb2d32cf --- /dev/null +++ b/drivers/staging/media/atomisp/TODO @@ -0,0 +1,147 @@ +NOTE: +===== + +While the driver probes the hardware and reports itself as a +V4L2 driver, there are still some issues preventing it to +stream (at least it doesn't with the standard V4L2 applications. +Didn't test yet with some custom-made app for this driver). +Solving the related bugs and issues preventing it to work is +needed (items 6 and 7 from the list below). + +TODO +==== + +1. The atomisp doesn't rely at the usual i2c stuff to discover the + sensors. Instead, it calls a function from atomisp_gmin_platform.c. + There are some hacks added there for it to wait for sensors to be + probed (with a timeout of 2 seconds or so). + This should be converted to the usual way, using V4L2 async subdev + framework to wait for cameras to be probed; + +2. Use ACPI _DSM table - DONE! + +3. Switch the driver to use pm_runtime stuff. Right now, it probes the + existing PMIC code and sensors call it directly. + +4. There's a problem at the sensor drivers: when trying to set a video + format, the atomisp main driver calls the sensor drivers with the + sensor turned off. This causes them to fail. + + The only exception is the atomisp-ov2880, which has a hack inside it + to turn it on when VIDIOC_S_FMT is called. + + The right fix seems to power on the sensor when a video device is + opened (or at the first VIDIOC_ ioctl - except for VIDIOC_QUERYCAP), + powering it down at close() syscall. + + Such kind of control would need to be done inside the atomisp driver, + not at the sensors code. + +5. There are several issues related to memory management, causing + crashes. The atomisp splits the memory management on three separate + regions: + + - dynamic pool; + - reserved pool; + - generic pool + + The code implementing it is at: + + drivers/staging/media/atomisp/pci/hmm/ + + It also has a separate code for managing DMA buffers at: + + drivers/staging/media/atomisp/pci/mmu/ + + The code there is really dirty, ugly and probably wrong. I fixed + one bug there already, but the best would be to just trash it and use + something else. Maybe the code from the newer intel driver could + serve as a model: + + drivers/staging/media/ipu3/ipu3-mmu.c + + But converting it to use something like that is painful and may + cause some breakages. + +6. There is some issues at the frame receive logic, causing the + DQBUF ioctls to fail. + +7. A single AtomISP driver needs to be implemented to support both + Baytrail (BYT) and Cherrytail (CHT) platforms at the same time. + The current driver is a mechanical and hand combined merge of the + two using several runtime macros, plus some ifdef ISP2401 to select the + CHT version. Yet, there are some ISP-specific headers that change the + driver's behavior during compile time. + +8. The file structure needs to get tidied up to resemble a normal Linux + driver. + +9. Lots of the midlayer glue. unused code and abstraction needs removing. + +10. The AtomISP driver includes some special IOCTLS (ATOMISP_IOC_XXXX_XXXX) + and controls that require some cleanup. Some of those code may have + been removed during the cleanups. They could be needed in order to + properly support 3A algorithms + + Such IOCTL interface needs more documentation. The better would + be to use something close to the interface used by the IPU3 IMGU driver. + +11. The ISP code has some dependencies of the exact FW version. + The version defined in pci/sh_css_firmware.c: + + BYT (isp2400): "irci_stable_candrpv_0415_20150521_0458" + + CHT (isp2401): "irci_ecr - master_20150911_0724" + + Those versions don't seem to be available anymore. On the tests we've + done so far, this version also seems to work for CHT: + + "irci_stable_candrpv_0415_20150521_0458" + + Which can be obtainable from Yocto Atom ISP respository. + + but this was not thoroughly tested. + + At some point we may need to round up a few driver versions and see if + there are any specific things that can be done to fold in support for + multiple firmware versions. + +12. Switch to standard V4L2 sub-device API for sensor and lens. In + particular, the user space API needs to support V4L2 controls as + defined in the V4L2 spec and references to atomisp must be removed from + these drivers. + +13. Use LED flash API for flash LED drivers such as LM3554 (which already + has a LED class driver). + +14. Switch from videobuf1 to videobuf2. Videobuf1 is being removed! + +15. Correct Coding Style. Please refrain sending coding style patches + for this driver until the other work is done, as there will be a lot + of code churn until this driver becomes functional again. + +Limitations +=========== + +1. To test the patches, you also need the ISP firmware + + for BYT: /lib/firmware/shisp_2400b0_v21.bin + for CHT: /lib/firmware/shisp_2401a0_v21.bin + + The firmware files will usually be found in /etc/firmware on an Android + device but can also be extracted from the upgrade kit if you've managed + to lose them somehow. + +2. Without a 3A library the capture behaviour is not very good. To take a good + picture, you need tune ISP parameters by IOCTL functions or use a 3A library + such as libxcam. + +3. The driver is intended to drive the PCI exposed versions of the device. + It will not detect those devices enumerated via ACPI as a field of the + i915 GPU driver. + + There are some patches adding i915 GPU support floating at the Yocto's + Aero repository (so far, untested upstream). + +4. The driver supports only v2 of the IPU/Camera. It will not work with the + versions of the hardware in other SoCs. |