| 1. 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. |
| |
| 2. The file structure needs to get tidied up to resemble a normal Linux |
| driver. |
| |
| 3. Lots of the midlayer glue. unused code and abstraction needs removing. |
| |
| 3. The sensor drivers read MIPI settings from EFI variables or default to the |
| settings hard-coded in the platform data file for different platforms. |
| It should be possible to improve it, by adding support for _DSM tables. |
| |
| 4. The sensor drivers use PMIC and the regulator framework API. In the ideal |
| world it would be using ACPI but that's not how the existing devices work. |
| |
| 5. The AtomISP driver includes some special IOCTLS (ATOMISP_IOC_XXXX_XXXX) |
| and controls that require some cleanup. |
| |
| 6. Correct Coding Style. Please don't send coding style patches for this |
| driver until the other work is done. |
| |
| 7. The ISP code has some dependencies of the exact FW version. |
| The version defined in pci/sh_css_firmware.c: |
| BYT: |
| static const char *isp2400_release_version = STR(irci_stable_candrpv_0415_20150521_0458); |
| |
| CHT: |
| static const char *isp2401_release_version = STR(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 isp2401: |
| |
| irci_stable_candrpv_0415_20150521_0458 |
| |
| 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. |
| |
| 8. Switch to V4L2 async API to set up sensor, lens and flash devices. |
| Control those devices using V4L2 sub-device API without custom |
| extensions. |
| |
| 9. 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. |
| |
| 10. Use LED flash API for flash LED drivers such as LM3554 (which already |
| has a LED class driver). |
| |
| 11. Switch from videobuf1 to videobuf2. Videobuf1 is being removed! |
| |
| 12. There are some memory management code that seems to be |
| forked from Kernel 3.10 inside hmm/ directory. Get rid of it, |
| making the driver to use a more standard memory management module. |
| |
| 13. 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. |
| |
| 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 libary the capture behaviour is not very good. To take a good |
| picture, you need tune ISP parameters by IOCTL functions or use a 3A libary |
| 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. |
| |
| 4. The driver supports only v2 of the IPU/Camera. It will not work with the |
| versions of the hardware in other SoCs. |
| |