Re: [PATCH v2] soc-camera: add API documentation

[Jean-Francois Moine <moinejf@free.fr>]

On Sat, 2008-08-30 at 07:03 -0300, Mauro Carvalho Chehab wrote:
	[snip]
> Yes, but still, this is something that it is still painful: gspca has lots of
> "magic" constants inside. Things like (from etoms.c):
> 	reg_w_val(gspca_dev, 0x80, 0x00);
	[snip]
> It is something really hard to understand why reg 3 needs value 1. OK, I know that
> most of this came from snooping URB's at another system driver, but, if there
> were bugs at the reversed-engineered driver (and there are bugs there also),
> you won't have any glue to debug.

Anyway you do it, I (we) have almost no information about the webcam
bridges and sensors. Sometimes, we find some documents and then, the
spec calls RSVD (reserved) some registers which are later differently
initialized for such and such bridge!

> It is much clearer if you look, for example, at ov7670:
> 	{ REG_CLKRC, 0x1 },	/* OV: clock scale (30 fps) */
> 	{ REG_TSLB,  0x04 },	/* OV */
	[snip]
> Ok, it is not fair to compare with ov7670, since I suspect that OLPC got the
> datasheets for that device. Yet, having a driver for each sensor makes easier
> to add more detailed info at that driver, if later the device manufacturer
> opens for us their datasheets, like several manufacturers already did.

I don't think so. First, I don't think the device manufacturers will
give information about their product: they prefer to sell opaque
drivers. Then, as, at job, I built firmware for embedded boards, I know
that a master/slave interface may be very complex and not easy to
explain. Also, once the driver works, why would you change anything?

> > If you look at the gspca code, you will see that many sensors are used
> > by different bridges. Indeed, some values are closed from each other,
> > but what to do with the differences? (the initial values of the sensor
> > registers seem to be tied to the physical wires, signal levels and
> > capabilities of the bridges)
> 
> I can see two ways:
	[snip]

Why do you want the drivers to be so complexified? I already tried to
look at such drivers, and I could not find where was the used code. With
gspca, all the webcam dependant stuff is located in one file only.

> The real gain is not the size reduction. Having a generic module for a sensor
> have some benefits:
> 
> 1) All common stuff being there means that it will be easier to maintain, since
> a bug found on one module should be replied on other modules;

I never saw that!

> 2) Newer drivers may be written faster, since they may use the existing code.

Usually, newer drivers are written because they do not fall into some
existing code.

> I'm not saying that we _need_ to do this change for gspca. I'm just saying that
> this is a _good_ improvement to the code. I know that this change
> requires lots of janitors effort with little gain to the end users.

I would go to an other way: instead of developping general functions
which have to be customized, why don't you use the generic gspca driver
as a base for all the USB video devices (including TV)?

Cheers.

-- 
Ken ar c'hentañ |             ** Breizh ha Linux atav! **
Jef             |               http://moinejf.free.fr/


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list