On Thu, 16 Apr 2009, Hans Verkuil wrote: > If you have mutually exclusive sources, then those should be implemented > as one device with multiple inputs. There is really no difference between > a TV capture driver that selects between a tuner and S-Video input, and a > camera driver that selects between multiple cameras. > > A completely different question is whether soc-camera should be used at > all for this. The RFC Nate posted today said that this implementation was > based around the S3C64XX SoC. The limitation of allowing only one camera > at a time is a limitation of the hardware implementation, not of the SoC > as far as I could tell. This is the opposite to how I understood it. S3C6400 only has one set of camera interface signals, so, it is supposed to only handle one camera (at a time). As for mutual exclusivity - this is not enforced by the soc-camera framework, rather it is a limitation of the hardware - SoC and implementation. The implementor wants to prohibit access to the inactive camera, and that's where the conflict arises. The framework would then have to treat a solution with one host and multiple cameras differently depending on board implementation: if they are not mutually exclusive map them to multiple video devices, if they are - map them to multiple inputs on one video device... > Given the fact that the SoC also supports codecs and other fun stuff, I > really wonder whether there shouldn't be a proper driver for that SoC that > supports all those features. Similar to what TI is doing for their davinci > platform. It is my understanding that soc-camera is really meant as a > simple framework around a sensor device, and not as a full-featured > implementation for codecs, previews, etc. Please correct me if I'm wrong. Having briefly looked at s3c6400, its video interface doesn't seem to be more advanced than, for instance, that of the PXA270 SoC. Ok, maybe only the preview path is missing on PXA. soc-camera framework has been designed as a standard framework between SoCs and video data sources with the primary goal to allow driver reuse. The functionality that it implements is what was required at that time, plus what has been added since then. Yes, it does impose a couple of simplifications on the current V4L2 API. So, of course, a decision has to be made either or not to use it in every specific case. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
