Let's reflect the current status at the TODO list, as other
developers can help addressing issues over there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx>
---
drivers/staging/media/atomisp/TODO | 188 ++++++++++++++++++++++-------
1 file changed, 142 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/media/atomisp/TODO b/drivers/staging/media/atomisp/TODO
index 52683a704223..f297840eea90 100644
--- a/drivers/staging/media/atomisp/TODO
+++ b/drivers/staging/media/atomisp/TODO
@@ -1,71 +1,165 @@
-1. A single AtomISP driver needs to be implemented to support both
+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. Support for newer board-specific data (like Asus T101HA support) uses a
+ DMI match table to retrieve sensor's data, using hard-coded values.
+ It sounds feasible to retrieve those data directly from ACPI via _DSM
+ tables (like this one, associated with CAM1 at the above mentioned
+ hardware):
+
+ Name (C1CD, Buffer (0x0220){})
+ Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
+ {
+ If ((Arg0 == ToUUID ("dc2f6c4f-045b-4f1d-97b9-882a6860a4be")))
+ {
+ Local0 = Package (0x12)
+ {
+ "CamId",
+ "ov2680",
+ "CamType",
+ "1",
+ "CsiPort",
+ "0",
+ "CsiLanes",
+ "1",
+ "CsiFmt",
+ "15",
+ "CsiBayer",
+ "0",
+ "CamClk",
+ "1",
+ "Regulator1p8v",
+ "0",
+ "Regulator2p8v",
+ "0"
+ }
+ Return (Local0)
+ }
+
+ The code there at atomisp_gmin_platform has an EFI parser, but it
+ assumes that the information would be stored on a different way.
+
+ As the Kernel has support for reading data from _DSM, via
+ acpi_evaluate_dsm(), it sounds doable to use such infra and remove the
+ DMI match, at least for some devices. This will likely allow covering
+ more devices that could also be using the same EFI UUID.
+
+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.
-2. The file structure needs to get tidied up to resemble a normal Linux
+8. 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.
+9. 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.
+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
-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.
+11. The ISP code has some dependencies of the exact FW version.
+ The version defined in pci/sh_css_firmware.c:
-5. The AtomISP driver includes some special IOCTLS (ATOMISP_IOC_XXXX_XXXX)
- and controls that require some cleanup.
+ BYT (isp2400): "irci_stable_candrpv_0415_20150521_0458"
-6. Correct Coding Style. Please don't send coding style patches for this
- driver until the other work is done.
+ CHT (isp2401): "irci_ecr - master_20150911_0724"
-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);
+ 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:
- CHT:
- static const char *isp2401_release_version = STR(irci_ecr - master_20150911_0724);
+ "irci_stable_candrpv_0415_20150521_0458"
- 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:
+ Which can be obtainable from Yocto Atom ISP respository.
- irci_stable_candrpv_0415_20150521_0458
+ 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.
+ 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.
+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.
-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
+13. 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!
+14. 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.
+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.
-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:
+Limitations
+===========
1. To test the patches, you also need the ISP firmware
@@ -84,6 +178,8 @@ Limitations:
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.
-
--
2.26.2
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
