media: atomisp: update TODO list (2a693c3e) · Commits · github.com / kvm-riscv / linux

drivers/staging/media/atomisp/TODO

+145 −46

Original line number	Diff line number	Diff line
		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"

		irci_stable_candrpv_0415_20150521_0458
		Which can be obtainable from Yocto Atom ISP respository.

		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!
		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.