Re: Move em27xx/em28xx webcams to a gspca subdriver ?

["Frank Schäfer" <fschaefer.oss@googlemail.com>]

[Was: eMPIA EM2710 Webcam (em28xx) and LIRC]

Continue this part of the discussion in a new thread...

Am 15.03.2012 14:05, schrieb Mauro Carvalho Chehab:
> Em 15-03-2012 09:34, Frank Schäfer escreveu:
>> ...
>>
>> I would like to bring up the question, if it wouldn't make sense to move
>> support for the em27xx/28xx webcams to a separate gspca-subdriver.
> The em2710/2750 chips are very similar to em2820. There's not much sense
> on moving it elsewhere, as it would duplicate a lot of the existing code,
> for no good reason.
Yes, that was my first thought, too.
But looking at the resulting gspca subdriver, you will see that there is
not much code duplication.
I would say that adding support for this device as a gspca subdriver
requires less new lines of code than extending/modifying the em28xx driver.

>> I'm currently working on adding support for the VAD Laplace webcam
>> (em2765 + OV2640) (http://linuxtv.org/wiki/index.php/VAD_Laplace).
>> Lots of modifications to the em28xx driver would be necessary to support
>> this device because of some significant differences:
>> - supports only bulk transfers
> em28xx supports it as well, but it is used only for dvb, currently.
You are talking about the em28xx device capabilities, right ?
AFAIK, the em28xx driver still has no bulk transfer support.

>> - uses proprietary I2C-writes
> huh? I2C writes are proprietary. What do you mean?
Maybe proprietary is not the best name...
Requests 0x06 an 0x08 are used for the usb control messages.
I have documented that at http://linuxtv.org/wiki/index.php/VAD_Laplace.
Could be the "vendor specific" usb requests the datasheet talks about.

>> - em25xx-eeprom
> Are you meaning more than 256 addresses eeprom? Newer Empia chips use it,
> not only the webcam ones. Currently, the code detects it but nobody wrote
> an implementation for it yet. It would likely make sense to implement it
> at em28xx anyway.
Yes, the device has an eeprom with 16bit addresses.
Anyway, I'm talking about a different format of the eeprom data:
http://wenku.baidu.com/view/a21a28eab8f67c1cfad6b8f6.html

You can find the eeprom content of my device at
http://linuxtv.org/wiki/index.php/VAD_Laplace

>> - ov2640 sensor
> The better is to use a separate I2C driver for the sensor. This is not
> a common practice at gspca, but doing that would help to re-use the sensor
> driver elsewhere.
I agree. But let's do things step by step...

>> Lots of changes concerning the USB-interface probing, button handling,
>> video controls, frame processing and more would be necessary, too.
> Video controls are implemented at the sensor sub-driver, so this is not
> an issue.
>
> Anyway, if em2765 is different enough from em2874 and em2750, then it makes
> sense to write it as a separate driver. Otherwise, it is better to add support
> for it there.

No, the em2765 itself seems to be very similar to the other
em27xx/em28xx chips.
But the device as a whole is different enough to consider a separate driver.

>> For reverse engineering purposes, I decided to write a gspca subdriver
>> for this device (will send a patch for testing/discussion soon).
> Ok.
See the patch posted a minute ago.

>
>> I have no strong opinion about this, but I somehow feel that the em28xx
>> driver gets bloated more and more...
> The advantage of adding it there is that it generally reduces maintenance 
> efforts, as the same code and fixes don't need to be added on two separate
> places.
Yes, that's right. But on the other hand, the benefit of separate
drivers is simpler code, which is easier to maintain/understand.
For example, there would be no LIRC modules issue ;-)

> For example, if the em2765 eeprom access is similar to em2874, the same
> code chunk would be required on both drivers.
Sure, code duplication is one of the disadvantages. The question is how
much duplicate code there would be.

Regards,
Frank

> Regards,
> Mauro