blob: d3cf6ed547ae0308fe88e8d10d5f858131c35b7c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
Some notes about the working of the atomisp drivers (learned while working
on cleaning it up).
The atomisp seems to be a generic DSP(ISP) like processor without a fixed
pipeline. It does not have its own memory, but instead uses main memory.
The ISP has its own address-space and main memory needs to be mapped into
its address space through the ISP's MMU.
Memory is allocated by the hmm code. hmm_alloc() returns an ISP virtual
address. The hmm code keeps a list of all allocations and when necessary
the hmm code finds the backing hmm-buffer-object (hmm_bo) by looking
up the hmm_bo based on the ISP virtual address.
The actual processing pipeline is made by loading one or more programs,
called binaries. The shisp_240??0_v21.bin firmware file contains many
different binaries. Binaries are picked by filling a ia_css_binary_descr
struct with various input and output parameters and then calling
ia_css_binary_find(). Some binaries support creating multiple outputs
(preview + video frame?) at the same time.
For example for the /dev/video0 preview node load_preview_binaries()
from atomisp/pci/sh_css.c is called and then loads a preview and
optionally a scalar binary. Note when digital zoom is disabled
(it is enabled by default) only the preview binary is loaded.
So in this case a single binary handles the entire pipeline.
Since getting a picture requires multiple processing steps,
this means that unlike in fixed pipelines the soft pipelines
on the ISP can do multiple processing steps in a single pipeline
element (in a single binary).
###
The sensor drivers use of v4l2_get_subdev_hostdata(), which returns
a camera_mipi_info struct. This struct is allocated/managed by
the core atomisp code. The most important parts of the struct
are filled by the atomisp core itself, like e.g. the port number.
The sensor drivers on a set_fmt call do fill in camera_mipi_info.data
which is a atomisp_sensor_mode_data struct. This gets filled from
a function called <sensor_name>_get_intg_factor(). This struct is not
used by the atomisp code at all. It is returned to userspace by
a ATOMISP_IOC_G_SENSOR_MODE_DATA and the Android userspace does use this.
Other members of camera_mipi_info which are set by some drivers are:
-metadata_width, metadata_height, metadata_effective_width, set by
the ov5693 driver (and used by the atomisp core)
-raw_bayer_order, adjusted by the ov2680 driver when flipping since
flipping can change the bayer order
|
