This commit was generated by cvs2svn to compensate for changes in r517,
[linux-2.6.git] / drivers / usb / media / sn9c102_sensor.h
1 /***************************************************************************
2  * API for image sensors connected to the SN9C10x PC Camera Controllers    *
3  *                                                                         *
4  * Copyright (C) 2004 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_pas106b(struct sn9c102_device* cam);
66 extern int sn9c102_probe_pas202bcb(struct sn9c102_device* cam);
67 extern int sn9c102_probe_tas5110c1b(struct sn9c102_device* cam);
68 extern int sn9c102_probe_tas5130d1b(struct sn9c102_device* cam);
69
70 /*
71    Add the above entries to this table. Be sure to add the entry in the right
72    place, since, on failure, the next probing routine is called according to 
73    the order of the list below, from top to bottom.
74 */
75 #define SN9C102_SENSOR_TABLE                                                  \
76 static int (*sn9c102_sensor_table[])(struct sn9c102_device*) = {              \
77         &sn9c102_probe_pas106b, /* strong detection based on SENSOR ids */    \
78         &sn9c102_probe_pas202bcb, /* strong detection based on SENSOR ids */  \
79         &sn9c102_probe_tas5110c1b, /* detection based on USB pid/vid */       \
80         &sn9c102_probe_tas5130d1b, /* detection based on USB pid/vid */       \
81         NULL,                                                                 \
82 };
83
84 /* Attach a probed sensor to the camera. */
85 extern void 
86 sn9c102_attach_sensor(struct sn9c102_device* cam,
87                       struct sn9c102_sensor* sensor);
88
89 /* Each SN9C10X camera has proper PID/VID identifiers. Add them here in case.*/
90 #define SN9C102_ID_TABLE                                                      \
91 static const struct usb_device_id sn9c102_id_table[] = {                      \
92         { USB_DEVICE(0x0c45, 0x6001), }, /* TAS5110C1B */                     \
93         { USB_DEVICE(0x0c45, 0x6005), }, /* TAS5110C1B */                     \
94         { USB_DEVICE(0x0c45, 0x6009), }, /* PAS106B */                        \
95         { USB_DEVICE(0x0c45, 0x600d), }, /* PAS106B */                        \
96         { USB_DEVICE(0x0c45, 0x6024), },                                      \
97         { USB_DEVICE(0x0c45, 0x6025), }, /* TAS5130D1B and TAS5110C1B */      \
98         { USB_DEVICE(0x0c45, 0x6028), }, /* PAS202BCB */                      \
99         { USB_DEVICE(0x0c45, 0x6029), }, /* PAS106B */                        \
100         { USB_DEVICE(0x0c45, 0x602a), }, /* HV7131[D|E1] */                   \
101         { USB_DEVICE(0x0c45, 0x602b), }, /* MI-0343 */                        \
102         { USB_DEVICE(0x0c45, 0x602c), }, /* OV7620 */                         \
103         { USB_DEVICE(0x0c45, 0x6030), }, /* MI03x */                          \
104         { USB_DEVICE(0x0c45, 0x6080), },                                      \
105         { USB_DEVICE(0x0c45, 0x6082), }, /* MI0343 and MI0360 */              \
106         { USB_DEVICE(0x0c45, 0x6083), }, /* HV7131[D|E1] */                   \
107         { USB_DEVICE(0x0c45, 0x6088), },                                      \
108         { USB_DEVICE(0x0c45, 0x608a), },                                      \
109         { USB_DEVICE(0x0c45, 0x608b), },                                      \
110         { USB_DEVICE(0x0c45, 0x608c), }, /* HV7131x */                        \
111         { USB_DEVICE(0x0c45, 0x608e), }, /* CIS-VF10 */                       \
112         { USB_DEVICE(0x0c45, 0x608f), }, /* OV7630 */                         \
113         { USB_DEVICE(0x0c45, 0x60a0), },                                      \
114         { USB_DEVICE(0x0c45, 0x60a2), },                                      \
115         { USB_DEVICE(0x0c45, 0x60a3), },                                      \
116         { USB_DEVICE(0x0c45, 0x60a8), }, /* PAS106B */                        \
117         { USB_DEVICE(0x0c45, 0x60aa), }, /* TAS5130D1B */                     \
118         { USB_DEVICE(0x0c45, 0x60ab), }, /* TAS5110C1B */                     \
119         { USB_DEVICE(0x0c45, 0x60ac), },                                      \
120         { USB_DEVICE(0x0c45, 0x60ae), },                                      \
121         { USB_DEVICE(0x0c45, 0x60af), }, /* PAS202BCB */                      \
122         { USB_DEVICE(0x0c45, 0x60b0), },                                      \
123         { USB_DEVICE(0x0c45, 0x60b2), },                                      \
124         { USB_DEVICE(0x0c45, 0x60b3), },                                      \
125         { USB_DEVICE(0x0c45, 0x60b8), },                                      \
126         { USB_DEVICE(0x0c45, 0x60ba), },                                      \
127         { USB_DEVICE(0x0c45, 0x60bb), },                                      \
128         { USB_DEVICE(0x0c45, 0x60bc), },                                      \
129         { USB_DEVICE(0x0c45, 0x60be), },                                      \
130         { }                                                                   \
131 };
132
133 /*****************************************************************************/
134
135 /*
136    Read/write routines: they always return -1 on error, 0 or the read value
137    otherwise. NOTE that a real read operation is not supported by the SN9C10X
138    chip for some of its registers. To work around this problem, a pseudo-read
139    call is provided instead: it returns the last successfully written value 
140    on the register (0 if it has never been written), the usual -1 on error.
141 */
142
143 /* The "try" I2C I/O versions are used when probing the sensor */
144 extern int sn9c102_i2c_try_write(struct sn9c102_device*,struct sn9c102_sensor*,
145                                  u8 address, u8 value);
146 extern int sn9c102_i2c_try_read(struct sn9c102_device*,struct sn9c102_sensor*,
147                                 u8 address);
148
149 /*
150    This must be used if and only if the sensor doesn't implement the standard
151    I2C protocol. There a number of good reasons why you must use the 
152    single-byte versions of this function: do not abuse. It writes n bytes, 
153    from data0 to datan, (registers 0x09 - 0x09+n of SN9C10X chip).
154 */
155 extern int sn9c102_i2c_try_raw_write(struct sn9c102_device* cam,
156                                      struct sn9c102_sensor* sensor, u8 n, 
157                                      u8 data0, u8 data1, u8 data2, u8 data3,
158                                      u8 data4, u8 data5);
159
160 /* To be used after the sensor struct has been attached to the camera struct */
161 extern int sn9c102_i2c_write(struct sn9c102_device*, u8 address, u8 value);
162 extern int sn9c102_i2c_read(struct sn9c102_device*, u8 address);
163
164 /* I/O on registers in the bridge. Could be used by the sensor methods too */
165 extern int sn9c102_write_reg(struct sn9c102_device*, u8 value, u16 index);
166 extern int sn9c102_pread_reg(struct sn9c102_device*, u16 index);
167
168 /*
169    NOTE: there are no debugging functions here. To uniform the output you must
170    use the dev_info()/dev_warn()/dev_err() macros defined in device.h, already
171    included here, the argument being the struct device 'dev' of the sensor
172    structure. Do NOT use these macros before the sensor is attached or the
173    kernel will crash! However you should not need to notify the user about
174    common errors or other messages, since this is done by the master module.
175 */
176
177 /*****************************************************************************/
178
179 enum sn9c102_i2c_frequency { /* sensors may support both the frequencies */
180         SN9C102_I2C_100KHZ = 0x01,
181         SN9C102_I2C_400KHZ = 0x02,
182 };
183
184 enum sn9c102_i2c_interface {
185         SN9C102_I2C_2WIRES,
186         SN9C102_I2C_3WIRES,
187 };
188
189 #define SN9C102_I2C_SLAVEID_FICTITIOUS 0xff
190 #define SN9C102_I2C_SLAVEID_UNAVAILABLE 0x00
191
192 struct sn9c102_sensor {
193         char name[32], /* sensor name */
194              maintainer[64]; /* name of the mantainer <email> */
195
196         /*
197            These sensor capabilities must be provided if the SN9C10X controller
198            needs to communicate through the sensor serial interface by using
199            at least one of the i2c functions available.
200         */
201         enum sn9c102_i2c_frequency frequency;
202         enum sn9c102_i2c_interface interface;
203
204         /*
205            These identifiers must be provided if the image sensor implements
206            the standard I2C protocol.
207         */
208         u8 slave_read_id, slave_write_id; /* reg. 0x09 */
209
210         /*
211            NOTE: Where not noted,most of the functions below are not mandatory.
212                  Set to null if you do not implement them. If implemented,
213                  they must return 0 on success, the proper error otherwise.
214         */
215
216         int (*init)(struct sn9c102_device* cam);
217         /*
218            This function is called after the sensor has been attached. 
219            It should be used to initialize the sensor only, but may also
220            configure part of the SN9C10X chip if necessary. You don't need to
221            setup picture settings like brightness, contrast, etc.. here, if
222            the corrisponding controls are implemented (see below), since 
223            they are adjusted in the core driver by calling the set_ctrl()
224            method after init(), where the arguments are the default values
225            specified in the v4l2_queryctrl list of supported controls;
226            Same suggestions apply for other settings, _if_ the corresponding
227            methods are present; if not, the initialization must configure the
228            sensor according to the default configuration structures below.
229         */
230
231         struct v4l2_queryctrl qctrl[V4L2_CID_LASTP1-V4L2_CID_BASE];
232         /*
233            Optional list of default controls, defined as indicated in the 
234            V4L2 API. Menu type controls are not handled by this interface.
235         */
236
237         int (*get_ctrl)(struct sn9c102_device* cam, struct v4l2_control* ctrl);
238         int (*set_ctrl)(struct sn9c102_device* cam,
239                         const struct v4l2_control* ctrl);
240         /*
241            You must implement at least the set_ctrl method if you have defined
242            the list above. The returned value must follow the V4L2
243            specifications for the VIDIOC_G|C_CTRL ioctls. V4L2_CID_H|VCENTER
244            are not supported by this driver, so do not implement them. Also,
245            you don't have to check whether the passed values are out of bounds,
246            given that this is done by the core module.
247         */
248
249         struct v4l2_cropcap cropcap;
250         /*
251            Think the image sensor as a grid of R,G,B monochromatic pixels
252            disposed according to a particular Bayer pattern, which describes
253            the complete array of pixels, from (0,0) to (xmax, ymax). We will
254            use this coordinate system from now on. It is assumed the sensor
255            chip can be programmed to capture/transmit a subsection of that
256            array of pixels: we will call this subsection "active window".
257            It is not always true that the largest achievable active window can
258            cover the whole array of pixels. The V4L2 API defines another
259            area called "source rectangle", which, in turn, is a subrectangle of
260            the active window. The SN9C10X chip is always programmed to read the
261            source rectangle.
262            The bounds of both the active window and the source rectangle are
263            specified in the cropcap substructures 'bounds' and 'defrect'.
264            By default, the source rectangle should cover the largest possible
265            area. Again, it is not always true that the largest source rectangle
266            can cover the entire active window, although it is a rare case for 
267            the hardware we have. The bounds of the source rectangle _must_ be
268            multiple of 16 and must use the same coordinate system as indicated
269            before; their centers shall align initially.
270            If necessary, the sensor chip must be initialized during init() to
271            set the bounds of the active sensor window; however, by default, it
272            usually covers the largest achievable area (maxwidth x maxheight)
273            of pixels, so no particular initialization is needed, if you have
274            defined the correct default bounds in the structures.
275            See the V4L2 API for further details.
276            NOTE: once you have defined the bounds of the active window
277                  (struct cropcap.bounds) you must not change them.anymore.
278            Only 'bounds' and 'defrect' fields are mandatory, other fields
279            will be ignored.
280         */
281
282         int (*set_crop)(struct sn9c102_device* cam,
283                         const struct v4l2_rect* rect);
284         /*
285            To be called on VIDIOC_C_SETCROP. The core module always calls a
286            default routine which configures the appropriate SN9C10X regs (also
287            scaling), but you may need to override/adjust specific stuff.
288            'rect' contains width and height values that are multiple of 16: in
289            case you override the default function, you always have to program
290            the chip to match those values; on error return the corresponding
291            error code without rolling back.
292            NOTE: in case, you must program the SN9C10X chip to get rid of 
293                  blank pixels or blank lines at the _start_ of each line or
294                  frame after each HSYNC or VSYNC, so that the image starts with
295                  real RGB data (see regs 0x12, 0x13) (having set H_SIZE and,
296                  V_SIZE you don't have to care about blank pixels or blank
297                  lines at the end of each line or frame).
298         */
299
300         struct v4l2_pix_format pix_format;
301         /*
302            What you have to define here are: 1) initial 'width' and 'height' of
303            the target rectangle 2) the initial 'pixelformat', which can be
304            either V4L2_PIX_FMT_SN9C10X (for compressed video) or
305            V4L2_PIX_FMT_SBGGR8 3) 'priv', which we'll be used to indicate the
306            number of bits per pixel for uncompressed video, 8 or 9 (despite the
307            current value of 'pixelformat').
308            NOTE 1: both 'width' and 'height' _must_ be either 1/1 or 1/2 or 1/4
309                    of cropcap.defrect.width and cropcap.defrect.height. I
310                    suggest 1/1.
311            NOTE 2: The initial compression quality is defined by the first bit
312                    of reg 0x17 during the initialization of the image sensor.
313            NOTE 3: as said above, you have to program the SN9C10X chip to get
314                    rid of any blank pixels, so that the output of the sensor
315                    matches the RGB bayer sequence (i.e. BGBGBG...GRGRGR).
316         */
317
318         const struct device* dev;
319         /*
320            This is the argument for dev_err(), dev_info() and dev_warn(). It
321            is used for debugging purposes. You must not access the struct
322            before the sensor is attached.
323         */
324
325         const struct usb_device* usbdev;
326         /*
327            Points to the usb_device struct after the sensor is attached.
328            Do not touch unless you know what you are doing.
329         */
330
331         /*
332            Do NOT write to the data below, it's READ ONLY. It is used by the
333            core module to store successfully updated values of the above
334            settings, for rollbacks..etc..in case of errors during atomic I/O
335         */
336         struct v4l2_queryctrl _qctrl[V4L2_CID_LASTP1-V4L2_CID_BASE];
337         struct v4l2_rect _rect;
338 };
339
340 /*****************************************************************************/
341
342 /* Private ioctl's for control settings supported by some image sensors */
343 #define SN9C102_V4L2_CID_DAC_MAGNITUDE V4L2_CID_PRIVATE_BASE
344 #define SN9C102_V4L2_CID_DAC_SIGN V4L2_CID_PRIVATE_BASE + 1
345 #define SN9C102_V4L2_CID_GREEN_BALANCE V4L2_CID_PRIVATE_BASE + 2
346
347 #endif /* _SN9C102_SENSOR_H_ */