1- 1. A single AtomISP driver needs to be implemented to support both
2- Baytrail (BYT and Cherrytail (CHT) platforms at the same time.
1+ NOTE:
2+ =====
3+
4+ While the driver probes the hardware and reports itself as a
5+ V4L2 driver, there are still some issues preventing it to
6+ stream (at least it doesn't with the standard V4L2 applications.
7+ Didn't test yet with some custom-made app for this driver).
8+ Solving the related bugs and issues preventing it to work is
9+ needed (items 6 and 7 from the list below).
10+
11+ TODO
12+ ====
13+
14+ 1. 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+
21+ 2. Use ACPI _DSM table - DONE!
22+
23+ 3. Switch the driver to use pm_runtime stuff. Right now, it probes the
24+ existing PMIC code and sensors call it directly.
25+
26+ 4. 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+
40+ 5. 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+
66+ 6. There is some issues at the frame receive logic, causing the
67+ DQBUF ioctls to fail.
68+
69+ 7. A single AtomISP driver needs to be implemented to support both
70+ Baytrail (BYT) and Cherrytail (CHT) platforms at the same time.
371 The current driver is a mechanical and hand combined merge of the
472 two using several runtime macros, plus some ifdef ISP2401 to select the
573 CHT version. Yet, there are some ISP-specific headers that change the
674 driver's behavior during compile time.
775
8- 2 . The file structure needs to get tidied up to resemble a normal Linux
76+ 8 . The file structure needs to get tidied up to resemble a normal Linux
977 driver.
1078
11- 3 . Lots of the midlayer glue. unused code and abstraction needs removing.
79+ 9 . Lots of the midlayer glue. unused code and abstraction needs removing.
1280
13- 3. The sensor drivers read MIPI settings from EFI variables or default to the
14- settings hard-coded in the platform data file for different platforms.
15- It should be possible to improve it, by adding support for _DSM tables.
81+ 10. 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
1685
17- 4. The sensor drivers use PMIC and the regulator framework API. In the ideal
18- world it would be using ACPI but that's not how the existing devices work .
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 .
1988
20- 5 . The AtomISP driver includes some special IOCTLS (ATOMISP_IOC_XXXX_XXXX)
21- and controls that require some cleanup.
89+ 11 . The ISP code has some dependencies of the exact FW version.
90+ The version defined in pci/sh_css_firmware.c:
2291
23- 6. Correct Coding Style. Please don't send coding style patches for this
24- driver until the other work is done.
92+ BYT (isp2400): "irci_stable_candrpv_0415_20150521_0458"
2593
26- 7. The ISP code has some dependencies of the exact FW version.
27- The version defined in pci/sh_css_firmware.c:
28- BYT:
29- static const char *isp2400_release_version = STR(irci_stable_candrpv_0415_20150521_0458);
94+ CHT (isp2401): "irci_ecr - master_20150911_0724"
3095
31- CHT:
32- static const char *isp2401_release_version = STR(irci_ecr - master_20150911_0724);
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:
3398
34- Those versions don't seem to be available anymore. On the tests we've
35- done so far, this version also seems to work for isp2401:
99+ "irci_stable_candrpv_0415_20150521_0458"
36100
37- irci_stable_candrpv_0415_20150521_0458
101+ Which can be obtainable from Yocto Atom ISP respository.
38102
39- At some point we may need to round up a few driver versions and see if
40- there are any specific things that can be done to fold in support for
41- multiple firmware versions.
103+ but this was not thoroughly tested.
42104
43- 8. Switch to V4L2 async API to set up sensor, lens and flash devices.
44- Control those devices using V4L2 sub-device API without custom
45- extensions .
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 .
46108
47- 9 . Switch to standard V4L2 sub-device API for sensor and lens. In
48- particular, the user space API needs to support V4L2 controls as
49- defined in the V4L2 spec and references to atomisp must be removed from
50- these drivers.
109+ 12 . 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.
51113
52- 10 . Use LED flash API for flash LED drivers such as LM3554 (which already
114+ 13 . Use LED flash API for flash LED drivers such as LM3554 (which already
53115 has a LED class driver).
54116
55- 11. Switch from videobuf1 to videobuf2. Videobuf1 is being removed!
56-
57- 12. There are some memory management code that seems to be
58- forked from Kernel 3.10 inside hmm/ directory. Get rid of it,
59- making the driver to use a more standard memory management module.
117+ 14. Switch from videobuf1 to videobuf2. Videobuf1 is being removed!
60118
61- 13. While the driver probes the hardware and reports itself as a
62- V4L2 driver, there are still some issues preventing it to
63- stream (at least it doesn't with the standard V4L2 applications.
64- Didn't test yet with some custom-made app for this driver).
65- Solving the related bugs and issues preventing it to work is
66- needed.
119+ 15. 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.
67122
68- Limitations:
123+ Limitations
124+ ===========
69125
701261. To test the patches, you also need the ISP firmware
71127
@@ -76,14 +132,16 @@ Limitations:
76132 device but can also be extracted from the upgrade kit if you've managed
77133 to lose them somehow.
78134
79- 2. Without a 3A libary the capture behaviour is not very good. To take a good
80- picture, you need tune ISP parameters by IOCTL functions or use a 3A libary
135+ 2. 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
81137 such as libxcam.
82138
831393. The driver is intended to drive the PCI exposed versions of the device.
84140 It will not detect those devices enumerated via ACPI as a field of the
85141 i915 GPU driver.
86142
143+ There are some patches adding i915 GPU support floating at the Yocto's
144+ Aero repository (so far, untested upstream).
145+
871464. The driver supports only v2 of the IPU/Camera. It will not work with the
88147 versions of the hardware in other SoCs.
89-
0 commit comments