Lines Matching +full:camera +full:- +full:sensor

1 The Soc-Camera Drivers
7 -----------
10  - camera / camera device / camera sensor - a video-camera sensor chip, capable
13  - camera host - an interface, to which a camera is connected. Typically a
16  - camera host bus - a connection between a camera host and a camera. Can be
20 Purpose of the soc-camera subsystem
21 -----------------------------------
23 The soc-camera subsystem initially provided a unified API between camera host
24 drivers and camera sensor drivers. Later the soc-camera sensor API has been
25 replaced with the V4L2 standard subdev API. This also made camera driver re-use
26 with non-soc-camera hosts possible. The camera host API to the soc-camera core
29 Soc-camera implements a V4L2 interface to the user, currently only the "mmap"
30 method is supported by host drivers. However, the soc-camera core also provides
33 The subsystem has been designed to support multiple camera host interfaces and
34 multiple cameras per interface, although most applications have only one camera
35 sensor.
38 ----------------
40 As of 3.7 there are seven host drivers in the mainline: atmel-isi.c,
42 omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor
45 Camera host API
46 ---------------
48 A host camera driver is registered using the
50 .. code-block:: none
56 .. code-block:: none
59 	ici->drv_name		= DRV_NAME;
60 	ici->ops		= &camera_host_ops;
61 	ici->priv		= pcdev;
62 	ici->v4l2_dev.dev	= &pdev->dev;
63 	ici->nr			= pdev->id;
65 All camera host methods are passed in a struct soc_camera_host_ops:
67 .. code-block:: none
82 .add and .remove methods are called when a sensor is attached to or detached
84 parameters between the host and the sensor. .init_videobuf2 is called by
85 soc-camera core when a video-device is opened, the host driver would typically
86 call vb2_queue_init() in this method. Further video-buffer management is
87 implemented completely by the specific camera host driver. If the host driver
88 supports non-standard pixel format conversion, it should implement a
93 Camera API
94 ----------
96 Sensor drivers can use struct soc_camera_link, typically provided by the
97 platform, and used to specify to which camera host bus the sensor is connected,
98 and optionally provide platform .power and .reset methods for the camera. This
99 struct is provided to the camera driver via the I2C client device platform data
103 running on an soc-camera host. The actual camera driver operation is implemented
104 using the V4L2 subdev API. Additionally soc-camera camera drivers can use
105 auxiliary soc-camera helper functions like soc_camera_power_on() and
107 board-specific power switching methods. soc_camera_apply_board_flags() takes
108 camera bus configuration capability flags and applies any board transformations,
110 pixel format descriptor, corresponding to a certain media-bus pixel format code.
112 side, based on camera capabilities.
115 ----------------------------------------
119 VIDIOC_S_CROP: sets location and sizes of the sensor window. Unit is one sensor
120 pixel. Changing sensor window sizes preserves any scaling factors, therefore
123 VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as
124 much as possible by modifying scaling factors. If the sensor window cannot be
127 In soc-camera there are two locations, where scaling and cropping can take
128 place: in the camera driver and in the host driver. User ioctls are first passed
129 to the host driver, which then generally passes them down to the camera driver.
130 It is more efficient to perform scaling and cropping in the camera driver to
131 save camera bus bandwidth and maximise the framerate. However, if the camera
136 Camera drivers are interfaced to the soc-camera core and to host drivers over
137 the v4l2-subdev API, which is completely functional, it doesn't pass any data.
138 Therefore all camera drivers shall reply to .g_fmt() requests with their current
139 output geometry. This is necessary to correctly configure the camera bus.
140 .s_fmt() and .try_fmt() have to be implemented too. Sensor window and scaling
141 factors have to be maintained by camera drivers internally. According to the
143 rely on camera drivers implementing .cropcap(). If the camera driver does not
145 cropping support by the camera host driver at least the .g_crop method must be
149 soc_camera_device and used by the soc-camera core and host drivers. The core
155 -----------------
158 they are transferred over a media bus. Soc-camera provides support to
160 maintained by soc-camera core, which describes, what FOURCC pixel format will
161 be obtained, if a media-bus pixel format is stored in memory according to
163 sample and stored in memory in the little-endian order with no gaps between
165 standard transformations will be used by soc-camera or by camera host drivers to
166 configure camera drivers to produce the FOURCC format, requested by the user,