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>
This commit is contained in:
Mauro Carvalho Chehab
parent
9c30f50d14
commit
2a693c3e18
|
|
@ -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.
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue