Am 16.03.2012 23:18, schrieb Frank Schäfer: > [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 Ping ! No comments, opinions ? ;-) Regards, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
