Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | /*************************************************************************** |
| 2 | * API for image sensors connected to the SN9C10x PC Camera Controllers * |
| 3 | * * |
| 4 | * Copyright (C) 2004-2005 by Luca Risolia <luca.risolia@studio.unibo.it> * |
| 5 | * * |
| 6 | * This program is free software; you can redistribute it and/or modify * |
| 7 | * it under the terms of the GNU General Public License as published by * |
| 8 | * the Free Software Foundation; either version 2 of the License, or * |
| 9 | * (at your option) any later version. * |
| 10 | * * |
| 11 | * This program is distributed in the hope that it will be useful, * |
| 12 | * but WITHOUT ANY WARRANTY; without even the implied warranty of * |
| 13 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * |
| 14 | * GNU General Public License for more details. * |
| 15 | * * |
| 16 | * You should have received a copy of the GNU General Public License * |
| 17 | * along with this program; if not, write to the Free Software * |
| 18 | * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * |
| 19 | ***************************************************************************/ |
| 20 | |
| 21 | #ifndef _SN9C102_SENSOR_H_ |
| 22 | #define _SN9C102_SENSOR_H_ |
| 23 | |
| 24 | #include <linux/usb.h> |
| 25 | #include <linux/videodev.h> |
| 26 | #include <linux/device.h> |
| 27 | #include <linux/stddef.h> |
| 28 | #include <linux/errno.h> |
| 29 | #include <asm/types.h> |
| 30 | |
| 31 | struct sn9c102_device; |
| 32 | struct sn9c102_sensor; |
| 33 | |
| 34 | /*****************************************************************************/ |
| 35 | |
| 36 | /* |
| 37 | OVERVIEW. |
| 38 | This is a small interface that allows you to add support for any CCD/CMOS |
| 39 | image sensors connected to the SN9C10X bridges. The entire API is documented |
| 40 | below. In the most general case, to support a sensor there are three steps |
| 41 | you have to follow: |
| 42 | 1) define the main "sn9c102_sensor" structure by setting the basic fields; |
| 43 | 2) write a probing function to be called by the core module when the USB |
| 44 | camera is recognized, then add both the USB ids and the name of that |
| 45 | function to the two corresponding tables SENSOR_TABLE and ID_TABLE (see |
| 46 | below); |
| 47 | 3) implement the methods that you want/need (and fill the rest of the main |
| 48 | structure accordingly). |
| 49 | "sn9c102_pas106b.c" is an example of all this stuff. Remember that you do |
| 50 | NOT need to touch the source code of the core module for the things to work |
| 51 | properly, unless you find bugs or flaws in it. Finally, do not forget to |
| 52 | read the V4L2 API for completeness. |
| 53 | */ |
| 54 | |
| 55 | /*****************************************************************************/ |
| 56 | |
| 57 | /* |
| 58 | Probing functions: on success, you must attach the sensor to the camera |
| 59 | by calling sn9c102_attach_sensor() provided below. |
| 60 | To enable the I2C communication, you might need to perform a really basic |
| 61 | initialization of the SN9C10X chip by using the write function declared |
| 62 | ahead. |
| 63 | Functions must return 0 on success, the appropriate error otherwise. |
| 64 | */ |
| 65 | extern int sn9c102_probe_hv7131d(struct sn9c102_device* cam); |
| 66 | extern int sn9c102_probe_mi0343(struct sn9c102_device* cam); |
Luca Risolia | b9df978 | 2005-06-25 16:30:24 +0200 | [diff] [blame] | 67 | extern int sn9c102_probe_ov7630(struct sn9c102_device* cam); |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 68 | extern int sn9c102_probe_pas106b(struct sn9c102_device* cam); |
| 69 | extern int sn9c102_probe_pas202bcb(struct sn9c102_device* cam); |
| 70 | extern int sn9c102_probe_tas5110c1b(struct sn9c102_device* cam); |
| 71 | extern int sn9c102_probe_tas5130d1b(struct sn9c102_device* cam); |
| 72 | |
| 73 | /* |
| 74 | Add the above entries to this table. Be sure to add the entry in the right |
| 75 | place, since, on failure, the next probing routine is called according to |
| 76 | the order of the list below, from top to bottom. |
| 77 | */ |
| 78 | #define SN9C102_SENSOR_TABLE \ |
| 79 | static int (*sn9c102_sensor_table[])(struct sn9c102_device*) = { \ |
| 80 | &sn9c102_probe_mi0343, /* strong detection based on SENSOR ids */ \ |
| 81 | &sn9c102_probe_pas106b, /* strong detection based on SENSOR ids */ \ |
| 82 | &sn9c102_probe_pas202bcb, /* strong detection based on SENSOR ids */ \ |
| 83 | &sn9c102_probe_hv7131d, /* strong detection based on SENSOR ids */ \ |
Luca Risolia | b9df978 | 2005-06-25 16:30:24 +0200 | [diff] [blame] | 84 | &sn9c102_probe_ov7630, /* detection mostly based on USB pid/vid */ \ |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 85 | &sn9c102_probe_tas5110c1b, /* detection based on USB pid/vid */ \ |
| 86 | &sn9c102_probe_tas5130d1b, /* detection based on USB pid/vid */ \ |
| 87 | NULL, \ |
| 88 | }; |
| 89 | |
| 90 | /* Attach a probed sensor to the camera. */ |
| 91 | extern void |
| 92 | sn9c102_attach_sensor(struct sn9c102_device* cam, |
| 93 | struct sn9c102_sensor* sensor); |
| 94 | |
| 95 | /* Each SN9C10X camera has proper PID/VID identifiers. Add them here in case.*/ |
| 96 | #define SN9C102_ID_TABLE \ |
| 97 | static const struct usb_device_id sn9c102_id_table[] = { \ |
| 98 | { USB_DEVICE(0x0c45, 0x6001), }, /* TAS5110C1B */ \ |
| 99 | { USB_DEVICE(0x0c45, 0x6005), }, /* TAS5110C1B */ \ |
| 100 | { USB_DEVICE(0x0c45, 0x6009), }, /* PAS106B */ \ |
| 101 | { USB_DEVICE(0x0c45, 0x600d), }, /* PAS106B */ \ |
| 102 | { USB_DEVICE(0x0c45, 0x6024), }, \ |
| 103 | { USB_DEVICE(0x0c45, 0x6025), }, /* TAS5130D1B and TAS5110C1B */ \ |
| 104 | { USB_DEVICE(0x0c45, 0x6028), }, /* PAS202BCB */ \ |
| 105 | { USB_DEVICE(0x0c45, 0x6029), }, /* PAS106B */ \ |
| 106 | { USB_DEVICE(0x0c45, 0x602a), }, /* HV7131D */ \ |
| 107 | { USB_DEVICE(0x0c45, 0x602b), }, /* MI-0343 */ \ |
Luca Risolia | b9df978 | 2005-06-25 16:30:24 +0200 | [diff] [blame] | 108 | { USB_DEVICE(0x0c45, 0x602c), }, /* OV7630 */ \ |
| 109 | { USB_DEVICE(0x0c45, 0x602d), }, \ |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 110 | { USB_DEVICE(0x0c45, 0x6030), }, /* MI03x */ \ |
| 111 | { USB_DEVICE(0x0c45, 0x6080), }, \ |
| 112 | { USB_DEVICE(0x0c45, 0x6082), }, /* MI0343 and MI0360 */ \ |
| 113 | { USB_DEVICE(0x0c45, 0x6083), }, /* HV7131[D|E1] */ \ |
| 114 | { USB_DEVICE(0x0c45, 0x6088), }, \ |
| 115 | { USB_DEVICE(0x0c45, 0x608a), }, \ |
| 116 | { USB_DEVICE(0x0c45, 0x608b), }, \ |
| 117 | { USB_DEVICE(0x0c45, 0x608c), }, /* HV7131x */ \ |
| 118 | { USB_DEVICE(0x0c45, 0x608e), }, /* CIS-VF10 */ \ |
| 119 | { USB_DEVICE(0x0c45, 0x608f), }, /* OV7630 */ \ |
| 120 | { USB_DEVICE(0x0c45, 0x60a0), }, \ |
| 121 | { USB_DEVICE(0x0c45, 0x60a2), }, \ |
| 122 | { USB_DEVICE(0x0c45, 0x60a3), }, \ |
| 123 | { USB_DEVICE(0x0c45, 0x60a8), }, /* PAS106B */ \ |
| 124 | { USB_DEVICE(0x0c45, 0x60aa), }, /* TAS5130D1B */ \ |
| 125 | { USB_DEVICE(0x0c45, 0x60ab), }, /* TAS5110C1B */ \ |
| 126 | { USB_DEVICE(0x0c45, 0x60ac), }, \ |
| 127 | { USB_DEVICE(0x0c45, 0x60ae), }, \ |
| 128 | { USB_DEVICE(0x0c45, 0x60af), }, /* PAS202BCB */ \ |
| 129 | { USB_DEVICE(0x0c45, 0x60b0), }, \ |
| 130 | { USB_DEVICE(0x0c45, 0x60b2), }, \ |
| 131 | { USB_DEVICE(0x0c45, 0x60b3), }, \ |
| 132 | { USB_DEVICE(0x0c45, 0x60b8), }, \ |
| 133 | { USB_DEVICE(0x0c45, 0x60ba), }, \ |
| 134 | { USB_DEVICE(0x0c45, 0x60bb), }, \ |
| 135 | { USB_DEVICE(0x0c45, 0x60bc), }, \ |
| 136 | { USB_DEVICE(0x0c45, 0x60be), }, \ |
| 137 | { } \ |
| 138 | }; |
| 139 | |
| 140 | /*****************************************************************************/ |
| 141 | |
| 142 | /* |
| 143 | Read/write routines: they always return -1 on error, 0 or the read value |
| 144 | otherwise. NOTE that a real read operation is not supported by the SN9C10X |
| 145 | chip for some of its registers. To work around this problem, a pseudo-read |
| 146 | call is provided instead: it returns the last successfully written value |
| 147 | on the register (0 if it has never been written), the usual -1 on error. |
| 148 | */ |
| 149 | |
| 150 | /* The "try" I2C I/O versions are used when probing the sensor */ |
Luca Risolia | b9df978 | 2005-06-25 16:30:24 +0200 | [diff] [blame] | 151 | extern int sn9c102_i2c_try_write(struct sn9c102_device*,struct sn9c102_sensor*, |
| 152 | u8 address, u8 value); |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 153 | extern int sn9c102_i2c_try_read(struct sn9c102_device*,struct sn9c102_sensor*, |
| 154 | u8 address); |
| 155 | |
| 156 | /* |
| 157 | These must be used if and only if the sensor doesn't implement the standard |
| 158 | I2C protocol. There are a number of good reasons why you must use the |
| 159 | single-byte versions of these functions: do not abuse. The first function |
| 160 | writes n bytes, from data0 to datan, to registers 0x09 - 0x09+n of SN9C10X |
| 161 | chip. The second one programs the registers 0x09 and 0x10 with data0 and |
| 162 | data1, and places the n bytes read from the sensor register table in the |
| 163 | buffer pointed by 'buffer'. Both the functions return -1 on error; the write |
| 164 | version returns 0 on success, while the read version returns the first read |
| 165 | byte. |
| 166 | */ |
| 167 | extern int sn9c102_i2c_try_raw_write(struct sn9c102_device* cam, |
| 168 | struct sn9c102_sensor* sensor, u8 n, |
| 169 | u8 data0, u8 data1, u8 data2, u8 data3, |
| 170 | u8 data4, u8 data5); |
| 171 | extern int sn9c102_i2c_try_raw_read(struct sn9c102_device* cam, |
| 172 | struct sn9c102_sensor* sensor, u8 data0, |
| 173 | u8 data1, u8 n, u8 buffer[]); |
| 174 | |
| 175 | /* To be used after the sensor struct has been attached to the camera struct */ |
| 176 | extern int sn9c102_i2c_write(struct sn9c102_device*, u8 address, u8 value); |
| 177 | extern int sn9c102_i2c_read(struct sn9c102_device*, u8 address); |
| 178 | |
| 179 | /* I/O on registers in the bridge. Could be used by the sensor methods too */ |
| 180 | extern int sn9c102_write_reg(struct sn9c102_device*, u8 value, u16 index); |
| 181 | extern int sn9c102_pread_reg(struct sn9c102_device*, u16 index); |
| 182 | |
| 183 | /* |
| 184 | NOTE: there are no exported debugging functions. To uniform the output you |
| 185 | must use the dev_info()/dev_warn()/dev_err() macros defined in device.h, |
| 186 | already included here, the argument being the struct device 'dev' of the |
| 187 | sensor structure. Do NOT use these macros before the sensor is attached or |
| 188 | the kernel will crash! However, you should not need to notify the user about |
| 189 | common errors or other messages, since this is done by the master module. |
| 190 | */ |
| 191 | |
| 192 | /*****************************************************************************/ |
| 193 | |
| 194 | enum sn9c102_i2c_sysfs_ops { |
| 195 | SN9C102_I2C_READ = 0x01, |
| 196 | SN9C102_I2C_WRITE = 0x02, |
| 197 | }; |
| 198 | |
| 199 | enum sn9c102_i2c_frequency { /* sensors may support both the frequencies */ |
| 200 | SN9C102_I2C_100KHZ = 0x01, |
| 201 | SN9C102_I2C_400KHZ = 0x02, |
| 202 | }; |
| 203 | |
| 204 | enum sn9c102_i2c_interface { |
| 205 | SN9C102_I2C_2WIRES, |
| 206 | SN9C102_I2C_3WIRES, |
| 207 | }; |
| 208 | |
Luca Risolia | b9df978 | 2005-06-25 16:30:24 +0200 | [diff] [blame] | 209 | #define SN9C102_MAX_CTRLS V4L2_CID_LASTP1-V4L2_CID_BASE+10 |
| 210 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 211 | struct sn9c102_sensor { |
| 212 | char name[32], /* sensor name */ |
| 213 | maintainer[64]; /* name of the mantainer <email> */ |
| 214 | |
| 215 | /* Supported operations through the 'sysfs' interface */ |
| 216 | enum sn9c102_i2c_sysfs_ops sysfs_ops; |
| 217 | |
| 218 | /* |
| 219 | These sensor capabilities must be provided if the SN9C10X controller |
| 220 | needs to communicate through the sensor serial interface by using |
| 221 | at least one of the i2c functions available. |
| 222 | */ |
| 223 | enum sn9c102_i2c_frequency frequency; |
| 224 | enum sn9c102_i2c_interface interface; |
| 225 | |
| 226 | /* |
| 227 | This identifier must be provided if the image sensor implements |
| 228 | the standard I2C protocol. |
| 229 | */ |
| 230 | u8 i2c_slave_id; /* reg. 0x09 */ |
| 231 | |
| 232 | /* |
| 233 | NOTE: Where not noted,most of the functions below are not mandatory. |
| 234 | Set to null if you do not implement them. If implemented, |
| 235 | they must return 0 on success, the proper error otherwise. |
| 236 | */ |
| 237 | |
| 238 | int (*init)(struct sn9c102_device* cam); |
| 239 | /* |
| 240 | This function will be called after the sensor has been attached. |
| 241 | It should be used to initialize the sensor only, but may also |
| 242 | configure part of the SN9C10X chip if necessary. You don't need to |
| 243 | setup picture settings like brightness, contrast, etc.. here, if |
| 244 | the corrisponding controls are implemented (see below), since |
| 245 | they are adjusted in the core driver by calling the set_ctrl() |
| 246 | method after init(), where the arguments are the default values |
| 247 | specified in the v4l2_queryctrl list of supported controls; |
| 248 | Same suggestions apply for other settings, _if_ the corresponding |
| 249 | methods are present; if not, the initialization must configure the |
| 250 | sensor according to the default configuration structures below. |
| 251 | */ |
| 252 | |
Luca Risolia | b9df978 | 2005-06-25 16:30:24 +0200 | [diff] [blame] | 253 | struct v4l2_queryctrl qctrl[SN9C102_MAX_CTRLS]; |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 254 | /* |
| 255 | Optional list of default controls, defined as indicated in the |
| 256 | V4L2 API. Menu type controls are not handled by this interface. |
| 257 | */ |
| 258 | |
| 259 | int (*get_ctrl)(struct sn9c102_device* cam, struct v4l2_control* ctrl); |
| 260 | int (*set_ctrl)(struct sn9c102_device* cam, |
| 261 | const struct v4l2_control* ctrl); |
| 262 | /* |
| 263 | You must implement at least the set_ctrl method if you have defined |
| 264 | the list above. The returned value must follow the V4L2 |
| 265 | specifications for the VIDIOC_G|C_CTRL ioctls. V4L2_CID_H|VCENTER |
| 266 | are not supported by this driver, so do not implement them. Also, |
| 267 | you don't have to check whether the passed values are out of bounds, |
| 268 | given that this is done by the core module. |
| 269 | */ |
| 270 | |
| 271 | struct v4l2_cropcap cropcap; |
| 272 | /* |
| 273 | Think the image sensor as a grid of R,G,B monochromatic pixels |
| 274 | disposed according to a particular Bayer pattern, which describes |
| 275 | the complete array of pixels, from (0,0) to (xmax, ymax). We will |
| 276 | use this coordinate system from now on. It is assumed the sensor |
| 277 | chip can be programmed to capture/transmit a subsection of that |
| 278 | array of pixels: we will call this subsection "active window". |
| 279 | It is not always true that the largest achievable active window can |
| 280 | cover the whole array of pixels. The V4L2 API defines another |
| 281 | area called "source rectangle", which, in turn, is a subrectangle of |
| 282 | the active window. The SN9C10X chip is always programmed to read the |
| 283 | source rectangle. |
| 284 | The bounds of both the active window and the source rectangle are |
| 285 | specified in the cropcap substructures 'bounds' and 'defrect'. |
| 286 | By default, the source rectangle should cover the largest possible |
| 287 | area. Again, it is not always true that the largest source rectangle |
| 288 | can cover the entire active window, although it is a rare case for |
| 289 | the hardware we have. The bounds of the source rectangle _must_ be |
| 290 | multiple of 16 and must use the same coordinate system as indicated |
| 291 | before; their centers shall align initially. |
| 292 | If necessary, the sensor chip must be initialized during init() to |
| 293 | set the bounds of the active sensor window; however, by default, it |
| 294 | usually covers the largest achievable area (maxwidth x maxheight) |
| 295 | of pixels, so no particular initialization is needed, if you have |
| 296 | defined the correct default bounds in the structures. |
| 297 | See the V4L2 API for further details. |
| 298 | NOTE: once you have defined the bounds of the active window |
| 299 | (struct cropcap.bounds) you must not change them.anymore. |
| 300 | Only 'bounds' and 'defrect' fields are mandatory, other fields |
| 301 | will be ignored. |
| 302 | */ |
| 303 | |
| 304 | int (*set_crop)(struct sn9c102_device* cam, |
| 305 | const struct v4l2_rect* rect); |
| 306 | /* |
| 307 | To be called on VIDIOC_C_SETCROP. The core module always calls a |
| 308 | default routine which configures the appropriate SN9C10X regs (also |
| 309 | scaling), but you may need to override/adjust specific stuff. |
| 310 | 'rect' contains width and height values that are multiple of 16: in |
| 311 | case you override the default function, you always have to program |
| 312 | the chip to match those values; on error return the corresponding |
| 313 | error code without rolling back. |
| 314 | NOTE: in case, you must program the SN9C10X chip to get rid of |
| 315 | blank pixels or blank lines at the _start_ of each line or |
| 316 | frame after each HSYNC or VSYNC, so that the image starts with |
| 317 | real RGB data (see regs 0x12, 0x13) (having set H_SIZE and, |
| 318 | V_SIZE you don't have to care about blank pixels or blank |
| 319 | lines at the end of each line or frame). |
| 320 | */ |
| 321 | |
| 322 | struct v4l2_pix_format pix_format; |
| 323 | /* |
| 324 | What you have to define here are: 1) initial 'width' and 'height' of |
| 325 | the target rectangle 2) the initial 'pixelformat', which can be |
| 326 | either V4L2_PIX_FMT_SN9C10X (for compressed video) or |
| 327 | V4L2_PIX_FMT_SBGGR8 3) 'priv', which we'll be used to indicate the |
| 328 | number of bits per pixel for uncompressed video, 8 or 9 (despite the |
| 329 | current value of 'pixelformat'). |
| 330 | NOTE 1: both 'width' and 'height' _must_ be either 1/1 or 1/2 or 1/4 |
| 331 | of cropcap.defrect.width and cropcap.defrect.height. I |
| 332 | suggest 1/1. |
| 333 | NOTE 2: The initial compression quality is defined by the first bit |
| 334 | of reg 0x17 during the initialization of the image sensor. |
| 335 | NOTE 3: as said above, you have to program the SN9C10X chip to get |
| 336 | rid of any blank pixels, so that the output of the sensor |
| 337 | matches the RGB bayer sequence (i.e. BGBGBG...GRGRGR). |
| 338 | */ |
| 339 | |
| 340 | int (*set_pix_format)(struct sn9c102_device* cam, |
| 341 | const struct v4l2_pix_format* pix); |
| 342 | /* |
| 343 | To be called on VIDIOC_S_FMT, when switching from the SBGGR8 to |
| 344 | SN9C10X pixel format or viceversa. On error return the corresponding |
| 345 | error code without rolling back. |
| 346 | */ |
| 347 | |
| 348 | const struct device* dev; |
| 349 | /* |
| 350 | This is the argument for dev_err(), dev_info() and dev_warn(). It |
| 351 | is used for debugging purposes. You must not access the struct |
| 352 | before the sensor is attached. |
| 353 | */ |
| 354 | |
| 355 | const struct usb_device* usbdev; |
| 356 | /* |
| 357 | Points to the usb_device struct after the sensor is attached. |
| 358 | Do not touch unless you know what you are doing. |
| 359 | */ |
| 360 | |
| 361 | /* |
| 362 | Do NOT write to the data below, it's READ ONLY. It is used by the |
| 363 | core module to store successfully updated values of the above |
| 364 | settings, for rollbacks..etc..in case of errors during atomic I/O |
| 365 | */ |
Luca Risolia | b9df978 | 2005-06-25 16:30:24 +0200 | [diff] [blame] | 366 | struct v4l2_queryctrl _qctrl[SN9C102_MAX_CTRLS]; |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 367 | struct v4l2_rect _rect; |
| 368 | }; |
| 369 | |
| 370 | /*****************************************************************************/ |
| 371 | |
| 372 | /* Private ioctl's for control settings supported by some image sensors */ |
| 373 | #define SN9C102_V4L2_CID_DAC_MAGNITUDE V4L2_CID_PRIVATE_BASE |
| 374 | #define SN9C102_V4L2_CID_GREEN_BALANCE V4L2_CID_PRIVATE_BASE + 1 |
| 375 | #define SN9C102_V4L2_CID_RESET_LEVEL V4L2_CID_PRIVATE_BASE + 2 |
| 376 | #define SN9C102_V4L2_CID_PIXEL_BIAS_VOLTAGE V4L2_CID_PRIVATE_BASE + 3 |
Luca Risolia | b9df978 | 2005-06-25 16:30:24 +0200 | [diff] [blame] | 377 | #define SN9C102_V4L2_CID_GAMMA V4L2_CID_PRIVATE_BASE + 4 |
| 378 | #define SN9C102_V4L2_CID_BAND_FILTER V4L2_CID_PRIVATE_BASE + 5 |
| 379 | #define SN9C102_V4L2_CID_BRIGHT_LEVEL V4L2_CID_PRIVATE_BASE + 6 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 380 | |
| 381 | #endif /* _SN9C102_SENSOR_H_ */ |