Re: [PATCH 5/5] soc-camera: Convert to a platform driver
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=AttachFiledo=gettarget=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 RD 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
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
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. 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. 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 -- 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
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote: 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. There are also some generic CMOS camera sensors, that support stereo mode, e.g., mt9v022. In this case you would do the actual stereo processing in host software, I think. The sensors just provide some synchronisation possibilities. And you would need both sensors in user-space over video0 and video1. Also, i.MX31 datasheet says the (single) camera interface can handle up to two cameras (simultaneously), however, I haven't found any details how this could be supported in software, but I didn't look hard either, because I didn't need it until now. 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=AttachFiledo=gettarget=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. I understand your idea, but I don't see any
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
Hi Guennadi, On Thu, Apr 16, 2009 at 7:30 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote: 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. There are also some generic CMOS camera sensors, that support stereo mode, e.g., mt9v022. In this case you would do the actual stereo processing in host software, I think. The sensors just provide some synchronisation possibilities. And you would need both sensors in user-space over video0 and video1. Also, i.MX31 datasheet says the (single) camera interface can handle up to two cameras (simultaneously), however, I haven't found any details how this could be supported in software, but I didn't look hard either, because I didn't need it until now. Oh, interesting. I should look for mt9v022 datasheet. BTW, also on OMAP3 user manual you can see that two cameras could be opened at once (with different clock and so on), but it says also that only one camera's data could be handled by ISP in OMAP. I think the freescale CPU case could be the same condition.(sorry I'm not sure) 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
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote: My concern is all about the logical thing. Why can't we open device node even if it is not opened from any other process. The answer is of course because the other node is currently active, but I can understand the sort of confusion that the user might have: we have two independent device nodes, but only one of them can be active at any given time. So, in a way you're right, this might not be very intuitive. I have been working on dual camera with Linux for few years, and everybody who I'm working with wants not to fail opening camera device node in the first place. Actually I'm mobile phone developer and I've been seeing so many exceptional cases in field with dual camera applications. With all my experiences, I got my conclusion which is Don't make user get confused with device opening failure. I want you to know that no offence but just want to make it better. Sure, I appreciate your opinion and respect your experience, but let's have a look at the current concept: 1. the platform has N cameras on camera interface X 2. soc_camera.c finds the matching interface X and creates M (= N) nodes for all successfully probed devices. 3. in the beginning, as long as no device is open, all cameras are powered down / inactive. 4. you then open() one of them, it gets powered on / activated, the others become unaccessible as long as one is used. 5. this way switching is easy - you're sure, that when no device is open, all cameras are powered down, so, you can safely select any of them. 6. module reference-counting is easy too - every open() of a device-node increments the use-count With your proposed approach: 1. the platform has N cameras on camera interface X. 2. as long as at least one camera probed successfully for interface X, you create a videoX device and count inputs for it - successfully probed cameras. 3. you open videoX, one default camera gets activated immediately - not all applications issue S_INPUT, so, there has to be a default. 4. if an S_INPUT is issued, you have to verify, whether any camera is currently active / capturing, if none - switch to the requested one, if one is active - return -EBUSY. 5. reference-counting and guaranteeing consistency is more difficult, as well as handling camera driver loading / unloading. So, I would say, your approach adds complexity and asymmetry. Can it be that one camera client has several inputs itself? E.g., a decoder? In any case, I wouldn't do this now, if we do decide in favour of your approach, then only after the v4l2-device transition, please. But the mt9v022 case, I should need some research. Ok. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote: My concern is all about the logical thing. Why can't we open device node even if it is not opened from any other process. The answer is of course because the other node is currently active, but I can understand the sort of confusion that the user might have: we have two independent device nodes, but only one of them can be active at any given time. So, in a way you're right, this might not be very intuitive. I have been working on dual camera with Linux for few years, and everybody who I'm working with wants not to fail opening camera device node in the first place. Actually I'm mobile phone developer and I've been seeing so many exceptional cases in field with dual camera applications. With all my experiences, I got my conclusion which is Don't make user get confused with device opening failure. I want you to know that no offence but just want to make it better. Sure, I appreciate your opinion and respect your experience, but let's have a look at the current concept: 1. the platform has N cameras on camera interface X 2. soc_camera.c finds the matching interface X and creates M (= N) nodes for all successfully probed devices. 3. in the beginning, as long as no device is open, all cameras are powered down / inactive. 4. you then open() one of them, it gets powered on / activated, the others become unaccessible as long as one is used. 5. this way switching is easy - you're sure, that when no device is open, all cameras are powered down, so, you can safely select any of them. 6. module reference-counting is easy too - every open() of a device-node increments the use-count With your proposed approach: 1. the platform has N cameras on camera interface X. 2. as long as at least one camera probed successfully for interface X, you create a videoX device and count inputs for it - successfully probed cameras. 3. you open videoX, one default camera gets activated immediately - not all applications issue S_INPUT, so, there has to be a default. 4. if an S_INPUT is issued, you have to verify, whether any camera is currently active / capturing, if none - switch to the requested one, if one is active - return -EBUSY. 5. reference-counting and guaranteeing consistency is more difficult, as well as handling camera driver loading / unloading. So, I would say, your approach adds complexity and asymmetry. Can it be that one camera client has several inputs itself? E.g., a decoder? In any case, I wouldn't do this now, if we do decide in favour of your approach, then only after the v4l2-device transition, please. 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. 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. Regards, Hans But the mt9v022 case, I should need some research. Ok. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
Hello Guennadi, On Thu, Apr 16, 2009 at 9:06 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote: My concern is all about the logical thing. Why can't we open device node even if it is not opened from any other process. The answer is of course because the other node is currently active, but I can understand the sort of confusion that the user might have: we have two independent device nodes, but only one of them can be active at any given time. So, in a way you're right, this might not be very intuitive. I have been working on dual camera with Linux for few years, and everybody who I'm working with wants not to fail opening camera device node in the first place. Actually I'm mobile phone developer and I've been seeing so many exceptional cases in field with dual camera applications. With all my experiences, I got my conclusion which is Don't make user get confused with device opening failure. I want you to know that no offence but just want to make it better. Sure, I appreciate your opinion and respect your experience, but let's have a look at the current concept: 1. the platform has N cameras on camera interface X 2. soc_camera.c finds the matching interface X and creates M (= N) nodes for all successfully probed devices. 3. in the beginning, as long as no device is open, all cameras are powered down / inactive. 4. you then open() one of them, it gets powered on / activated, the others become unaccessible as long as one is used. 5. this way switching is easy - you're sure, that when no device is open, all cameras are powered down, so, you can safely select any of them. 6. module reference-counting is easy too - every open() of a device-node increments the use-count Honestly it is not that bad. but in situation of multiple processes trying to access camera devices like process A already opened video0 and process B tries to open video1, process B should face an error returns even though process B checked for video1 is already opened or not and verified that it is not opened. With your proposed approach: 1. the platform has N cameras on camera interface X. 2. as long as at least one camera probed successfully for interface X, you create a videoX device and count inputs for it - successfully probed cameras. 3. you open videoX, one default camera gets activated immediately - not all applications issue S_INPUT, so, there has to be a default. 4. if an S_INPUT is issued, you have to verify, whether any camera is currently active / capturing, if none - switch to the requested one, if one is active - return -EBUSY. 5. reference-counting and guaranteeing consistency is more difficult, as well as handling camera driver loading / unloading. Oops I forgot to say that we need to enforce legacy v4l2 applications to use VIDIOC_S_INPUT after opening device. And every S_INPUT issuing should come after G_INPUT like every set API in v4l2. So, I would say, your approach adds complexity and asymmetry. Can it be that one camera client has several inputs itself? E.g., a decoder? In any case, I wouldn't do this now, if we do decide in favour of your approach, then only after the v4l2-device transition, please. Of course. I didn't mean to disturb your transition job. Please do your priority job first. And about camera client with several inputs question, I will say that almost every 3G UMTS phone has dual camera on it. And we can consider every 3G UMTS smart phones have dual camera on it with soc camera solution. BTW, thank you for this conversation. It was a pleasure to discuss about this issue with you. Cheers, Nate But the mt9v022 case, I should need some research. Ok. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD 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
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello Guennadi, On Thu, Apr 16, 2009 at 9:06 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: 3. you open videoX, one default camera gets activated immediately - not all applications issue S_INPUT, so, there has to be a default. 4. if an S_INPUT is issued, you have to verify, whether any camera is currently active / capturing, if none - switch to the requested one, if one is active - return -EBUSY. 5. reference-counting and guaranteeing consistency is more difficult, as well as handling camera driver loading / unloading. Oops I forgot to say that we need to enforce legacy v4l2 applications to use VIDIOC_S_INPUT after opening device. And every S_INPUT issuing should come after G_INPUT like every set API in v4l2. Hm? Does the API require it? If not, I don't think we should inforce it. And what do you mean legacy v4l2 applications - which applications are not legacy? So, I would say, your approach adds complexity and asymmetry. Can it be that one camera client has several inputs itself? E.g., a decoder? In any case, I wouldn't do this now, if we do decide in favour of your approach, then only after the v4l2-device transition, please. Of course. I didn't mean to disturb your transition job. Please do your priority job first. And about camera client with several inputs question, I will say that almost every 3G UMTS phone has dual camera on it. And we can consider every 3G UMTS smart phones have dual camera on it with soc camera solution. No, sorry, this wasn't my question. By client I meant one camera or decoder or whatever chip connects to a camera host. I.e., if we have a single chip with several inputs, that should logically be handled with S_INPUT ioctl, this would further add to the confusion of using different inputs on one video device to switch between chips or inputs / functions on one chip. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
On Thu, 16 Apr 2009, Dongsoo Kim wrote: And about camera client with several inputs question, I will say that almost every 3G UMTS phone has dual camera on it. And we can consider every 3G UMTS smart phones have dual camera on it with soc camera solution. No, sorry, this wasn't my question. By client I meant one camera or decoder or whatever chip connects to a camera host. I.e., if we have a single chip with several inputs, that should logically be handled with S_INPUT ioctl, this would further add to the confusion of using different inputs on one video device to switch between chips or inputs / functions on one chip. Yes exactly. It was single chip with several inputs. that I intended to tell. but still don't get what the confusion you mean. Sorry ;-() Cheers, Wow, so, on those phone a dual camera is a single (CMOS) controller with two sensors / lenses / filters?... Cool, do you have an example of such a camera to look for on the net? Preferably with a datasheet available. Confusion I meant that in this case switching between inputs sometimes switches you to another controller and sometimes to another function within the same controller... 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
2009. 04. 16, 오후 11:56, Guennadi Liakhovetski 작성: On Thu, 16 Apr 2009, Dongsoo Kim wrote: And about camera client with several inputs question, I will say that almost every 3G UMTS phone has dual camera on it. And we can consider every 3G UMTS smart phones have dual camera on it with soc camera solution. No, sorry, this wasn't my question. By client I meant one camera or decoder or whatever chip connects to a camera host. I.e., if we have a single chip with several inputs, that should logically be handled with S_INPUT ioctl, this would further add to the confusion of using different inputs on one video device to switch between chips or inputs / functions on one chip. Yes exactly. It was single chip with several inputs. that I intended to tell. but still don't get what the confusion you mean. Sorry ;-() Cheers, Wow, so, on those phone a dual camera is a single (CMOS) controller with two sensors / lenses / filters?... Cool, do you have an example of such a camera to look for on the net? Preferably with a datasheet available. Oops sorry I didn't mean that. I just meant one single camera interface on Application Processor and two camera modules (sensor, lens, isp) connected. Sorry I explained badly. I considered this as single camera interface with several inputs. Confusion I meant that in this case switching between inputs sometimes switches you to another controller and sometimes to another function within the same controller... I think we don't need to worry about that if we can query camera inputs clearly. Cheers, Nate 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
Guennadi Liakhovetski g.liakhovet...@gmx.de writes:
Convert soc-camera core to a platform driver. With this approach I2C
devices are no longer statically registered in platform code, instead they
are registered dynamically by the soc-camera core, when a match with a
host driver is found. With this patch all platforms and all soc-camera
device drivers are converted too. This is a preparatory step for the
v4l-subdev conversion.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Ok, here goes the bad guy. Hit it hard, hit it as hard as you can.
Robert, I addressed your wishes from your previous comments, but kept the
semicolon rearrangement hunk. I think, it is better not to terminate a
define with a semicolon, if you like, we can make this a separate patch.
Yep, I'd like to. That's because of merge conflict with current patches through
arm tree. It will be easier for Eric or me to handle that other patch conflict,
thus letting the true v4l patch through.
@@ -754,20 +756,21 @@ static struct platform_device var = {
\
.platform_data = pdata, \
.parent = tparent, \
}, \
-};
+}
#define MIO_SIMPLE_DEV(var, strname, pdata) \
MIO_PARENT_DEV(var, strname, NULL, pdata)
-MIO_SIMPLE_DEV(mioa701_gpio_keys, gpio-keys,
mioa701_gpio_keys_data)
+MIO_SIMPLE_DEV(mioa701_gpio_keys, gpio-keys,
mioa701_gpio_keys_data);
MIO_PARENT_DEV(mioa701_backlight, pwm-backlight, pxa27x_device_pwm0.dev,
mioa701_backlight_data);
-MIO_SIMPLE_DEV(mioa701_led,leds-gpio, gpio_led_info)
-MIO_SIMPLE_DEV(pxa2xx_pcm, pxa2xx-pcm, NULL)
-MIO_SIMPLE_DEV(pxa2xx_ac97,pxa2xx-ac97,NULL)
-MIO_PARENT_DEV(mio_wm9713_codec, wm9713-codec, pxa2xx_ac97.dev, NULL)
-MIO_SIMPLE_DEV(mioa701_sound, mioa701-wm9713, NULL)
-MIO_SIMPLE_DEV(mioa701_board, mioa701-board, NULL)
+MIO_SIMPLE_DEV(mioa701_led,leds-gpio, gpio_led_info);
+MIO_SIMPLE_DEV(pxa2xx_pcm, pxa2xx-pcm, NULL);
+MIO_SIMPLE_DEV(pxa2xx_ac97,pxa2xx-ac97,NULL);
+MIO_PARENT_DEV(mio_wm9713_codec, wm9713-codec, pxa2xx_ac97.dev, NULL);
+MIO_SIMPLE_DEV(mioa701_sound, mioa701-wm9713, NULL);
+MIO_SIMPLE_DEV(mioa701_board, mioa701-board, NULL);
MIO_SIMPLE_DEV(gpio_vbus, gpio-vbus, gpio_vbus_data);
+MIO_SIMPLE_DEV(mioa701_camera, soc-camera-pdrv,iclink[0]);
\
- still broken
(should be iclink)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
@@ -917,6 +921,11 @@ static int mt9m111_video_probe(struct soc_camera_device
*icd)
to_soc_camera_host(icd-dev.parent)-nr != icd-iface)
return -ENODEV;
+ /* Switch master clock on */
+ ret = soc_camera_video_start(icd, client-dev);
+ if (ret)
+ return ret;
+
Well, I'd wish to keep only out return point where return value is given back
by another function (ie. have goto evid).
The reason behind is when debuggin, it's easier to put one printk(%d, ret),
and see what happened.
As the legacy mt9m111 style is :
- either return immediate value
- or if single occurence return func(foo)
- or error path with gotos
I'd like that return ret to be transformed into goto evid or the like.
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
@@ -794,103 +791,70 @@ static void scan_add_host(struct soc_camera_host *ici)
list_for_each_entry(icd, devices, list) {
if (icd-iface == ici-nr) {
+ int ret;
icd-dev.parent = ici-dev;
- device_register_link(icd);
- }
- }
-
- mutex_unlock(list_lock);
-}
-
-/* return: 0 if no match found or a match found and
- * device_register() successful, error code otherwise */
-static int scan_add_device(struct soc_camera_device *icd)
-{
- struct soc_camera_host *ici;
- int ret = 0;
-
- mutex_lock(list_lock);
-
- list_add_tail(icd-list, devices);
-
- /* Watch out for class_for_each_device / class_find_device API by
- * Dave Young hidave.darks...@gmail.com */
- list_for_each_entry(ici, hosts, list) {
- if (icd-iface == ici-nr) {
- ret = 1;
- icd-dev.parent = ici-dev;
- break;
+ dev_set_name(icd-dev, %u-%u, icd-iface,
+ icd-devnum);
+ ret = device_register(icd-dev);
+ if (ret 0) {
+ icd-dev.parent = NULL;
+ dev_err(icd-dev,
+
