Hello Guennadi, On Thu, Apr 16, 2009 at 5:58 PM, Guennadi Liakhovetski <g.liakhovet...@gmx.de> wrote: > On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote: > >> Hello Guennadi, >> >> >> Reviewing your patch, I've got curious about a thing. >> I think your soc camera subsystem is covering multiple camera >> devices(sensors) in one target board, but if that is true I'm afraid >> I'm confused how to handle them properly. >> Because according to your patch, video_dev_create() takes camera >> device as parameter and it seems to be creating device node for each >> camera devices. > > This patch is a preparatory step for the v4l2-(sub)dev conversion. With it > yes (I think) a video device will be created for every registered on the > platform level camera, but only the one(s) that probed successfully will > actually work, others will return -ENODEV on open(). > >> It means, if I have one camera host and several camera devices, there >> should be several device nodes for camera devices but cannot be used >> at the same time. Because typical camera host(camera interface) can >> handle only one camera device at a time. But multiple device nodes >> mean "we can open and handle them at the same time". >> >> How about registering camera host device as v4l2 device and make >> camera device a input device which could be handled using >> VIDIOC_S_INPUT/G_INPUT api? > > There are also cases, when you have several cameras simultaneously (think > for example about stereo vision), even though we don't have any such cases > just yet.
I think, there are some specific camera interfaces for stereo camera. Like stereo camera controller chip from Epson. But in case of camera interface which can handle only one single camera at a time, I'm strongly believing that we should use only one device node for camera. I mean device node should be the camera interface not the sensor device. If you are using stereo camera controller chip, you can make that with a couple of device nodes, like /dev/video0 and /dev/video1. > >> Actually, I'm working on S3C64xx camera interface driver with soc >> camera subsystem, > > Looking forward to it!:-) > >> and I'm facing that issue right now because I've got >> dual camera on my target board. > > Good, I think, there also has been a similar design based on a pxa270 SoC. > How are cameras switched in your case? You probably have some additional > hardware logic to switch between them, right? So, you need some code to > control that. I think, you should even be able to do this automatically in > your platform code using power hooks from the struct soc_camera_link. You > could fail to power on a camera if another camera is currently active. In > fact, I have to add a return code test to the call to icl->power(icl, 1) > in soc_camera_open(), I'll do this for the final v4l2-dev version. Would > this work for you or do you have another requirements? In which case, can > you describe your use-case in more detail - should both cameras be open by > applications simultaneously (looks like not), do you need a more explicit > switching control, than just "first open switches," which shouldn't be the > case, since you can even create a separate task, that does nothing but > just keeps the required camera device open. > Yes exactly right. My H/W is designed to share data pins and mclk, pclk pins between both of cameras. And they have to work mutually exclusive. For now I'm working on s3c64xx with soc camera subsystem, so no way to make dual camera control with VIDIOC_S_INPUT, VIDIOC_G_INPUT. But the prior version of my driver was made to control dual camera with those S_INPUT/G_INPUT api. Actually with single device node and switching camera with S_INPUT and G_INPUT, there is no way to mis-control dual camera. Because both of cameras work mutually exclusive. To make it easier, you can take a look at my presentation file which I gave a talk at CELF ELC2009 in San Francisco. Here it is the presentation file http://tree.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=Framework_for_digital_camera_in_linux-in_detail.ppt I think it is more decent way to control dual camera. No need to check whether the sensor is available or not using this way. Just use G_INPUT to check current active sensor and do S_INPUT to switch into another one. Cheers, Nate >> I hope you to consider this concept, and also want to know your opinion. > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > -- ======================================================== DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo....@gmail.com dongsoo45....@samsung.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
