148 lines
5.4 KiB
Plaintext
148 lines
5.4 KiB
Plaintext
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. Use ACPI _DSM table - DONE!
|
|
|
|
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.
|
|
|
|
8. The file structure needs to get tidied up to resemble a normal Linux
|
|
driver.
|
|
|
|
9. Lots of the midlayer glue. unused code and abstraction needs removing.
|
|
|
|
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
|
|
|
|
Such IOCTL interface needs more documentation. The better would
|
|
be to use something close to the interface used by the IPU3 IMGU driver.
|
|
|
|
11. The ISP code has some dependencies of the exact FW version.
|
|
The version defined in pci/sh_css_firmware.c:
|
|
|
|
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 CHT:
|
|
|
|
"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.
|
|
|
|
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.
|
|
|
|
13. Use LED flash API for flash LED drivers such as LM3554 (which already
|
|
has a LED class driver).
|
|
|
|
14. Switch from videobuf1 to videobuf2. Videobuf1 is being removed!
|
|
|
|
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
|
|
===========
|
|
|
|
1. To test the patches, you also need the ISP firmware
|
|
|
|
for BYT: /lib/firmware/shisp_2400b0_v21.bin
|
|
for CHT: /lib/firmware/shisp_2401a0_v21.bin
|
|
|
|
The firmware files will usually be found in /etc/firmware on an Android
|
|
device but can also be extracted from the upgrade kit if you've managed
|
|
to lose them somehow.
|
|
|
|
2. Without a 3A library the capture behaviour is not very good. To take a good
|
|
picture, you need tune ISP parameters by IOCTL functions or use a 3A library
|
|
such as libxcam.
|
|
|
|
3. The driver is intended to drive the PCI exposed versions of the device.
|
|
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.
|