[media] sn9c102: prepare for removal by moving it to staging

During the last media summit meeting it was decided to move this driver to
staging as the first step to removing it altogether.

Most webcams covered by this driver are now supported by gspca. Nobody has the
hardware to convert the remaining devices to gspca.

This driver needs a major overhaul to have it conform to the latest frameworks
and compliancy tests.

Without hardware, however, this is next to impossible. Given the fact that
this driver seems to be pretty much unused (it has been removed from Fedora
several versions ago and nobody complained about that), we decided to drop
this driver.

This patch moves it to staging. Some time in 2014 we will drop it completely.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>

1 files changed, 0 insertions, 307 deletions

diff --git a/drivers/media/usb/sn9c102/sn9c102_sensor.h b/drivers/media/usb/sn9c102/sn9c102_sensor.h
deleted file mode 100644
index 3679970dba2c..000000000000
--- a/drivers/media/usb/sn9c102/sn9c102_sensor.h
+++ /dev/null
@@ -1,307 +0,0 @@
-/***************************************************************************
- * API for image sensors connected to the SN9C1xx PC Camera Controllers    *
- *                                                                         *
- * Copyright (C) 2004-2007 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/videodev2.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 SN9C1XX 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 in sn9c102_devtable.h;
-   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.
-*/
-
-/*****************************************************************************/
-
-enum sn9c102_bridge {
-	BRIDGE_SN9C101 = 0x01,
-	BRIDGE_SN9C102 = 0x02,
-	BRIDGE_SN9C103 = 0x04,
-	BRIDGE_SN9C105 = 0x08,
-	BRIDGE_SN9C120 = 0x10,
-};
-
-/* Return the bridge name */
-enum sn9c102_bridge sn9c102_get_bridge(struct sn9c102_device* cam);
-
-/* Return a pointer the sensor struct attached to the camera */
-struct sn9c102_sensor* sn9c102_get_sensor(struct sn9c102_device* cam);
-
-/* Identify a device */
-extern struct sn9c102_device*
-sn9c102_match_id(struct sn9c102_device* cam, const struct usb_device_id *id);
-
-/* Attach a probed sensor to the camera. */
-extern void
-sn9c102_attach_sensor(struct sn9c102_device* cam,
-		      const struct sn9c102_sensor* sensor);
-
-/*
-   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 SN9C1XX
-   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_read(struct sn9c102_device*,
-				const 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 SN9C1XX
-   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,
-				     const 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,
-				    const 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_read_reg(struct sn9c102_device*, u16 index);
-extern int sn9c102_pread_reg(struct sn9c102_device*, u16 index);
-extern int sn9c102_write_reg(struct sn9c102_device*, u8 value, u16 index);
-extern int sn9c102_write_regs(struct sn9c102_device*, const u8 valreg[][2],
-			      int count);
-/*
-   Write multiple registers with constant values. For example:
-   sn9c102_write_const_regs(cam, {0x00, 0x14}, {0x60, 0x17}, {0x0f, 0x18});
-   Register addresses must be < 256.
-*/
-#define sn9c102_write_const_regs(sn9c102_device, data...)                     \
-	({ static const u8 _valreg[][2] = {data};                             \
-	sn9c102_write_regs(sn9c102_device, _valreg, ARRAY_SIZE(_valreg)); })
-
-/*****************************************************************************/
-
-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 maintainer <email> */
-
-	enum sn9c102_bridge supported_bridge; /* supported SN9C1xx bridges */
-
-	/* Supported operations through the 'sysfs' interface */
-	enum sn9c102_i2c_sysfs_ops sysfs_ops;
-
-	/*
-	   These sensor capabilities must be provided if the SN9C1XX 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 SN9C1XX chip if necessary. You don't need to
-	   setup picture settings like brightness, contrast, etc.. here, if
-	   the corresponding 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 SN9C1XX 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 SN9C1XX 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 SN9C1XX 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, V4L2_PIX_FMT_JPEG (for ompressed 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 SN9C1XX 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.
-	*/
-
-	/*
-	   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 + 0)
-#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_ */