On Wed, 21 Oct 2009, Valentin Longchamp wrote: > Sascha Hauer wrote: > > On Mon, Oct 19, 2009 at 06:41:13PM +0200, Valentin Longchamp wrote: > > > Hi Guennadi, > > > > > > Guennadi Liakhovetski wrote: > > > > Hi > > > > > > > > On Thu, 15 Oct 2009, Valentin Longchamp wrote: > > > > > > > > > We have two mt9t031 cameras that have a muxed bus on the robot. > > > > > We can control which one we are using with gpio outputs. This > > > > > currently is not optimal > > > > So, what prevents you from registering two platform devices for your two > > > > cameras? Is there a problem with that? > > > The lack of time until now to do it properly. I sent those patches as > > > initial RFC (and by the way thanks for your comment). > > > > > > I would like to have one video interface only and that I can switch > > > between the two physical camera using a quite simple system call. Would > > > that be compatible with registering the two platform devices ? > > > > Wouldn't it be better to have /dev/video[01] for two cameras? How do > > keep the registers synchron between both cameras otherwise? > > > > Well, from my experimentations, most initializations are done when you open > the device. So if you close the device, switch camera and open it again, the > registers are initialized with the need values. Of course there is a problem > is you switch camera while the device is open. > > It could be ok with /dev/video[01], but I would need something that would > prevent one device to be opened when the other already is open (a mutex, but > where ?). > > Besides, I have read a slide from Dongsoo Kim > (http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=Framework_for_digital_camera_in_linux-in_detail.ppt > slides 41-47) and the cleanest solution would be to have the two chips > enumerated with VIDIOC_ENUMINPUT as proposed. What would then be the v4l2 call > to switch from one device to each other ? How to "link" it with the kernel > code that make the real hardware switching ? Ok, I don't have a definite answer to this, so, just my thoughts: 1. soc-camera currently registers one struct v4l2_device device per _host_ immediately upon its registration, and one struct video_device per _client_ platform device. 2. we currently have 1 or 2 boards in the mainline with two video client devices on one interface: arch/sh/boards/mach-migor/ and (unsure about) arch/sh/boards/board-ap325rxa.c. At least the first of them exports two platform devices and thus gets /dev/video[01]. Accesses are synchronised with a mutex (I don't actually like that, I'd prefer to get a -EBUSY back instead of hanging in D in open()), and a successful acquisition of the mutex switches the respective camera on. See code for details. So, this approach is supported and it works. In this case we have one v4l2_device and two video_device instances, don't know whether this matches how this is supposed to be done, but it works so far:-) 3. to support switching inputs, significant modifications to soc_camera.c would be required. I read Nate's argument before, that as long as clients can only be accessed one at a time, this should be presented by multiple inputs rather than multiple device nodes. Somebody else from the V4L folk has also confirmed this opinion. In principle I don't feel strongly either way. But currently soc-camera uses a one i2c client to one device node model, and I'm somewhat reluctant to change this before we're done with the v4l2-subdev conversion. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
