All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, video4linux-list@redhat.com
Subject: Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
Date: Mon, 28 May 2007 12:00:19 -0300	[thread overview]
Message-ID: <1180364420.21547.160.camel@localhost> (raw)
In-Reply-To: <2172422218943432279@wsc.cz>

Hi Jiri,

I have some comments for your driver.

> + * Copyright (C) Nicolas VIVIEN

It would be interesting to have Nicolas SOB as well, if possible.

> +
> +#ifndef CONFIG_STK11XX_DEBUG_STREAM
> +#define CONFIG_STK11XX_DEBUG_STREAM	0
> +#endif
> +
> +#if CONFIG_STK11XX_DEBUG_STREAM

I would instead use:
#ifdef CONFIG_STK11XX_DEBUG_STREAM

> +/*
> + * Bayer conversion
> + */

We don't do format conversions in kernel. Instead, you should return a
proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8).

> +static void stk11xx_resize_image(u8 *out, const u8 *in,
> +		unsigned int width, unsigned int height, unsigned int factor)

Also, kernel shouldn't be doing image resize.

> +static int stk11xx_decompress(struct stk11xx *dev)
> +{

We don't do format conversions in kernel. Instead, you should return a
proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8).

> +static int stk1125_load_microcode(struct stk11xx *dev)
> +{
> +	unsigned int i;
> +	const u8 *values_204, *values_205;
> +	int retok, value;
> +
> +	/* From 80x60 to 640x480 */
> +	const u8 values_1_204[] = {
> +		0x12, 0x11, 0x3b, 0x6a, 0x13, 0x10, 0x00, 0x01, 0x02, 0x13,
> +		0x39, 0x38, 0x37, 0x35, 0x0e, 0x12, 0x04, 0x0c, 0x0d, 0x17,
> +		0x18, 0x32, 0x19, 0x1a, 0x03, 0x1b, 0x16, 0x33, 0x34, 0x41,
> +		0x96, 0x3d, 0x69, 0x3a, 0x8e, 0x3c, 0x8f, 0x8b, 0x8c, 0x94,
> +		0x95, 0x40, 0x29, 0x0f, 0xa5, 0x1e, 0xa9, 0xaa, 0xab, 0x90,
> +		0x91, 0x9f, 0xa0, 0x24, 0x25, 0x26, 0x14, 0x2a, 0x2b
> +	};
> +	const u8 values_1_205[] = {
> +		0x45, 0x80, 0x01, 0x7d, 0x80, 0x00, 0x00, 0x80, 0x80, 0x80,
> +		0x50, 0x93, 0x00, 0x81, 0x20, 0x45, 0x00, 0x00, 0x00, 0x24,
> +		0xc4, 0xb6, 0x00, 0x3c, 0x36, 0x00, 0x07, 0xe2, 0xbf, 0x00,
> +		0x04, 0x19, 0x40, 0x0d, 0x00, 0x73, 0xdf, 0x06, 0x20, 0x88,
> +		0x88, 0xc1, 0x3f, 0x42, 0x80, 0x04, 0xb8, 0x92, 0x0a, 0x00,
> +		0x00, 0x00, 0x00, 0x68, 0x5c, 0xc3, 0x2e, 0x00, 0x00
> +	};
> +
> +	/* From 800x600 to 1280x1024 */
> +	const u8 values_2_204[] = {
> +		0x12, 0x11, 0x3b, 0x6a, 0x13, 0x10, 0x00, 0x01, 0x02, 0x13,
> +		0x39, 0x38, 0x37, 0x35, 0x0e, 0x12, 0x04, 0x0c, 0x0d, 0x17,
> +		0x18, 0x32, 0x19, 0x1a, 0x03, 0x1b, 0x16, 0x33, 0x34, 0x41,
> +		0x96, 0x3d, 0x69, 0x3a, 0x8e, 0x3c, 0x8f, 0x8b, 0x8c, 0x94,
> +		0x95, 0x40, 0x29, 0x0f, 0xa5, 0x1e, 0xa9, 0xaa, 0xab, 0x90,
> +		0x91, 0x9f, 0xa0, 0x24, 0x25, 0x26, 0x14, 0x2a, 0x2b
> +	};
> +	const u8 values_2_205[] = {
> +		0x05, 0x80, 0x01, 0x7d, 0x80, 0x00, 0x00, 0x80, 0x80, 0x80,
> +		0x50, 0x93, 0x00, 0x81, 0x20, 0x05, 0x00, 0x00, 0x00, 0x1b,
> +		0xbb, 0xa4, 0x01, 0x81, 0x12, 0x00, 0x07, 0xe2, 0xbf, 0x00,
> +		0x04, 0x19, 0x40, 0x0d, 0x00, 0x73, 0xdf, 0x06, 0x20, 0x88,
> +		0x88, 0xc1, 0x3f, 0x42, 0x80, 0x04, 0xb8, 0x92, 0x0a, 0x00,
> +		0x00, 0x00, 0x00, 0x68, 0x5c, 0xc3, 0x2e, 0x00, 0x00
> +	};

Please use instead the load_firmware routines. It is not a good idea to
have firmware inside the kernel. Also, this might rise some legal issues
due to licensing models.

> +
> +/* 
> + * The configuration of device is composed of 11 steps.
> + * This function is called by the initialization process.
> + *
> + * We don't know the meaning of these steps! We only replay the USB log.
> + *
> + * The steps 0 to 9 are called during the initialization.
> + * Then, the driver choose the last step :
> + *   10 : for a resolution from 80x60 to 640x480 
> + *   11 : for a resolution from 800x600 to 1280x1024
> + */
> +static int stk1125_configure_device(struct stk11xx *dev, int step)
> +{
> +	int value;
> +
> +	/*      0,    1,    2,    3,    4,    5,    6,    7,    8,    9, 
> +		    10,   11 */
> +
> +	const u8 values_001B[] = {
> +		0x0E, 0x03, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E,
> +		    0x0E, 0x0E
> +	};
> +	const u8 values_001C[] = {
> +		0x06, 0x02, 0x46, 0x46, 0x46, 0x46, 0x46, 0x46, 0x46, 0x46,
> +		    0x46, 0x0E
> +	};
> +	const u8 values_0202[] = {
> +		0x1E, 0x0A, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E,
> +		    0x1E, 0x1E
> +	};
> +	const u8 values_0110[] = {
> +		0x07, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x3E, 0x00, 0x00, 0x00,
> +		    0x00, 0x00
> +	};
> +	const u8 values_0112[] = {
> +		0x07, 0x00, 0x00, 0x00, 0x00, 0x09, 0x09, 0x00, 0x00, 0x00,
> +		    0x00, 0x00
> +	};
> +	const u8 values_0114[] = {
> +		0x87, 0x80, 0x80, 0x80, 0x80, 0xBE, 0xBE, 0x80, 0x80, 0x80,
> +		    0x80, 0x00
> +	};
> +	const u8 values_0115[] = {
> +		0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02,
> +		    0x02, 0x05
> +	};
> +	const u8 values_0116[] = {
> +		0xE7, 0xE0, 0xE0, 0xE0, 0xE0, 0xE9, 0xE9, 0xE0, 0xE0, 0xE0,
> +		    0xE0, 0x00
> +	};
> +	const u8 values_0117[] = {
> +		0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
> +		    0x01, 0x04
> +	};
> +	const u8 values_0100[] = {
> +		0x20, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21,
> +		    0x21, 0x21
> +	};
> +
> +	dev_dbg(&dev->udev->dev, "stk1125_configure_device: %d\n", step);
> +
> +	stk11xx_write_registry(dev, 0x0000, 0x0024);
> +	stk11xx_write_registry(dev, 0x0002, 0x0068);
> +	stk11xx_write_registry(dev, 0x0003, 0x0080);
> +	stk11xx_write_registry(dev, 0x0005, 0x0000);
	...

Instead of using all those write, you should consider creating a table
of values and use something like:
	stk11xx_write_regs(dev, table1);

> +/*
> + * STK-1135 API
> + */
> +
> +static int stk1135_load_microcode(struct stk11xx *dev)
> +{
> +	unsigned int i;
> +	int retok, value;

> +
> +	const u8 values_204[] = {
> +		0x17, 0x19, 0xb4, 0xa6, 0x12, 0x13, 0x1e, 0x21, 0x24, 0x32,
> +		0x36, 0x39, 0x4d, 0x53, 0x5d, 0x5f, 0x60, 0x61, 0x62, 0x63,
> +		0x64, 0x65, 0x66, 0x82, 0x83, 0x85, 0x86, 0x89, 0x97, 0x98,
> +		0xad, 0xae, 0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbf, 0x48, 0xd8,
> +		0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0x7f,
> +		0x80, 0x81, 0xd8, 0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, 0x7c,
> +		0x7d, 0x7e, 0x7f, 0x80, 0x81, 0xd8, 0x76, 0x77, 0x78, 0x79,
> +		0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0x7f, 0x80, 0x81, 0x5c, 0xc0,
> +		0x59, 0x5a, 0x5b, 0xd4, 0x8e, 0x8f, 0x90, 0x91, 0x92, 0x93,
> +		0x94, 0x95, 0x96, 0xb3, 0x73, 0x06, 0x07, 0x0b, 0x15, 0x20,
> +		0x4e, 0x4f, 0x49, 0x4a, 0x4b, 0x4c, 0x46, 0x06, 0x07, 0xb9,
> +		0xba, 0xbb, 0xbc, 0x61, 0x62, 0x65, 0x66
> +	};
> +	const u8 values_205[] = {
> +		0x41, 0x41, 0x03, 0x06, 0x06, 0x08, 0x06, 0x00, 0x02, 0x69,
> +		0x35, 0x60, 0xfe, 0x1c, 0x04, 0x08, 0x08, 0x08, 0x08, 0x00,
> +		0x00, 0x10, 0x14, 0x01, 0x80, 0x0c, 0xb6, 0x00, 0x25, 0x25,
> +		0x3f, 0x24, 0x10, 0x07, 0xcc, 0x1f, 0x30, 0x02, 0x9c, 0x80,
> +		0x00, 0x0d, 0x18, 0x22, 0x2c, 0x3e, 0x4f, 0x6f, 0x8e, 0xac,
> +		0xc8, 0xe5, 0xa0, 0x00, 0x0d, 0x18, 0x22, 0x2c, 0x3e, 0x4f,
> +		0x6f, 0x8e, 0xac, 0xc8, 0xe5, 0xc0, 0x00, 0x0d, 0x18, 0x22,
> +		0x2c, 0x3e, 0x4f, 0x6f, 0x8e, 0xac, 0xc8, 0xe5, 0x70, 0x18,
> +		0x09, 0x07, 0x07, 0x3c, 0x3d, 0x95, 0x88, 0x89, 0x47, 0x9c,
> +		0x81, 0x9c, 0x3d, 0x76, 0x76, 0x01, 0xf3, 0x05, 0x00, 0x44,
> +		0x06, 0x0a, 0x96, 0x00, 0x7d, 0x00, 0x20, 0x01, 0xf3, 0x04,
> +		0xe4, 0x09, 0xc8, 0x08, 0x08, 0x10, 0x14
> +	};

Same as commented before about microcode.

You may also consider writing a separate c file for stk1135. Having a
large .c file is not very nice. The better is to split the code into a
few parts.
> +static void *stk11xx_rvmalloc(unsigned long size)

Another rvmalloc implementation? You should consider using the one
already at kernel.

> +
> +static void stk11xx_rvfree(void *mem, unsigned long size)

same as above.

> +	cap->version = (u32)DRIVER_VERSION_NUM;

You should use, instead, KERNEL_VERSION macro.

> +       /* Create frame buffers and make circular ring */
> +       for (i = 0; i < default_nbrframebuf; i++)
> +               if (dev->framebuf[i].data == NULL) {
> +                       dev->framebuf[i].data = vmalloc(STK11XX_FRAME_SIZE); 

STK11XX_FRAME_SIZE is defined previously as  (1280 * 1024 * 3). Why to
allocate so much memory, even if the user selects a lower format? You
should, instead, allocate memory dynamically as needed by the user.

> +static int stk11xx_querystd(struct file *file, void *fh, v4l2_std_id
> *a)
> +{
> +	*a = V4L2_STD_UNKNOWN;
> +	return 0;
> +}
> +
> +static int stk11xx_s_std(struct file *file, void *fh, v4l2_std_id *a)
> +{
> +	return *a == V4L2_STD_UNKNOWN ? 0 : -EINVAL;
> +}

This raises an interesting discussion about video standards. I would,
instead, use V4L2_STD_ALL, since webcams are capable of properly
handling on 525 raw lines/60Hz based standards (those derived from
640x480 res) as well as 625 raw lines/50Hz based standards (those
derived from ITU-T CIF resolutions).

As reference, STD_ALL is defined as:

#define V4L2_STD_ALL            (V4L2_STD_525_60        |\
                                 V4L2_STD_625_50)

---

Also, I noticed that several hexadecimal values are using uppercases.
The better is to convert all of them to lowercase, to keep the same
codingstyle as the other drivers.

-- 
Cheers,
Mauro


  parent reply	other threads:[~2007-05-28 15:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-24 14:01 [PATCH 1/1] V4L: stk11xx, add a new webcam driver Jiri Slaby
2007-05-24 14:24 ` Markus Rechberger
2007-05-24 15:07   ` Jiri Slaby
2007-05-28 15:21     ` Markus Rechberger
2007-05-24 23:07   ` Jiri Slaby
2007-05-25  8:22     ` Stefan Richter
2007-05-25  8:30       ` Jiri Slaby
2007-05-24 17:38 ` Diego Calleja
2007-05-24 18:01   ` Ismail Dönmez
2007-05-25  8:19     ` Stefan Richter
     [not found]       ` <4af2d03a0705250127j3d05cd6bkb114cad0e6ecb449@mail.gmail.com>
2007-05-25  9:50         ` Stefan Richter
2007-05-28 15:00 ` Mauro Carvalho Chehab [this message]
2007-05-28 15:14   ` Markus Rechberger
2007-05-28 16:28     ` Luca Risolia
2007-05-28 16:42       ` Markus Rechberger
2007-05-28 18:57     ` Mauro Carvalho Chehab
2007-05-28 19:17       ` Markus Rechberger
2007-05-28 20:11         ` Mauro Carvalho Chehab
2007-05-28 21:30           ` Thierry Merle
2007-05-29  5:32             ` Thierry Merle
2007-05-29 14:25               ` Mauro Carvalho Chehab
2007-05-29 19:04                 ` Thierry Merle
2007-05-29 19:31                   ` Mauro Carvalho Chehab
2007-05-31 20:43                     ` Thierry Merle
2007-06-01 23:10                       ` Mauro Carvalho Chehab
2007-06-02  9:00                         ` Thierry Merle
2007-06-04 18:55                           ` Mauro Carvalho Chehab
2007-06-15 21:08                             ` Jiri Slaby
2007-06-16 11:46                               ` Thierry Merle
2007-06-16 12:07                                 ` Jiri Slaby
     [not found]                               ` <200706190941.47459.oliver@neukum.org>
2007-06-19  7:44                                 ` Jiri Slaby
2007-05-30 19:44   ` Jiri Slaby
2007-06-01 23:00     ` Mauro Carvalho Chehab
  -- strict thread matches above, loose matches on Subject: below --
2007-08-26 14:09 Jiri Slaby
2007-08-27 22:40 ` Andrew Morton
2007-08-28  5:33   ` Jiri Slaby
2007-08-28  5:36     ` Andrew Morton
2007-08-28  5:41       ` Jiri Slaby
2007-08-28  6:35 ` Alexander E. Patrakov
2007-11-06  7:40 ` Andrew Morton
2007-11-06 10:48   ` Jiri Slaby
2007-11-07 17:57     ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1180364420.21547.160.camel@localhost \
    --to=mchehab@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.