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>

drivers/staging/media/atomisp/TODO

-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.
-
-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.
+11. 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);
+    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 isp2401:
+    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.
 
-		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.
 
-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
+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!
-
-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.
+14. Switch from videobuf1 to videobuf2. Videobuf1 is being removed!
 
-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.
+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:
+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.
-