diff options
author | Mauro Carvalho Chehab <mchehab+huawei@kernel.org> | 2020-05-22 15:01:00 +0300 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab+huawei@kernel.org> | 2020-06-11 18:59:40 +0300 |
commit | 2a693c3e186c6651ce8980c777a5ba87179c93a7 (patch) | |
tree | 6715176d63acd81f37e1d23e3ffd2ad0a3125a17 /drivers/staging/media/atomisp/TODO | |
parent | 9c30f50d14c8779465bc8eb5e2b68fd840ca77f4 (diff) | |
download | linux-2a693c3e186c6651ce8980c777a5ba87179c93a7.tar.xz |
media: atomisp: update TODO list
Let's reflect the current status at the TODO list, as other
developers can help addressing issues over there.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Diffstat (limited to 'drivers/staging/media/atomisp/TODO')
-rw-r--r-- | drivers/staging/media/atomisp/TODO | 191 |
1 files changed, 145 insertions, 46 deletions
diff --git a/drivers/staging/media/atomisp/TODO b/drivers/staging/media/atomisp/TODO index 52683a704223..9456ffbfe4aa 100644 --- a/drivers/staging/media/atomisp/TODO +++ b/drivers/staging/media/atomisp/TODO @@ -1,71 +1,168 @@ -1. A single AtomISP driver needs to be implemented to support both - Baytrail (BYT and Cherrytail (CHT) platforms at the same time. +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. + Such IOCTL interface needs more documentation. The better would + be to use something close to the interface used by the IPU3 IMGU driver. -5. The AtomISP driver includes some special IOCTLS (ATOMISP_IOC_XXXX_XXXX) - and controls that require some cleanup. +11. The ISP code has some dependencies of the exact FW version. + The version defined in pci/sh_css_firmware.c: -6. Correct Coding Style. Please don't send coding style patches for this - driver until the other work is done. + BYT (isp2400): "irci_stable_candrpv_0415_20150521_0458" -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 (isp2401): "irci_ecr - master_20150911_0724" - 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 CHT: - 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" - irci_stable_candrpv_0415_20150521_0458 + Which can be obtainable from Yocto Atom ISP respository. - 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. + but this was not thoroughly tested. -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. + 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. -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. +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. -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 +181,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. - |