Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 2c794075 authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab
Browse files

[media] gspca/touptek: Fix a few CodingStyle issues 



Checkpatch complained about a few issues, like FSF address. Also,
multi-line comments are not following the Kernel CodingStyle.

While not too late, let's fix those issues.

Cc: John McMaster <johndmcmaster@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
parent 7cc42d9f

drivers/media/usb/gspca/touptek.c

+110 −111
Original line number Diff line number Diff line
@@ -17,10 +17,6 @@ 
 * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

 */



#include "gspca.h"
@@ -32,79 +28,79 @@ MODULE_DESCRIPTION("ToupTek UCMOS / Amscope MU microscope camera driver"); 
MODULE_LICENSE("GPL");



/*

Exposure reg is linear with exposure time

Exposure (sec), E (reg)

0.000400, 0x0002

0.001000, 0x0005

0.005000, 0x0019

0.020000, 0x0064

0.080000, 0x0190

0.400000, 0x07D0

1.000000, 0x1388

2.000000, 0x2710



Three gain stages

0x1000: master channel enable bit

0x007F: low gain bits

0x0080: medium gain bit

0x0100: high gain bit

gain = enable * (1 + regH) * (1 + regM) * z * regL



Gain implementation

Want to do something similar to mt9v011.c's set_balance



Gain does not vary with resolution (checked 640x480 vs 1600x1200)



Constant derivation:



Raw data:

Gain,   GTOP,   B,	  R,	  GBOT

1.00,   0x105C, 0x1068, 0x10C8, 0x105C

1.20,   0x106E, 0x107E, 0x10D6, 0x106E

1.40,   0x10C0, 0x10CA, 0x10E5, 0x10C0

1.60,   0x10C9, 0x10D4, 0x10F3, 0x10C9

1.80,   0x10D2, 0x10DE, 0x11C1, 0x10D2

2.00,   0x10DC, 0x10E9, 0x11C8, 0x10DC

2.20,   0x10E5, 0x10F3, 0x11CF, 0x10E5

2.40,   0x10EE, 0x10FE, 0x11D7, 0x10EE

2.60,   0x10F7, 0x11C4, 0x11DE, 0x10F7

2.80,   0x11C0, 0x11CA, 0x11E5, 0x11C0

3.00,   0x11C5, 0x11CF, 0x11ED, 0x11C5



zR = 0.0069605943152454778

	about 3/431 = 0.0069605568445475635

zB = 0.0095695970695970703

	about 6/627 = 0.0095693779904306216

zG = 0.010889328063241107

	about 6/551 = 0.010889292196007259

about 10 bits for constant + 7 bits for value => at least 17 bit intermediate

with 32 bit ints should be fine for overflow etc

Essentially gains are in range 0-0x001FF



However, V4L expects a main gain channel + R and B balance

To keep things simple for now saturate the values of balance is too high/low

This isn't really ideal but easy way to fit the Linux model



Converted using gain model turns out to be quite linear:

Gain, GTOP, B, R, GBOT

1.00, 92, 104, 144, 92

1.20, 110, 126, 172, 110

1.40, 128, 148, 202, 128

1.60, 146, 168, 230, 146

1.80, 164, 188, 260, 164

2.00, 184, 210, 288, 184

2.20, 202, 230, 316, 202

2.40, 220, 252, 348, 220

2.60, 238, 272, 376, 238

2.80, 256, 296, 404, 256

3.00, 276, 316, 436, 276



Maximum gain is 0x7FF * 2 * 2 => 0x1FFC (8188)

or about 13 effective bits of gain

The highest the commercial driver goes in my setup 436

However, because could *maybe* damage circuits

limit the gain until have a reason to go higher

Solution: gain clipped and warning emitted

 * Exposure reg is linear with exposure time

 * Exposure (sec), E (reg)

 * 0.000400, 0x0002

 * 0.001000, 0x0005

 * 0.005000, 0x0019

 * 0.020000, 0x0064

 * 0.080000, 0x0190

 * 0.400000, 0x07D0

 * 1.000000, 0x1388

 * 2.000000, 0x2710

 *

 * Three gain stages

 * 0x1000: master channel enable bit

 * 0x007F: low gain bits

 * 0x0080: medium gain bit

 * 0x0100: high gain bit

 * gain = enable * (1 + regH) * (1 + regM) * z * regL

 *

 * Gain implementation

 * Want to do something similar to mt9v011.c's set_balance

 *

 * Gain does not vary with resolution (checked 640x480 vs 1600x1200)

 *

 * Constant derivation:

 *

 * Raw data:

 * Gain,   GTOP,   B,	  R,	  GBOT

 * 1.00,   0x105C, 0x1068, 0x10C8, 0x105C

 * 1.20,   0x106E, 0x107E, 0x10D6, 0x106E

 * 1.40,   0x10C0, 0x10CA, 0x10E5, 0x10C0

 * 1.60,   0x10C9, 0x10D4, 0x10F3, 0x10C9

 * 1.80,   0x10D2, 0x10DE, 0x11C1, 0x10D2

 * 2.00,   0x10DC, 0x10E9, 0x11C8, 0x10DC

 * 2.20,   0x10E5, 0x10F3, 0x11CF, 0x10E5

 * 2.40,   0x10EE, 0x10FE, 0x11D7, 0x10EE

 * 2.60,   0x10F7, 0x11C4, 0x11DE, 0x10F7

 * 2.80,   0x11C0, 0x11CA, 0x11E5, 0x11C0

 * 3.00,   0x11C5, 0x11CF, 0x11ED, 0x11C5

 *

 * zR = 0.0069605943152454778

 *	about 3/431 = 0.0069605568445475635

 * zB = 0.0095695970695970703

 *	about 6/627 = 0.0095693779904306216

 * zG = 0.010889328063241107

 *	about 6/551 = 0.010889292196007259

 * about 10 bits for constant + 7 bits for value => at least 17 bit

 * intermediate with 32 bit ints should be fine for overflow etc

 * Essentially gains are in range 0-0x001FF

 *

 * However, V4L expects a main gain channel + R and B balance

 * To keep things simple for now saturate the values of balance is too high/low

 * This isn't really ideal but easy way to fit the Linux model

 *

 * Converted using gain model turns out to be quite linear:

 * Gain, GTOP, B, R, GBOT

 * 1.00, 92, 104, 144, 92

 * 1.20, 110, 126, 172, 110

 * 1.40, 128, 148, 202, 128

 * 1.60, 146, 168, 230, 146

 * 1.80, 164, 188, 260, 164

 * 2.00, 184, 210, 288, 184

 * 2.20, 202, 230, 316, 202

 * 2.40, 220, 252, 348, 220

 * 2.60, 238, 272, 376, 238

 * 2.80, 256, 296, 404, 256

 * 3.00, 276, 316, 436, 276

 *

 * Maximum gain is 0x7FF * 2 * 2 => 0x1FFC (8188)

 * or about 13 effective bits of gain

 * The highest the commercial driver goes in my setup 436

 * However, because could *maybe* damage circuits

 * limit the gain until have a reason to go higher

 * Solution: gain clipped and warning emitted

 */

#define GAIN_MAX		511
@@ -189,8 +185,8 @@ static const struct v4l2_pix_format vga_mode[] = { 
};



/*

As theres no known frame sync, the only way to keep synced is to try hard

to never miss any packets

 * As theres no known frame sync, the only way to keep synced is to try hard

 * to never miss any packets

 */

#if MAX_NURBS < 4

#error "Not enough URBs in the gspca table"
@@ -218,7 +214,8 @@ static void reg_w(struct gspca_dev *gspca_dev, u16 value, u16 index) 
	char buff[1];

	int rc;



	PDEBUG(D_USBO, "reg_w bReq=0x0B, bReqT=0xC0, wVal=0x%04X, wInd=0x%04X\n",

	PDEBUG(D_USBO,

		"reg_w bReq=0x0B, bReqT=0xC0, wVal=0x%04X, wInd=0x%04X\n",

		value, index);

	rc = usb_control_msg(gspca_dev->dev, usb_rcvctrlpipe(gspca_dev->dev, 0),

		0x0B, 0xC0, value, index, buff, 1, 500);
@@ -271,10 +268,10 @@ static void setexposure(struct gspca_dev *gspca_dev, s32 val) 
static int gainify(int in)

{

	/*

	TODO: check if there are any issues with corner cases

	0x000 (0):0x07F (127): regL

	0x080 (128) - 0x0FF (255): regM, regL

	0x100 (256) - max: regH, regM, regL

	 * TODO: check if there are any issues with corner cases

	 * 0x000 (0):0x07F (127): regL

	 * 0x080 (128) - 0x0FF (255): regM, regL

	 * 0x100 (256) - max: regH, regM, regL

	 */

	if (in <= 0x7F)

		return 0x1000 | in;
@@ -446,17 +443,17 @@ static int configure(struct gspca_dev *gspca_dev) 
	PDEBUG(D_STREAM, "configure()\n");



	/*

	First driver sets a sort of encryption key

	A number of futur requests of this type have wValue and wIndex encrypted

	as follows:

	-Compute key = this wValue rotate left by 4 bits

		(decrypt.py rotates right because we are decrypting)

	-Later packets encrypt packets by XOR'ing with key

		XOR encrypt/decrypt is symmetrical

		wValue, and wIndex are encrypted

		bRequest is not and bRequestType is always 0xC0

			This allows resyncing if key is unknown?

	By setting 0 we XOR with 0 and the shifting and XOR drops out

	 * First driver sets a sort of encryption key

	 * A number of futur requests of this type have wValue and wIndex

	 * encrypted as follows:

	 * -Compute key = this wValue rotate left by 4 bits

	 *	(decrypt.py rotates right because we are decrypting)

	 * -Later packets encrypt packets by XOR'ing with key

	 *	XOR encrypt/decrypt is symmetrical

	 *	wValue, and wIndex are encrypted

	 *	bRequest is not and bRequestType is always 0xC0

	 *		This allows resyncing if key is unknown?

	 * By setting 0 we XOR with 0 and the shifting and XOR drops out

	 */

	rc = usb_control_msg(gspca_dev->dev, usb_rcvctrlpipe(gspca_dev->dev, 0),

			     0x16, 0xC0, 0x0000, 0x0000, buff, 2, 500);
@@ -466,12 +463,13 @@ static int configure(struct gspca_dev *gspca_dev) 
	}



	/*

	Next does some sort of 2 packet challenge / response

	evidence suggests its an Atmel I2C crypto part but nobody cares to look

	(to make sure its not cloned hardware?)

	Ignore: I want to work with their hardware, not clone it

	16 bytes out challenge, requestType: 0x40

	16 bytes in response, requestType: 0xC0

	 * Next does some sort of 2 packet challenge / response

	 * evidence suggests its an Atmel I2C crypto part but nobody cares to

	 * look

	 * (to make sure its not cloned hardware?)

	 * Ignore: I want to work with their hardware, not clone it

	 * 16 bytes out challenge, requestType: 0x40

	 * 16 bytes in response, requestType: 0xC0

	 */



	rc = usb_control_msg(gspca_dev->dev, usb_sndctrlpipe(gspca_dev->dev, 0),
@@ -496,10 +494,11 @@ static int configure(struct gspca_dev *gspca_dev) 
	}



	/*

	Serial number?  Doesn't seem to be required

	cam1: \xE6\x0D\x00\x00, cam2: \x70\x19\x00\x00

	rc = usb_control_msg(gspca_dev->dev, usb_rcvctrlpipe(gspca_dev->dev, 0),

			     0x20, 0xC0, 0x0000, 0x0000, buff, 4, 500);

	 * Serial number?  Doesn't seem to be required

	 * cam1: \xE6\x0D\x00\x00, cam2: \x70\x19\x00\x00

	 * rc = usb_control_msg(gspca_dev->dev,

	 *			usb_rcvctrlpipe(gspca_dev->dev, 0),

	 *			0x20, 0xC0, 0x0000, 0x0000, buff, 4, 500);

	 */



	/* Large (EEPROM?) read, skip it since no idea what to do with it */