On Sunday 09 August 2009 13:13:40 Dongsoo, Nathaniel Kim wrote: > 2009/8/9 Hans Verkuil <hverkuil@xxxxxxxxx>: > > On Sunday 09 August 2009 10:20:47 Erik Andrén wrote: > >> > >> Dongsoo, Nathaniel Kim wrote: > >> > Hello, > >> > > >> > It has been years I've working on linux multimedia drivers, but what a > >> > shame I found that there were already sensor drivers that I've already > >> > implemented. Precisely speaking, soc camera devices from Samsung named > >> > s5k4aa* and s5k83a* were already in Linux kernel and even seems to > >> > have been there for years. > >> > But a thing that I'm curious is those drivers are totally mc602 and > >> > gspca oriented. So some users who are intending to use those samsung > >> > camera devices but not using gspca and mc5602 H/W have to figure out > >> > another way. > >> > As you know, the s5k* camera devices are actually ISP devices which > >> > are made in SoC device and can be used independently with any kind of > >> > ITU or MIPI supporting host devices. > >> > However, I see that gspca and mc5602 have their own driver structure > >> > so it seems to be tough to split out the sensor drivers from them. > >> > So, how should we coordinate our drivers if a new s5k* driver is > >> > getting adopted in the Linux kernel? different version of s5k* drivers > >> > in gspca and subdev or gspca also is able to use subdev drivers? > >> > I am very willing to contribute several drivers for s5k* soc camera > >> > isp devices and in the middle of researching to prepare for > >> > contribution those s5k* drivers popped up. > >> > Please let me know whether it is arrangeable or not. > >> > Cheers, > >> > > >> > >> Hi Nathaniel, > >> The sensor sharing question pops up now and then and I'm sure that > >> if you search the mailing list archive you can find several threads > >> discussing this. > >> IIRC the main problem is that in an usb webcam consisting of a > >> sensor and an usb bridge. The sensor is often configured in a very > >> specific way tied to the particular usb bridge. It is also common > >> that much of the initialization is reverse engineered and that we > >> may have little or no understanding what we're actually doing. > >> (Often just mimicing a windows webcam driver). > >> I think the conclusion reached now is that it's not worth the effort > >> considering that the sensors usually don't need that much setup to > >> get working. Of course this may need to be reevaluated from time to > >> time. If someone could device a clever solution I would be all for > >> trying to create some kind of driver sharing. > > > > Basically any gspca driver that can set registers in the i2c device > > (as opposed to only replaying USB commands) can be modified so the i2c > > part can be split off into a regular sub-device driver. I've discussed > > this in the past with Hans de Goede and that is definitely the way to go. > > > >> In the gspca-m5602-s5k* case everything is reverse-engineered, as I > >> don't possess any datasheets of the ALi m5602 nor the s5k83a, > >> s5k4aa. I would be much happy if you Samsung folks would be able to > >> provide with me with datasheets for the s5k* sensors. > > > > Looking at the code I'd say that it should be possible to implement an > > i2c_adapter in m5602_core.c, and when that's in place the various sensor > > drivers can be gradually split off into generic subdev drivers. Which is > > of course ever so much easier if the datasheets are available :-) > > > > For this particular bridge driver I strongly suggest that this approach > > is taken since there are already duplicate sensor drivers here (mt9m111). > > > > Regards, > > > > Hans > > > > Hi Hans, > > I didn't know that there already have been a discussion. I'll google > about that thread and go through. It was a face-to-face discussion while enjoying a good glass of beer :-) > And thanks to your mail, I could find that there already existing > duplicated drivers. I'll take that as a reference. > BTW, I was strongly appealing my boss to let me attend the > linuxplumber conf and I sense a slight possibility to go there. It's a > progress :-). I'm looking forward to having approval. It would be great news. My goal is to leave that conference with a roadmap for the next year and in particular an updated RFC for the media controller and media processor implementation. And the more input we have regarding the sort of hardware that is out there, the better. I wonder whether I shouldn't organize this as a V4L mini-summit. I'm pretty sure this isn't something that can be finalized in one day. Regards, Hans > Cheers, > > Nate > > >> > >> Best regards, > >> Erik > >> > >> > Nate > >> > > >> > >> > > > > > > > > -- > > Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom > > > > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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
