Blame view

Documentation/video4linux/omap3isp.txt 9.98 KB
e83dd485e   Sakari Ailus   [media] omap3isp:...
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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
  OMAP 3 Image Signal Processor (ISP) driver
  
  Copyright (C) 2010 Nokia Corporation
  Copyright (C) 2009 Texas Instruments, Inc.
  
  Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  	  Sakari Ailus <sakari.ailus@iki.fi>
  	  David Cohen <dacohen@gmail.com>
  
  
  Introduction
  ============
  
  This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
  driver located under drivers/media/video/omap3isp. The original driver was
  written by Texas Instruments but since that it has been rewritten (twice) at
  Nokia.
  
  The driver has been successfully used on the following versions of OMAP 3:
  
  	3430
  	3530
  	3630
  
  The driver implements V4L2, Media controller and v4l2_subdev interfaces.
  Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
  are supported.
  
  
  Split to subdevs
  ================
  
  The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP
  having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
  interface to userspace.
  
  	OMAP3 ISP CCP2
  	OMAP3 ISP CSI2a
  	OMAP3 ISP CCDC
  	OMAP3 ISP preview
  	OMAP3 ISP resizer
  	OMAP3 ISP AEWB
  	OMAP3 ISP AF
  	OMAP3 ISP histogram
  
  Each possible link in the ISP is modelled by a link in the Media controller
  interface. For an example program see [2].
  
  
  Controlling the OMAP 3 ISP
  ==========================
  
  In general, the settings given to the OMAP 3 ISP take effect at the beginning
  of the following frame. This is done when the module becomes idle during the
  vertical blanking period on the sensor. In memory-to-memory operation the pipe
  is run one frame at a time. Applying the settings is done between the frames.
  
  All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver,
  insist on receiving complete frames. Sensors must thus never send the ISP
  partial frames.
  
  Autoidle does have issues with some ISP blocks on the 3430, at least.
  Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle
  is non-zero.
  
  
  Events
  ======
  
  The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and
  statistics (AEWB, AF and histogram) subdevs.
  
  The CCDC subdev produces V4L2_EVENT_OMAP3ISP_HS_VS type event on HS_VS
  interrupt which is used to signal frame start. The event is triggered exactly
  when the reception of the first line of the frame starts in the CCDC module.
  The event can be subscribed on the CCDC subdev.
  
  (When using parallel interface one must pay account to correct configuration
  of the VS signal polarity. This is automatically correct when using the serial
  receivers.)
  
  Each of the statistics subdevs is able to produce events. An event is
  generated whenever a statistics buffer can be dequeued by a user space
  application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available
  are:
  
  	V4L2_EVENT_OMAP3ISP_AEWB
  	V4L2_EVENT_OMAP3ISP_AF
  	V4L2_EVENT_OMAP3ISP_HIST
  
  The type of the event data is struct omap3isp_stat_event_status for these
  ioctls. If there is an error calculating the statistics, there will be an
  event as usual, but no related statistics buffer. In this case
  omap3isp_stat_event_status.buf_err is set to non-zero.
  
  
  Private IOCTLs
  ==============
  
  The OMAP 3 ISP driver supports standard V4L2 IOCTLs and controls where
  possible and practical. Much of the functions provided by the ISP, however,
  does not fall under the standard IOCTLs --- gamma tables and configuration of
  statistics collection are examples of such.
  
  In general, there is a private ioctl for configuring each of the blocks
  containing hardware-dependent functions.
  
  The following private IOCTLs are supported:
  
  	VIDIOC_OMAP3ISP_CCDC_CFG
  	VIDIOC_OMAP3ISP_PRV_CFG
  	VIDIOC_OMAP3ISP_AEWB_CFG
  	VIDIOC_OMAP3ISP_HIST_CFG
  	VIDIOC_OMAP3ISP_AF_CFG
  	VIDIOC_OMAP3ISP_STAT_REQ
  	VIDIOC_OMAP3ISP_STAT_EN
  
  The parameter structures used by these ioctls are described in
  include/linux/omap3isp.h. The detailed functions of the ISP itself related to
  a given ISP block is described in the Technical Reference Manuals (TRMs) ---
  see the end of the document for those.
  
  While it is possible to use the ISP driver without any use of these private
  IOCTLs it is not possible to obtain optimal image quality this way. The AEWB,
  AF and histogram modules cannot be used without configuring them using the
  appropriate private IOCTLs.
  
  
  CCDC and preview block IOCTLs
  =============================
  
  The VIDIOC_OMAP3ISP_CCDC_CFG and VIDIOC_OMAP3ISP_PRV_CFG IOCTLs are used to
  configure, enable and disable functions in the CCDC and preview blocks,
  respectively. Both IOCTLs control several functions in the blocks they
  control. VIDIOC_OMAP3ISP_CCDC_CFG IOCTL accepts a pointer to struct
  omap3isp_ccdc_update_config as its argument. Similarly VIDIOC_OMAP3ISP_PRV_CFG
  accepts a pointer to struct omap3isp_prev_update_config. The definition of
  both structures is available in [1].
  
  The update field in the structures tells whether to update the configuration
  for the specific function and the flag tells whether to enable or disable the
  function.
  
  The update and flag bit masks accept the following values. Each separate
  functions in the CCDC and preview blocks is associated with a flag (either
  disable or enable; part of the flag field in the structure) and a pointer to
  configuration data for the function.
  
  Valid values for the update and flag fields are listed here for
  VIDIOC_OMAP3ISP_CCDC_CFG. Values may be or'ed to configure more than one
  function in the same IOCTL call.
  
          OMAP3ISP_CCDC_ALAW
          OMAP3ISP_CCDC_LPF
          OMAP3ISP_CCDC_BLCLAMP
          OMAP3ISP_CCDC_BCOMP
          OMAP3ISP_CCDC_FPC
          OMAP3ISP_CCDC_CULL
          OMAP3ISP_CCDC_CONFIG_LSC
          OMAP3ISP_CCDC_TBL_LSC
  
  The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here:
  
          OMAP3ISP_PREV_LUMAENH
          OMAP3ISP_PREV_INVALAW
          OMAP3ISP_PREV_HRZ_MED
          OMAP3ISP_PREV_CFA
          OMAP3ISP_PREV_CHROMA_SUPP
          OMAP3ISP_PREV_WB
          OMAP3ISP_PREV_BLKADJ
          OMAP3ISP_PREV_RGB2RGB
          OMAP3ISP_PREV_COLOR_CONV
          OMAP3ISP_PREV_YC_LIMIT
          OMAP3ISP_PREV_DEFECT_COR
          OMAP3ISP_PREV_GAMMABYPASS
          OMAP3ISP_PREV_DRK_FRM_CAPTURE
          OMAP3ISP_PREV_DRK_FRM_SUBTRACT
          OMAP3ISP_PREV_LENS_SHADING
          OMAP3ISP_PREV_NF
          OMAP3ISP_PREV_GAMMA
  
  The associated configuration pointer for the function may not be NULL when
  enabling the function. When disabling a function the configuration pointer is
  ignored.
  
  
  Statistic blocks IOCTLs
  =======================
  
  The statistics subdevs do offer more dynamic configuration options than the
  other subdevs. They can be enabled, disable and reconfigured when the pipeline
  is in streaming state.
  
  The statistics blocks always get the input image data from the CCDC (as the
  histogram memory read isn't implemented). The statistics are dequeueable by
  the user from the statistics subdev nodes using private IOCTLs.
  
  The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily
  reflected by the register level interface offered by the ISP hardware. There
  are aspects that are purely related to the driver implementation and these are
  discussed next.
  
  VIDIOC_OMAP3ISP_STAT_EN
  -----------------------
  
  This private IOCTL enables/disables a statistic module. If this request is
  done before streaming, it will take effect as soon as the pipeline starts to
  stream.  If the pipeline is already streaming, it will take effect as soon as
  the CCDC becomes idle.
  
  VIDIOC_OMAP3ISP_AEWB_CFG, VIDIOC_OMAP3ISP_HIST_CFG and VIDIOC_OMAP3ISP_AF_CFG
  -----------------------------------------------------------------------------
  
  Those IOCTLs are used to configure the modules. They require user applications
  to have an in-depth knowledge of the hardware. Most of the fields explanation
  can be found on OMAP's TRMs. The two following fields common to all the above
  configure private IOCTLs require explanation for better understanding as they
  are not part of the TRM.
  
  omap3isp_[h3a_af/h3a_aewb/hist]_config.buf_size:
  
  The modules handle their buffers internally. The necessary buffer size for the
  module's data output depends on the requested configuration. Although the
  driver supports reconfiguration while streaming, it does not support a
  reconfiguration which requires bigger buffer size than what is already
  internally allocated if the module is enabled. It will return -EBUSY on this
  case. In order to avoid such condition, either disable/reconfigure/enable the
  module or request the necessary buffer size during the first configuration
  while the module is disabled.
  
  The internal buffer size allocation considers the requested configuration's
  minimum buffer size and the value set on buf_size field. If buf_size field is
  out of [minimum, maximum] buffer size range, it's clamped to fit in there.
  The driver then selects the biggest value. The corrected buf_size value is
  written back to user application.
  
  omap3isp_[h3a_af/h3a_aewb/hist]_config.config_counter:
  
  As the configuration doesn't take effect synchronously to the request, the
  driver must provide a way to track this information to provide more accurate
  data. After a configuration is requested, the config_counter returned to user
  space application will be an unique value associated to that request. When
  user application receives an event for buffer availability or when a new
  buffer is requested, this config_counter is used to match a buffer data and a
  configuration.
  
  VIDIOC_OMAP3ISP_STAT_REQ
  ------------------------
  
  Send to user space the oldest data available in the internal buffer queue and
  discards such buffer afterwards. The field omap3isp_stat_data.frame_number
  matches with the video buffer's field_count.
  
  
  Technical reference manuals (TRMs) and other documentation
  ==========================================================
  
  OMAP 3430 TRM:
  <URL:http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM.zip>
  Referenced 2011-03-05.
  
  OMAP 35xx TRM:
  <URL:http://www.ti.com/litv/pdf/spruf98o> Referenced 2011-03-05.
  
  OMAP 3630 TRM:
  <URL:http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vQ.zip>
  Referenced 2011-03-05.
  
  DM 3730 TRM:
  <URL:http://www.ti.com/litv/pdf/sprugn4h> Referenced 2011-03-06.
  
  
  References
  ==========
  
  [1] include/linux/omap3isp.h
  
  [2] http://git.ideasonboard.org/?p=media-ctl.git;a=summary