Lines Matching refs:the

14 This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
19 The driver has been successfully used on the following versions of OMAP 3:
26 Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
33 The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP
34 having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
46 Each possible link in the ISP is modelled by a link in the Media controller
50 Controlling the OMAP 3 ISP
53 In general, the settings given to the OMAP 3 ISP take effect at the beginning
54 of the following frame. This is done when the module becomes idle during the
55 vertical blanking period on the sensor. In memory-to-memory operation the pipe
56 is run one frame at a time. Applying the settings is done between the frames.
58 All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver,
59 insist on receiving complete frames. Sensors must thus never send the ISP
62 Autoidle does have issues with some ISP blocks on the 3430, at least.
63 Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle
70 The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and
76 triggered exactly when the reception of the first line of the frame starts
77 in the CCDC module. The event can be subscribed on the CCDC subdev.
80 of the VS signal polarity. This is automatically correct when using the serial
83 Each of the statistics subdevs is able to produce events. An event is
85 application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available
92 The type of the event data is struct omap3isp_stat_event_status for these
93 ioctls. If there is an error calculating the statistics, there will be an
102 possible and practical. Much of the functions provided by the ISP, however,
103 does not fall under the standard IOCTLs --- gamma tables and configuration of
106 In general, there is a private ioctl for configuring each of the blocks
120 include/linux/omap3isp.h. The detailed functions of the ISP itself related to
121 a given ISP block is described in the Technical Reference Manuals (TRMs) ---
122 see the end of the document for those.
124 While it is possible to use the ISP driver without any use of these private
126 AF and histogram modules cannot be used without configuring them using the
134 configure, enable and disable functions in the CCDC and preview blocks,
135 respectively. Both IOCTLs control several functions in the blocks they
141 The update field in the structures tells whether to update the configuration
142 for the specific function and the flag tells whether to enable or disable the
145 The update and flag bit masks accept the following values. Each separate
146 functions in the CCDC and preview blocks is associated with a flag (either
147 disable or enable; part of the flag field in the structure) and a pointer to
148 configuration data for the function.
150 Valid values for the update and flag fields are listed here for
152 function in the same IOCTL call.
163 The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here:
183 The associated configuration pointer for the function may not be NULL when
184 enabling the function. When disabling a function the configuration pointer is
191 The statistics subdevs do offer more dynamic configuration options than the
192 other subdevs. They can be enabled, disable and reconfigured when the pipeline
195 The statistics blocks always get the input image data from the CCDC (as the
197 the user from the statistics subdev nodes using private IOCTLs.
199 The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily
200 reflected by the register level interface offered by the ISP hardware. There
201 are aspects that are purely related to the driver implementation and these are
208 done before streaming, it will take effect as soon as the pipeline starts to
209 stream.  If the pipeline is already streaming, it will take effect as soon as
210 the CCDC becomes idle.
215 Those IOCTLs are used to configure the modules. They require user applications
216 to have an in-depth knowledge of the hardware. Most of the fields explanation
217 can be found on OMAP's TRMs. The two following fields common to all the above
219 are not part of the TRM.
223 The modules handle their buffers internally. The necessary buffer size for the
224 module's data output depends on the requested configuration. Although the
227 internally allocated if the module is enabled. It will return -EBUSY on this
228 case. In order to avoid such condition, either disable/reconfigure/enable the
229 module or request the necessary buffer size during the first configuration
230 while the module is disabled.
232 The internal buffer size allocation considers the requested configuration's
233 minimum buffer size and the value set on buf_size field. If buf_size field is
235 The driver then selects the biggest value. The corrected buf_size value is
240 As the configuration doesn't take effect synchronously to the request, the
242 data. After a configuration is requested, the config_counter returned to user
251 Send to user space the oldest data available in the internal buffer queue and
253 matches with the video buffer's field_count.