Em 21-03-2012 15:01, Frank Schäfer escreveu: > 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 ? ;-) -ETOOBUSY ;) We're in the middle of a merge window. I don't have any time during this and the next week for discussing it due to that, as there are some maintainer's task that I need to handle. Please ping me by the beginning of April, after the end of the merge window. Sorry, Mauro -- 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
