[deliverable/linux.git] / drivers / usb / media / sn9c102_sensor.h

/***************************************************************************
 * API for image sensors connected to the SN9C10x PC Camera Controllers    *
 *                                                                         *
 * Copyright (C) 2004-2006 by Luca Risolia <luca.risolia@studio.unibo.it>  *
 *                                                                         *
 * This program is free software; you can redistribute it and/or modify    *
 * it under the terms of the GNU General Public License as published by    *
 * the Free Software Foundation; either version 2 of the License, or       *
 * (at your option) any later version.                                     *
 *                                                                         *
 * This program is distributed in the hope that it will be useful,         *
 * but WITHOUT ANY WARRANTY; without even the implied warranty of          *
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the           *
 * GNU General Public License for more details.                            *
 *                                                                         *
 * You should have received a copy of the GNU General Public License       *
 * along with this program; if not, write to the Free Software             *
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.               *
 ***************************************************************************/

#ifndef _SN9C102_SENSOR_H_
#define _SN9C102_SENSOR_H_

#include <linux/usb.h>
#include <linux/videodev.h>
#include <linux/device.h>
#include <linux/stddef.h>
#include <linux/errno.h>
#include <asm/types.h>

struct sn9c102_device;
struct sn9c102_sensor;

/*****************************************************************************/

/*
   OVERVIEW.
   This is a small interface that allows you to add support for any CCD/CMOS
   image sensors connected to the SN9C10X bridges. The entire API is documented
   below. In the most general case, to support a sensor there are three steps
   you have to follow:
   1) define the main "sn9c102_sensor" structure by setting the basic fields;
   2) write a probing function to be called by the core module when the USB
      camera is recognized, then add both the USB ids and the name of that
      function to the two corresponding tables SENSOR_TABLE and ID_TABLE (see
      below);
   3) implement the methods that you want/need (and fill the rest of the main
      structure accordingly).
   "sn9c102_pas106b.c" is an example of all this stuff. Remember that you do
   NOT need to touch the source code of the core module for the things to work
   properly, unless you find bugs or flaws in it. Finally, do not forget to
   read the V4L2 API for completeness.
*/

/*****************************************************************************/

/*
   Probing functions: on success, you must attach the sensor to the camera
   by calling sn9c102_attach_sensor() provided below.
   To enable the I2C communication, you might need to perform a really basic
   initialization of the SN9C10X chip by using the write function declared 
   ahead.
   Functions must return 0 on success, the appropriate error otherwise.
*/
extern int sn9c102_probe_hv7131d(struct sn9c102_device* cam);
extern int sn9c102_probe_mi0343(struct sn9c102_device* cam);
extern int sn9c102_probe_ov7630(struct sn9c102_device* cam);
extern int sn9c102_probe_pas106b(struct sn9c102_device* cam);
extern int sn9c102_probe_pas202bcb(struct sn9c102_device* cam);
extern int sn9c102_probe_tas5110c1b(struct sn9c102_device* cam);
extern int sn9c102_probe_tas5130d1b(struct sn9c102_device* cam);

/*
   Add the above entries to this table. Be sure to add the entry in the right
   place, since, on failure, the next probing routine is called according to 
   the order of the list below, from top to bottom.
*/
#define SN9C102_SENSOR_TABLE                                                  \
static int (*sn9c102_sensor_table[])(struct sn9c102_device*) = {              \
	&sn9c102_probe_mi0343, /* strong detection based on SENSOR ids */     \
	&sn9c102_probe_pas106b, /* strong detection based on SENSOR ids */    \
	&sn9c102_probe_pas202bcb, /* strong detection based on SENSOR ids */  \
	&sn9c102_probe_hv7131d, /* strong detection based on SENSOR ids */    \
	&sn9c102_probe_ov7630, /* detection mostly based on USB pid/vid */    \
	&sn9c102_probe_tas5110c1b, /* detection based on USB pid/vid */       \
	&sn9c102_probe_tas5130d1b, /* detection based on USB pid/vid */       \
	NULL,                                                                 \
};

/* Attach a probed sensor to the camera. */
extern void 
sn9c102_attach_sensor(struct sn9c102_device* cam,
                      struct sn9c102_sensor* sensor);

/*
   Each SN9C10x camera has proper PID/VID identifiers.
   SN9C103 supports multiple interfaces, but we only handle the video class
   interface.
*/
#define SN9C102_USB_DEVICE(vend, prod, intclass)                              \
	.match_flags = USB_DEVICE_ID_MATCH_DEVICE |                           \
	               USB_DEVICE_ID_MATCH_INT_CLASS,                         \
	.idVendor = (vend),                                                   \
	.idProduct = (prod),                                                  \
	.bInterfaceClass = (intclass)

#define SN9C102_ID_TABLE                                                      \
static const struct usb_device_id sn9c102_id_table[] = {                      \
	{ USB_DEVICE(0x0c45, 0x6001), }, /* TAS5110C1B */                     \
	{ USB_DEVICE(0x0c45, 0x6005), }, /* TAS5110C1B */                     \
	{ USB_DEVICE(0x0c45, 0x6009), }, /* PAS106B */                        \
	{ USB_DEVICE(0x0c45, 0x600d), }, /* PAS106B */                        \
	{ USB_DEVICE(0x0c45, 0x6024), },                                      \
	{ USB_DEVICE(0x0c45, 0x6025), }, /* TAS5130D1B and TAS5110C1B */      \
	{ USB_DEVICE(0x0c45, 0x6028), }, /* PAS202BCB */                      \
	{ USB_DEVICE(0x0c45, 0x6029), }, /* PAS106B */                        \
	{ USB_DEVICE(0x0c45, 0x602a), }, /* HV7131D */                        \
	{ USB_DEVICE(0x0c45, 0x602b), }, /* MI-0343 */                        \
	{ USB_DEVICE(0x0c45, 0x602c), }, /* OV7630 */                         \
	{ USB_DEVICE(0x0c45, 0x602d), },                                      \
	{ USB_DEVICE(0x0c45, 0x602e), }, /* OV7630 */                         \
	{ USB_DEVICE(0x0c45, 0x6030), }, /* MI03x */                          \
	{ SN9C102_USB_DEVICE(0x0c45, 0x6080, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x6082, 0xff), }, /* MI0343 & MI0360 */  \
	{ SN9C102_USB_DEVICE(0x0c45, 0x6083, 0xff), }, /* HV7131[D|E1] */     \
	{ SN9C102_USB_DEVICE(0x0c45, 0x6088, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x608a, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x608b, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x608c, 0xff), }, /* HV7131x */          \
	{ SN9C102_USB_DEVICE(0x0c45, 0x608e, 0xff), }, /* CIS-VF10 */         \
	{ SN9C102_USB_DEVICE(0x0c45, 0x608f, 0xff), }, /* OV7630 */           \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60a0, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60a2, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60a3, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60a8, 0xff), }, /* PAS106B */          \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60aa, 0xff), }, /* TAS5130D1B */       \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60ab, 0xff), }, /* TAS5110C1B */       \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60ac, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60ae, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60af, 0xff), }, /* PAS202BCB */        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60b0, 0xff), }, /* OV7630 (?) */       \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60b2, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60b3, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60b8, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60ba, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60bb, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60bc, 0xff), },                        \
	{ SN9C102_USB_DEVICE(0x0c45, 0x60be, 0xff), },                        \
	{ }                                                                   \
};

/*****************************************************************************/

/*
   Read/write routines: they always return -1 on error, 0 or the read value
   otherwise. NOTE that a real read operation is not supported by the SN9C10X
   chip for some of its registers. To work around this problem, a pseudo-read
   call is provided instead: it returns the last successfully written value 
   on the register (0 if it has never been written), the usual -1 on error.
*/

/* The "try" I2C I/O versions are used when probing the sensor */
extern int sn9c102_i2c_try_write(struct sn9c102_device*,struct sn9c102_sensor*,
                                 u8 address, u8 value);
extern int sn9c102_i2c_try_read(struct sn9c102_device*,struct sn9c102_sensor*,
                                u8 address);

/*
   These must be used if and only if the sensor doesn't implement the standard
   I2C protocol. There are a number of good reasons why you must use the 
   single-byte versions of these functions: do not abuse. The first function
   writes n bytes, from data0 to datan, to registers 0x09 - 0x09+n of SN9C10X
   chip. The second one programs the registers 0x09 and 0x10 with data0 and
   data1, and places the n bytes read from the sensor register table in the
   buffer pointed by 'buffer'. Both the functions return -1 on error; the write
   version returns 0 on success, while the read version returns the first read
   byte.
*/
extern int sn9c102_i2c_try_raw_write(struct sn9c102_device* cam,
                                     struct sn9c102_sensor* sensor, u8 n, 
                                     u8 data0, u8 data1, u8 data2, u8 data3,
                                     u8 data4, u8 data5);
extern int sn9c102_i2c_try_raw_read(struct sn9c102_device* cam,
                                    struct sn9c102_sensor* sensor, u8 data0,
                                    u8 data1, u8 n, u8 buffer[]);

/* To be used after the sensor struct has been attached to the camera struct */
extern int sn9c102_i2c_write(struct sn9c102_device*, u8 address, u8 value);
extern int sn9c102_i2c_read(struct sn9c102_device*, u8 address);

/* I/O on registers in the bridge. Could be used by the sensor methods too */
extern int sn9c102_write_regs(struct sn9c102_device*, u8* buff, u16 index);
extern int sn9c102_write_reg(struct sn9c102_device*, u8 value, u16 index);
extern int sn9c102_pread_reg(struct sn9c102_device*, u16 index);

/*
   NOTE: there are no exported debugging functions. To uniform the output you
   must use the dev_info()/dev_warn()/dev_err() macros defined in device.h,
   already included here, the argument being the struct device '&usbdev->dev'
   of the sensor structure. Do NOT use these macros before the sensor is
   attached or the kernel will crash! However, you should not need to notify
   the user about common errors or other messages, since this is done by the
   master module.
*/

/*****************************************************************************/

enum sn9c102_i2c_sysfs_ops {
	SN9C102_I2C_READ = 0x01,
	SN9C102_I2C_WRITE = 0x02,
};

enum sn9c102_i2c_frequency { /* sensors may support both the frequencies */
	SN9C102_I2C_100KHZ = 0x01,
	SN9C102_I2C_400KHZ = 0x02,
};

enum sn9c102_i2c_interface {
	SN9C102_I2C_2WIRES,
	SN9C102_I2C_3WIRES,
};

#define SN9C102_MAX_CTRLS V4L2_CID_LASTP1-V4L2_CID_BASE+10

struct sn9c102_sensor {
	char name[32], /* sensor name */
	     maintainer[64]; /* name of the mantainer <email> */

	/* Supported operations through the 'sysfs' interface */
	enum sn9c102_i2c_sysfs_ops sysfs_ops;

	/*
	   These sensor capabilities must be provided if the SN9C10X controller
	   needs to communicate through the sensor serial interface by using
	   at least one of the i2c functions available.
	*/
	enum sn9c102_i2c_frequency frequency;
	enum sn9c102_i2c_interface interface;

	/*
	   This identifier must be provided if the image sensor implements
	   the standard I2C protocol.
	*/
	u8 i2c_slave_id; /* reg. 0x09 */

	/*
	   NOTE: Where not noted,most of the functions below are not mandatory.
	         Set to null if you do not implement them. If implemented,
	         they must return 0 on success, the proper error otherwise.
	*/

	int (*init)(struct sn9c102_device* cam);
	/*
	   This function will be called after the sensor has been attached. 
	   It should be used to initialize the sensor only, but may also
	   configure part of the SN9C10X chip if necessary. You don't need to
	   setup picture settings like brightness, contrast, etc.. here, if
	   the corrisponding controls are implemented (see below), since 
	   they are adjusted in the core driver by calling the set_ctrl()
	   method after init(), where the arguments are the default values
	   specified in the v4l2_queryctrl list of supported controls;
	   Same suggestions apply for other settings, _if_ the corresponding
	   methods are present; if not, the initialization must configure the
	   sensor according to the default configuration structures below.
	*/

	struct v4l2_queryctrl qctrl[SN9C102_MAX_CTRLS];
	/*
	   Optional list of default controls, defined as indicated in the 
	   V4L2 API. Menu type controls are not handled by this interface.
	*/

	int (*get_ctrl)(struct sn9c102_device* cam, struct v4l2_control* ctrl);
	int (*set_ctrl)(struct sn9c102_device* cam,
	                const struct v4l2_control* ctrl);
	/*
	   You must implement at least the set_ctrl method if you have defined
	   the list above. The returned value must follow the V4L2
	   specifications for the VIDIOC_G|C_CTRL ioctls. V4L2_CID_H|VCENTER
	   are not supported by this driver, so do not implement them. Also,
	   you don't have to check whether the passed values are out of bounds,
	   given that this is done by the core module.
	*/

	struct v4l2_cropcap cropcap;
	/*
	   Think the image sensor as a grid of R,G,B monochromatic pixels
	   disposed according to a particular Bayer pattern, which describes
	   the complete array of pixels, from (0,0) to (xmax, ymax). We will
	   use this coordinate system from now on. It is assumed the sensor
	   chip can be programmed to capture/transmit a subsection of that
	   array of pixels: we will call this subsection "active window".
	   It is not always true that the largest achievable active window can
	   cover the whole array of pixels. The V4L2 API defines another
	   area called "source rectangle", which, in turn, is a subrectangle of
	   the active window. The SN9C10X chip is always programmed to read the
	   source rectangle.
	   The bounds of both the active window and the source rectangle are
	   specified in the cropcap substructures 'bounds' and 'defrect'.
	   By default, the source rectangle should cover the largest possible
	   area. Again, it is not always true that the largest source rectangle
	   can cover the entire active window, although it is a rare case for 
	   the hardware we have. The bounds of the source rectangle _must_ be
	   multiple of 16 and must use the same coordinate system as indicated
	   before; their centers shall align initially.
	   If necessary, the sensor chip must be initialized during init() to
	   set the bounds of the active sensor window; however, by default, it
	   usually covers the largest achievable area (maxwidth x maxheight)
	   of pixels, so no particular initialization is needed, if you have
	   defined the correct default bounds in the structures.
	   See the V4L2 API for further details.
	   NOTE: once you have defined the bounds of the active window
	         (struct cropcap.bounds) you must not change them.anymore.
	   Only 'bounds' and 'defrect' fields are mandatory, other fields
	   will be ignored.
	*/

	int (*set_crop)(struct sn9c102_device* cam,
	                const struct v4l2_rect* rect);
	/*
	   To be called on VIDIOC_C_SETCROP. The core module always calls a
	   default routine which configures the appropriate SN9C10X regs (also
	   scaling), but you may need to override/adjust specific stuff.
	   'rect' contains width and height values that are multiple of 16: in
	   case you override the default function, you always have to program
	   the chip to match those values; on error return the corresponding
	   error code without rolling back.
	   NOTE: in case, you must program the SN9C10X chip to get rid of 
	         blank pixels or blank lines at the _start_ of each line or
	         frame after each HSYNC or VSYNC, so that the image starts with
	         real RGB data (see regs 0x12, 0x13) (having set H_SIZE and,
	         V_SIZE you don't have to care about blank pixels or blank
	         lines at the end of each line or frame).
	*/

	struct v4l2_pix_format pix_format;
	/*
	   What you have to define here are: 1) initial 'width' and 'height' of
	   the target rectangle 2) the initial 'pixelformat', which can be
	   either V4L2_PIX_FMT_SN9C10X (for compressed video) or
	   V4L2_PIX_FMT_SBGGR8 3) 'priv', which we'll be used to indicate the
	   number of bits per pixel for uncompressed video, 8 or 9 (despite the
	   current value of 'pixelformat').
	   NOTE 1: both 'width' and 'height' _must_ be either 1/1 or 1/2 or 1/4
	           of cropcap.defrect.width and cropcap.defrect.height. I
	           suggest 1/1.
	   NOTE 2: The initial compression quality is defined by the first bit
	           of reg 0x17 during the initialization of the image sensor.
	   NOTE 3: as said above, you have to program the SN9C10X chip to get
	           rid of any blank pixels, so that the output of the sensor
	           matches the RGB bayer sequence (i.e. BGBGBG...GRGRGR).
	*/

	int (*set_pix_format)(struct sn9c102_device* cam,
	                      const struct v4l2_pix_format* pix);
	/*
	   To be called on VIDIOC_S_FMT, when switching from the SBGGR8 to
	   SN9C10X pixel format or viceversa. On error return the corresponding
	   error code without rolling back.
	*/

	const struct usb_device* usbdev;
	/*
	   Points to the usb_device struct after the sensor is attached.
	   Do not touch unless you know what you are doing.
	*/

	/*
	   Do NOT write to the data below, it's READ ONLY. It is used by the
	   core module to store successfully updated values of the above
	   settings, for rollbacks..etc..in case of errors during atomic I/O
	*/
	struct v4l2_queryctrl _qctrl[SN9C102_MAX_CTRLS];
	struct v4l2_rect _rect;
};

/*****************************************************************************/

/* Private ioctl's for control settings supported by some image sensors */
#define SN9C102_V4L2_CID_DAC_MAGNITUDE V4L2_CID_PRIVATE_BASE
#define SN9C102_V4L2_CID_GREEN_BALANCE V4L2_CID_PRIVATE_BASE + 1
#define SN9C102_V4L2_CID_RESET_LEVEL V4L2_CID_PRIVATE_BASE + 2
#define SN9C102_V4L2_CID_PIXEL_BIAS_VOLTAGE V4L2_CID_PRIVATE_BASE + 3
#define SN9C102_V4L2_CID_GAMMA V4L2_CID_PRIVATE_BASE + 4
#define SN9C102_V4L2_CID_BAND_FILTER V4L2_CID_PRIVATE_BASE + 5
#define SN9C102_V4L2_CID_BRIGHT_LEVEL V4L2_CID_PRIVATE_BASE + 6

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