Hans Verkuil wrote:
On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote:
Thank you for your kind explanation Hans.
Problem is omap3 camera subsystem is making device node for every int
device attached to it.
That's wrong. Multiple devices should only be created if they can all be
used at the same time. Otherwise there should be just one device that uses
S_INPUT et al to select between the inputs.
There might be situations where multiple device nodes would be
beneficial even if they cannot be used simultaneously in all cases.
Currently the omap34xxcam camera driver creates one device per camera. A
camera in this case contains an isp (or camera controller), image
sensor, lens and flash. The properties like maximum frame rate or
resolution of a camera are usually (almost) completely defined by those
of the sensor, lens and flash. This affects also cropping capabilities.
Several programs can access video devices simultaneously. What happens
if another program switches the input when the first one doesn't expect
it? The original user won't notice the change, instead of getting -EBUSY
when trying to open the other video device.
In short, it's been just more clear to have one device per camera. There
may be other reasons but these come to mind this time.
BTW, do I understand correctly that e.g. lens drivers also get their
own /dev/videoX node? Please tell me I'm mistaken! Since that would be so
very wrong.
Yes, you're mistaken this time. :)
The contents of a video devices are defined in platform data.
I hope that the conversion to v4l2_subdev will take place soon. You are
basically stuck in a technological dead-end :-(
Making things working properly in camera and ISP drivers has taken much
more time than was anticipated and v4l2_subdev framework has developed a
lot during that time. You're right --- we'll start thinking of how and
when to move to v4l2_subdev.
Thanks.
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
