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