On Tue, 21 Apr 2009, Dongsoo, Nathaniel Kim wrote: > Hello, > > One of my recent work is making S3C64XX camera interface driver with > SoC camera framework. Thanks to Guennadi, SoC camera framework is so > clear and easy to follow. Actually I didn't need to worry about my > whole driver structure, the framework almost has everything that I > need. > > But here is a problem that I couldn't make up my mind while > implementing some of the features of S3C64XX camera IP. > As you know, S3C64XX camera IP has scaler and rotator capability on > it's own which can be used standalone even memory to memory scaling > and rotating jobs. > If you want to know in detail please take a look at the user manual > (just remind if you have already seen this) : > http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C6400X_UserManual_rev1-0_2008-02_661558um.pdf > > Telling you about the driver concept that I wanted to make is like following: > > (I want to select inputs like external camera and MSDMA using > S_INPUT'/G_INPUT but we don't have them in SoC camera framework. > So this should be the version of design with current SoC camera framework.) > > 1. S3C64XX has preview and codec path > 2. Each preview and codec path can have external camera and MSDMA for input > 3. make external camera and MSDMA device nodes for each preview and codec. > => Let's assume that we have camera A and B, then it should go like this > /dev/video0 (camera A on preview device) > /dev/video1 (camera B on preview device) > /dev/video2 (MSDMA on preview device) > /dev/video3 (camera A on codec device) > /dev/video4 (camera B on codec device) > /dev/video5 (MSDMA on codec device) My proposal was a bit different. You don't need two different output devices per camera - video3 and video4. I suggested to make preview a pure output device, without the ability to select the input. So, if you activate (open) video1, video3 will get data from the first camera. If you activate video2, video3 will preview camera 2. Also, you can have a look at arch/sh/boards/mach-migor/setup.c for an example of handling two cameras on one interface. The only difference to what I have proposed is that they block on open(video1) if video0 is in use and the other way round. Whereas I suggested to return -EBUSY. You can choose. > 4. Those device nodes are "device" in SoC camera framework (and S3C > camera interface should be "host" device) > => External camera devices can be made in SoC camera device. Fair enough. > > But MSMDA? what should I do If I want to make it as a "device" > driver in SoC camera framework? > Any reference that I could have? because I can't find any "device" > drivers besides camera sensor,isp drivers. > Please let me know if there is any. Actually, last time we talked about it I didn't realise, that you can configure the preview path to read data from memory while your codec path processes data from the camera, is this really the case? I didn't study the datasheet in enough detail. Well, you might look at drivers/media/video/soc_camera_platform.c for an example of a simple "pseudo" camera driver. Of course, with your two additional devices you don't want to add extra platform devices and extra probing. In fact, you can do this with the "old" (currently in the mainline) soc-camera model, where client drivers actively report themselves to the soc-camera core using soc_camera_device_register() / soc_camera_device_unregister() and the core doesn't care about the nature of those drivers. This is not going to be the case with the new platform / v4l2-subdev infrastructure, which is pretty tightly bound to i2c... So, we'll have to extend it too. I would suggest you reserve slots for those two from-memory video devices in your design, base your design on latest patches on this list (see the patches I just submitted) and concentrate on camera-devices for now. Then we shall see how to add non-i2c video data-sources to the framework. 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
